[swordfish-dev] FW: UI Guidelines from Eclipse

[Renat Zubairov <renat.zubairov@xxxxxxxxx>]

Title: FW: UI Guidelines from Eclipse

FYI

------ Forwarded Message
From: Diya Muliyil <diya.muliyil@xxxxxxxxx>
Date: Thu, 28 May 2009 09:33:31 +0200
To: DL Swordfish_tooling_dev <swordfish_tooling_dev@xxxxxxxxx>
Subject: UI Guidelines from Eclipse

Hi All,

After an analysis of the UI guidelines from Eclipse, I have made a short list that I think applies to us now. Please feel free to add a topic or point that you see missing.

Capitalization

·       Headline style (nouns, pronouns, adjectives, verbs and adverbs to be capitalized along with first and last word): menus, tool tip and all titles, including those used for windows, dialogs, tabs, column headings and push buttons.

·       Sentence style (Capitalize the first letter of the first word, and any proper names such as the word Java): control labels in a dialog or window, including those for check boxes, radio buttons, group labels, and simple text fields.

Error Handling

In case of a programming error, the plug-in should provide the following information in the detail area of the error dialog: 

·       Provider name 
·       Plug-in name (user friendly name) 
·       Plug-in ID 
·       Version 

There are separate guidelines for Wizards (http://wiki.eclipse.org/User_Interface_Guidelines#Wizards <http://wiki.eclipse.org/User_Interface_Guidelines#Wizards> ) and for Views (http://wiki.eclipse.org/User_Interface_Guidelines#Editors <http://wiki.eclipse.org/User_Interface_Guidelines#Editors> ).


UI Graphics

This section deals with details about icons, color palettes and also has a section, “tips and tricks”.

The main highlight is: To quickly make graphics that are consistent with the Eclipse style without having to use the palette directly, select colors from existing Eclipse-based icons and wizards.

For details, see: http://wiki.eclipse.org/User_Interface_Guidelines#UI_Graphics_.283.x_updates.29 <http://wiki.eclipse.org/User_Interface_Guidelines#UI_Graphics_.283.x_updates.29> .

Naming Conventions

Abbreviations

·       The file name should be an abbreviation of the full icon name, for example, the name for the Create DTD Wizard icon might be abbreviated to "CrtDTD".

Case

·       All file names must be in lower case, for example, CrtDTD becomes "crtdtd".

Character length

·       File names should be 10 characters or less whenever possible. Underscores count as a character.

Suffixes

·       The file name should end with a suffix that describes its location or function in the user interface, for example, "crtdtd_wiz.gif". See the table below for suffix suggestions.

Multiple sizes

·       Icons that have multiple sizes within one folder, such as multiple palette icon sizes, are differentiated by adding the icon size to the suffix. For example, file_pal.gif, file_pal24.gif, file_pal32.gif, where *_pal represents the default 16 x 16 pixel size and the *_pal24 and *_pal32 represent larger sizes of the same icon. 



Dialogs

·       Initial focus must be on first input control. If there are no input controls, the initial focus should be assigned to the default button.

Wizards

Appearance

·       Must contain a banner and text area 
·       At the bottom of each wizard, a Back, Next, Finish, and Cancel button should appear.

Initialization

·       Start the wizard with a prompt, not an error message. 
·       Seed the fields within the wizard using the current workbench state.

Validation of Data

·       Validate the wizard data in tab order. Display a prompt when information is absent, and an error when information is invalid.

·       Only enable the Next / Finish buttons if all required information in the dialog is present and valid. 
·       Remove all programming message ID's from wizard text.

Browse Buttons

·       Use a Browse Button whenever an existing object is referenced in a wizard. 
·       In the Browse Dialog, invalid choices should not appear. When the dialog is closed, and focus returns to the parent control, refresh the enablement state of controls within the dialog. In particular, refresh the enablement of Next, Finish, and OK buttons.

Wizard Completion

·       If a new file is created, open the file in an editor. If a group of files are created, open the most important, or central file in an editor. Open the readme.html file upon creation of an example project.

·       If a new project is created, prompt users and change the active perspective to suit the project type. 
·       If a new object is created, select and reveal the new object in the appropriate view.

Terminology

·       Use the term "Project name" for the input field label when the item must be a Project; otherwise, use the term "Folder name". Do not qualify the term.

Context Menus

·       Fill the context menu with selection oriented commands. 
·       Fill the context menu with a fixed set of commands for each selection type, and then enable or disable each to reflect the selection state.

The Preference Dialog 

·       Global options should be exposed within the Preferences Dialog. 
·       Expose the preferences for a particular view, editor or window in the view itself, via a menu or tool item. 
·       Start out with a single preference page. Then evolve to more if you need to. 
·       If you create a preference group, use the root page for frequently used preferences, or those preferences which have wide spread effect. Specialize within the sub pages. The root preference page should not be blank.

·       Attempt to integrate plug-in preferences, wizards, and views into existing categories for a new plug-in first, before considering the creation of a new category.

Finally!!!

Top Ten Eclipse UI Guidelines 

1.      Use the Eclipse look and feel if extending or plugging into Eclipse 
2.      Use common SWT controls to get what SWT offers for cross-platform adaptability and accessibility 
3.      Be familiar with APIs for the UIs you are building 
4.      Use icons and graphics consistent with the Eclipse style, decorations, states, and quality 
5.      Understand the conventions of the OSs you are developing for 
6.      Use understandable messages to help people recover from error conditions 
7.      Don't initiate dialogs or wizards in an error state 
8.      Use quick fix and quick assist mechanisms 
9.      Reserve time for "polish" 

Top Ten Eclipse UI Violations 

1.      Low quality graphics or not consistent with the Eclipse style 
2.      Poorly organized or sized dialogs and wizards 
3.      Useless dialogs 
4.      Cryptic error messages 
5.      Messages with concatenated strings 
6.      Property pages that don't adhere to platform uses (normal and tabbed) 
7.      Assuming more importance than other contributions (see John/Mik comments below) 

For those who want to read more: http://wiki.eclipse.org/User_Interface_Guidelines#Checklist_For_Developers <http://wiki.eclipse.org/User_Interface_Guidelines#Checklist_For_Developers> .

Thank you.

Regards,

Diya








------ End of Forwarded Message