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.
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.
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).
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.
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.
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.
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.
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.
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?)
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.
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.
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.
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.
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.
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.
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.
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.
Firefox history shows only page titles and I am always glad for the "Hacker News |". Though I wouldn't mind it being shortened to "HN|". But then again, page titles are prominently picked up by google and the ilk, so I suppose that will have to factor into the decision somewhere.
Not true, it shows favicons too in the default which makes the HN bit superfluous IMO. Also if you want listings by domain then choose the "date and site" view. Simples.
I'd agree that pages without a title banner or heading are probably making a usability mistake, but I disagree that titles don't impact usability. When done correctly, correct titles make a site much more usable. Usability doesn't just apply to the page that a particular user is on, but to the site as a whole. For starters, I thought the article's example of bookmarks was a decent one.
Maybe I'm not the typical user, but I personally find page titles extremely useful when using a back button. I get annoyed when I expand the back history and just see the site name for every entry. I've also noticed a trend in browsers like Chrome that use the title as an autocomplete hint in the address bar.
Also, beyond the SEO importance highlighted by the article, if you have multiple pages indexed in a search engine, it makes it much easier for an actual user to locate a particular page of interest. As a side note, I am actually more inclined to click a search result if the title looks like it was made for me, seems to match my intent, and looks like it was not just constructed for a search engine.
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.
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.
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.
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.