115. sxsw

Paul Boag

On show 115: Lessons learnt at SXSW, Garett Dimon on form design and how to find usability test subjects.

Download this show.

Launch our podcast player

News and events | Lessons learnt at SXSW | Garrett Dimon on form design | Listener feedback

News and events

Microsoft launches beta of Internet Explorer 8

The big story over the last couple of weeks has been Microsoft’s release of Internet Explorer 8 as a beta. This has sparked a flurry of posts from various bloggers on the pros and cons of the new release. However the two that caught my attention were Kevin Yank at Sitepoint and Roger Johansson.

In short, IE8 looks like an impressive update with significant improvements in standards support. It would appear we can finally say good by to HasLayout, while at the same time welcoming decent CSS table support. This will open up a lot of possibilities for layout.

There are too many updates to go through here so I would encourage you to check out "what’s new in internet explorer 8" over at the MSDN blog. You might also want to look at the Internet Explorer 8 readiness toolkit that tells you all you need to know about the new browser.

Designers agnst

There seems to be a lot of designer angst flying around the tubes this week including two posts on A List Apart and one at ideas on ideas.

As designers we seem to spend too much time fretting over the creative process, always looking for inspiration and techniques to improve the quality of our work. Andy Rutledge piles on the pressure in a fascinating article about creativity where he redefines the word. A second post on A List Apart twists the knife further by arguing that as designers we need to be superhuman obsessives, willing to work late into the night to produce the truely exceptional.

It maybe the case that to be a truely outstanding designer we need to live in a world of unrealistic personal expectations. However, personally I like the down to earth reality of "Six suggestions that can make you a better designer." In this post Eric writes…

Your project doesn’t have to do everything. It doesn’t have to win awards, make you look good, or have a wry subtext. Getting something simple to work is hard enough. Concentrate on the basics, and see if your idea holds up when shown to the audience.

In my opinion there is too much written about being outstanding and not enough on just being better.

Usability challenges associated with web applications

The final story of the week is a post by Jared Spool. Jared is a truely exceptional usability expert and I can highly recommend his Podcast. He is also an excellent speaker that I had the pleasure to hear again this year at SXSW.

The reason I mention him is because of a post entitled "3 important usability challenges for designing web applications." What I find so refreshing about this post is that it focuses on the web applications we all have on our sites rather than the trendy web 2.0. apps we hear so much about.

Sites like delicious, gmail, of even the up and coming getsignoff (shamless plug!) are somewhat unusal in terms of web apps because the whole site is the app. Most web applications are a part of a greater whole. They are contact databases on corporate intranets or ticket reservation systems on airline sites.

The challenges associated with these types of web apps are different from their trendier cousins and Jared addresses these problems in his post.

It is definately worth reading if you have web applications on your site.

Back to top

Feature: Lessons learnt SXSW

Marcus shares his impressions of SXSW and the lessons we can all learn.

Back to top

Interview: Garrett Dimon on form design

Paul: So joining me today is Garrett Dimon. Good to have you on the show. How are you?

Garrett: Pretty good.

Paul: Now I have to say I’m really excited about having you on the show because I have to say I’ve become a bit of a fan. I’m sorry to admit this and I know it’s horribly embarrassing when people say things like this to you. But ever since you’ve released your website which so impressed me I’ve been kinda following your work since then, some of the stuff you’ve been doing. You’re everything I’m not. You’re minimalistic, you’re clean and considered and well thought through while I’m chaotic, over the top and brash. That’s why I’m attracted to your work I think because you’re the
opposite of me.

Garrett: Everything I do from my apartment and everything is just the less I have, the simpler things are, the better things seem to turn out for me.

Paul: If only I could live that way. I’m just not… my brain just doesn’t function in that way. But that’s really cool. So I wanted to get you on the show to talk about forms of all things. It’s something that we’ve touched upon a couple of times in the show but mainly as passing comments in news stories and things like that. In actual fact a couple of the times we have mentioned it, it’s your name that’s come up. It seems to be something that you write a lot about from time to time. You see different articles popping up in different places. Why forms? What is it about forms that seems to attract your attention?

