MESDA Annual Conference 2002 Software Development Track

MESDA Conference 2002

MESDA Annual Conference 2002MESDA Annual Conference 2002Software Development TrackSoftware Development Track

Put the User Back in UI Put the User Back in UI DesignDesign

MESDA Conference 2002

Presenter

Arthur Fink, Arthur Fink ConsultingArthur Fink Consulting<[email protected]>

3 © 2002 Arthur Fink Consulting www . arthur fink .com arthur @ arthur fink.com (207) 766 - 5722

Putting the User into Graphic User

InterfaceOr

On Being User-Friendly

Putting the User into Graphic User

InterfaceOr

On Being User-Friendly

Arthur FinkOwner, Arthur Fink Consulting


Who is Arthur Fink?Who is Arthur Fink?

• Developer working with Progress (triumph of stealth marketing) …… “technical” person

• Consultant, interested in how people interact with systems ....… “systems” person

• Son of graphic designer … “visual” person

Arthur Fink Consulting10 New Island AvenuePeaks Island, Maine 04108(207) 776 - 5722arthur @ arthur fink.com


About this talkAbout this talk

• Based upon my course, “Designing and Refining Graphic User Interfaces”

• Designing = Refining• Not about these ...


(from www.baddesigns.com)



(from www.baddesigns.com)(from www.baddesigns.com)


Design for usabilityDesign for usability


(from www.baddesigns.com)



























Characteristics of a GUI(Graphic User Interface)Characteristics of a GUI(Graphic User Interface)

• One window “anchors” the system

• Buttons replace many menu items

• Action choices are plainly visible

• Don’t need or want hierarchical menus

• Lots of freedom for user to move around

• Users do more work; less navigating


What’s Better About GUI?What’s Better About GUI?

• Not just that it uses graphics!• Vocabulary only a small set of mouse

actions, or other constructs• Keyboard only for data entry -- not for

commands or navigation• User interaction can mirror user’s view of

the world (do it their way!)


What are we seeking?What are we seeking?

• Usability– Interface should be “transparent”– Objects on screen work “naturally”– Minimum of “gotcha’s”– User can focus on the real task!– Simple screens guide the user– Icons, colors, etc give appealing feel


What are we seeking? (continued)What are we seeking? (continued)

• Standardization– User already knows how to work it– Moves easily across platforms– Many interface objects already built– Modules are re-usable– Closely follows Microsoft examples– Coordinated systems and paper flow


Refining the InterfaceRefining the Interface

• Clear modality

• Visual cues – Default buttons– Dimming inactive objects– Metaphors (copying a household object)– Icons– Colors– Fonts

• Sensible design


Default buttonsDefault buttons

• Identified by darker outline

• Windows traps the ‘enter’ key, and translates it into choose of the default button


Dimming inactive objectsDimming inactive objects

Keeping them visible may be less busy and confusing than frequently viewing and hiding


ModalityModality


MetaphorsMetaphors


Are metaphors helpful? Do they...Are metaphors helpful? Do they...

• Help or hinder product learning?• Suggest an outmoded way of thinking?• Mislead the user in other ways?• Make the user more comfortable?• Give implicit instructions to the user?• Add another thing that needs to be learned?


What’s wrong with metaphors?What’s wrong with metaphors?

"Metaphors offer a tiny boost in learnability to first-time users, but at a tremendous cost. By representing old technologies, most metaphors firmly nail our conceptual feet to the ground, forever limiting the power of our software. They have a host of other problems as well, including the simple facts that there aren't enough metaphors to go around, they don't scale well, and the ability of users to recognize them is questionable.”

Alan Cooper About Face: The Essentials of User Interface Design


IconsIcons

• Graphic cues, for common tasks• Can provide character and style• An international interface, if well chosen• Often over-used• Can add to user’s learning curve• Easier to learn if accompanied by text• “Tool Tip” help makes them more useful


• Icons alone can be very confusing


• Icons alone can be very confusing

• But icons with text can help user learn


ColorColor• Common colors

suggest a relationship• Use color coding

consistently• Don’t depend upon

color recognition• Many people are color

blind for blue-green• Loud colors can be

unsettling


Fonts ... for maximum readabilityFonts ... for maximum readabilityFonts ... for maximum readabilityFonts ... for maximum readability

Fonts ... for maximum readabilityFonts ... for maximum readabilityFonts ... for maximum readabilityFonts ... for maximum readability

• Serif fonts Serif fonts• Lower case LOWER CASE• Ragged right text• Dark text on light (not white) background• Just a few fonts• At least 9 point size


Error messagesError messages

• Be clear, and as non-technical as possible• Tell user how to solve the problem:

• Use this: Enter a valid employee ID• Rather than: Employee not found

• Don’t blame the user, or refer to “error”


FeedbackFeedback

• Give some feedback for every user action

• Feedback should come as soon after action as possible

• Users are frustrated with “dead” screen


Please don’t show off ...Please don’t show off ...


Even though some vendors doEven though some vendors do


A GUI must be designed ...A GUI must be designed ...

GUI style requires it• Lots of ways to represent & modify data• Visual elements can be busy & confusing

Users expect it• Users expect interface to be intuitive• Key application suites set high standard• Bad interfaces are very annoying!


Three common design paradigmsThree common design paradigms

• Technology: Knowing how the system is built will make it natural & easy to use.

• Metaphor: A good metaphor will help the user understand how to use it.

• Idiom: Once the user learns an idiom (that is distinctive and helpful), the system will make sense. A good idiom still needs to be learned, but only once.


