Design

1
Design

• Principles!
• Documents of your design
• Prototyping

2
Agenda

• Design guidelines
• Rules of thumb
• Displaying your designs
• Storyboards
• Lo-Fi
• Wizard of Oz
• Visual Basic
• Dialog design

3
Design Guidelines/Principles

• General guidelines (rules of thumb) to help
  create more usable systems
• Can be subtle, even contradictory

4
Design Principles

• 1. Use simple and natural dialog in users
  language
• Match users task in a natural way
• Avoid jargon, techno-speak
• Present exactly info that user needs
• Less is more!

5
Design Principles

• 2. Strive for consistency
• Sequences, actions, commands, layout, terminology
• Makes more predictable
• Dialog boxes all having same closure options

6
Design Principles

• 3. Provide informative feedback
• Continuously inform user about what is occurring
• Most important on frequent, substantive actions
• in file
• How to deal with delays?
• Special cursors
• Done graphs

7
Design Principles

• 4. Minimize users memory load
• Recognition is better than recall
• Make visible!
• Describe required input format, include example
  and default
• Date _ _ - _ _ - _ _ (DD-MM-YY)
• Use small of generally applicable cmds

8
Design Principles

• 5. Permit easy reversal of actions
• Undo!
• Reduces anxiety, encourages experimentation

9
Design Principles

• 6. Provide clearly marked exits
• Dont want the user to feel trapped
• Examples

10
Design Principles

• 7. Provide shortcuts
• Enable frequent users to perform often-used
  operations quickly
• Keyboard mouse
• Navigation between windows/forms
• Reuse

11
Design Principles

• 8. Support internal locus of control
• Put user in charge, not computer
• Can be major source of anxiety

12
Design Principles

• 9. Handle errors smoothly and positively
• 10. Provide useful help and documentation
• (More to come later in course on these two)

13
Storyboarding

• Pencil and paper simulation or walkthrough of
  system look and functionality
• Use diagrams
• Show key snap shots
• Quick easy

14
Other Ways

• Tutorials Manuals
• Maybe write them out ahead of time to flesh out
  functionality
• Forces designer to be explicit about decisions
• Putting it on paper is valuable

15
Computer Methods

• Prototyping
• Artifact that simulates planned system, but does
  not implement all features
• Good for trying out ideas
• Engaging
• Speed is of the essence
• Be wrong fast!
• Facilitates iterative design and formative
  evaluation

16
Dilemma

• You cant evaluate design until its built
• But
• After building, changes to the design are
  difficult
• Simulate the design, in low-cost manner

17
Prototyping Dimensions

• 1. Representation
• How is the design depicted or represented?
• The more visual, the better
• 2. Scope
• Is it just the interface (mock-up) or does it
  include some computational component?

18
Dimensions (contd)

• 3. Executability
• Can the prototype be run?
• 4. Maturation
• What are the stages of the product as it comes
  along?
• Evolutionary

19
Terminology (1)

• Horizontal prototype
• Very broad, covers a lot of the interface
• Detailed functionality for each item is missing
• Vertical prototype
• Few commands implemented
• Each implemented command works well in detail

20
Terminology (2)

• Early prototyping
• A few screens to get across the basic idea
• Late prototyping
• Test the details
• Details are slow and buggy, but they work

21
Terminology (3)

• High-fidelity prototype
• Media used resembles final interface
• Low-fidelity prototype
• Materials unlike final interface
• Drawings, sketches, storyboards, paper

22
Prototyping Tools

• 1.Draw/Paint programs
• Draw each screen, good for look
• Photoshop, Paintshop Pro, Corel Draw,
  Paintbrush..
• Diagrams!

23
Prototyping Tools

• 2. Scripted simulations/slide shows
• Put storyboard-like views down with (animated)
  transitions between them
• Can give user very specific script to follow
• Often called chauffeured prototyping
• Examples Hypercard, Macromedia Director,
  Powerpoint, HTML

24
Prototyping Tools

• 3. Interface Builders
• Tools for laying out windows, controls, etc. of
  interface
• Have build and test modes that are good for
  exhibiting look and feel
• Generate code to which back-end functionality can
  be added through programming
• Examples Visual Basic, UIMX, ...

25
Prototyping Technique

• Wizard of Oz - Person simulates and controls
  system from behind the scenes
• Use mock interface and interact with users
• Good for simulating system that would be
  difficult to build

26
Wizard of Oz

• Method
• Behavior should be algorithmic
• Good for voice recognition systems
• Advantages
• Allows designer to immerse oneself in situation
• See how people respond, how specify tasks

27
Prototyping Tools

• Good features
• Easy to develop modify screens
• Supports type of interface you are developing
• Supports variety I/O devices
• Easy to link screens and modify links
• Allows calling external procedures program
• Allows importing text, graphics, other media
• Easy to learn and use
• Good support from vendor

28
Dialog Design

• How does a user interact with the interface?

29
Dialog Styles

• 1. Command languages
• 2. WIMP - Window, Icon, Menu, Pointer
• 3. Direct manipulation
• 4. Speech/Natural language
• 5. Gesture, pen, VR

