Creating the Initial Design "Do v. don't"

Creating the Initial Design

“Do v. don’t”

Borrow

• Good quality, tested techniques

• Users already understand features

• Reduced design and implementation effort

• ** - within boundaries -- i.e. “look and feel” patent concerns

Existing Frameworks

• Windows

• Macintosh

• X/Motif

• Java/Swing

Advantages

• Style guide describes features, advice

• Software tools may exist

Existing Applications

• Incorporate good existing tools where needed -- spreadsheets and databases, for example – saves development time– users already familiar with these– “commercial grade”

Existing Interaction Techniques

• Programs whose interfaces serve as models of good practice

• Be knowledgeable about these commonly used programs

• Example: tool palette v. menus

Tool palette v. menus

• Select: enter a mode• graphical spec• Mode ok because:

– cursor indicates mode

– user is aware

– easy to get out

• icons show choices– pack well

– good to rep graphics

• Select: one-time action• text shows choices

– list representation

– better for “hard-to-draw” operations

Modes

• Considered “bad”

• example - vi -- what you type can be text or a command, depending on the mode, little feedback to tell you which is which

Geometry and Motion

• Small targets harder and slower to hit with a mouse than big targets

• long mouse movements slower than short ones

• icons pack differently than text

• more keystrokes -> slower

• switching mouse <->keyboard slower

Memory Considerations

• Recognize v. recall

• hard to remember from step to step– have help available where needed– info used together should be presented together– interface should present key info (like mode)

Problem-Solving Concerns

• Interface should help user select relevant operations– label ops to match user tasks– feedback on results– undo – “gray out” irrelevant choices

Attention Concerns

• To get user’s attention:– big change in display– near where user is looking– auditory signals harder to ignore

“Be conventional”

• Users will be happier with “familiar” techniques

“Support diversity”

• Different users may prefer different interaction styles

• physical limitations may prevent use of certain features – mouse v. keyboard for blind users, or problems

w/ motor control– multi-key combination

The Clustering Principle

• Organize the screen into visually separate blocks of similar controls, preferably with a title for each block of controls– similar commands on same menu– buttons for a given function grouped together

and visually delineated (box, white space, color)

Why cluster?

• Helps users search for the command they need

• Helps user acquire conceptual organization of the program

Visibility Reflects Usefulness

• Make frequently used controls obvious, visible, and easy to access

• Hide or shrink controls used less often

Why VRU?

• Users can quickly search small set of controls

• more extended search okay for rare functions

Intelligent Consistency Principle

• Use similar screens for similar functions– once users learn where controls are on one

screen, they can apply this knowledge to other screens

• Screens shouldn’t look alike if they do drastically different things

Color as Supplement

• Don’t rely on color to carry information

• Use color sparingly to emphasize info provided through other means

Color whys

• Easier to misuse color than to use it well– mean of color varies w/ culture

• (red = danger, death, life)

– color-blindness

• Design in black&white -- add color judiciously later

Reduced Clutter Principle

• Don’t put too much on the screen– See earlier principles– one or two type styles– small number of colors