CSE 8316 User Interface Design Rob Oshana Southern Methodist University

Interaction Styles

Agenda Windows Files Storage and Retrieval Systems Menus Forms Dialog boxes Typed command languages

Introduction Interaction Style: A collection of interface objects and associated techniques from which the designer chooses Provide behavioral view for user communication These objects are implemented with widgets/toolkits This implementation falls in the constructional domain

Steps to good GUI design Know your client Understand the business function Understand the principles of good screen design Develop system menus and navigation schemes Select the proper kinds of windows

Steps to good GUI design 6. Select the proper device based controls 7. Choose the proper screen based controls 8. Write clear text and messages 9. Provide effective feedback and guidance and assistance

Steps to good GUI design 10. Provide effective internationalization and accessibility 11. Create meaningful graphics, icons, and images 12. Choose proper colors 13. Organize and layout windows and pages 14. Test, test, and retest

Windows

History Xerox PARC - Apple Mac Contributed many things mouse rectangular window scrollbar push button desktop metaphor pull down menus

PARCs Principles Modes Overlapping Windows Tiling confusing and frustrating Overlapping Windows metaphor of overlapping sheets on desk Tiling more than one application on the screen

Description Window: Screen object that provides basis for other interaction objects All interaction occurs through the window Two types: Primary: The first window for an application, acts as ``parent'' for other windows Secondary: Created from primary. Include such objects as dialogue boxes

Standard window decorations Control menu Maximize button Window border button Title bar Minimize button Window Name Client area Window border Minimize button Close button Title bar Maximize button Window Name Client Area Sizing grip

Interaction restrictions in modeless and modal windows

Unnecessary Rooms Should not add windows to our program unless they have a special purpose that can’t or shouldn’t be served by existing windows A dialog box is another room. Have a reason to go there Build function controls into the window where they are used

Necessary Rooms When providing a function out of the normal sequence of events, provide a special place to perform it Examine the users goals Don’t put every function in a dialog box

Windows Pollution A gallon of oil won’t make a bicycle pedal itself No way to show the connections between lots of windows modal dialogs don’t count; they always get you back immediately to the point of departure Tools make it easy to make lots of windows and boxes

Guidelines Don't overuse windows Minimize window manipulation needed Give user flexibility to move and resize Tiled windows give better user performance, but require more area Appearance and behavior of primary window should be consistent Primary is user's home base

Guidelines Use different windows for different independent tasks Allows one-to-one mapping to be set up in mental model Completion of task equates to completing window

Guidelines Use different windows for different coordinated views of the same task Permits examination from different perspective or detail All views should be updated uniformly to prevent inconsistency between windows

Files

Tragedy of the file system Most difficult to understand Main memory and disk storage confusing Programs stored in two places at once Putting might on will; user might say no but will probably say yes

Problems caused by disks Disks and files make users crazy Influence of the file system on the user interface is deep We still render the implementation model to the user

Problems caused by disks Behavior characteristics applied based on real world metaphor only one document it belongs to the user Implementation model violates most of these Disk drive is the book shelf Main memory represents the hands doing the editing (copy is made!)

Dispensing with the disk model “Put the book back on the shelf” instead of “Save changes” Structure commands according to the goals of the user instead of according to the needs of the operating system Change “file” to “document”

Designing software with the proper model Treat documents as single instances instead of copies - unified file model Save automatically at intervals countdown clock noticeable delay wait til the user stops typing to save

Designing software with the proper model Closing Does not map well to unified model Required knowledge of file system

Designing software with the proper model Rude error message for something that a user should be able to do

Archiving No explicit function for making a copy of or archiving a file Must use the “save as” function Not very clear “Save as” dialog is the wrong tool for making and managing copies

Unify the file model If the file system is going to show the user a file that cannot be changes because it is already in use, this should be indicated to the user special color or icon Pull a hammer out of the toolbox only to look inside and find another hammer!!

Document Management Goal directed functions creating a copy of the document creating a milestone copy of the document naming and renaming the document placing and repositioning the document specifying a stored format for the document reversing some changes abandoning all changes

