That's why I have compiled a list of RIA-specific usability heuristics (or best practices) that may help when it comes time to develop or to evaluate a rich web application. They are not intended to fully cover all the aspects of the application, but to address issues specific of rich web interfaces; these heuristics should be a complement of more general ones.

As with the psychological usability heuristics, they are in the form of a Google Docs spreadsheet to make it easy to download or clone it for your own work.

RIA Usability Heuristics spreadsheet (Google Docs)

These are some of the sources I have used to compile the heuristics (thanks to them!):

• Usability for Rich Internet Applications (Digital Web Magazine)
• Minimizing Usability Risks in Web Applications (Blink UX)
• Staff Picks: 10 Usability Favorites for 2006 (Blink UX)
• Usability Heuristics for Rich Internet Applications (Boxes and Arrows)

What do you think of those heuristics? Do you know any other?

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

QED

Let's take a look at two of the buttons; isn't this your first guess when you see them?

Wrong. The real functions of those buttons are:

Using fancy original self-designed icons is a common mistake made by novice interface designers; icons are hard to memorize, and users usually recognize just a few of the most common. Many times, the best way to describe a function is simply a text label.

I'm surprised Google has fallen into that error; maybe they have been paying too much attention to people complaining about their ugly interfaces. Anyway, Google, please, give me back my text labels for actions!

When you enter the academic world, you realize of one surprising thing: it's a rather opaque world. In fact, many of the most prestigious journals make their publications only available to subscripters, so the only part that is available on the web for free are their abstracts.

So in the era of Internet and free access to information, scientific knowledge obtained through research (which should be the paradigm of free access to knowledge) depends mostly on an previous outlay.

At least until now. The Research Without Walls movement allows the research community to pledge to assist in the peer review process only for conferences and journals that make their accepted publications available to the public for free via the web.

Right now, the number of subscribers is not very large, but the list of institutions they belong to is pretty impressive: Google, Microsoft, Berkeley University, etc. And their prestige is important, since the reputation of conferences and journals is mostly determined by the researches that assist in them. The fact that they refuse to collaborate with closed-access publications may be a great boost to the free access to academic contents on the web.

• Requirements are defined by another team (business analysts) and the UX team is not involved in this phase; they usually don't take part until the design phase.
• The UX team is involved when the project is almost finished (and the interface problems are already pretty severe).

Yes, we know that the UX team should participate since the early stages of the development, but… what can we do when we are faced to given requirements, which are usually incomplete, long lists of technical features, and which have nothing to do with UCD techniques like use cases or user stories?

UX Interpretations

Last June, Greg Lauger explained in his article 'Matching Requirements with User Experience' on Johnny Holland Magazine some techniques used in that kind of situations, and I think that the 'UX Interpretation' approach (he calls it a "collaborative clarification") is a great idea and could be used as a UCD technique on its own.

For every single requirement (or every important requirement, or every unclear requirement), the UX team would develop the corresponding 'UX Interpretation', following this simple structure:

1. Reference to the original requirement.
2. UX interpretation of the requirement.

The UX interpretation could be a use case, a storyboard, a prototype… any technique which described the implications on the interaction of that requirement. After that, the interpretation would be reviewed by other members of the development team.

What would be the purpose and benefits of these interpretations?

• The UX team would work with a more familiar way of describing requirements.
• The interpretations would be the equivalent of "this is what we have understood from the UX point of view". Consequently, they would be a better reference for discussions with the analysts team than the original requirement. The analysts could then give feedback about the correctness of the interpretation.
• The UX team would show that the requirements are a fundamental aspect of the development, and that the team uses them and cares about them.
• The analysts would have contact with the "UX way" of describing requirements, and they could use that knowledge for following projects.

So… do you think you could have used this technique in some past situation? Or better… Do you think this could be useful in future projects?

So… why don't we use those psychological facts as heuristic principles when evaluating interfaces, instead of the typical technical ones? To that end, I have translated Susan's points into heuristic principles and checkpoints that may be used to evaluate interfaces, creating a spreadsheet to make evaluations easier. Here you have it:

Psychological Usability Heuristics spreadsheet (Google Docs)

Of course, the translation of facts into heuristics is subjective, and this work may be updated and/or expanded at any time; anyway, I think this may be a good approach to usability from a more human perspective.

Feel free to use this spreadsheet for your own work (you may have to download or make a copy before). Any feedback about this work will be welcome!

Update 19-sep-2011

I have contacted Susan Weinschenk explaining her this idea, and this is her kind reply:

Hi Jordi,
Thanks for writing.
It's a very interesting idea. I'm surprised I didn't think of it myself!
Have you read my book: 100 Things Every Designer Needs To Know About People? Probably more ideas in there too.
Susan

I haven't read '100 Things' (yet), but I have read her previous book and multiple articles in her blog. I wonder if 100 things may lead to 100 heuristic principles. It seems like a lot of work for me alone; maybe if this first idea achieves some success…

Jakob Nielsen defined guerrilla HCI as a collection of usability techniques that may be performed along development projects in an informal and fast way, requiring few resources, getting acceptable results and avoiding the intimidation barrier of using that kind of techniques.

One advantage of guerrilla HCI is that it can be performed without great involvement of the development team, and consequently, it is useful in traditional website development.

According to their own nature, websites must be self-explanatory and their interface must follow existing standards in order to make possible that anyone can use it without advanced skills neither previous training.

For example, guerrilla HCI could be perfectly applied in the evaluation of an e-commerce website or one belonging to a university since, in principle, they don't require special knowledge.

Nevertheless, there are cases where it's not that simple…

Board the ship

Sometimes, usability experts have to deal with development projects where they know little or nothing about the system being developed; it may be a desktop application, an intranet or a specialized web application. In those cases, it's difficult to apply straight guerrilla HCI since the expert doesn't know basic characteristics of the system, like user roles, which are the most important tasks, or the use context.

In those situations, it's necessary to apply something we can call "ship-boarding usability": the expert has to "reach" the development team and "board the ship" to get to know the objectives and the project status so to improve the system's usability, "changing the course" when necessary.

To that end, I suggest selecting a collection of basic and simple techniques between those usually included in User Centered Design methodologies:

1. User roles (and personas).
2. (Essential) use cases.
3. User interface prototyping.

1. User roles (and personas):
who will use the application?

In many development processes, user profiles or roles are implicit in developers' knowledge, but there isn't any explicit documentation about them. In such situations, I suggest first to develop documents describing basic characteristics of users who will use the system; in this phase, they will usually uncover that user roles are not as clear as it seemed, or even new roles are discovered.

One of the templates that may be used for that purpose is this one developed by Constantine & Lockwood:

User Role Model (PDF, 145 KB)

It's not indispensable to follow strictly that structure; the important point is to identify, at least, user roles and their main characteristics.

Ideally, that documentation (and any other described in this article) should be based on a platform allowing the developers to read and update it quickly and easily.

Once those roles are identified, it's possible to use "personas" technique to have a more realistic reference of the users; however, I think it's a technique that requires the developers/designers to have a good attitude to be effective.

2. (Essential) use cases:
how will be the interaction with the system?

System requirements, when defined, are many times written as a list of functionalities ("the application should …") , but without any instruction of how the interaction between the system and the user should be. That forces designers (who sometimes are also the programmers) to make assumptions when implementing the interface; that leads frequently to usability problems.

Through use cases, it's possible to describe system functionalities  in a more structured way. There are many descriptions of how use cases should be structured; I specifically suggest using what they call "essential use cases", also defined by Constantine & Lockwood. They propose a high-level semi-structured description (as a dialog) of the user-system interaction. This is the template:

Essential Use Case (PDF, 146 KB)

Identifying and defining the most important and/or problematic use cases first help to get an idea of the purpose of the system and allows to concentrate the efforts where the results will be more effective.

Moreover, this kind of use cases has the following advantages:

