5 ms·

Common Usability Mistakes

44 points by joez 17y ago

pierrefar 17y ago
The last tip should be the first. I'd also add UI testing on real users - not doing so is a common mistake!
thwarted 17y ago
As for #1, there's a good reason why login forms shouldn't persist form state: it leaks information. Showing the successful username leaks information that that username exists. It also is a subtle, possibly incorrect, hint that the user typed their username correctly. It is just as likely that the user typed their username wrong, and as the number of users go up, the chance of a one or two character difference between usernames is increased. If the username field is filled in, users might realize that they entered it wrong and won't fix it, but rather just retype the password, the wrong password for the account given.
- dnaquin 17y ago
  but regardless of whether the username is a correct one or not (in the database) - it should still persist in the UI.
  - thwarted 17y ago
    I thought I covered that, what follows the line you quoted is what I'm refuting. But there's another reason not to have it persist depending on the style guide for forms on your site (you are using a style guide, correct?). The style guide may say that incorrect fields be called out as incorrect, using an icon or a red border or whatever; the correct fields are not called out and do persist their values, so you only need to change the incorrect ones. With a login form, the entire form is invalid, so do you persist the values in all the fields but indicate that they're all bad? This may require a change in your site's style guide, to acknowledge the existent of entire forms that could have invalid data and are not in an editable state, but it's does require not just blindly persisting the login name.
- seldo 17y ago
  In the case of Yahoo's login form, the username is explicitly not echoed because people often have quite similar usernames, so they will try to login three times with the wrong username (it exists, it's just not their username) and then open a support ticket, etc. (It's Yahoo. This is the single most-used piece of UI on Yahoo other than the front page. Do you really think we don't do it because we're lazy? We never got around to persisting the username in 14 years of endlessly recoding the login page?)
ams6110 17y ago
I'd quibble a bit with #8, page titles. In my experience users rarely if ever look at the page titles in the browser; they don't really impact usability. If titles are important, pages should have a title banner or heading in the page itself, and not rely on users looking at the title up at the top of the browser window.
- spicyj 17y ago
  Who uses bookmarks still, and who sorts them alphabetically? Most people I know just remember the URL or search for the page on Google if they want it again. Googling "Doctor Who" gives the BBC site as the first result.
  - pbhjpbhj 17y ago
    I tag a lot of pages and put them in the "unspecified" Firefox bookmarks folder. Then I tend to just use awesome bar to find them again unless I'm after something from months back.
- ugh 17y ago
  I would argue that page titles are less important (and less looked at) for the page currently displayed, but as soon as tabs come into play they become immensely important. Titles are then the only way to identify the pages (plus, much of the time, favicons). And in that context I also do not agree with the suggestion in the article. Displaying only on which page you are currently will be good enough much of the time but not always. Finding a (short!) way of denoting which website you are on seems sensible to me. Now, honestly, this doesn’t apply to the page he mentions. You could indeed cut the BBC out. “Doctor Who” becomes the important information – but that identifier should definitely be preserved. Now, having titles like “Contact” or “<Title of Article>” – that would be a bad idea.
- wtallis 17y ago
  Useful page titles are absolutely crucial to tabbed browsing. For example, all the page titles here start with the string "Hacker News | ", which is completely redundant given the favicon, and could just as well go at the end of the title. As things stand now, my tabs seldom show more than the first three or four characters of the actual article title.
warwick 17y ago
There are a couple of things I disagree with. Colours have very different meanings depending on where the culture. The go-to example is how red is percieved in the U.S. (danger/bad) versus China (happiness/luck). With regards to website names in titles, URLs aren't displayed in some history lists. It's also important to remember the sizable chunk of the population that Googles everything and has no idea how to read a URL.
ax0n 17y ago
I think one of the most loathsome and ubiquitous UI sins is the "show more" style of navigation, where some ajaxy cruft goes and makes the page longer, propagated with more data. Paginated navigation (ex: flickr) is much friendlier and lends itself well to digging deep into the past whereas services such as Twitter, Brightkite, facebook and the like have practically solidified their role as platforms for ephemeral and trite chatter with one simple UI decision.
- ugh 17y ago
  Well. I don’t agree. At least for search this is a useful approach much of the time. Especially in cases where there is some non-transparent (e.g. not newest first or something like that) ordering of the results and if there are many of them. So this has its applications and calling it a “loathsome […] UI sin” is more than a bit over the top.
  - ax0n 17y ago
    Perhaps a little over the top, but I stand by my assertion that search is not an excuse for having no intuitive way to reach into the past on a timeline.
- forsaken 17y ago
  Twitter still supports pagination, it just isn't exposed in the UI. http://twitter.com/?page=20 http://twitter.com/?page=20
- omouse 17y ago
  Your screen is infinite. It isn't a book, it doesn't have pages. I appreciate the "show more" style of navigation because it fits how the screen is.
- blasdel 17y ago
  Except that every goddamn webapp completely fucks up pagination! They all implement the completely braindead pattern where the most recent N posts are on page 1, and then count up into the past. The resources found on "Page 2" get pushed down every time a new item is posted. It really couldn't be any shittier, and only a handful of people have ever implemented anything else. It also makes it impossible to usefully cache the whole page, which is just deadly for an API. At minimum, your page numbers should be in the same reverse order that your content is. A better implementation is to have the pages represent fixed periods of time (hours/days/weeks/months/years). http://www.dehora.net/journal/2008/07/20/efficient-api-paging-count-down-not-up/ http://www.dehora.net/journal/2008/07/20/efficient-api-pagin... is the only clear elucidation of this insanity I've seen. It's better to not expose paging in the UI than to cock it up like everyone else. Having real links to "Page 2" in Twitter's timeline would be a terrible idea -- it would be anything but a permalink, as the content would change completely 20 tweets later.
RyanMcGreal 17y ago
>2) Forgetting tab index Is that necessary with a properly structured form?
- Hexstream 17y ago
  Isn't tabindex part of what makes a form properly structured?
  - jackmoore 17y ago
    If you are separating your markup from presentation, it is unnecessary. Give your markup the property hierarchy and then arrange things via your presentation layer.
