Usability Categories And Heuristics

The following categories can be used for heuristic evaluations of TWiki as well as for grouping usability issues, discussion and proposals on twiki.org regardless of the actual implementation.

Background info:

A Heuristic evaluation is done as a systematic inspection of a user interface design for usability. The goal of heuristic evaluation is to find the usability problems in the design so that they can be attended to as part of an iterative design process. Heuristic evaluation involves having a small set of evaluators examine the interface and judge its compliance with recognized usability principles (the "heuristics").
http://www.useit.com/papers/heuristic/

1. Understandability

• Wording: clear, appropriate wording; fits the target group, lack of foreign and technical terms?
• Information: clear, sufficient, available everywhere where neces-sary, fits the target group?
• System feedback (error messages, confirmations): pre-sent/available where necessary, clear, sufficient, fits the target group?
• Navigational elements (navigation elements, buttons, icons, sym-bols): complete, clear, fitting?
• Information architecture: classification of topics and content to categories clear and comprehendible?
• Input: Clear which input is expected; input processing unit must tolerate and cope with input errors.
• Process: The order of the steps in a process is clear und compre-hendible, appears logical and complete.
• Concept: Concept is clearly communicated and can be easily grasped.

2. Recognisability

• Legibility: Typeface allows easy reading, font size is sufficiently large and can be easily recognized, font colour contrasts the back-ground well.
• Visibility; Design and Layout clarity*: clear design, appropriate use of colours; fundamental information, content, links, buttons and symbols can be quickly spotted and easily recognized. The applica-tion lacks elements that divert from the main content or key aspects of the application.

3. Navigation & Orientation

• Navigation within the application or in a process does not limit, but provides all possible/necessary degrees of freedom. Back and for-ward navigation is always possible.
• Navigation to the main menu is consistently available.
• All required links are present and functioning as intended or ex-pected by users.
• Structure, layout and design allow the user to unambiguously know
  1. his current position within an application,
  2. how he arrived at this point and where he came from and
  3. and how he can continue. The application is equipped with tools or features, such as breadcrumbs (web) and highlighting of menu items that aid orientation.

4. Handling

• Manipulation of elements is easy and obvious.
• Reaching a goal is from an operational perspective simple and straight-forward.

5. Control

• Easily recognizable system status / transparency: Information about what the system is currently doing and about what the user can presently do is readily presented. Clear messages informing about the beginning and end of a process are available. The system unambiguously prompts the user when he can/should do something.
• Meets expectations: The application acts/reacts as the user ex-pects it to. It meets general conventions.
• System Feedback: System messages are available.
• Critical Information (e.g. General Terms and Conditions, Prices) can be quickly and easily loaded.

6. Consistency

• Buttons, links, labels, titles or design elements are presented con-sistently and/or conform to style-guides. Learning is simplified by eliminating unnecessary trial and error.
• Meaning and function of important elements is clear, unambiguous and can be quickly deduced due to their resemblance in appearance and/or behaviour to other objects of equal quality or category.

7. Performance

• Menus, windows and screens load quickly.
• Usage is simplified by the systems’ quick responses. Slow and unre-sponsive systems can make users insecure.

8. Technology

• Compatibility with other systems works seamlessly.
• Output quality is of good quality (e.g. Videostreams, Pics).

9. Errors

• The application is free from spelling mistakes, bugs, bogus output.

10. Utility

• The application is complete. Content, features and functions that are de-manded by users or by the task are all available.

-- Contributors: CarloSchulz - 23 May 2008

Discussion

Cool effort, Carlo! That is valuable input. I was also already thinking of our need for an ongoing collection of usability-bugs. We should help programmers to understand and erase them step by step.

-- MartinSeibert - 23 May 2008

heck yes please

-- SvenDowideit - 24 May 2008

I hear one use for this classification - organising bugs - which might be really handy for devs. Another, perhaps more important, is metrics; it's always hard to judge "how useable" something is. Perhaps assigning a score in each of these classifications is one way of doing that?

-- CrawfordCurrie - 24 May 2008