• They allow to refine the requirements specification, detecting problems, inconsistencies and lack of definitions in an early stage of development.
• They are a reference for the interface designer; the high-level specifications give freedom to the designer when choosing technologies and concrete solutions.
• They will be the starting point for later usability techniques.

3. User interfaces prototyping:
what will the screens be like?

User interface prototyping is a well-known and very used technique. However, launching into prototyping without a clear definition of the users and the details of the interaction may be really difficult. Using the previously mentioned techniques, prototype creation (of new interfaces or redesigns of existing ones) would be much more effective.

In the ship-boarding usability case, prototypes would be useful to design the most critic interfaces (from the most important use cases), or the modification of existing interfaces (to fix usability problems).

From there…

With the help of the previous techniques, the approach to the application will be less traumatic and the specific usability methods will become more productive and easier to apply: for example, heuristic evaluations will be centered on the most important aspects of the application, taking into account the characteristics of its users; and user testing will have a starting point for user recruitment in user roles, and for scenarios and tasks in use cases.

Anyway, the documents and knowledge generated by those techniques will work out useful through the entire development process, and not just for interface design or usability methods. In general, one of the benefits of applying usability techniques during a development process is that they help to increase the quality of the processes themselves and of their documentation.

User Centered Design (UCD) seems to be growing in popularity, and it's not strange. Who could be against the user being the center of the design process? But looking beyond this popularity it turns out that there is not a consensus about what UCD is.

Formal definitions like in Wikipedia or ISO 13407:1999 describe it vaguely using terms as "design philosophies", "models", "general guidelines", "recommendations", … All those are positive instructions, but they aren't really useful when you face a real project developing a real interface.

User Centered Design is something as generic as this figure, according to ISO 13407.

What do we actually have?

Actually UCD refers almost always to a set of techniques that may be applied along all the life-cycle of a software application; the only thing those techniques have in common is that users are their main roles (at least theoretically). The number of techniques included may vary from six (like in this Webcredible article) to several tens (like in this interactive table at UsabilityNet). Those techniques may be as different between them as focus groups, user testing and interface prototyping.

Oddly some UCD techniques don't include real users in their carrying out: for example, heuristic evaluations of usability.

Every single technique may be applied in different moments of software development, although guidelines in that sense are usually approximated (see UsabilityNet table); their implementation and results are also depending on the specific technique. So in real projects it's the usability (or design) expert who has to decide which techniques are going to be applied and when; and he/she obviously has to have in mind habitual limitations of resources: time, people, etc.

Taking all this into consideration, should we call "User Centered Design" a development process which includes any of those techniques? What is the criterion to decide which an how many are necessary? Can we say we have followed a UCD process just because we have conducted some interviews for requirements definition, for instance?

Moreover, makes it sense talking about a design process without specifying what is its relationship with the rest of development processes?

What would we expect from a real UCD?

We could say then that current "User Centered Design" is a somewhat empty expression, since a real UCD should include:

• Some kind of integration between different techniques, specifying when and how should they be applied in development projects.
• Some kind of integration with development methodologies of the software itself.

There are indeed some attempts to relate UCD with software-development methodologies (like LUCID framework or MPIu+a methodology) but they seem to be yet in a definition stage and/or limited to academic environment.

Perhaps that's the reason why most practical approaches to UCD seem to be oriented towards web applications for content publication. In a web project of that kind most elements (infrastructure, language, technologies) are defined in advance: web server architecture + browser, HTML language for contents, etc. Consequently almost all development decisions are about design (of pages, of contents, of navigation, etc.) and a User Centered Design process seems to be enough to carry out the project.

A UCD methodology oriented to web sites.

But… what happens with other kinds of applications (non web)? When developing this kind of "more traditional" applications it's necessary a more complex analysis and definition of, for example, necessary infrastructure, architecture, database model… All those tasks don't belong directly to interface design field, although they are related to it. How do we apply UCD in those cases? Should design be the conductor of the full development process? Or should it be just another process in the development? What happens with common techniques (like requirements definition)?