How did we get here? From a user’s point of view, there is no reason for a disk to exist Advantages for the engineer; disks are cheaper than solid state memory once written to, disks don’t forget when the power is off disks provide a physical means of moving information from one computer to another

How did we get here? Drawbacks Mainly a cost issue slower than solid state memory less reliable with many moving parts more space and power CPU needs help to access processing more complex Mainly a cost issue

Storage and Retrieval Systems

Storage vs. Finding In the real world, storing and retrieving are linked Not so in the digital world Storage system; a tool for placing goods into a repository for safekeeping physical container tools necessary to put objects in and take them back out again

Storage vs. Finding Retrieval system; method for finding goods in a repository logical system that allows the goods to be located according to some abstract value name position aspect of contents

Storage vs. Finding Real world retrieval indices author subject title We ignore these in the computer world where we put them what we named them

Storage vs. Finding Books can also be identified by color shape Location may change bookshelf coffee table night stand We don’t find a book by referring to its contents!!

Retrieval Methods Positional retrieval; remembering where you left it Identity retrieval; remembering its identifying name Associative retrieval; remembering some inherent quality of the document

Indexing Libraries used Dewey Decimal system because names can be too disparate or insufficiently unique good approach to storage Card catalog helps in retrieval Libraries provide three indices author subject title

Indexing Each index is associative allows the user to find the book according to an inherent property of the book other than its identifying number or its location on the shelf Retrieval is done by looking up one of the indices, find its number, find the row of books, examine signs

Retrieval Systems in Computer

Retrieval Systems in Computer

An associative retrieval system Enables us to find documents by their contents Should know where documents can be found Create temporary or permanent groups of files Browse by synonym or related topic Assign attributes to files

Things to remember The program that created the file The type of document The program that last opened the document If the document is very large or small If the document has been untouched for a long time The length of time the document was last open

Getting Better SGML and XML OLE Unix standard file formats

Menus

Brief History Typing commands into a standard keyboard was once considered revolutionary Command line interface Hard to know what to type Still preferred today in some spaces Modern complexity makes it hard to use

Brief History Hierarchical menu in the late 70’s User could forget many of the commands and option details Read information of the screen instead of keeping it in your head Very sequential in nature due to batch nature of computers at the time

Example Enter transactions Close books for month Print income statement Print balance sheet Exit

1. Enter Transactions Enter Invoices Enter payments Enter invoice corrections Enter payment corrections Exit

Lotus 1-2-3 Revolutionary Visible hierarchical menu Took advantage of 1979 computer screens 2000 characters/screen 25 horizontal rows 80 characters each Powerful because it enabled users to move in an ad hoc, piecemeal fashion, from beginner to expert

Monocline grouping Method of organizing things into a single layer of groups simple and powerful (users mental model) the method we use at home/office never exceeds a single level of nesting Most users don’t like hierarchies in a file cabinet you don’t see folders within folders

Command types Command vector; each distinct technique for issuing instructions to a program Multiple command vectors - each function has menu commands toolbar commands keyboard commands direct manipulation commands

Migrating commands Immediate vectors direct manipulation; immediate affect on the information without intermediary menus and dialog boxes don’t have this toolbar-button command vectors no delay between pressing a button and seeing the results of the function Most frequently used commands migrate to buttons on the toolbar

Menu commands Menu commands that have the advantage of natural language descriptions of the functions, and the detailed controls and data that appear on corresponding dialog boxes Menus and dialog boxes are the pedagogic vector

Menus Hard to first understand what a complex application can do We look at the menu Similar to a restaurant menu that we view at the entrance to get a feel for type, price, setting, etc

Menus must be complete Full selection of actions and facilities available in the program Hints that describe keyboard equivalents

Example

Description Menu: Object that provides a list of items from which one or more of the items are selected. One of the most popular, easiest to use interaction objects Promotes recognition over recall Reduces typing errors Wide assortment of styles

Structures of menus Single menus Sequential menus Simultaneous menus Hierarchical menus Connected menus

Single menus Single screen to seek input or request action to be performed Conceptually require choices from one menu only and no others will follow User only considers immediate consequences May be iterative – data entry

Single menus Galitz, Essential Guide to User Interface Design