30
Command Languages

• Earliest UI interaction paradigms
• Examples
• MS-DOS shell
• UNIX shell
• dBase
• GPSS

31
CL Attributes

• Work primarily by recall, not recognition
• Heavy memory load
• Little or nothing is visibleso
• Poor choice for novicesbut...

32
CL Attributes

• Advantages for experts
• Speed
• Functionality
• Power
• Script, macros
• Screen Resource efficient

33
CL Advantages

• Advantages for experts
• Speed, conciseness
• ls ltretgt
• Can express actions beyond a limited set
• Flags, pipes
• Repetition, extensibility
• Scripts, macros
• Easier implementation, less overhead
• Power
• Wild cards

34
CL Dangers

• With added power, comes added responsibility and
  danger
• UNIX
• rm -r
• Deletes every file that you have, and you cant
  get them back

35
CL Reflection

• Command languages are often maligned (for good
  reason)
• But increased functionality can win out over bad
  UI (e.g., UNIX)
• Try to get both
• Avoid excess functionality (comes at cost)

36
CL Design Goals

• Consistency
• Good naming and abbreviations
• Doing your homework in design can help alleviate
  some of the negatives

37
Consistency

• Provide a consistent syntax
• In general Have options and arguments expressed
  the same way everywhere
• UNIX fails here because commands were developed
  by lots of different people at different
  organizations
• No guidelines provided

38
Order

• English SVO subject verb object
• CL S assumed (you)
• Is VO or OV better? rm file
• file rm
• V dO iO vs. V iO dO
• print file calvin
• lpr -Pcalvin file

39
Syntax

• Pick a consistent syntax strategy
• Simple command list
• e.g, vi, minimize keystrokes
• Commands plus arguments
• realistic, can provide keyword parameters
• cp fromfoo tobar
• Commands plus options plus arguments
• what you usually see

40
Terminology

• Keep terminology consistent
• Same concept expressed with same options
• Useful to provide symmetric (congruent) pairings
• forward/backward
• next/prev
• control/meta

41
Example

• vi text editor
• w - forward word
• b - backward word
• Wouldnt f be better for forward?
• f already used
• How about fw and bw?
• Extra keystrokes

42
Ordering

• Keep ordering consistent
• VO seems to be the most natural
• Typically need to pick where options go
• Example
• ln -s file1 file2 (I can never remember)
• Think of cp file1 file2

43
Names and Abbreviations

• Specificity versus Generality
• General words
• More familiar, easier to accept
• Specific (typically better)
• More descriptive, meaningful, distinctive
• (Nonsense does surprisingly well in small set)

44
Abbreviations

• Abbrevs. allow for faster actions
• Expert performance begins to be dominated by
  motor times such as of keystrokes
• Not good idea for novices
• (Allow but dont require)
• IBM CMSi and DEC VMS had shortened commands-
  first uniqe characters were enough
• filelist -- f, fi, fil, file, filel, fileli,
  filelis, filelist

45
Picking Good Abbrevs.

• Strategies
• Simple truncation (works best, but conflicts)
• Vowel drop plus truncation (avoid conflicts)
• First and last letters
• First letters of words in a phrase
• Standard abbrev from other contexts
• qty, rm, bldg
• Phonics
• xqt

46
Abbrv Gdlns

• Use single primary rule (with single fallback for
  conflicts)
• Use fallback as little as possible
• Mark use of fallback in documentation
• Let user know primary and secondary rules
• Truncation is good but generates conflicts
• Fixed length is better than variable length
• Dont use abbrevs in system output

47
WIMP

• Focus Menus, Buttons, Forms
• Predominant interface paradigm now (with some
  direct manipulation added)
• Advantages
• ?

48
Menus

• Key advantages
• 1 keystroke or mouse operation vs. many
• No memorization of commands
• Limited input set

49
Menus

• Many different types
• pop-up
• pull-down
• radio buttons
• pie buttons
• hierarchies

50
Menu Items

• Organization strategies
• Create groups of logically similar items
• Cover all possibilities
• Ensure that items are non-overlapping
• Keep wording concise, understandable

51
Bad Example

• Travel web page links
• Flight page
• 3 Best Itineraries
• Flights Prices
• Timetables
• Fares
• Which do you choose for reservations?

52
Presentation Sequence

• How does Mac, Netscape, etc, do it?
• Use natural if available
• Time
• e.g. Breakfast, Lunch, Dinner
• Numeric ordering
• e.g. Point sizes for font

53
Presentation Sequence

• Choices
• Alphabetical
• Group related items
• Frequently used first
• Most important first
• Conventional order (MTWRF)
• Dont change the order on the fly!

54
Presentation Sequence

• User studies
• Novices alpha gt functional gt random
• Experts categorization
• How would you do it in general?

55
Presentation Sequence

• One possible methodology (first-gtlast)
• Natural order (if exists)
• Frequency of use
• Order of use
• Categorical
• Alphabetical
• Dont change dynamically!