It seems that there's still a long road before we can follow a User Centered Design in any project beyond applying specific techniques in concrete moments along its life-cycle.

As a final point, in the next HCI congress in Valencia I will be presenting a paper (in Spanish) related to this subject called "Más allá del cuchillo de palo: hacia una herramienta integrada para un verdadero diseño centrado en el usuario".

Once you overcome the fear of performing a task with such a fancy name, the following step is obvious: choosing the heuristics (guidelines) to use. There are some popular heuristics lists, but there are some risks when using them for a usability evaluation:

• If the heuristics are too generic, they don't help you to identify real issues.
• Otherwise, if the heuristics include detailed checkpoints, you may concentrate on small or very specific issues while overlooking the important ones.

Consequently I suggest using alternative heuristics: the 'top lists'.

Which lists?

With 'top lists' I am referring to lists similar to these by Jakob Nielsen: 

• The ten very worst design mistakes of all time
• Most violated homepage guidelines
• Top homepage usability guidelines
• Good deeds in Web design
• Web design mistakes (2005) 
• Web design mistakes (2003) 
• Web design mistakes (2002) 
• Web design mistakes (1999)
• Web design mistakes (1996)
• Application design mistakes
• Information Architecture (IA) mistakes

I think this kind of guidelines might be used (or the mistakes avoided) in small projects, or even in big projects as a preliminar evaluation, or in other situations.

For example, the home page is a special page in any web site, so we can use 'Top homepage usability guidelines' as heuristics for that single page:

1. Include a One-Sentence Tagline
2. Write a Window Title with Good Visibility in Search Engines and Bookmarks Lists
3. Group all Corporate Information in One Distinct Area
4. Emphasize the Site's Top High-Priority Tasks
5. Include a Search Input Box
6. Show Examples of Real Site Content
7. Begin Link Names with the Most Important Keyword
8. Offer Easy Access to Recent Homepage Features
9. Don't Over-Format Critical Content, Such as Navigation Areas
10. 10. Use Meaningful Graphics

Another example: most of the heuristics are referred to web applications; so if you're evaluating a desktop application, you can use the 'Application design mistakes' as heuristics:

1. Non-Standard GUI Controls
2. Inconsistency
3. No Perceived Affordance
4. No Feedback
5. Bad Error Messages
6. Asking for the Same Info Twice
7. No Default Values
8. Dumping Users into the App
9. Not Indicating How Info Will Be Used
10. System-Centric Features

If you are designing/evaluating an application, take a look at the top common mistakes before asserting you have already considered them…

In conclusion: if you're in a project with no budget or experience or time for usual complete heuristic evaluations, at least you can apply this single heuristic:

• Avoid common ("top ten") mistakes.

We may consider Google as a “big eye” not only because of the images provided by Google Maps and Google Earth but also because it seems “to see” everything that is written on the web. But in fact the way Google indexing process works is more like a huge brain.

[…] keep on reading in METAeuFORiAS

Yes, you forgot to attach the file. It's a common but hard to avoid problem; a good rule is always attach the file before writing the e-mail, but aren't there any better ways to avoid this?

Some systems, like GMail or Thunderbird, have options to alert you when you try to send an e-mail which includes specific words ("file", "enclose", "photo", …) but has no attached files. It's a nice idea, but far from perfect: you will still miss files if the system doesn't detect these words, or you will get an annoying alert about an attachment you don't want to send.

A simple solution

Here's a simpler solution: the user gets notified of how many attachments the e-mail has when he/she is about to send the e-mail, not using annoying alerts but simply including that information in the send button, like this (GMail example):

So when you are going to send the e-mail, you realize that the message has no attachments. Simple and effective, don't you think so?

Implementing it in GMail

Developers should be able to include this functionality easily in e-mail clients. Meanwhile, however, we can try to implement it using plugins or other customization systems.

As an example, you can get that functionality (seeing the number of attachments in the send button of Gmail like in the previous image) installing the following Greasemonkey script:

