JACOB GUIGuidelines
From JACOBWiki
Contents |
Title page
jACOB GUI Guidelines
(non technical view)
[edit] General
[edit] What is the Purpose of these Guidelines?
These guidelines describes how to develop usable and accessible Web applications using the jACOB Framework.
The three major building block are:
General rules for the design and accessibility of jACOB applications.
Rules for the overall layout and for special layout controls.
A reference section – the main part of these guidelines – describing the look and behavior for each jACOB UI control.
[edit] Layout Hierarchy
The user interface for the jACOB Web Client consists of six parts: title area, left navigation bar, tools, result list, work area, and status bar.
The visual emphasis on the different areas is determined by how often call center agents need them; the focus is on those areas where agents spend most of their time.
The result list and work area are the primary visual focus. The work area is where agents carry out their main tasks. The left navigation bar and the work area tools are the secondary visual focus. The navigation bar allows agents to call up the tasks they need, and the work area tools provide the functions for those tasks.
The status bars and title area are rarely referenced. The title are could contain the name of the application, while the status bar generally displays the application status.
[edit] Capitalization
There are two systems of capitalization used in program strings. When to use which system is included in the rules for different situations.
[edit] Title-Capitalization
Title-style capitalization is, unfortunately, quite complicated. Just do your best to follow these simplified rules. The rest will be cleaned up in the proofreading process.
- Capitalize the first word no matter what is it
- Capitalize all major words
- Lowercase the, an, a, and, but, for, or, nor, to, and as
- Lowercase prepositions, such as up, in, down, new, old and of
- Capitalize the last word
The following are some examples strings in title-style capitalization.
- Hostname and Name Server Configuration
- Do Not Use LDAP
- Reload All Patches from Server
The specific rule followed in the proofreading process is the Chicago Manual of Style rule 8.167.
[edit] Sentence-Style
Capitalize the first word. Only capitalize other words if they are proper nouns or names.
[edit] System Messages
[edit] General Rules
Use sentence-style capitalization for system messages.
[edit] Wording
1. Don’t use technical jargon.
2. Don’t use Please.
3. Don’t use the word ’Error’.
4. Speak the user language.
5. Use positive construction.
6. Use imperative.
7. Always use a verb in a sentence with a dot at the end of the line of the sentence.
8. No special characters like <>"’-*# in the sentence.
9. Do not use abbreviations like e.g, etc., i.e.
10. No article at the beginning of the sentence.
11. Do not shout at the user.
The term ’Error’ message is relevant only to programmer, it has no equivalent in our day-to-day conversation with other peoples. ’Error’ has a strong negative connotation. It adds nothing between the computer and the user. And can only decrease the spirit of cooperation between the user and computer.
Your application is designed to cooperate with the user, helping him or here to complete some task. Using exclamations points (!) in your messages, either in the message, in the title or as icon transforms your program from a cooperative partner to pompous, arrogant ass. Avoid them.
[edit] Examples
Bad: Personal number has not been entered
Good. Enter personal number.
Bad: Please enter the company code
Good: Enter the company code.
Bad: The data can’t be saved.
Good: Data cannot be saved.
Bad: Error: You have entered an invalid date!
Good: Enter date in format DD.MM.YYYY
Bad: Would you exiting without saving?
Good: Would you save the data before exiting?
[edit] Layout
[edit] General Layout Strategy
This describes a general strategy for layout jACOB applications and forms. Layout a form is not just "throwing" controls on a page. Several aspects have to be considered, such as
- Flow of control - how the user progresses through a form when doing his or her work
- Dependencies - how elements on a form affect each other
- Togetherness - which elements on a form belong to each other, there may be closer and farther relations between elements
- Aesthetics and general Gestalt principles - how information can be effectively communicated visually
There are three steps in layout - these can be done in the following sequence: Determine the
1. Sequence of elements (vertical, horizontal)
2. Nesting of elements
3. Spacing between elements at different hierarchy levels.
The sequence takes care of the flow of control, dependencies, and information about which elements belong together - the latter in a more linear fashion. The nesting also takes care of dependencies and of togetherness -- but in a hierarchical or top-down fashion. The spacing takes care for aesthetics and the proper application of Gestalt principles (mostly togetherness).
[edit] Spacing between Grouped Controls
[edit] Spacing between Single Controls
The following controls are covered here:
- Groups of entry Fields – this is the most often needed case for form-line applications.
- Check box Groups – these elements are often used in groups for offering choices or options.
- Mixed Form elements in Vertical succession – this case covers combinations of different input elements, which are arranged in one vertical column; for several columns refer to the spacing for multi column checkbox groups.
The spacing rules in short:
- Vertical spacing between single elements: 5 pixels for fields and dropdown list boxes, 8 pixels for checkboxes and radio buttons
- Horizontal spacing between multiple columns: 15 pixels
- Horizontal spacing between label and input element, width of label column: Width of widest label plus an offset of 8 to 22 pixels
- Spacing between selection element and label: 8 pixels for checkboxes and radio buttons
Below you find positive and negative examples for all these cases.
Leave an offset of five pixels between entry fields.
It is common style to have fields that are left aligned with ragged edges on the right side.
Justified fields are not necessarily wrong. However, it is hard to figure out why one needs a birth date field with more than eight characters.
As one can never predict the length of a fields label on the one side, and how many fields will be necessary in one scenario in succession on the other, it is hardly possible to give a standard offset between label and entry field.
Here you can still adjust the largest label and its corresponding field but it becomes almost hard work adjusting "E-mail" to its input field.
Thoug all offsets seem to look correct the missing offset between "Reenter Your Password" and its entry field makes the whole interface look ugly.
Leave an offset of five pixels between entry fields. It is common style to have fields that are left aligned with ragged edges on the right side.
Between field like form elements in a vertical succession is always an offset of 5 pixels.
Above and beneath button like form elements is always an offset of 8 pixels regardless of the following or previous element.
Leave an offset of 15 pixels between columns of form elements.
[edit] Visible Controls
[edit] Button
[edit] Common
Use title-style capitalization for buttons, except for certain small words, such as articles and short prepositions.
Use buttons only for few and very important functions. A lot of buttons make a screen look heavy and complex. Therefore, when in doubt about a button or a context menu entry, go with a context menu entry.
Pressing the Enter key activates the default function.
[edit] Rules
1. Whenever a function can lead to lost data, provide the user with a warning.
2. Use an infinitive verb, such as Cancel, Close, Delete, or Save when it is clear what object is affected by the action. When it may not be clear, use the verb with the name of the object, for example, Add to Shopping Cart not To Cart.
3. Be as precise as possible. For example, write Change Address not Process Address.
4. Use ... at the end of command that open a pop-up or new dialog requiring user input.
5. Do not use ... on navigational buttons, such as Next or Back.
6. When the group of buttons allows the user to do different things with the same object, use the verb alone on each pushbutton. For example, if he is working with an invoice, write Change on one button, and Display and Cancel on the others instead of Change Invoice, Display Invoice and Cancel Invoice.
7. When the group of buttons allows the user to do the same thing with different objects, use the object alone. For example, if he or she is making changes to various objects, write Invoice, Cancellation and Address instead of Change Invoice, Change Cancellation and Change Address.
[edit] Usage
Disabled buttons indicate that a function is not available. Therefore, use disabled buttons for functions that are temporarily disabled. For example, a certain system state, such an error, may prevent that the user can execute a function.
Hide buttons that are permanently not available for a user. For example, a user may not have the permission to perform certain actions.
[edit] Image
[edit] Common
Use title-style capitalization for the labels.
[edit] Usage
The image control displays a bitmap in GIF, JPED or PNG format. The width and height of the image can be specified.
Photographs, graphics, chart- and diagrams, maps, sketches may be used in the jACOB application. If used properly, they carry great amounts of information, which would take up much more time and screen space, if they were explained in words.
[edit] Chart
[edit] Common
A chart displays data that are relevant for the user in a graphical representation so that the characteristics of the data and their relations are easy to capture for the user.
[edit] Date
[edit] Common
Use title-style capitalization for the labels.
[edit] Usage
The date field is a control control for advanced handling of all actions, which requires a date input and to visualize a date. Thus, the main purpose of the date field is to ensures that the date is entered in an appropriate format.
[edit] List Box
[edit] Common
Use title-style capitalization for the labels.
The list box is a box that displays a list of items where users can select one item from. If the number of items exceeds the box size, a vertical scrollbar is activated. The list box is read only.
There are two possible ways to align the description label of the edit control:
- In line with other fields within a field group with a label to the left
- Above the list box control
[edit] Dropdown List Box
[edit] Common
Use title-style capitalization for the labels.
[edit] Rules
1. Always propose an appropriate default value in the list box field.
2. If there is no suitable default value, display No object selected. Do not leave the field empty, and do not use it for instructions.
3. When using a list box for navigation, set the system to act on the users choice when he or she presses Go. Don’t use a UI hook for automatic navigation on selection change.
4. Dropdown list boxes are most appropriate for up to 20 alternatives.
[edit] Input Field
[edit] Common
Use title-style capitalization for the labels.
[edit] Rules
Typically, the label is placed left to the input field, while the description follows the field. There is one exception to tis rule. You may use small labels if you place the labels above input fields to achieve a more compact design.
|
|
Often input fields are grouped to form a semantic block of input data, such as address data, or bank data. In that case, input fields should indicate how many characters the user has to enter. Therefore, it is not appropriate to set all fields within a group to the same size. That is important because input fields are often used in combination with other input types, such as checkboxes and radio buttons.
|
|
 |
 |
