[Gridsphere-users] Usability 101

[Anurag Shankar]

Dear fellow Gridsphericals? Gridsphere-ites? Gridspheroids? (sorry,
can't decide which is best),

I've been taking a look recently at usability (from a complete novice's point 
of view). As a result, I now have a brief document that I've put together to
check frequently during my portal projects. I am including it below since 
Jason thinks it might be useful more generally.  I hope he's right. 

As always, feedback is always appreciated.

Finally, have an excellent Christmas/Hanukkah/Kwanzaa/Felicitations (take your 
pick) and a very Happy New Year. Have a great time wherever you are and be sure 
to take time off to decompress before starting the new year.

Cheers,

--Anurag

-- 
Anurag Shankar, Ph.D. <ashankar at indiana.edu>
Dept. of Astronomy & Univ. Information Technology  Services 
Indiana University, 2711 E. 10th St., Bloomington, IN 47408
Voice: +1.812.855.4981  Fax: +1.812.855.8299

------------------------------------------------------------------
$Id: usability.txt,v 1.4 2006/12/22 14:36:49 ashankar Exp $


Usability 101 for Developers
December 2006

[ Note: Web UI here means a portal, standalone web app, etc., but I'll use the 
word portal in the text below. ]

1. First, ask some key questions and be totally clear on the why of it.

- Why do a Web UI at all? 
- Why should/would the user want to use this UI?
- Is a Web UI superior to the tradidional CLI*/shell/perl scripts? How? Why?
- Does it help enable users to get the data/answers they need *HERE* 
      (i.e.  wherever they are) and *NOW* (i.e. quickly)? 
- Would it make things more efficienct/transparent/easier?
- Would it allow users to save time, perhaps by
    - prepackaging repetitious tasks?
    - the users' ability to create arbitrary workflows?
    - a GUI being more natural to use than a CLI?

(*CLI = Command Line Interface)

2. Second, be devil's advocate and list possible arguments against a Web UI.

- JavaScript sucks (browser dependecies and such).
- The Web/Java/HTTP is slow.
- Using Javascript/AJAX and HTML is a very poor way to create a UI.
- The last time someone did a (nice) Web UI for this crowd, it was used by 
      exactly 1.5 poeple. Why would it be better this time?
- We don't have a clue how to do a Web UI well (nor do we care).
- We don't have time or resources to do it well. The best we will succeed
      at is to irritate the users.
- Our Web server is too slow/unreliable/ancient/whatever.
- The Web UI will be completely unmaintainable/unscalable/one of, etc.
- I wouldn't touch this project with a ten foot pole! 
- There's already a product that does it well.
- A Web UI further obfuscates the debugging process that the user is used 
      to (by hiding the back-end complexity) and make the situation worse.
- The only reason we are doing it is because it is sexy. No one is really
      going to use it, ever. 
- etc.

Weigh these pros and cons carefully to your satisfaction before proceeding (if 
you are genuinely serious about helping users).

If you do decide to proceed, the following may be helpful.

3. Avoid the following pitfalls.

- Self delusions: "My own preferences and experiences as a designer/developer 
are sufficient to design a portal for real users". This will inevitably lead to 
disaster and/or to a useless portal.

- Plain out myths:
    - You can educate the users.
    - It's the user's fault.
    - One size fits all.
    - Fewer navigation click are better.
    - Build it and they will come.
    - People will pore over each page, reading your finely crafted text, 
        figuring out how things are organized, etc. The reality is that 
        people simply glance at a page, scan some text, then click on the 
        first link that catches their interest. They notice nothing else.
    - People will choose the best option on a Web page. The reality is 
        that they don't. They choose the first reasonable option.
    - People actually read instructions. The page must be sufficiently self 
        evident so that instructions are superfluous.

- You make a lot of assumptions until proven otherwise, for example:
    - If a technology is simple to use, users will like it.
    - We can anticipate why, when, under what conditions, and how the user is
        likely to interact with the UI.
    - Users will feel that they are deriving a benefit from using your UI.
    - Costs of development won't exceed the benefits.

