Commentary on top 10 blog usability mistakes - epilogue

Commentary on the top 10 blog usability mistakes by Jakob Nielsen (2005) is now coming to an end and I want to give my own personal opinions on which blog usability mistakes you must avoid (important), which mistakes are not as critical but go against good usability practice (recommended) and which you can ignore from usability point of view (ignore):
  1. No author biographies: ignore - you can safely ignore this from usability point of view.
  2. No author photo: ignore - you can safely ignore also this from usability point of view.
  3. Nondescript posting titles: important - you must avoid making this mistake.
  4. Links don't say where they go: important - you must avoid making this mistake.
  5. Classic hits are buried: recommended - try to avoid making this mistake.
  6. The calendar is the only navigation: important - you must avoid making this mistake.
  7. Irregular publishing frequency: ignore - you can safely ignore this from usability point of view if you post "on hiatus until" messages when necessary and encourage users to subscribe feeds.
  8. Mixing topics: recommended - try to avoid making this mistake.
  9. Forgetting that you write for your future boss: ignore - you can safely ignore this from usability point of view.
  10. Having a domain name owned by weblog service: ignore - you can safely ignore this from usability point of view.
When we take important and recommended items from that list we come up with my personal condensed list of "Top 5 Blog Usability Mistakes That Are Really Related To Usability And That You Really Should Avoid" or T5BUMTARRTUATYRSA for short (and yes, capitalizing every word in the sentence is not good practice) in order of importance:
  1. Links don't say where they go
  2. Nondescript posting titles
  3. The calendar is the only navigation
  4. Classic hits are buried
  5. Mixing topics

Commentary on top 10 blog usability mistakes - is usabilityspot usable?

Now that we have gone through all of the top 10 blog usability mistakes list by Jakob Nielsen (2005) it is time for the mandatory "how would this usability blog do when evaluated using this list of usability criterion" -evaluation. So without further ado, lets see how does this usabilityspot blog do when compared against these blog usability mistakes, salted with some commentary to add flavor:

  1. No author biographies: No author biography here. Not really because author identity would be very big secret but because I don't think advertising my usability experience or publications in this blog would contribute very much to the actual posts.
  2. No author photo: No author photo here either because I don't think it is necessary in other than consultant blogs.
  3. Nondescript posting titles: This is hard one to evaluate but I try to keep the post titles descriptive though sometimes attempting to add some dry humor into appropriate titles.
  4. Links don't say where they go: Shouldn't be a problem here since links have long descriptions.
  5. Classic hits are buried: This is not quite yet applicable here since this blog is not very old and there really isn't yet any classical golden posts of infinite wisdom to be promoted. Lets wait one year and see if there are any particular posts that attract attention.
  6. The calendar is the only navigation: Labels and search are also navigation aids here so this shouldn't be a problem here.
  7. Irregular publishing frequency: So far it has been post per day, but o guarantees are given for that posting frequency. There are so many things in the field of usability to talk about and of course world is full of examples of bad usability to point fingers at, but there is also life outside blogging. There will be notification before expected longer hiatus.
  8. Mixing topics: No topics are mixed here, though usability is wide and high field so you can expect posts ranging from theoretical papers to game usability and beyond. If it is about usability, it belongs here. But you will not likely find cookie recipes or lolcat pictures here, unless they can somehow be related to usability.
  9. Forgetting that you write for your future boss: No big secrets here and an usability advocate writing about usability shouldn't be very shocking finding for any future boss.
  10. Having a domain name owned by weblog service: Guilty as charged in this account, but using  Blogger as blogging service gives enough flexibility with relative ease of use (usability problems in Blogger are a topic of some other post) and building a dedicated blog of my own would not be worth the hassle.

Commentary on top 10 blog usability mistakes - having a domain name owned by weblog service

Tenth and final mistake in the top 10 blog usability mistakes by Jakob Nielsen (2005) is having your blogs address pointing to blog service (Blogger, Typepad etc). Nielsen sees this as sign of naive beginner who shouldn't be taken too seriously. And again, in my opinion this mistake is not really usability mistake at all but rather a question about PR and image. If you are pro blogger by all means you can have your own domain and build your own blog as you like it, but I follow several professional blogs and v-logs (some in Blogger, some in other blog services), and the idea that blog service provider would somehow lessen the value or image of information or entertainment I get from that particular blog hasn't crossed my mind. I would argue that using a blog service lets you as blog writer concentrate better to the main attraction (i.e. your blog posts) and not worry about technical details, layouts and trying to get problems solved with sometimes quite unresponsive tech support especially when using cheap service provider.