• GMail attachment number (v0.1) Greasemonkey script

Greasemonkey is a system to allow the user to control the way they use the web, by customizing it with scripting. It works with Firefox with this addon installed.

The number of attachments is computed when the cursor goes over the button. This is not the best implementation but a demonstration of how the functionality would work. The feature could be easily included by the developers (Mozilla, Google, Microsoft, … You know) in their e-mail clients.

This idea is just one of the improvements our e-mail systems need, as I explained in a previous article (in Spanish).

If you want a better badge including clickable URLs and @replies (like the one at the left column of this page), just follow these steps:

1. Download and link to .js and .css files

Download twitter.css and twitter.js from my site. Put them on your own server, and modify your HTML page/template so as to link to them; you have to include something similar to this inside the <head> section:

<link rel="stylesheet" type="text/css" media="screen" href="twitter.css" />
<script type="text/javascript" src="twitter.js" /> 

You can modify the css file to get the appearance you want. You can also modify some strings in the .js file (for instance to adapt them to your language).

2. Include the code to insert the badge

Modify your HTML page/template inserting this code where you want the badge to appear:

<div id="twitter_div"><ul id="twitter_update_list"><li>loading…</li></ul>
</div>
<div>
<a class="twitter_follow" href="http://twitter.com/YOUR_USERNAME">follow me at http://twitter.com</a>
</div>

Don't forget including your own Twitter username. You can also modify the 'loading…' or the 'follow me' strings.

3.Include the call to the Twitter API

