Search Tools Links Login

GUI Design Tips v2.0


I am very surprised to see the lack of information in the area of Graphical User Interface (GUI) Design on this web site. Here are some tips to get you seriously thinking about how people use your software.

Original Author: Daniel Cassar

Code

User Interface Design


Version 2


I am very surprised to see the lack of information in the area of Graphical User Interfaces (GUI) on this web site. The useability of your software will largely affect peoples impressions. Here is some information that will hopefully get you thinking more seriously about how you design your software.


1. Applying Psychology to Design



1.1 Sensation & Perception


Don't rely on a visual notification alone to let the user know a process has started or finished. Processes that can take a while may be helped by using audition to let the user know the task has been started or completed. At the same time be weary of sensory overkill, the user doesn't want the system beeping at them every 5 seconds or to have a message box popping up interrupting them from the task they are performing.


Tip: Avoid actions that could stress/frustrate sensory systems.



1.1.1 Feedback


Provide feedback for users actions. Good feedback helps confirm that the software is responding to input and communicates details that distinguish the nature of the action. Effective feedback is timely and is presented as close to the point of the user's interaction as possible. Even when the computer is processing a particular task, provide the user with information about the state of the process and how to cancel the process if that is an option. Nothing is more disconcerting to users than a "dead" screen that is unresponsive to input. A typical user will tolerate only a few seconds of an unresponsive interface.


Tip: You can communicate simple information through mouse pointer changes, sounds or a status bar message; for more complex feedback, you may need to display a progress control or message box.



1.2 Attention & Performance


1.2.1 Decision Automation


The operational assumption is that the user - not the computer or software - initiates actions. The user plays an active rather than reactive role. You can automate tasks, but implement the automation in a way that allows the user to choose or control it.


Tip: Do not automatically get your program to run on start up or place icons on the desktop.



1.2.2 Design for Learning


Initial performance by new users is slow and may require attention and guidance, however once a task has been learnt continually guiding a user through the task is both slow and frustrating, the option to better automate the task needs to be available to the user.


Tip: Make use of program preferences to turn on/off help aids.


Tip: Have multiple ways of executing common tasks such as menu options, icon bars, shortcut-keys and dropdown menus.


Tip: Make menu bars and tool bars more customable.



1.2.3 Design for Error


Don't just capture boundary conditions. Take into account mistakes of intention and action slips of commission. Users like to explore an interface and often learn by trial and error.


Tip: Make use of message boxes to warn, notify users about potential situations where they could damage the system or data, or better, makes actions reversible or recoverable.



1.3 Human Memory


Use existing knowledge when possible. Assist learning by analogy and use recognition over recall.


Don't overload short-term memory, remember an average person has a limit of 7+/-2 ‘chunks' for about 15 seconds. Auditory rehearsal, primacy & recency effects are also a focus of short-term memory. Maintain an external memory for the user where possible.


Design for consistency to avoid interference: Avoid pro-active and retroactive interference


1.4 User Neiching


Who are the people using your software and how often do they use it. You need to take into account their industry background, age, frequency of use and general computer knowledge.


Tip: Be careful who evaluates your software, are they the types of people who will be using it?



2. Design Principles/Goals


Simplicity – Simple tasks should be easy to do


Generalisability – One set of conventions should apply to many tasks


Consistency – Follow established / own conventions


Redundancy – Provide multiple means to accomplish tasks


Documentability – Systems should be easy to document


Accuracy – Online help and documents should reflect actual function


Learnability – Terms/icons/syntax/operations should be memorable/discriminable


Flexibility – Systems should adapt to individual/different users


Recoverability – Systems should allow recovery from errors


Security/Privacy – Systems should not sacrifice privacy/security for ease of use


Stress/fun systems should not be stressful; they should be fun


3. Tradeoffs of Design Principles/Issues


Specificity/Generality: General Systems may not be particularly good at specific tasks


Internal / External: Internally consistent systems may violate external conventions