Which model to follow?Which model to follow?

• Mental model: User’s Vision of the world• Implementation model: How the program is

built

Shield users from the implementation model -- although this is the model used by most software today.


Thinking of the userThinking of the user

• Finite span of focus• Limited visual memory• Better recognition than recall• Not comfortable making “mistakes”• Appreciates a gentle guiding hand


Limited “span of focus”Limited “span of focus”

• We can keep track of only seven things– Supervise seven staff– Memorize 7-digit telephone numbers– Sort into seven categories

• Implications for GUI design– Seven objects on a screen (at most)– Seven choices in a menu (at most)– To handle more than seven, use grouping


Use easily recognized symbolsUse easily recognized symbols

GHJKPQRX)_+,.cfmirvx=EFM


Do these icons make sense?Do these icons make sense?


Recognition is easier than recallRecognition is easier than recall

• Don’t expect users to recall command sequences, codes, icon meanings, etc.

• Help the users with consistent use of buttons, icons, and other GUI objects.

• This is much easier in a GUI than a character environment.


The mouse can be a time-wasterThe mouse can be a time-waster

• Reaching for a mouse takes time(3 - 8 keystrokes)

• Provide alternatives to “point-and-click”– “Accelerator” or “hot” keys– Function keys– Mnemonics on the button

• Once the mouse is in the user’s hand, it does permit quick object selection


Progressive disclosure (start simple) Progressive disclosure (start simple)

• Program is simple at start

• But gets complex when user is ready ...


“Design for good affordances” Jarad Spool (User Interface Engineering)

“Design for good affordances” Jarad Spool (User Interface Engineering)

Affordance: How an object communicates the way it is used


AffordancesAffordances

• Some objects have “obvious” use– Push a button– Check a toggle box– Turn a window crank

• Spin box with 3-part date is confusing• The whole window needs affordances

– How to complete a task?– Is order of operations important?


ModalityModality

• Mode gives contextual meaning to events• Change mode = New effect of user actions

– Insert mode / Overstrike mode– Enter order header / Enter order detail

• Let user see current mode, and change it• Don’t create extra modes

– Button meaning should stay the same– Mode change should “feel” natural


FocusFocus

• Which object receives next user input• Action may just change focus, or may also

act on new object• User needs visual display of focus


Use a formal design processUse a formal design process

• Review tentative designs with users and management

• Re-design following each review • Budget time for the re-design process• Have clear criteria to measure success• Use a formal style guide (for consistency)


SuggestionsSuggestions

• Keep it simple• Avoid extra activity• Don’t cram data onto screen• Avoid lots of transitions to finish task• Think of user’s hands, moving between

keyboard and mouse


Design 1: Clarify user tasksDesign 1: Clarify user tasks

• What does the user need to do?• What data gets examined? In what way?• What gets updated? ..created? ..deleted?• Is there necessary ordering? • How does system relate to paper flow?• What database activity will take place?


Design 2: Identify GUI Objects Design 2: Identify GUI Objects

• What objects work best?• Fill-in, text, or editor• Browser• Selection list• Drop down list (combo box)• Radio set• Toggle box• Slider• Button• Active-X spin box, grid, etc.


Design 3: Work out flowDesign 3: Work out flow

• Is navigation simple and automatic?• Where do users begin? • How do they move around?• Can they go back?• Do any steps need to be blocked?• Should tab folders provide organization?• Are there other ways to switch pages?


Design 4: Test, and revise Design 4: Test, and revise

• Test, with paper or live prototype (measure actual usability)

• Revise, based upon user feedback (comments and behavior)

• Test and revise again (... and again ...)• This is iterative development


Paper prototyping(as described by Jarad Spool)Paper prototyping

(as described by Jarad Spool)

• Develop screens from paper and board (be creative)

• Developers “play” the computer– Manipulate the interface– Simulate program behavior

• Users take the simulation seriously, and provide real feedback


Goals of paper prototyping,and of later testing

Goals of paper prototyping,and of later testing

• Are the supposed affordances working? (e.g. are they really affordances?)

• Can users proceed confidently?• Do they get help, in their own terms?• When they ask for help, can they get help using

their own terms?


ConsistencyConsistency

• With the “real world”– Application should be a good “model”

• Within and among applications– Shared and consistent conceptual model– Common language– Consistent visual elements– Same function

• Allow use of standard interface elements


ForgivenessForgiveness

• Allow for user’s interactive discovery

• Provide only appropriate sets of choices

• Minimize opportunities for errors

• Handle errors gracefully

• When users make mistakes, guide them back gently


Human strengths and limitationsHuman strengths and limitations

• Respect user’s limitations– Perception– Memory– Reasoning– Physical handicaps

• Don’t ask user to– Calculate anything (even day of the week)– Recall command or option names


For disabled usersFor disabled users

• Provide cues for different senses (e.g. sight and sound)

• Don’t use color or sound alone for essential signals

• Don’t require rapid responses

• Provide alternatives to the mouse

• Avoid rapid flashing on the screen


The art of Graphic User Interface designThe art of Graphic User Interface design

• Be guided by the users’ experience!

• User should find screen “intuitive”

• Use paper prototyping to make sure

• Follow windows or motif standards

• Keep screens simple and uncluttered

• Recognize cultural differences; avoid jargon

• Provide enough “affordances”


??????????????

Date post:	31-Dec-2015
Category:	Documents
Upload:	harding-conway
View:	27 times
Download:	1 times

MESDA Annual Conference 2002 Software Development Track

Documents