User interface design (intro)
•	goals and principles
•	interface design process
•	design issues
•	design evaluation
•	WYSIWIG: pros and cons
Goals and principles
•	Reduce user errors
•	Put user in control
•	Optimize work performance for the work environment
•	Need usability goals as part of requirements
•	User interface design should be tied to requirements (inc. usability goals)
•	Objective evaluation and iterate to refine
Profiling
•	Users
–	determine experience with computers, interface styles
•	Work environment
–	work patterns
–	physical concerns
•	Task requirements
–	Satisfying basic requirements vs. doing the job well
–	Navigating among tasks
Suggested practices
•	do not force anything on user
•	flexibility -- multiple modes of interaction
•	allow user to interrupt execution
•	allow undoing of actions
•	allow customization of interface
•	hide technical details (layered arch.)
•	allow user to manipulate what's on the screen
Suggested practices (continued)
•	Reduce what has to be memorized
–	short-term memory -- ex: highlighting selected text
–	good defaults
–	intuitive shortcuts
•	layout matches real-world counterpart
–	ex: calculator with buttons
•	organize info hierarchically
–	ex: File, Edit, etc. menus each lead to sets of related options
Suggested practices (continued)
•	Accessibility
•	Localization
–	Do all users have access to same resources?
–	What languages are used?
•	Vision-impairment
•	Accessibility for other programs
•	http://bobby.watchfire.com/bobby/html/en/index.jsp
–	tests individual web pages
Suggested practices (continued)
•	Reduce complexity
–	# steps to do
–	# links to follow
•	Standards/templates
–	straying from company standards is common reason for mistakes
Suggested practices (continued)
•	Consistent interface
–	provide context
–	ex: Unix support for different prompts -- machine, current directory, privileges
•	consistency within family of applications
–	ex: MS Office, Lotus SmartSuite
•	some features become expected and should not be modified casually
•	consistency across different supported interfaces, esp. during maintenance
Interaction Patterns
•	http://www.welie.com/patterns
–	Especially the GUI page
•	Ex: Grid layout
–	When options can be organized in subgroups
–	Minimize number of rows and columns
•	Compact, organized appearance
Interaction Patterns (continued)
•	Ex: Unambiguous format
–	Only allow user to enter data in correct format
–	Sample problem: entering date
•	Compare entering date with 3 text boxes for numbers vs. a Calendar
•	What could go wrong with the first approach?
•	Also check other links on welie.com
Interface design process
•	iterative (spiral) approach
•	prototypes useful to validate interface
–	does the tasks
–	easy to use/learn
–	accepted by users
–	counter-ex: early AI medical diagnosis tools -- failure from users not entering data
Interface design process (continued)
•	similar to general software process, but for only the subsystems the user sees
•	ex: identify input/output objects in this process, not internal objects
•	plan layout of interface
•	emphasis on what is available via the interface rather than how it is done
Interface design issues
•	system response time
–	want consistent response time
–	what does "real-time" really mean?
–	want appropriate response time
Interface design issues (continued)
•	user help 
–	should be integrated into system
–	decide how much of system is covered
–	smooth return from help
–	organization: "flat", hierarchical, and/or hypertext, maybe with indices
–	representation -- pop-up, menu
Interface design issues (continued)
•	error messages
–	avoid jargon (what else besides programming terms/abbreviations?)
–	provide advice if possible
•	alert user to error (ex: highlighting lines with problems) 
•	typed command options
–	consistency
–	easy to remember
Tools
•	user interface well-suited for prototyping
•	standard components -- good tools are available, reuse is possible
Design evaluation
•	length and complexity of specification indicate inherent complexity of system
•	# user tasks, #actions required per task indicate efficiency
•	memory load
•	mostly done by questionnaires
Design evaluation (continued)
•	be specific
–	ex: were icons self-explanatory? how many different actions did you try?
•	Monitor what is actually getting used
–	easiest on a website
•	survey users for features that are not used
–	What are the possible reasons?
•	Check for correctness
–	ex: checkboxes vs. radio buttons
–	boundary conditions
–	layout errors
Graphical vs. nongraphical user interfaces
•	Don’t assume GUI is always best
•	Screen space is limited
–	Hierarchical organization of options is not necessarily clear
•	Ex: inserting date in Notepad vs. MS-Word
•	Not everyone appreciates GUI’s
–	visually-handicapped
–	other programs