Zeichnung 1: Good and bad example of groupd input fields
[edit] Check boxes
[edit] Common
Use title-style style capitalization for labels.
[edit] Rules
1. Use checkboxes when the user needs to be able to select multiple items simultaneously, or select only one item, or select nothing.
2. Checkboxes are most appropriate for up to 7 - 9 items.
3. A horizontal arrangement is good for 2 to 4 checkboxes,
4. Vertical arrangement or a matrix is good for more.
5. Place checkboxes (or a single checkbox) that refer to one or more fields below, and left-aligned with, the field or fields. When there is enough space, you can place a single checkbox to the right of the field or fields. If it refers to multiple fields, place it to the right of the last field.
6. Place checkbox labels to the right of the checkboxes.
7. When other screen elements are dependent on the setting of a checkbox, place them below the checkbox, and use an unmarked checkbox for the default case.
[edit] Label
[edit] Common
Use title-style capitalization for labels.
[edit] Rules
1. Ending punctuation, such as : or ., should not be used.
2. Use words or short phrases that users easily understand.
3. Use nouns or phrases with nouns.
4. Use title case, for example Shipping Address not Shipping address.
5. Do not use punctuation at the end of the word or phrase.
6. Place a label to the left of the field it describes. If this is not possible, place it above, and left-aligned with, the field.
7. Remember that translations may require more space than the original language, and provide some extra spaces.
8. Consider providing a link to the glossary if it would help understand the field label, and if it is possible.
[edit] Table View
[edit] Common
Use title-style capitalization for column and row headers. Use sentence-style capitalization for entries. Do not use ending punctuation.
[edit] Text Edit
[edit] Common
Use title-style capitalization for labels.
[edit] Rules
Use the text edit control to allow users to edit line of text. The text is restricted to a single font, size and style. The scrollbar is enabled when the number of text lines exceeds the number of visible lines.
There are two possible ways to align the description label of the edit control:
|
|
[edit] Dialogs
[edit] Tree Dialog
The programmer pointed out that a tree soon fills up with identical icons differentiated only by the names that appears beneath. He suggest that a greater variety of icons be used because the "environment is a visual one". He’s right in that tree full of identical icons is just a waste of space. He goes on to suggest that four different icons be used. But there will still be lots of identical icons lying around. He doesn’t take the next step and realize that the icons are totally unnecessary. In making graphics-based interfaces we must remember that text is also a visual cue, it is a very powerful one that is full of specific content, and one that we all know very well. Text is pften the best visual cue possible;we are expert at visual differentiating one word from another (especially f they are not printed in all upper case letters) and can convey quite specific content.
TODO: Image of good an bad TreeDialog
[edit] Message Dialog
No messages are good messages. Dialog boxes need extra effort of the user. Both physically and psychologically. Reconceive the need of each message box.
[edit] Example
If you have a purchase order open and you want to do an item inquiry you receive the following dialog box: "This function may not be used when Create/Update P.O. is running". The correct user reaction is: Why not?
It is clear that the designer were not aware of real work flow of the user’s task.
The general principal here is that almost any overly-structured work flow approach to system design risks impeding a user whose task or inspiration demands a different approach. In this case the interface moves from aiding the user to being a dictator. A computer should be servant, not a peer or boss.