Sequential linear menus Presented in a series of screens possessing only one path Presented in preset order (may be problem if user wants a different order) Objective to specify parameters or for entering data Path may be short or long (long may become tedious) All important and require user action

Sequential linear menu Galitz, Essential Guide to User Interface Design

Sequential linear menu

Simultaneous menus Instead of being presented on separate screens, all menu options are available simultaneously Menu may be completed in order desired by user Choices can be skipped and returned to later Tedium associated with long series of sequential menus greatly reduced Large collections of alternatives can clutter screen – paging or scrolling may be necessary Important to clearly indicate menu choice relationships and dependencies (this can be confusing if not done right)

Simultaneous menus Galitz, Essential Guide to User Interface Design

Hierarchical Menus When many relationships exist between menu alternatives, and some menu options are only appropriate depending on a previous selection, a hierarchical structure is the best solution This approach provides an increasing refinement of choice as menus are stepped through Options to suboptions Categories to subcategories Pages to sections to subsections Represent with an inverse tree

Hierarchical Menu Galitz, Essential Guide to User Interface Design

Hierarchical Menus Examples are menu bars with pull-downs Web sites with navigation links Order and structure of branching in a hierarchy is preset Normal order of flow is one way top down Branching order may not fit user conception of the task flow May go down wrong paths

Connected menus Networks of menus interconnected in some manner Movement not restricted to a hierarchical tree – permitted between most or all menus in the network My be cyclical or acyclical (movement in only one direction) Gives user full control over navigation flow For novice, complexity and navigation may be daunting

Connected menu Galitz, Essential Guide to User Interface Design

Event trapping menus Provide ever-present background of control over the system’s state and parameters while the user is working on a foreground task Serve three functions Immediately change some parameter in the current environment (bold text) Take user out of current environment to perform function (spell check) Exit and allow user to go to new environment (exit)

Event trapping menus Paste option will only function if there is something in a clipboard to paste

Suggested Menu Structure Program Document Pieces Help Properties Views Functions Access Properties Views Functions Access Properties Views Functions Access

Suggested Menu Structure Far left is the topic of broadest scope (program) Move to the right with diminishing scope Submenus in descending order of importance properties views of them functions that operate on them access to the “outside world”

Program Menus Default settings What templates are available What mode it is in Configuration of standard interface idioms like toolbars Personalization items like color and graphics

Document menus Covers document under construction Prime menu items cover properties of the currently active document Views (draft vs presentation) Functions that operate on the entire document at once calculating spreadsheets formatting text Most recently used information

Pieces of the document Covers objects embedded in the document (tables or images) Only active when the particular object is selected Handles transformations like rotation, formatting Ability to load and save objects to/from other documents/disk

File Menu accelerators mnemonics separator MRU list

Pop up menu Used to present alternatives or choices within the context of the task Choices are context sensitive depending on where the pointer is positioned and when the request is made

Pop up menu Advantages Appear in working area Do not use window space when not displayed No pointer movement needed if selected by button Vertical orientation efficient for scanning and grouping Disadvantages Existence must be learned and remembered Require a special action to see the menu Items are smaller than full size buttons which slows selection time Display locations may not be consistent

Pop up menu guidelines Provide a pop-up menu for common, frequent, contextual tasks Items that cannot be chosen due to the current state of an application should not be displayed Continue to display pop-up until Choice is selected An action outside the pop-up is initiated The user removes the pop-up

Iconic menu

Iconic menu Use to remind users of the functions, commands, attributes, or application choices available Create icons that Help enhance recognition and hasten option selection Are concrete and meaningful Clearly represent choices

Iconic menu advantages/disadvantages Pictures help facilitate memory of applications Large size increases speed of selection Pictures consume more screen space and difficult to organize for scanning efficiently Creating meaningful icons requires special skills and extended time

Menu System Standard menus Optional menus File menu Edit menu Windows menu Help menu Optional menus View menu Insert menu Setting menu Format menu Tools menu

Types Push-Button Menus Choices are in terms of push-buttons, sometimes called a button bank Typically one of the selections is the default and is highlighted in some way Selection may be based on pointer object or keyboard accelerators Articulatory feedback is given Need to label carefully and clearly -- shortness of label versus clarity of meaning

