Doing It Like Everyone Else Does

blog
1

Jon Galloway called me out in a comment yesterday for advocating a non-standard approach:

This is a companion discussion topic for the original blog entry at: http://www.codinghorror.com/blog/2006/03/doing-it-like-everyone-else-does.html
2

John would be right if all web forms people encounter for the last ten years were the same and functioned the very same way. Which is not the case, of course. One input field makes you think much less than dozen of them.

3

Let’s attempt to summarize:

Steve “Don’t make me think” Krug said: Many clicks are not a problem as long as they are obvious.

Jeff Atwood says: OK, but less clicks is better than many if they are as obvious.

iow, improved usability is a good thing as long as it doesn’t mean reduced learnability.

I pretty much agree.

4

Of course we probably haven’t yet invented the UI equivalent of the hammer.

I rather feel that right now, the dirty shoe and extra-smashy-glass bottle are the currently accepted norms simply because we don’t know any better yet.

5

It’s a small amount of mindless work, which we’re replacing with pretty much the same amount of work, only it’s no longer mindless.

Well, that’s where I disagree, because I fill out mailing labels all the freakin’ time. My home address is practically embossed on my brain. I could type it in my sleep! And it’s way easier to type it all in one swell foop than it is to add the annoying mental overhead of a bunch of arbitrary textboxes and dropdowns. Let me type my FREAKIN’ ADDRESS, man!

Why should I have to TAB TAB TAB and deal with an individual drop down for the two-letter (!!) state and an individual box for the zip code when it’s just as easy to type “CA, 94707”? It’s a total no-brainer to me, and real friction is reduced. I type my address exactly the way I would (and do) in Microsoft Word.

This is where usability arguments come to a head. Neither one of us can “prove” which is easier without some data to support our positions.

6

I’m always amazed by the way ridiculous conventions are followed. Allot of the time it’s due to the big boys implementing it, so everyone else following.
My favourite example of a hugely ridiculous situation are Save dialoged in Windows (I don’t know about other OS’s. I know certainly allot of Java apps don’t work like this) Who the hell decided they should be modal? There is no reason what so ever for them to be modal in 98% of cases (made up figure). Yet almost all of them are.
I recently faced a challenge when implementing the UI for a booking service (crappy computing c/w) I decided, for my own experience, to design the UI as best I could. This ultimately lead to me designing a zooming style interface. However, despite various mock up tests, Fit’s Law calculations and the likes, and real world user tests I still faced opposition from several people who claimed I should stick to the standard calendar and fields input system. I will prove them wrong.

7

I think UI experimentation is not only desirable, but necessary

Try swapping the brake and accelerator pedals in your car and see where that gets you.

If you’re not collecting usage data, or your reason is “it looks better this way”, then you’re doing it wrong, and you should stick with the conventions.

Are YOU collecting usage data? Somehow I think not. On the other hand, Jakob Nielsen has been looking into this sort of thing for a long time. “Breaking design conventions” is one of his top ten mistakes in web design (a href="Top 10 Mistakes in Web Design)"Top 10 Mistakes in Web Design)/a

8

Having an iron-clad rule that you will never break a web convention isn’t what Nielsen is recommending here. Most designers/developers who fail to follow the conventions are so clueless that they don’t even know what the conventions are in the first place.

Try swapping the brake and accelerator pedals in your car and see where that gets you.

What I propose is more analogous to consolidating the RPM gauge into the MPH gauge. Or removing the RPM gauge altogether.

“Breaking design conventions” is one of his top ten mistakes in web design.

If you truly understand the conventions-- and their strenghs and weaknesses-- then you also know where it makes sense to experiment by modifying them. It’s a different scenario.

9

I’d also like to point out that very few users know about using the TAB key to advance to the next field. You laugh, but I see it all the time. Even from developers who really, REALLY should know better.

So for these kinds of naive users, the traditional “everything in a textbox” form works like this:

  1. Move mouse to street field.
  2. Click.
  3. Type street.
  4. Move mouse to city field.
  5. Click.
  6. Type street.
    (repeat for each and every field)

Compare that with an address textbox:

  1. Type my mailing address, exactly as I would in Microsoft Word.

Kind of a no-brainer, really.

10

Your interpretation of this article is completely wrong.

Neilsen says that 80% of the problems he identified 10 years ago are still a problem today. The other 20% accounts for bad practices that have fallen out of fashion, including “design crimes, such as splash screens that get between a user and the site they are trying to visit”.

Can you actually find a quote by Neilsen (or anyone else for that matter) that says it’s OK to futz around with interface conventions?

