MScIT HCI Web GUI design

IBM’s CUA guidelines - taster Design Principles Each principle has supporting implementation techniques. The two design principles are: Users can develop a conceptual model of the interface. Users can develop a conceptual model of how an application should work. The user interface should confirm the conceptual model by providing the outcome users expect for any action. This occurs only when the application model is the same as the users' conceptual model. Users can be and should be in control of the dialog. Allow users to control the dialog. Traditional applications that are sequential in nature do not support this principle. Putting users in control means that users should be able to perform any action in any sequence they want to complete their tasks.

Nielsen’s Deadly Sins 1.Long download times. This is more critical than ever. You have 10 seconds before users get bored and leave. 2.Lack of navigation support. Don't assume users know as much about your site as you do. 3.Outdated information. Hire a Web gardener. Maintenance is a cheap way to enhance the content on your Web site. 4.Frames. They break the fundamental user model of the Web page. URLs don't work: You cannot bookmark the page and return to it. 5.Annoying animation. Mainstream users care more about useful content. 6.Orphan pages. Pages that lack logos, links or other hints to indicate what site they're part of. Always indicate what site the page is on and provide a link to the homepage. 7.Long, scrolling pages. No longer a catastrophe, but still a problem. People don't like to scroll.

Nielsen’s Usability Heuristics Visibility of system status The system should always keep users informed about what is going on, through appropriate feedback within reasonable time. 2. Match between system and the real world The system should speak the users' language, with words, phrases and concepts familiar to the user, rather than system-oriented terms. Follow real-world conventions, making information appear in a natural and logical order. 3. User control and freedom Users often choose system functions by mistake and will need a clearly marked "emergency exit" to leave the unwanted state without having to go through an extended dialogue. Support undo and redo. 4. Consistency and standards Users should not have to wonder whether different words, situations, or actions mean the same thing. Follow platform conventions. 5. Error prevention Even better than good error messages is a careful design which prevents a problem from occurring in the first place.

Nielsen’s Usability Heuristics Recognition rather than recall Make objects, actions, and options visible. The user should not have to remember information from one part of the dialogue to another. Instructions for use of the system should be visible or easily retrievable whenever appropriate. 7. Flexibility and efficiency of use Accelerators -- unseen by the novice user -- may often speed up the interaction for the expert user such that the system can cater to both inexperienced and experienced users. Allow users to tailor frequent actions. 8. Aesthetic and minimalist design Dialogues should not contain information which is irrelevant or rarely needed. Every extra unit of information in a dialogue competes with the relevant units of information and diminishes their relative visibility. 9. Help users recognize, diagnose, and recover from errors Error messages should be expressed in plain language (no codes), precisely indicate the problem, and constructively suggest a solution. 10. Help and documentation Even though it is better if the system can be used without documentation, it may be necessary to provide help and documentation. Any such information should be easy to search, focused on the user's task, list concrete steps to be carried out, and not be too large.

Nielsen reported that users identified navigability as the most important quality of an interface…

A Tree A Star A Net A List Possible Web architectures

Online Commerce Example Fred is ordering plants from an online nursery. (The arrow indicates clicking on a link and moving to the next page.) Step (a) Fred collects the products that he wants to buy by clicking any of the Add Item links in the catalog. Step (b) Fred checks the order form for correctness and clicks on the Payment link when done with the form. Step (c) Fred enters credit card information and clicks Submit Step (d) Fred sees that his purchase was approved.

Before leaving the store, Fred realizes that he forgot to buy the dibble that he needs to plant the tulip bulbs, so he uses the Back button to return to the pages of the catalog. As he goes back from (d) to (c) to (b) to (a), he realizes that he’s backed up over all of the ordering information. Now he wonders about the state of his purchase: Will his credit card be charged? Will he get the items he has ordered? Does he have to reorder? When he clicks on the Add item link again, will he get an empty order form, or the one he has been using? It is difficult for users to answer these questions, especially when they first encounter the situation. Designers should encourage users to kick the back habit. Instead of encouraging or requiring the use of the Back button, applications should have navigation buttons to take users directly to where they need to go.

Prototyping cycle (Steve Draper )

Case Study - Student database List of students - append ?students to the URL above. Enroll a student - call with a form that supplies Student and Major Dismiss a student – call with a form that supplies Student List of classes – append ?classes Add a class – form provides Classname and Instructor Delete a class – form provides Classname Classes for student – form provides Student Students in class – form provides Classname Take a class – form provides Student and Classname Drop a class – form provides Student and Classname