with text labels, graphic labels, Example push buttons with text labels, graphic labels, or both

Types Radio-Button Menus Check-Button Menus Choices are exhaustive and mutually exclusive, selecting one deselects another Selection indicated by highlighted box Typical for dialogue or property boxes Check-Button Menus Like a radio-button menu, but more than one item may be selected Selections indicated by highlighted box, check mark, etc

Examples of menu options in Motif

Example radio button in MS Windows

Example check box group in Motif

Example of unavailable menu option in Motif

Types Pull-Down Menu Menu title is shown. When selected, entire menu appears, selection is made and menu is hidden Since only title is permanent, provides compromise between pop-up and continuously displayed menus Selection may be done with one or more user actions

Example pull-down menu in MS Windows

Types Pop-Up Menus Menu appears at location where mouse is pressed Unlike pull-down, there is no evidence the menu exists Contents may change depending on location of cursor Minimizes mouse movement and screen real-estate

Example pop-up menu in Motif

Types Option Menu Toggle Menu Appears much like a field in a form, but when selected a menu appears Distinct from pop-up since visual cue of existence Toggle Menu One choice is shown. Clicking on item will sequence through all possible choices User is not presented with all choices at once

Example option menu in Motif

Example menu button in Motif

Types Cascading Menus Like a pull-down, however selecting one choice brings up another menu Helps group into hierarchical fashion Visual clue to existence should be provided Requires more coordination than other styles

Organization of options in submenus

Types Pie Menus Choices arranged as wedges in circle Minimizes mouse movement over linear list Other aspects (such as radius or wedge size) can be used

Types Palette/Iconic Menus Menu consists of an array of icon push-buttons. Used for frequently chosen features or in graphically oriented applications Choice is indicated by highlighting icon

Types Embedded Menus Dynamic Menus Menu items are highlighted/underlined text Selecting text performs action Also called hypertext Dynamic Menus Menu contents change over time Sometimes done by graying out selection items

Example submenu in Motif

Example tear-off menu in Motif

Example menu window in Motif

Guidelines Use the user tasks and system functions to organize hierarchical menus Goal is three to four levels with four to eight items per level Can place tasks on paper and organize into hierarchy to aid design Use meaningful groupings of menu choices

Guidelines Use meaningful ordering of menu choices Orderings include alphabetical, numerical or temporal, frequency Not good to dynamically change ordering

Guidelines Use brief descriptions for menu choices Single word is best Otherwise begin each choice with same type of word (noun, verb, etc) Use a consistent layout across all menus and keep the screen uncluttered Should be covered in customized style guide

Guidelines Allow Shortcuts Separate with white space, use consistent help messages Allow Shortcuts Provide accelerator keys and macros

Other Design Tips Disable menu items when they are moot Parallel visual symbols on parallel command vectors Don’t use bang menu items

Parallel visual symbols

Tips for Creating Good Accelerators Follow standards Provide for their daily use Show how to access them

Forms

Description A series of labeled fields that are to be filled in by the user Intuitive interface, however free form typing is more prone to errors Various types of fields for forms

Field Types User-Typed Strings User Choices from a List Can have validated and invalidated Validated fields should have some visual cue User Choices from a List Toggle and option menus are good for this situation Default Values for Fields All fields for which values can be predefined should have them

Types of Fields Required vs. Optional Values Dependent Fields Should have visual cue as to which is optional and which required Dependent Fields These are fields that are required if a particular value is entered in another field.

Guidelines Use a consistent, visually appealing layout and content Group fields and separate with white space Provide titles and concise instructions Be consistent across different forms

Guidelines Do not assume that existing paper forms convert directly to screen designs and a good user interface Paper forms frequently are not optimal Good opportunity to evaluate purpose of forms, involving users Screen size versus paper is different. Attempting to copy the form directly, but changing some aspects can be confusing

Guidelines Use appropriate visual cues for fields on forms Indicate maximum length, types of input allowed, etc. Use familiar and consistent field labels and abbreviations Field labels should be concise, using standard terms Labels should be located to the left of the field with a simple delimiter

Guidelines Use logical navigation among fields Arrow keys, return key, tab Permit wraparound or direct access using mouse Use logical navigation within fields Support editing and error correction of fields Do no require entire field be replaced, but rather permit changing of single characters

