[Gridsphere-users] Usability 101

[Wilfred Li]

Cool post! I'm sure we can all find something useful.

Regards,
 
Wilfred
 

	-----Original Message-----
	From: gridsphere-users-bounces at gridsphere.org 
	[mailto:gridsphere-users-bounces at gridsphere.org] On 
	Behalf Of Anurag Shankar
	Sent: Friday, December 22, 2006 6:54 AM
	To: GridSphere Users
	Subject: [Gridsphere-users] Usability 101
	
	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. ] 
	_______________________________________________
	Gridsphere-users mailing list
	Gridsphere-users at gridsphere.org
	http://lists.gridsphere.org/mailman/listinfo/gridsphere-users