Commentary on top 10 blog usability mistakes - forgetting that you write for your future boss

Forgetting that you write for your future boss gets the ninth place in the Jakob Nielsens top 10 blog usability mistakes list from 2005. Write anything into internet and it can be found quite easily. Even if writing is modified the originals can sometimes be found from Google caches, archive.org archives or other similar sites. So in case you want to get name and fame or think that your current or future boss or colleagues might get curious, it is good idea to think carefully what and how you write into internet and perhaps make a search using your name to find out where your name pops up. Of course you can write anonymously, with pseudonym or just with fake name. While there is nothing wrong with this kind of advice and certainly blog writers would be fools not to think with what kind of things and issues they want their real names to be associated with, I have to again respectfully disagree here that this advice would have much to do with usability. So think what kind of image you want to give for those who google your name but it has more to do about creating a professional public image than about usability.

Commentary on top 10 blog usability mistakes - mixing topics

Mixing different topic in one blog is the eighth mistake in the top 10 blog usability mistakes by Jakob Nielsen (2005). One easy way to confuse your readers is to write posts from various topics into same blog. If the users don't know whether your blog is about political satire or family dilemmas, they have to live in permanent uncertainty not knowing which topic will the next post be about. Or more likely they just move along and find a blog that actually can stick to one topic and not meander aimlessly over all possible topics and then some more. In case you really have burning desire to blog about more than one issue, by all means make multiple separate blogs each with their own distinct topic. How this mistake is connected to usability may not be apparent at first, but letting your users know what they can expect is a good usability practice in general.

Commentary on top 10 blog usability mistakes - irregular publishing frequency

Irregular publishing frequency is the seventh mistake in the top 10 blog usability mistakes by Jakob Nielsen (2005). It is generally a good idea in all web publishing (blogs, webcomics, etc) to give your audience some vague idea when they can expect your next masterpiece. If users come back again and again time after time only to find that nothing new has been added, your faithful readers can soon become ex-readers. So have some kind of regular publishing frequency and stick to it. Or if you want to publish longer and more insightful articles with plenty of time between them, you might want to encourage your readers to subscribe to your RSS and/or Atom feeds, because feed subscriptions effectively negate the impact of readers dropping because of irregular publishing frequency.

If you know you will be publishing in irregular intervals, let your readers know that so they don't expect regular service. And if you know that for one reason or another you will not be posting for a while and the blog will start collecting dust, post "on hiatus until" message telling no new posts are to be expected until certain time. Keeping a regular publishing frequency is not easy, so it is good idea to keep some draft posts ready in case deadline approaches and you get the dreaded "writers block" (unless you want to write about that). Bottom line is, let your readers know when they can expect your next magnus opus and don't give promises of publishing frequency that you won't be able to keep.

Commentary on top 10 blog usability mistakes - the calendar is the only navigation

Sixth usability mistake in the top 10 blog usability mistakes by Jakob Nielsen (2005) is using the calendar as only navigation architecture for the blog posts. Fortunately nowadays blog publishing systems have labels, tags and/or search on by default so the users task of finding blog posts of certain topic gets much easier and they don't have to wade through zillions of historical posts trying to find posts of particular topic based on post titles. Don't go crazy with the tags/labels though, because it is easy just to slap every possible tag/label to every post and thus make the categorization of posts totally useless for the users. Most blog publishing systems let you edit tags/labels long after you have published the post so you can start with few tags/labels and add or modify them in your old posts when you know better which categorization works and which don't. And in case you don't use a blog publishing system (e.g. Blogger) with blog post labels and search ready, you should look at your blog from visitors point of view and think how visitors will be able to find your earlier posts easily without having to remember when you posted them. And when in doubt, why not ask your users if they think navigating in your blog is easy and intuitive?

Commentary on top 10 blog usability mistakes - classic hits are buried

Jakob Nielsen lists burying your classic hits as fifth common mistake in his top 10 blog usability mistakes list from 2005. Have you ever searched from a blog something that you knew was there but couldn't quite find it? Did you write a brilliant/insightful/funny piece of blogging with lasting value but the future generations won't be able to find it unless they know which year and month you posted it, know which labels it has or know that it exists in the first place? Usually blogs have labels, tags and/or search that will help users to find relevant posts from your blog but you might want to link back to your earlier posts when you write a new post on the same subject or highlight the most important posts (or as Nielsen calls them, evergreens) by placing links to them in prominent position on the page.