Include this code at the end of your template/HTML file, just before </body> tag (this way you ensure your page will still display correctly if the call fails, for instance, if Twitter's site is down):

<script type="text/javascript" src="http://twitter.com/statuses/user_timeline/YOUR_USERNAME.json?callback=twitterCallback2&count=10"></script>

Don't forget including your own Twitter username. You can also modify the number of updates to show. 

And that's all

Please tell me if you are using this badge, or you find any error or upgrade.

Clearly identify changes in the natural language of a document's text and any text equivalents (e.g., captions). [Priority 1]

So here you are an easy way to mark a single post using a different language, using custom fields in Wordpress:

1. Modify your template file(s) (tipically single.php, index.php, archive.php) where the following piece of code appears (the div block containing every single post):

<div class="post" id="post-<?php the_ID(); ?>">

Modify them by adding the highlighted code (to check if there's a custom field called lang for that single post and include it as the language of the post, if not empty):

<div class="post" id="post-<?php the_ID(); ?>"<?php $custom = get_post_custom_values('lang'); if ( $custom != '' ) echo ' lang="'. $custom[0] . '"'; ?>>

2. For every single post written in a different language than the blog main language, add a custom field called lang and assign it the post's language code ('en' for English; 'es' for Spanish, …)

3. And that's all. Now, every post may be identified with its own language. Of course, you don't need to include that field if the language of the article is the same language than the blog, as long as the main language is identified in the header of the web page.

Please, let me know it this works for you or if you find any bugs or improvements.

(click to enlarge)

Can you tell where does this picture come from?

Let me suggest these:

Ok, usability specialists know icons and logos are overused in many sites, and they're not really important for the user; it should be so natural than there's no need to say "we care for usability". Anyway, I think it would be a good idea having a logo to identify sites related to usability aspects, or maybe to identify sites that specially care about those issues.

The teapot is from Don Norman's book 'The Design of Everyday Things', and it's sometimes used (with different designs) in presentations, web sites, etc. The 'u' is supposed to be the handle of the teapot so as to make it more usable. Wait! It's not a great logo if I have to explain this

You get the idea, don't you? Now, remember I'm not a graphic designer and leave your opinions in the comments (and feel free to use them if you want to, of course).

• Because they're used to launch actions by double clicking (as on Windows icons).
• Because the server doesn't replies instantantly, and they click again "just to see if something happens".

What's the result? The form data is sent twice to the server, and users usually don't realize it; they just get the response to one of the submits. Try this simulation to see what happens when submitting several times the form before the server response arrives:

This is not a big issue if it's, for instance, a search form: the query is being launched twice but the user simply gets the result. It may be annoying if someone is receiving the same mail several times just because users are submiting several times the contact form. And it's a real big problem when the user is submiting a payment (you can be pretty sure they don't want to pay twice the same object!).

The solution

There's an easy solution for that problem! Simply disable the button just after the form is submitted, and you can change the button text too. The result is something like this:

This is done using the onsubmit form event:

<form onsubmit=document.forms['formname'].submitbutton.disabled=true;
document.forms['formname'].submitbutton.value='Sending...';" action="action" name="formname">
  <!-- some form controls here -->
  <input value="Send" name="submitbutton" id="submitbutton" type="submit">
</form>

With this technique, you achieve two positive effects:

• avoiding the double submit problem; and
• giving feedback to the user confirming the submit

Of course, there's no perfect solution. If JavaScript is disabled at the browser, it doesn't works; if it's really important avoiding multiple submits (for instance, when it's an economical transaction), it should be done at server's level.

It's really simple to use and without negative effects. Try it if you are really tired of multiple submits and tell me how it goes!

I can select a range of dates at Google Analytics and get different statistics: visits, unique users, etc. But there are many events (internal and external) that may affect that data. For instance:

• Changes at the site: contents, layout, etc.
• Changes in Google Analytics configuration (for instance, in filters)
• Google Adwords campaigns linking to that site
• etc, etc.

Any webmaster would be happy to know how those events are related to the statistics, wouldn't they?

How could Google do that? We already have a solution: Google Calendar. So we simply would associate a site monitorized by Google Anlytics to a calendar in Google Calendar. A webmaster could add events to that calendar, and they would be shown at Google Analytics.

Here's an example; this graph shows a decrease in the number of visits on June, 2nd:

Hmmm… What happened that day? Oh, maybe that new filter to exclude inner visits. With the feature I suggest, I would link the Google Analytics account with a Google Calendar which includes events related to the site, like this:

And the event would be shown at Google Analytics, like this:

They could show events at every place where dates are used; at the date range selection too:

I think it's not possible to create this association externally since Google Analytics has no API.

This could be only a first step, but there are many other possibilities: for instance, create events automatically from Google Analytics!

Este artículo está en inglés; supongo que la mayoría no tendréis problemas en leerlo. De todas formas, espero escribir un poco más adelante sobre Twitter; si no quieres esperar, puedes leer alguna página que explique qué es Twitter. O, más fácil aún, regístrate y podrás añadirme para saber qué estoy haciendo en cada momento.

I have recently inserted the Flash badge for Twitter in my site; but the original code offered by them is not valid HTML. So why not use code that passes validation? Here it is:

<div style="width: 176px; text-align: center">
 <object width="176" height="176" title="what am I doing... (Twitter badge)" type="application/x-shockwave-flash" data="http://twitter.com/flash/twitter_badge.swf">
  <param value="http://twitter.com/flash/twitter_badge.swf" name="movie" />
  <param value="color1=255&type=user&id=USER_ID" name="flashvars" />
  <param value="high" name="quality" />
  <param value="twitter_badge" name="name" />
  <param value="always" name="allowScriptAccess" />
  <param value="transparent" name="wmode" />
  <param value="http://www.macromedia.com/go/getflashplayer" name="pluginspage" />
 </object>
 <a style="font-size: 10px; color: #0000ff; text-decoration: none" href="http://twitter.com/USER_NAME">follow USER_NAME at http://twitter.com</a>
</div>

And the result is (using my own user data):

Just some comments:

• Don't forget inserting your actual USER_ID and USER_NAME (and your preferred color1 parameter if you want to); you can get them at Twitter's badges page.
• The & strings are not part of the URL but the correct way to write ampersands in HTML code; more information about ampersands in URLs can be found here.
• More information about inserting Flash using valid (X)HTML can be found here.