Just to reiterate: the page I linked to earlier contains Neilsen’s list of “The ten very worst design mistakes of all time” (his words, not mine). “Violating Design Conventions” is at number 8. His list of top mistakes for 2005 [*] also recommends supporting autocomplete functions as much as possible. As far as I’m aware, there are no browsers that support autocomplete in textarea elements. So by using text areas for address input, you’re making two major blunders.

On the general balance of things, I think I’ll be sticking with Neilsen’s findings for the time being. Perhaps I’ll change my mind when you publish the results of your own usability studies. But I doubt it.

[*] a href="http://www.useit.com/alertbox/designmistakes.html"http://www.useit.com/alertbox/designmistakes.html/a

11

Here’s an example of one convention that has changed, directly from Nielsen himself:

http://www.codinghorror.com/blog/archives/000376.html

“We know from several user studies that users don’t scroll.” (1996)

“As users got more experience with scrolling pages, many of them started scrolling.” (2003)

So in 1998, if I recommended designing pages that scrolled-- and I’ve always thought that the “design above the fold” guideline was ridiculous-- you’d tell me I was wrong because I was violating a convention.

I like Nielsen’s conventions a lot. But I am also unafraid to make a case that some conventions have worn out their welcome.

Anyone can read a list and blindly adhere to it. I think we need to do better than that. We should strive to understand the “why” behind the conventions and then make reasonable decisions about what we’re doing.

12

There are several form helps BHOs for IE and extensions for Firefox. Safari comes with form filling ability baked in. So what’s the argument here? That the address filling should be baked into IE and Firefox?