- nfriedly 17y ago
  No, and I've noticed a few occasions where someone used a tab index, then re-ranged things, but forgot to update the tab index. So rather than having a natural flow, the form went completely bonkers when I tried to tab through it.
seldo 17y ago
Pluralizing everything with an apostrophe isn't a usability problem, but boy does this article do it a lot.
known 17y ago
Microsoft hired 111 Psychologists since 2001 to improve its Software Usability http://www.myvisajobs.com/H1B-Visa-045-2009-SO.htm http://www.myvisajobs.com/H1B-Visa-045-2009-SO.htm
kwamenum86 17y ago
1) Good idea. Tangent: a token would NOT prevent a dictionary attack. It is pretty simple to mimic the functionality of a web browser using server side code including grabbing whatever token the web browser should be passing back. Doesn't mean you should not persist data though. 2) ...that dotted line is so ugly...but fine 5) html maxlength attribute? maybe this is too web 1.0 for some people 8) ...ut if you do not prefix your title with, por ejemplo, BBC then BBC bookmarks will be mixed with others. At least this way when sorted alphabetically bookmarks from the same domain will be grouped together and even sorted correctly amongst themselves.
- pbhjpbhj 17y ago
  re 8), couldn't you sort by bookmark folder, URL then by title?
  - kwamenum86 17y ago
    Yes :) I think there are a lot of ways the user can organize their bookmarks to get what they want and that is my point. I don't think the title matters.

44 points by joez 17y ago

The last tip should be the first. I'd also add UI testing on real users - not doing so is a common mistake!

As for #1, there's a good reason why login forms shouldn't persist form state: it leaks information. Showing the successful username leaks information that that username exists. It also is a subtle, possibly incorrect, hint that the user typed their username correctly. It is just as likely that the user typed their username wrong, and as the number of users go up, the chance of a one or two character difference between usernames is increased. If the username field is filled in, users might realize that they entered it wrong and won't fix it, but rather just retype the password, the wrong password for the account given.

dnaquin 17y ago
but regardless of whether the username is a correct one or not (in the database) - it should still persist in the UI.
- thwarted 17y ago
  I thought I covered that, what follows the line you quoted is what I'm refuting. But there's another reason not to have it persist depending on the style guide for forms on your site (you are using a style guide, correct?). The style guide may say that incorrect fields be called out as incorrect, using an icon or a red border or whatever; the correct fields are not called out and do persist their values, so you only need to change the incorrect ones. With a login form, the entire form is invalid, so do you persist the values in all the fields but indicate that they're all bad? This may require a change in your site's style guide, to acknowledge the existent of entire forms that could have invalid data and are not in an editable state, but it's does require not just blindly persisting the login name.