Commentary on top 10 blog usability mistakes - links don't say where they go

Fourth usability mistake in to the top 10 blog usability mistakes by Jakob Nielsen (2005) is having nondescript links in blog post, like this. This type of usability problem is also common in normal web pages where users have to guess where the links are going or try to find out the destinations with trial and error. There should also be clear difference between internal and external links so that user knows if clicking the link will take them into another post in the same blog or if it will take them in completely different site. Also there should be clear (usually color) difference between visited and unvisited links so that users don't have to remember which links they have already visited. Some authors have the external links to open in new browser window/tab but this cannot be recommended unless you tell the users somehow (e.g. with an icon) which links will open new windows/tabs. Expert web users know how to open every link in new tab when they want so opening new tabs without telling them will only irritate them, while novice users can get completely confused where they are and try to use the back button in browser to return to page they were while they are in new window, which of course doesn't work.

Commentary on top 10 blog usability mistakes - nondescript posting titles

Jakob Nielsen presents nondescript posting titles as third common mistake in his top 10 blog usability mistakes list from 2005. This type of usability mistake is also common in graphical user interfaces where windows, dialogs or menus sometimes don't have informative titles and the user has to decipher from the content of the windows, dialogs or menus what it is all about. In the wonderful world of blogging the titles are important because they represent the blog and its posts in search engine results and feeds.Title of the blog post should not only describe the content of the post but also reflect its style. Unless you have clear idea what the posting is going to be like, it might be better to write the post first and add the title last when post is in its final form. When writing series of postings on particular topic (like this top 10 blog usability mistakes commentary) it is good to use the titles of the posts to bring some continuation between posts (in this case first name of the common theme and then the name of the individual usability mistake).

Commentary on top 10 blog usability mistakes - no author photo

Second usability mistake according to the top 10 blog usability mistakes by Jakob Nielsen (2005) is not having an author photo in author biography, since an author photo will improve credibility, offer more personable impression and connect the virtual and physical world in case some of your readers have met you. In my humble opinion, again the credibility of any writing should come from presented facts, clear reasoning and well defined opinions, not from the authors own persona. And furthermore, having or not having an author photo has more to do about creating a professional public image and less to do about blog usability.

Commentary on top 10 blog usability mistakes - no author biographies

According to the top 10 blog usability mistakes list by Jakob Nielsen (2005) the readers of the blog want to know who are they dealing with and not having an author biography is one of the top 10 blog usability mistakes. But is it really a matter of trust? According to Nielsen signed writings have more credibility than anonymous writings. In my humble opinion facts and opinions speak for themselves and person behind them is rather inconsequential. We could draw a weak analogy to double blind peer-reviewed conference and journal papers. No one in their right mind (at least if they have some experience in research and publishing) would suggest that authors of submitted papers would also submit a detailed resume about their past and present work and publications for the reviewers to see if the results in that particular paper should be considered credible. Every submitted conference and journal paper must convince its peer-reviewers on its own merits, rather than the merits of its authors. And overall, having an author biography or not having one doesn't have very much to do with how the blog can be used by specified users to achieve specified goals with effectiveness, efficiency and satisfaction in a specified context of use, i.e. usability.

Commentary on top 10 blog usability mistakes - prologue

When writing any blog about usability sooner or later you have to address the blog usability. Blogs as specific type of web medium should follow the same general web usability guidelines, like making the links obvious and using graphics for highlighting content and structure, not as decoration. Of course there are also some specific usability guidelines for blog usability but the maybe the most interesting one is by usability the advocate grand old man Jakob Nielsen himself. So the ten following posts will form an editorial commentary of the top 10 blog usability mistakes by Jakob Nielsen (2005):
  1. No author biographies
  2. No author photo
  3. Nondescript posting titles
  4. Links don't say where they go
  5. Classic hits are buried
  6. The calendar is the only navigation
  7. Irregular publishing frequency
  8. Mixing topics
  9. Forgetting that you write for your future boss
  10. Having a domain name owned by weblog service

More obscure error messages - PS3

"80410418, 80710016, 80710101, 80710102, 8002F994..."