the pseudo-biometrics fingerprint reader by Microsoft comes with a nifty app. when you encounter a new login page, a dialog comes up and shows you what it assumes the username, password, and submit buttons to be. You can then assign the correct boxes if they are incorrect. (say the text box for “password” is named “passkey phrase” instead of “password”. The apps remembers which fields correspond to which data between sessions. So the next time, you just place your fingertip on the reader and it logs you in. I’m sure there are form assistants that perform the same kind of functionality.

13

A bit more on this:

http://www.informationdesign.org/special/spool_interview.php

The problem we’re trying to solve here is much more insidious. It’s an internal problem, not an external one. Our problem is that we believe in ourselves a little too much. And, as a result, we’ve stagnated.

Take the discipline of software usability. Software usability has been around, conceptually, since the late 1970’s, though some aspects of it can be traced to the late 1960’s and even earlier. So, it’s been something people have been thinking about for almost 30 years.

In the 1970’s and 1980’s, we saw huge advancements. Graphical user interfaces, the notion of mental models, the discussion of affordances, and techniques like discount usability testing and ethnographic research were all part of the landscape.

Yet, in the last ten years, what new advancements have we seen? Virtually none. The techniques and foundations that we use today have remained the same for more than ten years.

Take the two pillar stone questions of usable design:

Users: Who will use your design?
Tasks: What do they want to accomplish with it?

Everyone can agree that understanding users and tasks are essential to good design. Yet, we’re still using the same techniques today that we were using 15 years ago. And these techniques are deeply flawed. They don’t correctly identify users and they don’t bring out the tasks.

We’ve avoided the guideline approach, primarily because it’s our philosophy that we are really still too ignorant to know what the right guidelines are. We haven’t found a set of guidelines that really matches what is happening in the real world.

Early on, we discovered that you could take any guideline and turn it into a hypothesis. For example, take the commonly-found guideline that you should ensure your pages load in 8 seconds or less. Well, we can test this guideline with the hypothesis that any site with the average page-load time is more than 8 seconds will be less usable than sites with less than 8 seconds average.

The beauty of our work is that we collect a lot of data about a lot of sites. And we can test hypotheses like this extremely simply. Sure enough, when we look into our data, we find that, by any measure of usable we can come up with (such as task completion, user satisfaction, purchases, or lead generation), there is no difference between the fast loading sites and the slow loading sites. No matter how many sites we look at, we can’t see any pattern that supports this guideline.

Some people don’t like our approach. They want to just have a set of rules to work within. Jakob’s guidelines philosophy will work great for them.

14

A no-brainer? You seem to be assuming that users who are unfamiliar with the use of the tab key are nevertheless competent users of Microsoft Word.

In my experience, novices are just as bad at using the return key. Instead, they press the space bar repeatedly until the cursor wraps to the next line. In fact, it’s better to produce web forms that don’t require users to press the return key at all. Otherwise they’ll start using it in single-line input fields, submitting incomplete forms as a result.

If you actually conducted some usability studies, I think you’d find that separate single-line text input fields are both easier to use and less prone to error, given the availability of autocomplete and autofill functions.

But go ahead and prove me wrong if you can :smiley:

15

Jeff,

Alan Kay touched on some of those ideas during a talk he gave. I’m assuming it was a recent talk.

http://www.windley.com/archives/2006/02/alan_kay_is_com.shtml

We’re still here.
http://lostgarden.com/uploaded_images/Evolution-LateBusinessEra-722820.jpg

But, we’re moving towards here.
http://lostgarden.com/uploaded_images/Evolution-ProductDesignEra-767548.jpg

http://lostgarden.com/2006/02/software-developments-evolution.html

16

users who are unfamiliar with the use of the tab key are nevertheless competent users of Microsoft Word.

I think so, considering that pressing ENTER is fundamental: it’s how you send an instant message, or end a paragraph in any editor you’ve ever used (including such luminaries as Notepad, and Outlook Express). Both extremely common activities.

TAB isn’t even remotely as common.

17

“Breaking design conventions” is one of his top ten mistakes in web design

And yet, 20 percent of the these conventions have changed in ten years, by Nielsen’s own admission:

http://news.bbc.co.uk/1/hi/technology/4061093.stm

Dr Nielsen has looked back at a decade of work on usability and considered whether the 34 core guidelines drawn up back then are relevant to the web of today.

“Roughly 80% of the things we found 10 years ago are still an issue today,” he said.

“Some have gone away because users have changed and 10% have changed because technology has changed.”

18

Just as a note, known even less than TAB is Shift+TAB to move to the previous control.

" I think UI experimentation is not only desirable, but necessary

Try swapping the brake and accelerator pedals in your car and see where that gets you."

"1. Have a complete understanding of the current convention and how it arose
2. Have a good, reasoned argument for deviating from the convention
4. Make decisions based on the usage data "

Would fail at 1, 2 and 3. He’s not suggesting things are blindly changed. More that conventions be challanged. Change round the pedals, or the OK and Cancel buttons, and you have no reason to and break habituation. Change how a UI works so that it is modeless, or uses a Ribbon UI, or restructure the workflow to be more productive, and you have a benifit in an environment which favours new habits to be easily formed.

To reitterate a point touched on earlier, one of the biggest problems is that whilst most people are taught conventions (Alot aren’t even taught that. My computing class recommended people use a splash screen menu when it clearly shouldn’t be) alot of people don’t know why. They are also treated as stupid if they do question them (mainly the amature web designing community, based on observation) and very rarely given any good guidlines as to why these are conventions.

It is only through people who are educated in an area can we find innovation. And it is only by challanging existing concepts can we progress. What was wrong with the command line days? What was wrong with Windows XP? What is wrong with Windows Vista? Keep asking, keep experimenting, and you will find gold.

19

My 2 cents about this particular input case (Address). I think this is what happens when you write an address on an envelope:

  1. You write the address in almost any way you like, FROM ANY part of the world, TO ANY part of the world, and you can make a lot of mistakes, especially in the street/number, for example “251/ac Unioxn Drisve, 50100, Chicago, I, USA”
  2. Some electronic (or human) device can usually “parse” the State/Town/ZIP that you wrote, despite your mistakes, and your envelope reaches Chicago (USA)
  3. Eventually, according to the ZIP Code (hopefully) your envelope is given to the best address normalizer for the ZIP 50100 Area: mailman Joe Smith, who’s been delivering mail in Chicago for 20 years, and knows perfectly that “Unioxn Drisve” is indeed “Union Drive”
  4. Your envelope is delivered

The same thing, with a “distributed system” running for a long time, happens with mailman Olaf Gunnerson in Stockholm, Sweden, mailman Mario Rossi in Rome, Italy, and mailman Cho Zhang in Beijing, China.

Unfortunately, this does not happen in your webpage’s Address TextArea or in your DataBase…

I agree that 20 textboxes/comboboxes are HELL to type just one address, but the “one textarea, just type whatever you want, then I’ll try to check” approach is not the best one.
For a UI experimentation, I would start with 3 large singleline textboxes, with a sample/hint right to each box, and see what happens. Something like:
[] street
[] city, zip
[________________________________] state/country

20

One thing I think you’re forgetting: The address field EVOLVED into what it is today. It started out as a big text area, but when people saw what kind of bad, incomplete data they were getting, they changed it to separate, user hand-holding fields.