Guidelines Use consistent, informative error messages for unacceptable characters and values Provide explanatory messages for expected field inputs Can be made available on user demand or automatically provided. If automatic, should be concise

Guidelines Provide default values in fields whenever possible Fill in obvious fields, allow user to change Can help describe format for input Provide a completion indicator for each form-filling screen Give user control over when finished Permit cancellation and ability to return to partially completed form

Dialog Boxes

Description A rectangular, delineated screen area that is used for messages, text entry, commands, selection and user control May be initiated by user or system Temporary object that obscures part of screen

Suspension of Normal Interaction Dialog boxes are superimposed over the main window of the owning program Engages user by offering information and requesting some input After editing user has option of accepting or rejecting changes Dialog box then disappears

Suspension of Normal Interaction When the application presents a dialog box, it is temporarily moving the action out of the mainstream Taking the focus off the dinner party and into the kitchen for preparation of the food May be crucial but not the main point Should be use for secondary interaction

Put primary action on the primary window Dialogs break flow

Dialogs break flow Appropriate for functions or actions out of the mainstream interaction Good for presenting infrequently used functions and settings Well suited for concentrating information related to a single subject Serve two masters; frequent users and infrequent user

Dialog box basics All dialog boxes have an owner Always placed visually on top of the owning program Every dialog box has at least one terminating command OK Cancel

Modal Dialog boxes Most common Once the box comes up, the owning program cannot continue until the dialog box is closed It stops the proceedings User can activate other programs while the modal dialog box is up dialog box remains indefinately

Modal Dialog boxes Easiest for users and designers to understand “Stop what you are doing and deal with me now! When you are done you can return to what you were doing” Like a subroutine call Rigidly defined behavior

Modal Dialog boxes Function-oriented; operates on the entire program or document Process- or property- oriented; operates on the current selection Application modal; can only stop their owning application System modal; brings every program in the system to a halt (catastrophic conditions only!)

Modeless Dialog boxes Less common and more misunderstood Owning program continues to run without interruption Does not stop the proceedings Have terminating commands Scope of operation is often unclear

Modal Dialog box design tips Visually differentiate modeless dialogs from modal dialogs Give modeless dialog boxes consistent terminating commands Never change the terminating button captions Things that behave differently should look different!

Making modeless dialog boxes into toolbars

Typical state-of-the-art modeless dialog box

Property Dialog Box Usually modal, but not uncommon to find these modeless

Function Dialog Box Usually summoned from the menu Most frequently modal dialog boxes Control a single function printing inserting spell check

Bulletin Dialog Box Most abused part of the interface Error message box Property and function dialog boxes are intentionally requested by the user they serve the user Bulletins are issued unilaterally by the program they serve the program

Bulletin Dialog Box

Process Dialog Box Like bulletin in the sense that they are erected at the program’s discretion rather than users request Indicate that the program is busy with some internal function Alerts the user to the program’s inability to respond normally Warns the user not to be overcome with impatience

Process Dialog Box Single CPU systems require this to some extent good at time sharing between software tasks once the hardware becomes involved problems arise accessing the disk dialing up a modem

Process Dialog Box

Process Dialog Boxes The program must inform the user when it gets stupid Four basic tasks make clear to the user that a time-consuming process is happening make clear to the user that things are completely normal make clear to the user how much more time the process will take provide a way for the user to cancel the operation

Process Dialog Boxes Process meter

Types List Boxes Entry Boxes Scrollable sequence of users choices Contents are usually dynamic Frequently search cability exists Entry Boxes Allows user to enter data May be one line (as in form field) or multi-line Supports full editing

Example list box in Motif

Example list and text box used in an incremental search in Motif

Example drop-down list box in Motif

Example combo box in Motif

Example drop-down combo box in MS Windows

Example spin box in Motif

Types Message Boxes Usually created by system (not at user request) Contains information from user and allows limited interaction

Types Dialogue Boxes Composite interaction object that contains other interaction objects. Typically part of user task sequence Group various, related functions Modal dialogues grab the user focus and require the user to resolve before continuing Modeless allows user to interact with other window without finishing it