What are these seemingly random series of numbers and occasional letter? Believe it or not, but those are apparently what PS3 developers think as informative error messages. Just google "ps3 error" and you get plenty of PS3 code lists and decoders with dozens of cryptic error codes, speculative and often conflicting explanations for what these error codes are about and how to recover from these errors. Problem is of course that you have to dig again into various forums in the internet trying to find out what the error is about (8002F994 means that there are too many people trying to download an update at this time and that you have to try again later - but of course you should have known that just by reading the code!) and what to do. And in case you get an error code like 80710102 (PS3 cannot connect to router with current IP information - reboot the router) you better have another source for accessing the internet at hand beside your trusty PS3 or you might be scratching your head wondering what is going on. So lets reiterate yet again what a good error message should tell the user: A) what happened, B) why it happened, C) how the user can safely recover from this error situation and D) how to prevent such errors from happening in the future. How hard can it be?

Reporting errors in error reporting




Getting the obscured bX-error message (like the "bX-ob6b7r" yesterday) which tells the user absolutely nothing about what is going on, what is the user supposed to do? Searching high and low from help forums and googling the vast interwebz a certain reporting form [link] was mentioned, supposedly giving the user chance of reporting error codes directly to developers. First problem is that this link was nowhere to be found in the error message itself, so the hapless user has to notice the link in some help forum discussion usually unrelated to that particular error code. Second problem is that this bX-code reporting form is your standard Google spreadsheet form and there is no indication that the form is made by or is read by the developers, and not made by someone not related to development in any shape or form. So just fill the form and hope that something happens.

When we look at the form itself, there are some additional problems. What time should I input into the "Timestamp" field? Is it the time now or the time of the error occurred? Do I put date, time or both? In what format do I input the time? In 24 hour or 12 hour format (AM/PM)? In what timezone? Can I put the time according to my timezone or do I have to try to find somewhere what timezone system uses and convert the time to that? If I have to put date too is ISO 8601 standard time (YYYY-MM-DD) ok or should I use Unix time (seconds since new year of 1970)? Does any of this matter when reporting the error?

The user faces another classical user interface problem when trying to "Describe what you were doing when you received this bX-code". The field name is long but field itself is the same size as every other field, i.e. too short for writing a long description what the user was doing when receiving this code. User interface input field sizes should be based on the amount of input the user wants to make into that particular field. E.g. field for postal code can (and usually should) be relatively short but field for street address should be much longer because street addresses are usually much longer than postal codes. Fortunately for the users writing a short story about what were they doing when error happened, these fields allow more input than their length would suggest. Or maybe the form just cuts the description after first 21 characters and rest disappears into oblivion, who knows. And when we are at it, I want to give a free advice for all those developers who force me to select my home state in their web forms: there is life also outside the States and it would be really nice if you would recognize that if you want me to buy something from you.

Then user has to "Select the browser you were using" so that shouldn't be a... wait a minute, it says "select" even though the user interface element used here is not a drop-down list but an input field. Tsk-tsk. Of course actually having a drop-down list would make things much more easier since now the users have to worry if just generic browser name is enough or should they add also the version number.

Want obscure error messages? - Look no further!


"bX-ob6b7r" Sometimes the error messages are not useless just because designers didn't bother to put any useful information in them, but because the error message is obscured or coded in such a way that it is more or less useless for the user when the error happens. To get an example of such an obscured error message we need not to look any further than the very Blogger itself. To reiterate from last post, a good error message should tell the user: A) what happened, B) why it happened, C) how the user can safely recover from this error situation and D) how to prevent such errors from happening in the future. This obscured error message fails in all those accounts.

Internal debugging error codes might be very useful for the designers but are quite useless for the users as a source of information about what is going on. By trial and error I was able to find out that this particular bX-error is related to changing the layout of the blog. So why couldn't the error message tell me that in plain user-friendly terminology in the first place and instead forced me to jump the hoops trying to find if somebody out there in the forums or in the whole internet has some vague idea what is going on while trying to avoid red herrings, wild speculations and temporary try-at-your-own-risk workarounds.

So how about changing this obscure "bX-ob6b7r" error message into something more useful for the users, like "It seems that we cannot update your blog template at the moment for some reason, but your blog is still up and running. Please tell us about this problem directly through this convenient link. We will tell you when you can update your template again."?

Return of the Captain Obvious