Learnability / Usability: Easy-to-learn does not imply easy-to-use


Speed/Accuracy: The faster people try to go, the more they will make errors


Information Depth / Breadth: The more breadth provided, the less depth is covered


Batch / Interactive: Systems should support interactive access, with programmability


Passive/Active: Experts may use commands, novices menus, so provide both


Brevity/Verbosity: Amount of information must adapt to user needs


Graphical/Textual: Intuitive graphical interfaces may not be programmable


4. Style Guide



4.1 Controls


Instructional text is generally placed above the control in question, additional information below. Don't forget to properly set the tab index's for the controls in a coherent manner and they have tool tip text if applicable.


4.1.2 Button Labels


Button labels should describe the buttons action and follow book-title capitalisation.


You can use the button label to reflect other information about the button's operation. For example, if the action represented by the button requires additional information, include an ellipsis (…). If the button expands the window to display additional information, include (>>).


4.1.3 Option Buttons & Check Boxes


Limit to a small number, typically seven or fewer. If you need more choices, consider using a different type of control, such as a single-selection list box or a drop-down list box.


Use sentence-style capitalisation with no ending punctuation. Write parallel labels of approximately equal length for related check boxes. If a check box label also acts as the label for the control that follows it, end the label with a colon


4.1.4 List Boxes


List box controls do not include their own labels. However, you should include a label using a static text field; the label enables you to provide a description of the control and keyboard access to the control. Use sentence-style capitalisation for a list box label and end the label with a colon


Use sentence-style capitalisation for items in the list. The width of the list box should be sufficient to display the average width of an entry in the list.


4.2 Menu Items


If the menu is a verb use a noun or noun phrase


Eg. On the Insert menu: Text, Table, Picture



If the menu is a noun use a verb or verb phrase


Eg. On the Table menu: Insert Table, Select Row, Insert Column



4.3 Shortcut Keys


Use the following guidelines for designing shortcut keys:



  • Assign simple and consistent key combinations.

  • Make shortcut keys customizable.

  • Use a shortcut with the CTRL key for actions that represent a large-scale effect, such as CTRL+S for save current document.

  • Use the SHIFT+ key combination for actions that extend or complement the actions of the standard shortcut key. For example, the ALT+TAB shortcut key displays the primary window of a running application. Alternatively, the SHIFT+ALT+TAB key combination allows you to navigate backward through currently running applications that have been previously accessed.

  • Use the SPACEBAR key as the default action of a control, such as for pressing a button control or toggling the status of a check box control. This is similar to clicking the left or primary mouse button.

  • Use the ENTER key for the default action of a dialog box, if available.

  • Use the ESC key to stop or cancel an operation.

  • Avoid modified or case-sensitive letters for shortcuts.

  • Avoid using the following characters for shortcut keys: @ £ $ {} [] ~ | ^ ' < >

  • Avoid ALT+ letter combinations because they may conflict with access keys. In addition, the system uses many specific key combinations for specialized input; for example, ALT+~ invokes an input editor for the Japanese language.

  • Avoid CTRL+ALT combinations because the system interprets this combination in some language versions as an ALTGR key, which generates alphanumeric characters.

  • Avoid assigning combinations that are reserved or defined by the system or are commonly used by other applications.

  • Do not use the Windows logo key as a modifier key for non-system-level functions.



  • Common shortcuts: New - Ctrl-N; Open – Ctrl-O; Save – Ctrl-S; Print – Ctrl-P; Undo – Ctrl-Z; Cut – Ctrl-X; Copy – Ctrl-C; Paste – Ctrl-V; Select All – Ctrl-A; Find – Ctrl-F; Goto – Ctrl-G.

About this post

Posted: 2003-06-01
By: ArchiveBot
Viewed: 120 times

Categories

Visual Basic 6

Attachments

No attachments for this post


Loading Comments ...

Comments

No comments have been added for this post.

You must be logged in to make a comment.