seldo 17y ago
In the case of Yahoo's login form, the username is explicitly not echoed because people often have quite similar usernames, so they will try to login three times with the wrong username (it exists, it's just not their username) and then open a support ticket, etc. (It's Yahoo. This is the single most-used piece of UI on Yahoo other than the front page. Do you really think we don't do it because we're lazy? We never got around to persisting the username in 14 years of endlessly recoding the login page?)

ams6110 17y ago

I'd quibble a bit with #8, page titles. In my experience users rarely if ever look at the page titles in the browser; they don't really impact usability. If titles are important, pages should have a title banner or heading in the page itself, and not rely on users looking at the title up at the top of the browser window.

spicyj 17y ago
Who uses bookmarks still, and who sorts them alphabetically? Most people I know just remember the URL or search for the page on Google if they want it again. Googling "Doctor Who" gives the BBC site as the first result.
- pbhjpbhj 17y ago
  I tag a lot of pages and put them in the "unspecified" Firefox bookmarks folder. Then I tend to just use awesome bar to find them again unless I'm after something from months back.
ugh 17y ago
I would argue that page titles are less important (and less looked at) for the page currently displayed, but as soon as tabs come into play they become immensely important. Titles are then the only way to identify the pages (plus, much of the time, favicons). And in that context I also do not agree with the suggestion in the article. Displaying only on which page you are currently will be good enough much of the time but not always. Finding a (short!) way of denoting which website you are on seems sensible to me. Now, honestly, this doesn’t apply to the page he mentions. You could indeed cut the BBC out. “Doctor Who” becomes the important information – but that identifier should definitely be preserved. Now, having titles like “Contact” or “<Title of Article>” – that would be a bad idea.
wtallis 17y ago
Useful page titles are absolutely crucial to tabbed browsing. For example, all the page titles here start with the string "Hacker News | ", which is completely redundant given the favicon, and could just as well go at the end of the title. As things stand now, my tabs seldom show more than the first three or four characters of the actual article title.

warwick 17y ago

There are a couple of things I disagree with. Colours have very different meanings depending on where the culture. The go-to example is how red is percieved in the U.S. (danger/bad) versus China (happiness/luck). With regards to website names in titles, URLs aren't displayed in some history lists. It's also important to remember the sizable chunk of the population that Googles everything and has no idea how to read a URL.

ax0n 17y ago

I think one of the most loathsome and ubiquitous UI sins is the "show more" style of navigation, where some ajaxy cruft goes and makes the page longer, propagated with more data. Paginated navigation (ex: flickr) is much friendlier and lends itself well to digging deep into the past whereas services such as Twitter, Brightkite, facebook and the like have practically solidified their role as platforms for ephemeral and trite chatter with one simple UI decision.

ugh 17y ago
Well. I don’t agree. At least for search this is a useful approach much of the time. Especially in cases where there is some non-transparent (e.g. not newest first or something like that) ordering of the results and if there are many of them. So this has its applications and calling it a “loathsome […] UI sin” is more than a bit over the top.
- ax0n 17y ago
  Perhaps a little over the top, but I stand by my assertion that search is not an excuse for having no intuitive way to reach into the past on a timeline.
forsaken 17y ago
Twitter still supports pagination, it just isn't exposed in the UI. http://twitter.com/?page=20 http://twitter.com/?page=20
omouse 17y ago
Your screen is infinite. It isn't a book, it doesn't have pages. I appreciate the "show more" style of navigation because it fits how the screen is.
blasdel 17y ago
Except that every goddamn webapp completely fucks up pagination! They all implement the completely braindead pattern where the most recent N posts are on page 1, and then count up into the past. The resources found on "Page 2" get pushed down every time a new item is posted. It really couldn't be any shittier, and only a handful of people have ever implemented anything else. It also makes it impossible to usefully cache the whole page, which is just deadly for an API. At minimum, your page numbers should be in the same reverse order that your content is. A better implementation is to have the pages represent fixed periods of time (hours/days/weeks/months/years). http://www.dehora.net/journal/2008/07/20/efficient-api-paging-count-down-not-up/ http://www.dehora.net/journal/2008/07/20/efficient-api-pagin... is the only clear elucidation of this insanity I've seen. It's better to not expose paging in the UI than to cock it up like everyone else. Having real links to "Page 2" in Twitter's timeline would be a terrible idea -- it would be anything but a permalink, as the content would change completely 20 tweets later.

RyanMcGreal 17y ago

>2) Forgetting tab index Is that necessary with a properly structured form?

Hexstream 17y ago
Isn't tabindex part of what makes a form properly structured?
- jackmoore 17y ago
  If you are separating your markup from presentation, it is unnecessary. Give your markup the property hierarchy and then arrange things via your presentation layer.
nfriedly 17y ago
No, and I've noticed a few occasions where someone used a tab index, then re-ranged things, but forgot to update the tab index. So rather than having a natural flow, the form went completely bonkers when I tried to tab through it.

seldo 17y ago

Pluralizing everything with an apostrophe isn't a usability problem, but boy does this article do it a lot.

known 17y ago

Microsoft hired 111 Psychologists since 2001 to improve its Software Usability http://www.myvisajobs.com/H1B-Visa-045-2009-SO.htm http://www.myvisajobs.com/H1B-Visa-045-2009-SO.htm

kwamenum86 17y ago

1) Good idea. Tangent: a token would NOT prevent a dictionary attack. It is pretty simple to mimic the functionality of a web browser using server side code including grabbing whatever token the web browser should be passing back. Doesn't mean you should not persist data though. 2) ...that dotted line is so ugly...but fine 5) html maxlength attribute? maybe this is too web 1.0 for some people 8) ...ut if you do not prefix your title with, por ejemplo, BBC then BBC bookmarks will be mixed with others. At least this way when sorted alphabetically bookmarks from the same domain will be grouped together and even sorted correctly amongst themselves.

pbhjpbhj 17y ago
re 8), couldn't you sort by bookmark folder, URL then by title?
- kwamenum86 17y ago
  Yes :) I think there are a lot of ways the user can organize their bookmarks to get what they want and that is my point. I don't think the title matters.