Example text box and label in MS Windows

Example text box labels providing format cues

Guidelines Use brief but comprehensible instructions Because of potential complexity of boxes, instructions should be provided Use carefully worded messages Use logical groupings and orderings of objects in a box Use visual cues to delineate groupings within boxes Keep layout consistent and visually appealing

Guidelines Make defaults visually distinctive Menu selections that lead to dialogue boxes should contain a visual cue Boxes should disappear under user control Windows that appear and disappear ``magically'' confuse the user Exception is for boxes displaying status information

Components of a scroll bar in MS Windows

Example sash in Motif

Example tabbed pages in MS Windows

Example scale in Motif

Example gauge in Motif

Dialog Box Etiquette

Design Tips All dialog boxes should have caption bars Use verbs in function dialog caption bars Use object names in property dialog caption bars Dialog boxes should be as small as possible but no smaller

Reduce Excise

Terminating Commands for Modal Dialog Boxes Offer OK and CANCEL buttons on all modal dialog boxes CANCEL good for pedagogical purposes Bulletin dialog boxes (errors) can get away with just an OK Process dialogs need a CANCEL to stop a time consuming process Never user terminating words in dialog boxes (CLOSE)

The Close Box Don’t put close boxes on modal dialogs disposition of changes is unclear changes accepted or rejected?

Tabbed Dialog Sometimes called “multi-pane” dialog Panes and tabs Helps with size and complexity Follows the users mental model for how things are stored monocline grouping (one level deep) Content must have meaningful rational

Put terminating buttons in un-tabbed area Tabbed Dialogs Tabbed area Un-tabbed area Put terminating buttons in un-tabbed area

Extreme Case of Tabbed Dialogs All idioms have practical limits Don’t stack tabs

Directed Dialogs Changes and adapts its suite of gizmos based on some user input Programming these can get complicated May be confusing to the user Effective when user is entering settings in a clearly sequenced manner

Directed Dialogs

Typed-Command Languages

Description Earliest form of communication Can be very efficient to use, popular with frequent users Requires extensive training and knowledge of syntax

Guidelines Use a consistent rule of formation for entering commands Since learning is more difficult, consistency is essential Typical formation is ``action-modifier(s)-object(s)''

Guidelines Choose meaningful, specific, distinctive command names Can be very difficult since all commands are typically visible at once May permit abbreviations, but that can cause additional confusion Use diametrical opposites for commands that are logically opposite (e.g. create/destroy)

Guidelines Apply consistent rules for abbreviating commands Single characters may work for small command sets For larger, truncation appears best (over such techniques as dropping vowels, first and last letter, etc) Allow easy correction of typing errors Do not force user to retype lines that had errors, but allow editing.

Guidelines Allow frequent users to develop macros Geared towards frequent users Allows for increased speed and customization

Graphical Interfaces

Description The term Graphical User Interface (GUI) has come to represent interaction objects such as windows, buttons, etc. Generally use direct manipulation with an object-action paradigm and visual feedback This is just a subset of various ways to use graphics to communicate. Call that superset graphical interfaces.

Types Data and Scientific Visualization Visual Databases This includes charts, graphs, plots, etc. Widely used in the scientific community to gain insight into large amounts of data (numbers) Visual Databases Store visual images much as you would store text Use stored images to construct simulations

Types Animation Video Effective for simulating various scenarios Also, like visualization, can show temporal relationships Video Combine audio/video with other windows Requires more skill to design effectively

Types Multimedia and Hypermedia Virtual Reality The integration of graphical, audio and video information with associative links Links provide simple navigation through ``hyperspace'' Navigation must be designed carefully Virtual Reality Represents a greater immersion into the application with various sensory devices Still very expensive with much still in development stage

Guidelines Since many of these interaction styles are very new, there is little in the way of hard evidence. The following are heuristics based on common sense and experience Use real-world analogies as much as possible Since systems tend to model the real world, these analogies work best

Guidelines Keep the visual presentation as simple as possible Avoid the tendency to do too much, just because you can

Guidelines Show different views of the same visual object Use color sparingly and meaningfully Use video sparingly Only high-quality video should be used, and that is difficult to produce