- You are in trouble if *any* page on your portal makes users think:
    - Where am I?
    - Where do I begin?
    - Where did they put ____?
    - How do I do ____?
    - What are the most important things on this page?
    - Why did they call it that?

- Repeat after me:
     - Users Hate Learning
     - Users Hate Repeating
     - Users Hate Waiting
     - Users Hate Searching
     - Users Hate Reading
     - Users Hate Security Breaches
     - Users Hate a Monotonous Look
     - Users Hate Platform Restrictions
     - Users Hate Rigid Functionality
     - Users Hate Mistakes

4. Consider the following carefully.

General stuff:

- What is it that the users want?
- Can the user actually articulate what they want? If not, how are you going 
     to figure it out?
- What do you think the users need?  Confirm that they do indeed.
- Where and under what conditions will users use the portal?
- Who will use the portal? Faculty, graduate students, undergraduates?
- How will the portal be used?
- What are the goals for the portal then?
- What are the resources available, cost, etc.?

Your User:

- Who is the user? 
- What is the user culture like? 
- What are the user characteristics/types/level of expertise? Are there 
    multiple classes of users based on knowledge/experience/skill?, etc.?) 
- What is the user's environment? (Windows/Mac/Linux?, local help provided?,
    etc. etc.) 
- What does the user fear the most?
- What is the chief expectation of the user in this project?
- What is the task generally?
- What are the task components? Functions?
- How should the user be allowed to invoke those functions?
- How should we tell the users how to invoke the functions?
- How do we help the users when things don't work?
- What is the user's age?  (This will determine
  - Information flow needs
  - Font size
  - Grapihcs necessities
  - Help functionality features
  - Data presentation )

The User Environment:

- Physical space

Users map their physical space to the Web page they have in front of us. The
physical space consists of the following components:

* Objects - These act as clues that trigger thought processes during 
  navigation.  (e.g. to a user, a chair is a chair no matter where it is
  placed.)  

* Interrelationships - How objects are positioned relative to one another.  
  Recreating users' familiar environment or space is key.

* Characteristics - To help recognize, classify, distinguish from other 
  objects. Use color, shape, size, location, volume.

* Location: Where the user is located and what is his purpose in using the 
  portal at that location?

- Cognitive space:

Then there is the stuff that goes on inside the user's head. This includes:

* Thoughts -  These may be triggered by the physical space (outside of the 
  portal).

* Situations - When the situation requires a different approach.  For example,
  the need for quick access to information on the fly to resolve a problem
  that has cropped up unexpectedly.

* User intentions/goals - How the environment can shape goals/intentions and 
  how goals/intentions lead to specific web activity.

* Information processing - Selective attention (user ignoring sensory data/
  messages/events to focus on specific info), short-term memory (small 
  chunks are better, in short attention spans), long-term memory.
  
The Web Environment:

* Real world mapping - Users apply their real world mental models to the Web.
Use this insight to design the page.

* Scenarios - Think of steps a user might take when presented by a number of 
given scenarios and how the user might approach each.

* Simple vs complex environment - Simple does not necessarily mean more usable. 
Design a simple site if efficiency is the goal. Complexity must be consistent 
with what the user expects, i.e. not too simple, not too complex.
  
Web Page Design:

* Postitioning - No scrolling on home page. Short home page. Use top left of
home page (& the top in general) to convey the most important info. Tabular 
data should be left justified. Don't use fixed width tables. Tables > 1 page 
with same headings, important stuff on the left (like instructions) as
people read English left to right. Put most important stuff in biggest font.

* Aesthetics - Background shouldn't conflict with color of links/content.
Don't use fixed width fonts; use percentages so they work for most browser 
window sizes.

* Response Time - As quick as possible. If delay, give the user feedback on
what delay to expect, total page content (text+graphics) should be less than 
60KB,  graphics should be 25KB, each graphic less than 10KB for 5 graphics 
or more.  Use 1"x2" thumbnails for graphics. Provide text-only option as well. 
Use no animation, no audio clips/multimedia/plug-ins, use progressive 
redenring (text downloads before graphics).  Use GIFs since they are smaller 
than equivalant JPEGs.