"Catastrophic failure" - An example of an error message that gets an immediate nomination to categories "useless error messages" and "return of the Captain Obvious". What is the purpose of an error message? To tell the user: A) what happened, B) why it happened, C) how the user can safely recover from this error situation and D) how to prevent such errors from happening in the future. So thanks for telling me that a catastrophic failure happened, I wouldn't had guessed it when everything stopped working...

What am I doing?



"Send Message Error - Sending of message failed" Another example of error message that first sounds very easy to understand and actually provides more helpful information than your average "there is an error" - error message. This time the error message provides more details about reason of this error (unable to open the temporary file) and gives an advice what to do (check your 'Temporary Directory' settings). So what could possibly be wrong about it? Well again the problem lies in the context where this error message appeared. In this case user was importing some mail to Thunderbird when this error message appeared, which becomes quite apparent considering the clues like "Import Wizard", "Importing..." and "The following items are currently being imported...". So why is this error message talking about sending a message when user is actually importing messages? Is the error message just confusing the user by using different terminology (importing vs. sending) or is it just stock error message that is used instead of non-existing import error message? Is the helpful information in the error message just a red herring that will send users to change their temporary file settings in vain?

World Usability Day - an international usability awareness day




Happy World Usability Day! World Usability Day (or WUD for short) is held annually on the second Thursday of November (so this year it is 12th of November) to promote better usability. WUD was originally initiated by Usability Professionals' Association (a professional association for people interested in usability) in 2005, but it has since grown and attracted interest from all over the world. In 2008 there were events in 43 countries with over 50.000 participants and volunteers, and even more unofficial usability related events and meetings at that day. If there is no official WUD events nearby, today is good day to have a nice discussion (whether it be with other like-minded usability advocates or hard-core developers) about usability and its importance. It is World Usability Day today - think about usability!

Different worlds, different terminology



"Error: Your community has been deleted" Doesn't this error message sound like a very straightforward and easy to understand? What could possibly be wrong about it? Well, it is easier to understand the problem about this error message that has caused some users to scratch their heads wondering what is going on when you consider the context where this message was displayed. Was it some community based information system? Some kind of Facebook application or group? No, it was an information system for booking travels online. From your average users point of view booking a travel has very little to do with communities or being member of some community. So what exactly is this "your community" that has been deleted and why should its deletion be a problem when all you want to do is to book a trip? That being the case, what exactly is this "community" that the error message is talking about? Nobody but the designers of this system knows and they surely are not telling.

Users are from Mercury, Designers are from Pluto

For a designer designing an information system the users and their everyday work are usually as distant as Mercury and Sun are from Pluto. Who are those users, what is their background, what do they do, what do they expect, how to best support their work, what kind of terminology they use, what kind of systems they are already familiar with? For a designer trying to answer these questions without any kind of contact to the actual users and their everyday life, is like trying to observe weather in Mercury (users) and Solar activities (context of use) from Pluto. Things get much easier if you communicate with people who are situated closest to observe the users and their everyday life - namely the users themselves. Of course you have to remember that since users are not designers and they lack an objective view of the context of use as a whole, so just asking them to design information system for themselves is usually a bad idea. The designer has the design expertise, objective viewpoint and moral responsibility to design the best possible system for these particular users in this particular context of use.

Usability - what is it anyway?

You encounter usability (or rather lack of it) every time you try to do something and end up pulling your hair from frustration when your tools (either software or physical device) seems to do everything in its power to hinder you work, but what exactly is usability? There are almost as many definitions for usability as there are researchers trying to define it. Usability is one of the main software product and system quality attributes described in the international standard ISO 9126 where usability is linked to the capability of the product to be understood by, learned, used by and attractive to the specified user, when used under specified conditions. Another common definition of usability is in standard ISO 9241-11, where usability is defined as: The extent to which a product can be used by specified users to achieve specified goals with effectiveness, efficiency and satisfaction in a specified context of use.

Nielsen (1993) and Shneiderman (1998) have both independently defined five key attributes of usability that applies to all aspects of a system with human-computer interaction. The key usability attributes are according to Nielsen/Schneiderman: learnability/ease of learning, efficiency/speed of performance, low rate and severity of errors, memorability/retention over time, and subjective user satisfaction/user attitude. How high would you rank the tools you have to work with using these five key usability attributes?

Usability Spot - it is all about usability

Welcome to Usability Spot - a blog discussing all things related to usability and ease (or more often than not - difficulty) of use. Topics can be usability related research papers, latest news about novel user interfaces, insightful blog articles or dreadful user interfaces - it is all about usability.