Welcome to the GUI Guidelines Home Page
Guidelines for Graphical Interfaces Targetted at Scientific Programmers
Users & Developers Don't Like the Same GUIs
- GUI developers appreciate & are rewarded for:
- GUI "sex appeal"
- graphics instead of text
- impressive complexity
- Scientific programmers prefer
- no bells or whistles
- command-line interface, too
- impressive simplicity
Examples of Developer Reactions to GUIs
"That's a great way to show ..."
"... and what does Cntl-click do?"
"Can I see all eight views at the same time?"
"This will make great screendumps!"
"Can I launch all the other tools from this one?"
"How much of the appearance can I customize?"
Examples of User Reactions to GUIs
"Why is it taking so long?"
"Which part am I supposed to be looking at?"
"Why is it showing me this?"
"What do I do next?"
"How can that help me improve my program?"
"How much work does it take?"
How Ptools Can Help
- Working groups are "discovering" things about
- what users like
- what users dislike
- how to make GUIs clearer to users
- when to use command-line interfaces
- That information is used for the project, but non-project people never see it.
- save info on users preferences for GUIs
- consolidate the info for quick reference
- make info available online
Draft GUI Guidelines
- Eliminate windows.
- Use as few windows as possible.
- rationale: To reduce visual complexity.
- criteria for applying:
- Is it really necessary to see more than one view at the same time?
- Are the views dramatically different in size, scale, or appearance?
- Are the controls dramitically different in the different views?
- Are there too many views to accomodate via buttons?
- Consolidate related windows into a single window.
- Is there a flat or hierarchical organization of windows and functionality?
- Use a message area instead of dialog boxes.
- Integrate the user input fields into the the main display.
- Consolidate related dialogs into a single dialog.
- If a functionality is used frequently, make it a part of the main display.
- Use consistent, simple terminology.
- This section refers to the names used for menu items, messages, and
- Make these names simple, unambiguous, and consistent across tools.
- Use a verb when an action will take place (including a new window coming
- instead of process subset, use select process
- instead of color mapping, use change color
- instead of filter, use apply filter
- Avoid computer science jargon:
- instead of asynchronous send, use non-blocking
- instead of acyclic tree, use call graph
- Pay attention to good visibility.
- Make one or two important elements the most visible ones.
- Center these important elements in the viewing area.
- Use color (red and orange stand out), font (italics first, bold second),
size, shape, or outlining to make important elements more visible.
- Be explicit about current versus default settings.
- Change the appearance of the settings:
- For radio groups, show the current setting using a special color or highlighting.
- For buttons, show the current one in use by desensitizing it.
- Provide a message about what is happening.
- Frequency of use.
- Make frequently used functions available as buttons or radio groups.
- rationale: GUI components that invoke frequently used or main functions
should be conveniently located and highly visible. Quick access GUI
components, such as buttons, are good for invoking these functions.
- Option settings should be presented as radio groups.
- Frequently used commands should be presented as buttons.
- View controls can be either buttons or radio groups.
- Radio groups can be arranged hierarchically.
- Buttons should have a flat organization, and may be grouped into panes.
- Only use option lists when screen real-estate is important.
- Showing the user what to do next.
- The less obvious the function is to the user, the more visible the cue
- Use a message area to suggest an action (e.g., click here to see....
- If a preparatory action is needed, prompt the user automatically. For
example, if the user has to click the Load button before the
Run button, bring up the load dialogue automatically. Don't just
desensitize or disable Run, and don't just depend on an error
dialog stating Load first.
- Menu organization.
- Avoid cascading menus; try radio groups instead.
- If items are related or similar, group them together.
- If there are dependences (e.g., a sequence of actions), put the items
in the order they have to be carried out.
- Order items based on frequency of use; frequent ones first.
- Use hot keys for the most commonly used items only. Make hot key labels
simple (pneumonic) for easy remembering.
- Use radio groups in menus for alternatives.
- Menu items shouldn't change; but you can desensitize them.
- Message are location.
- Position message areas where the user will be already looking.
- just above the button controls
- just below the scroll bar of the main viewing area
- There should be enough room in a message area to contain a long string.
- Advanced features.
- Provide advanced features only if a number of users explicitly request them.
- Outlining areas.
- Each area in the application window should be outlined so that the
interface appears well organized. A thick outline emphasizes the
enclosed area. Each area can be further divided using dividers
according to the functional nature of its components.
- Dialog controls.
What YOU Can Do to Help
- If you're a tool developer, tell us:
- what info would help you most
- how it should be organized for easy searches
- by GUI element (menus, dialogs, etc.)?
- by function (presenting choices, launching commands, etc.)?
- whether you want to see explanations, or just guidelines
- If you're a tool user:
- join the mailing list for electronic queries
- tell the developers here what you like/hate about GUIs
GUI Guidelines: Status Update
- Feedback from users and ISVs
- On-line guidelines for tool developers
- On-line pointers to bibliographic references (e.g., color standards)
- Functionality to support in buttons/menus
- Standardizing access to common functions across reference implementations (e.g., hot keys, killing an application)
- Providing visual feedback about operations (e.g., during lengthy operations, when displays are selectable)
- Look-and-feel for "standard components" (e.g., file selection, option specification, menus)
- What to include in distribution (demo/sample/makefile/setup files)
- Importance of non-graphical interfaces for remote users
- Distributing the GUI front end onto desktop
- Need for "GUI review process" for all Ptools projects
(but who will do it?)
- Reference implementation of standard components would be highly desirable
(but who will do it?)
This page was last updated on 6/12/95