Garret You know it’s hard to give an answer. I really don’t know. But in thinking about it probably my first bet is that I really don’t consider myself to be a designer per say in terms of the more traditional, more artistic design orientated type of visual designer. But with forms it’s more about the interaction design and the more logical aspects of design which are things that definitely work better in my head. So how do you write error messages; how do you label fields; what order do they go in; how should they be grouped; do they go on one page or two pages. Some of the more logical, more interaction issues. Then using what little design knowledge I have to supplement that and make it visually easier to digest the form and see and understand the pieces of it. Basically to me it’s basically the one thing that I feel like I can comfortably design and layout because there’s a lot more to it than just the aesthetics.

Paul: Yeah that kinda makes sense. Why do you think forms are so important in a way? It’s obviously something you consider important but there doesn’t seem to be huge amounts written on the subject. What is it that makes them worth of that kind of attention as far as you’re concerned.

Garrett: I think part of the reason is precisely because they don’t get enough attention. Any real attention you see to forms, I haven’t seen it recently but it’s how do you skin your forms to completely control how they look. Which to me is one of my huge pet peeves. It seems like such a waste of time. To worry about what the forms look like in the browser as opposed to how they actually work, I’m thinking if you’re going to invest the time worrying about how your forms looks it’s probably better to spend that time worrying about how they are going to work. Are you using the right form field for that job and some of the more critical things about forms. Really forms, especially now with web apps being what they are, forms are such a huge part of your everyday interacts. Things like efficiency, learnability, accuracy, all the vasts of usability that matter. It’s not just a matter of “Is this form efficient?”. Well it’s easy to make an efficient form but it’s not necessiarly going to be something that somebody else could learn and use or you might be able to learn it but will you remember how to use it next time you come back. Balancing all the different kind of vasts of usability that Nielsen identifies and really working them out so that you don’t dumb the form down so that it’s so simple that anyone can use it that it’s just a cumbersome process to fill out. Really kind of massaging it with all those things in mind.

Paul: You’re right when you say that in the world of web applications certainly forms are amazingly important but they pretty much appear on every site. It’s hard to thing of a site where they don’t appear.

Garrett: Well you think about a magazine site or anything like that where it’s more content orientated, it’s definitely a lower priority.

Paul: Yeah but you’ve still got contact us forms and things like that.

Garrett: Yeah, comment forms and…

Paul: Ok. So you touch there on the fact that one of your pet peeves was the fact that people worry about the design of their forms rather than how usable they are. What over common mistakes are you seeing from people about how they design and implement forms?

Garrett: I think there’s a whole slew of them and I think a lot of it is just worrying about the wrong things or not giving thought to things that matter. My main reason with the designing the form fields is that people are used to seeing form fields and what they look like in their browser, in their native rendering. Sure as a designer having pixel perfect control would be nice but I would hope that most of us who are now designing on the web would have forgone that state of mind where we have to have complete control over everything, it has to look exactly the way we want. A lot of time not only is it a waste of time but it actually hinders usability when those form fields don’t look like what someone expects a form field to look like or button for that matter. When the design becomes design for design’s sake it actually hinders usability in addition to just wasting time. When I initially started developing things it was all about consistency because consistency is easier to implement. If every form field looks the same, behaved the same, is the same size etc. it’s easier to implement because you use the same CSS and you don’t have to put as much thought into it. So while consistency is valuable there’s definitely an aspect of context that a lot of people don’t necessarily pay attention to. In some situations, I think 37 Signals have done a good job on this, they’ll make some fields larger than others relative to the size. In particular in Backpack, their headings aren’t just a form field they are actually bolder and look a little more like a header. They are a little larger font than the body of the note. It adds a little bit of context so that it’s more intuitive as to what the purpose of that field is. There’s a lot of different ways to do it. That’s just one of the more tangible ones. Basically the mistake being focusing too blindly on making everything consistent when there are appropriate situations to break the rules and use context to make some changes. Another one is just dumping a whole form onto the page without breaking it up into logical sections or groups. A lot of times people are afraid of making a form any longer visually because of scrolling. While you don’t want somebody to scroll 80 screenfuls, scrolling one versus eight screens is neligable.

Paul: So you wouldn’t suggest splitting forms across multiple pages then?

