

Common Usability Mistakes - joez
http://blog.webdistortion.com/2009/10/01/9-usability-mistakes-even-the-big-boys-make/

======
warwick
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
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.

~~~
blasdel
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-
pagin...](http://www.dehora.net/journal/2008/07/20/efficient-api-paging-count-
down-not-up/) 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.

~~~
ax0n
I would totally get behind one page = a given time window, as long as the time
window is configurable, or at the least, page n is an offset from what was the
first item on the first page when you started paging.

------
kwamenum86
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
re 8), couldn't you sort by bookmark folder, URL then by title?

~~~
kwamenum86
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.

------
thwarted
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
_but regardless of whether the username is a correct one or not (in the
database) - it should still persist in the UI._

~~~
thwarted
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
Pluralizing everything with an apostrophe isn't a usability problem, but boy
does this article do it a lot.

------
RyanMcGreal
>2) Forgetting tab index

Is that necessary with a properly structured form?

~~~
Hexstream
Isn't tabindex part of what makes a form properly structured?

~~~
jackmoore
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.

------
ams6110
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.

~~~
wtallis
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.

~~~
ugh
Safari doesn’t display favicons on tabs. (Edit: It’s true! It really doesn’t!)

~~~
brodie
It also strips out common prefixes among tab titles that would cause the tab
title to become abbreviated. It's pretty clever, I think.

~~~
blasdel
Safari also uses some pretty clever tricks when abbreviating to preserve as
much information as possible -- it uses interior ellipses sometimes instead of
trailing ones, and I think it has a blacklist of low-content words to strip
out first.

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

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

