Skip to content

Comment on Common Usability Mistakes

Comments

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 doesn’t display favicons on tabs. (Edit: It’s true! It really doesn’t!)

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

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.

Page titles are most important in SERPs.

AboutSource Built by g1lg1l

Hackerly is an independent reader for Hacker News, built on the public HN API. Not affiliated with Y Combinator.