Garrett: Well there’s definitely context for that if it’s appropriate. Amazon is a great example there because you’ve got your payment screen and your address screen. It actually can be a fairly complex process but the time you’ve selected several addresses or updated an address, updated a payment method, changed the items in your cart. As you’re jumping around the different screen’s you definitely wouldn’t want all that interaction to try and be contained on one screen. It depends on the size of the form and the context of the form and how interactive it can be, how many potential branches off of that path are there to take. Another would be poor labelling. A lot of the time people label things. This goes back to just naming conventions in general. Just basic information architecture stuff. Whether it follows a corporate naming convention that may not be the right word for somebody that’s not inside the company wall or just simply flat out the wrong word for international [???]. Really anything. Just not putting enough thought into the label. The first thing that pops into your head isn’t always the right thing. Using the wrong kind of inputs so a lot of times whilst… and I have no idea in the world why people would do this… People who for instance who use checkboxes when they won’t use radio buttons and instead they write Javascript to control the radio button. Checkboxes as if they were radio buttons. Thinks like that where I just have no idea what these people were thinking in some of these situations. Just a lot of things like using a radio button or having a yes/no radio button where a checkbox could work. Multiple select lists which are an absolutely terrible interface element to use because a lot of people don’t know you can control+click. If there are small lines and you accidentally slip off that control key and click on a new one, it’ll select that new one and erase all your other selections in that list. There’s different things that kinda get abused and misused in situations where they really aren’t necessiary. A much simpler solution usually exists.

Paul: Yeah. I’ve seen the radio button, checkbox problem and it’s always very amusing.

Garrett: And vice-versa. Where it’s radio buttons and they try and make them checkboxes just because they think it looks prettier sometimes.

Paul: How bizarre.

Garrett: Which I guess is another great example – over using Javascript in forms. It’s one of those things. I don’t know where I heard it but the best description I ever heard of Javascript, Ajax or any of that stuff is that it’s really a spice. If you’re cooking you wouldn’t just dump a whole bottle into your pot. Or you wouldn’t start with a bottle of curry and dump it into a pot and say “OK, now what are we going to make?” You would decide what you are going to make and then think “You know this could really use a bit of curry here”. A lot of people just don’t use Javascript as a spice. It really starts to define the experience and in a lot of situations actually makes it worse or more confusing.

Paul: I presume you would encourage some use of Javascript for example. Things like doing some client side validation as long as it falls back on a server side validation. That kind of thing.

Garrett: Yeah absolutely.

Paul: OK so let’s turn that question around. We’ve been talking very much about the mistakes that people make, but what advice would you provide people about approaching forms? What are the things that they should be doing rather than shouldn’t be doing? I know that in some ways this is going to overlap but is there a particular approach that you take?

Garrett: One of the biggest things I guess is when ever; doing consulting for custom applications or things like that a lot of times we don’t realize that a lot of the complexity from forms comes from the complexity of the business. Whether it’s somebody doing markup or somebody designing a form, a lot of times you know if a business analyst or whoever creates these form requirements and says “here you go design this form.” It has 100 fields and this is out contact form and 80 of the fields are required. A lot of times people just say “okay, it’s my job to implement this. In my experience a lot of business analysts aren’t really familiar with principles of the web and what makes sense. A lot of times the real effort to creating a good form is in educating everybody else about what would be involved. Pushing back in situations like that. Not in a bad way but in a very professional productive way. “You realize that this is going to be a really bad contact form. Nobody’s acutually going to use it. I’ve even heard response like “That’s the point. If people contact us we have to take time a respond to them.” The problem isn’t with the form there, its with underlying things. Obviously that’s a little bit of an exaggeration. The idea is that the best place to start with forms and any kind of interaction like that is with the principles that are underneath there kind of guiding it. With the issue tracker that I am developing, I started out parring back the process of what’s the lifecycle of an issue. Trimming out parts that I didn’t think would really be necessary. I was just looking at it in the context of the lifecycle. I hadn’t even thought about what are the forms going to look like? How am I going to communicate this lifecycle within the context of the application? When it came down to the point when I had to explain how that actually worked, because I had trimmed the proccess and the lifecycle down so much, and it was only 3 steps really, I was able to translate that concept directly into the interface. If I had never actually gone and trimmed the lifecycle down and it had 6 different states that were very cross dependant and this state only is an option when you are in this state… It gets so complicated that even if I could express it in an interface, the code to build it would have been so absolutely unweildly that I could have never created a natural and intuitive inteface. So, I guess really challenging the underlying things rather than just thinking about the things on the surface. And then really just look at every form on it’s own. In it’s own light. What is the goal of this form? Should it be laid out like a traditional form? With one set of “label” “field” all the way down the page and a submit button. Should there be other buttons? Another thing when, I have a fairly consistent model that I am using when I am designing forms in my new application. The main form is for submitting issues and that one form is probably going to get 80% of the useage in this whole system. That and commenting. In the context of submitting issue alot of times you will be in a meeting capturing things as people are talking, capturing issues cause it’s an issue tracker. You want to be able to capture and issue, save it, and move on and capture another one really in kind of rapid succession. So I added an extra button at the bottom that I wouldn’t put on any other page, cause it doesn’t make sense, to save and add another. So it immediately saves that one and takes you back to the data entry screen. You can just continue in a circle and just keep on adding and adding. So really looking at forms and thinking about how are people going to be interacting with this? What are they doing in the real world while they’re using this form? Are they copying data from another application into here? Are they in the middle of a meeting just capturing items in rapid succession. What are they doing? Are they just quickly jotting it down from their iPhone? Understanding that context helps illustrate ideas and different sublte variations that you can do to forms and make them very very practical without adding a whole bunch of extra overhead on the implementation.