* Navigation 

- Tasks - Tasks statement should contain all the info needed to perform the 
task successfully. Show only information the user actually needs to reach 
his or her goal.

Provide a prominent "where do I start?" hint on the home page or any other
pages with tasks.

The user should be able to reach his/her goal in a minimum # of clicks.

Facilitate user actions (tell users what to do and what to expect) and 
provide unambiguous feedback when take these actions.

- Aids - Use links/buttons/contentlists/trails/keyword searches as navigation 
aids.  Code information in less than 6 colors. Be consistent - all links of 
one type should have the same default color, underlining,  type, font, etc.
Use ALT entries for graphics.

Place a link to the home page on each portal page. On long pages, use 
subheadings. Every page should display a title (within the page itself, not 
in the window titlebar) and the right context. When entering data, the user 
should be able to navigate away from page and return to it easily (or at 
least save and be able to retrieve the data entered), Captions should be 
over/left of the entry field for column/row oriented entries. 

Institute a "you are here" in the site hierarchy near the top on each page.
(Can use breadcrumbs.)

When the user clicks on a link to navigate, the resulting page title (again,
the title within the page, not in the window titlebar) should be the same 
(word by word preferably) as the verbiage in the link the user clicked on.

Use navigation aids such as go back, redo this/that, etc.

Use tabs since they are self-evident and map for the user physical file 
folders to the Web page.

Provide navigation buttons at the top/bottom both if possible.

Provide a clear "Logout" button.

- Speed - Minimize the # of keystrokes in data entry. Provide default values 
for data entry available. Make it obvious what is clickable on the page.