I gave a TWiki-Heart for these valuable usability-contributions (TWikiUsability, UsabilityCategoriesAndHeuristics) to Carlo Schulz. He is our Usability-Champion! - TWikiHeart

-- MartinSeibert - 24 May 2008

We should create a page, that lists all usability-related "bugs" and "requests" including a categorization and a prioritization. Then all programmers know exactly how to proceed, if they want to improve TWiki-usability.

-- MartinSeibert - 25 May 2008

I would suggest a simple 1,2,3 prioritization.

1. this is a major usability problem that effects core components
   • eg. the user can't drive the car as it has no steering wheel.
2. this is more for annoying stuff you can work around. They stand in your way but you are still able to achieve your goal.
   • eg. the current raw edit - you need to learn or look up the syntax in order to do more advanced stuff but you can still add content without it.
3. small problem, actually more like an irrtation.
   • eg. that the search box has no submit button.

-- CarloSchulz - 25 May 2008

A word of warning; please do collect usability issues in one place, but don't just expect something to happen as a result. You have to make sure that someone:

1. analyses those issues, and decides what to do about them
2. raises feature and/or change requests as appropriate (feature requests are for major changes and are raised in this web. Change requests are for minor changes and are raise in Bugs web)
3. finds, and follows up with, implementors, to ensure the changes actually happen.

-- CrawfordCurrie - 26 May 2008

Another word of warning.

Improving usability is a good thing. But it is important to not optimize the usability for the first 60 minutes of a TWiki users life at the expense of the next 10000 minutes.

Meaning - do not hide the part of the user interface behind 2-3 clicks that the user after 60 minutes of practice will need as a one click feature to be effective the rest of the years of usage.

TWiki is not a place people come to buy a concert ticket or find a phone number. It is mainly a tool used in workplaces on a daily basis and it has to be fast and effective in daily use. But that does not mean you cannot improve the UI. But be careful with the hiding.

-- KennethLavrsen - 26 May 2008

Actually, its not all about hiding, it's more about where and when you expect and need certain options, tools, links or what ever.

And more important: What is your goal? What did you came for? Browsing, looking for information? Collaborating? Or maybe more advanced things like building a TWikiApplication?

The current interface allows you somehow to do everything you might wanna do. And this is the problem - To be satisfied with an UI it is important that it helps you in achieving your goal and not the goal of others.

-- CarloSchulz - 26 May 2008

So what we want is a geek tool that does not look like a geek tool.

That is cool

But what we have is a geek tool that has been build by geeks, mostly used by geeks and as a result looks like a geek tool.

That's not...

-- CarloSchulz - 26 May 2008

Kenneth and Crawford: Thank you very much for your thoughts. I will keep that in mind. But at the moment there are so many low-hanging usability-fruits to pick, that you can be sure, that we will be able to address easy "quick wins" first.

To give you an impression, look at this:

1. Why does TWiki offer two unlabeled Search prompts if one with two submit buttons can serve the same purpose much better. See Wikipedia as a good example:

2. Why does TWiki offer me to change the language of the interface not only once but throughout my whole lifetime of usage?

-- MartinSeibert - 31 May 2008

Note: if you see unlabeled search boxes then you have a javascript problem. Both of the boxes have "default text": jump and search. Some people like the jump box, not me by the way.

Note 2: the wikipedia buttons "article" and "full text" are also not ideal. Better to have 1 button and to let people go directly to the one page if the search query matches that topic name, and show a hint box at the top to show the user "You can continue searching for topics containing 'search phrase'".

Note 3: usability is not new, but it is also difficult. Most issues have been discussed here on twiki without a clear outcome. You need to show perseverance!

-- ArthurClemens - 01 Jun 2008

As a user, I think the Jump Box and Search Box are very usable. I wouldn't want either of them to go away. Nor would I want one box with two buttons. I know it's probably inconsistent UI design to not have a "submit" button, but the simplicity and speed of use could not be matched if there was a "submit" button. I know that one could still hit "Enter" to submit the form, but most users presented with a button are going to move their mouse to it and click it. Yeah, about 1 in 20 people will question, "How do I use these boxes." As soon as it's explained to them, they go off and use them with no problems.

-- DavidWolfe - 02 Jun 2008