Paul: I remember you wrote an article at one stage redesigning eBay registration form. When you wrote about that you talked about the fact that this is a registration form. It is a one off form, and all of the ways that that then informed the way that you built the form. How it affected the positioning of things, and the layout and things, simply because it wasn’t going to be a form that people were using again and again. That’s the same kind of context that you are talking about.

Garrett: Yeah exactly. There’s always a different context to a form and it matters. It is easy to overlook it but that context, and really any design for that matter, context is so important but it is something that…I think that main reason that people don’t pay as much attention to context is because it requires a lot of extra work. A lot of times it’s easier, and it makes sense for kind of a first pass, to make every form look the same. It takes a lot more work to go through and re-invent the wheel every time you look at a form even though, re-inventing the wheel is probably a little bit extreme, to really give it some custom attention. Some tender loving care, just takes a lot more effort that lot of projects don’t have time for.

Paul: You mentioned earlier 37signals that you liked some of the stuff that they were doing. Are there any other good examples out there of forms that you really think are getting it right and are worth us having a look at?

Garrett: Probably the one thing that always jumps to my mind any time anybody asks me about forms is all of the work that Luke W is doing. I hate trying to butcher his name. The stuff that he is doing and hopefully his upcoming book is just really incredible. In depth. He’s done a lot of eye tracking research about label placement and button placement and he’s talked extensively about primary and secondary action buttons. All of his stuff is really incredible.

Paul: So where can people find out about him?

Garrett: I always just google for Luke W to get to his site. Functioning form is his blog. He’s the first hit for Luke W.

Paul: I’ll add it to the show notes. People can get to it via that. That’s interesting. I must admit I hadn’t hear of him so I’ll definitely check that out.

Garrett: He’s one of the, I don’t know his exact title, but he works at Yahoo and he’s got a plethora of presentations about form design and all of the kind of stuff. Really sharp guy.

Paul: And he’s writing a book you say as well?

Garrett: Yes he is for Rosenfeld Media. It’s due out early 2008.

Paul: Excellent. So just to finish us off. A little bit of bile at the end of the interview. Is there any forms that you want to name and shame? Any site that do things really badly that we can all go and laugh at and sneer at?

Garrett: You know that’s a very tough thing to do.

Paul: (lauging) So many out there.