- Persistence - There should be a persistent navigation area, with site ID 
prominently displayed on the top left + sections + a way home + a way to 
search + any utilities you have. Should do this for each page except home 
page and forms. This reassures the user that he/she hasn't navigated out of 
your site. A cleer tagline next to the site ID (such as "Moving People Since 
1880" next to the site ID "U-Haul Moving" or something like that).

- Transparency - Provide self-evident answers to questions the user has at 
any moment, for example: What (the h***) is this?  What can I do here?  What 
do they have here?  Why am here and not somewhere else?  How do I do ___? 
(Do this for each page).

- Continuity - If possible, provide a way for the user to return to the same 
point in the Web session in case he/she needs to end the session and restart 
elsewhere.  

- Help - FAQ/contact info should be prominently displayed.

- Don'ts- Avoid pull-down menu's if possible.  Preserve the home page from 
promotional overload (or any kind of info overload).

Absolutely no flashing stuff on pages where reading is necessary.

Don't change terminology from page to page. This is extremely confusing to
people.

- Coherence - Amount/placement of content. Preserve as much of white space
on the page as possible (for clear delineation between items). Use unambiguous 
labels for different chunks of info. Use fonts that enhance text clarity.

- Quality -

  - Provide personalization
  - As for feedback on each page
  - Frequently update content with date of update clearly visible
  - Remove/fix dangling links frequently
  - Indicate "new" for new info
  - Site pages easy to print
  - Incorporate new technology

5. Design process

- Consider human factors/design guidelines input early in the design.
- Iterate on design.
- Test continuously.

6. (Poor Man's) Usability Testing

- Testing one user is 100% better than testing none.
- Testing one user early is better than 50 near the end.
- The importance of recruiting representative users is overrated. Users who
    are "like" your users is good enough; just test often.
- Testing doesn't prove or disprove a thing. It is to inform your judgment.
- Testing is iterative.
- Nothing beats a live audience reaction.
- You don't need a full blown usability lab to test.
- Use 3-4 users per test.
- Grab anybody who uses the web. You're in trouble if your 13 yr old 
    son/daughter can't navigate the site or perform the actions you want the
    users to perform.
- Don't be embarrassed to ask friends and neighbors.
- Offer reasonable incentives.
- Keep the invitation simple.
- Avoid at all discussing the site with the user beforehand.
- Test in any office or conference room.
- Find a reasonably patient human being to act as a usability professional.
- Plan ahead what you will show to the users.
- Run small tests throughout the devleopment process.
- Spend one morning a month doing usability testing.
- Debrief the development team after each test the same day (preferably at
     9 if you did the test at 8 or 8:30; definitely before 1!)
- Make small changes with big results ("head slappers" or "can't believe I
     didn't think of that?") right away.
- Forget written reports.
- Use the testing script at www.sensible.com and edit for your own case.

Common Wisdom:
- It's not a good idea to design a site for only your target audience
    (unless it is a *very* specialized audience)..
- Experts are rarely insulted by something that is clear enough for beginners.
    In fact, they often appreciate it and think "Wow, someone really thought
    about this!"..
- If the target audience is split between clearly defined but divergent groups,
    test each group at least once

Of course, for highly specialized users, use the right kind of user with the 
right domain expertise.

7. Design Goals

With everyone being so busy and all, the user is coming to the portal with
the attitude "don't make me think, pleeeaaaase!".  Here is then your design 
goal (tough, eh?).

Here's some more stuff from a book (that sounds a lot more professional), but 
I think all this is already covered.

- Designing for Context: Consider the relationship between the artifact's
core elements and the elements that surround the core.

- Designing for User experience: Efficiency as measured in times and actions,
not necessarily user satisfaction. Questions to answer:
  - Did the users perform tasks as they expected to?
  - Did they achieve their goals?
  - How did they feel during the interaction?
  - Were their expectations met?

8. Misc

Think of things this way:
- Every user entering the site starts with a reservoir of goodwill.
- Each click depletes this goodwill a bit (because you are having the user
     do something - like move a finger).
- Each problem depletes this reservoir even faster.
- The reservoir is idiosyncratic, situational, can be refilled, but a 
     single mistake can also empty it.

Here's some more do's and don'ts from one of the books:

Do's

- Know the main things user wants to do and make them obvious/easy.
- Tell user what he/she wants to know.
- Save the user steps wherever possible.
- Put effort into the site.
- Know what questions users are likely to come up and answer them (FAQs).
- Provide creature comforts, like printer-friendly pages.
- Make it easy to recover from errors.
- When in doubt, apologize.

Don'ts

- Don't hide the info the user wants.
- Don't punish the user for not doing things your way (e.g. asking them to 
    put dashes when they enter their SSN; they shouldn't have to care. You
    deal with it programmatically. And, did I say that you shouldn't be asking
    their SSN anway?).
- Don't ask for info you don't really need.
- Don't lie: "Your call is important to us", Yea, right!
- Don't put a puzzle in the user's way.
- Don't make the site look amateurish. Even 11 year olds can design a site
    that looks like it was designed by a fancy web designer these days.

9. Bibliography

1. "Shaping Web Usability: Interaction Design in Context", 2002, Allbert N. 
Badre, Addison Wesley Professional.

2. "Customer-Centered Design: A New Approach to Web Usability", 2002, Kreta 
Chandler, Karen Hyatt, Prentice Hall.

3. "Designing Web Usability", 1999, Jakob Nielsen, New Riders.

4. "Don't Make Me Think!: A Common Sense Approach to Web Usability",
2nd Edition, 2005, Steve Krug, New Riders. [Excellent book]

**5. "Usability Testing at a Discount", 1989, Jakob Nielsen, www.useit.com.

6. "Camtasia" screen reader is recommended.

7. "Information Architecture for the Web", 2002, Louis Rosenfeld and Peter
Morville, O'Reilly, 2nd Edition.

8. "Source of Power: How Pople Make Decisions", 1999, Gary Klein, MIT Press.

9. "Web Application Design Handbook: Best Practices for Web-Based Software",
2004, Susan Fowler and Victor Stanwick, Morgan Kaufmann.

10. http://www.sitepoint.com/article/architecture-usable

plus the essence of a whole lot of random GooglyGook.

[ Plese email <ashankar at indiana.edu> to report errors/provide critique or 
to provide useful info that we can add here. ]