Garrett: Well there are so many out there. But at the same time too there are a lot that seem like they could use improvement but they’re companies that are investing a lot of money and research to improving their forms. So I’m hesitant as an outsider, somebody who isn’t exposed to some of that data, to try and call them out, when they’re probably acutually right on the money. The top two that come to mind that I know are successful are eBay and Amazon. I think Amazon succeeds on the interaction design of their buttons and the flow of their checkout is natural and intuitive but I feel like a lot of their page designs, and it could be a very intentional thing in order to, although I hate thinking that Amazon would acutually do that, to kind of trap people and confuse them almost. If you look at each page in and of itself I think there is a lot of design things that they could make adjustments to that would make the pages easier to understand and comprehend at a glance. I feel like right now their design of their checkout process, or most of their site in general, is very busy and intense. It’s difficult to focus on one element because there’s so many elements. There is very little very intuitive page hierarchy within each page. And they’ve made leaps and bounds, watching the site evolve over the years. But, it still feels like there’s a lot more room for some design consistency for them to introduce. They’re slowly getting there. eBay is another one who, I know they acutually, I forget their CEO’s name, but she declared 2008 the year of user experience at eBay. They’ve acutually invested a lot in trying to improve their forms and really their user experience period. eBay is one that I’ve only successfully purchased something on there once and everytime I try to swim through there I get lost and just give up. Too me any situation like that is just begging for help. I think any form, even the best of the best, even 37signals, everybody is still learning. This is all so new that even the best forms have so much room for improvement. Even my stuff, I come a month later and say “what was I thinking there?” There’s so much work that needs to be done. I think that Luke’s work that he’s doing is probably some of the best and most important work that we’ll see in forms in the near future. He’s starting to really put down facts about what really is good and bad and why it is good and bad. Up until now most of us have just been pontificating based on “well this form is hard to fill out because of errors.” Or you know, the form breaks, or the error message isn’t helpful. Very obvious things. He’s tracking the much more subconcious things that until now nobody’s really dug into and made claims about. It’s kind of a cop out on your question.

Paul: No No. You gave two example there and you gave constructive reasons why they should be improved or could be improved. No I don’t thinks it’s a cop out. You’re just so much nicer than I am. You didn’t go for the jugular that was the only thing. Garrett it’s been great to have you on the show. I think that you’ve given us some real good hints to get going I guess and make some imrovements. It was good to talk to you.

Garrett: Yeah likewise.

Paul: No doubt we’ll get to talk again soon before too long. Especially when you’re issue tracker comes out. We’ll have to get you on hear all about that.

Garrett: Yeah. I’m hoping it will be sooner rather than later but it’s definitely tough to balance the feelancing and paying the bills and making progress on it.

Paul: I know exactly how you feel, we’re doing the same thing at Headscape at the moment. It’s always difficult. Client work is so tempting because it pays the bills here and now.

Garrett: Yup, exactly.

Paul: Okay good to talk to you and we’ll talk again sooon.

Garrett: Sounds good.

Thanks to Lee Theobald for doing the transcription

Back to top

Listeners feedback:

Finding usability test subjects

Our audio question comes from Clare who asks…

"Where do you find your test subjects for more formal user testing"

It can be hard to find good test subjects and I am not aware of any agencies out there that source people for you (although I am sure somebody will correct me).

I think it is worth stressing that finding users who match the demographic of your target audience is not a huge concern. As Steve Krug points out in his book "Don’t make me think" most problems are encountered by any user. That said, where possible it is good to find people that roughly match the specification.

To be honest our approach it is very adhoc. It normally consists of both Headscape and the client scrambling around to see who you can find. The client often has "tame" customers they can ask and we fallback on family, friends and other clients for recommendations.

I should also say my local church has been very handy! A church seems to have a good cross section of ages and backgrounds and an advert in the church newsletter often does the trick. Equally advertising in your local newspaper can attract people, but you have to be willing to pay for their time.

Accessible tables

This week’s email is from Daniel and takes the form of a recommendation rather than a question…

"Could you cover the tips discussed in this article [about accessible tables]? I have seen a lot of tables on the web. Almost none of them uses any of these tips."

The article Daniel is refering to can be found on the Opera developers site, which is a great resource covering all aspects of web development (not just stuff relating specifically to Opera). The specific post looks at how to markup data tables in an accessible format. Since designers have stopped using tables for layout they have become largely ignored. However, if not marked up correctly they can prove a real problem for speech readers. A simple table such as this…

TuesdayFree timeMeeting

…can become impossible to understand when read back because it is read in a linear fashion…

Day, AM, PM, Monday, Meeting, Travelling, Tuesday, Free time, Meeting

However, if marked up correctly it suddenly makes sense…

  • Day Monday AM Meeting
  • Day Monday PM Travelling
  • Day Tuesday AM Free time
  • Day Tuesday PM Meeting

Great find Daniel. These are tips we should all be implementing.