Skip to main content
Jump to: navigation, search

Top Ten Lists Working Page

Revision as of 19:25, 23 March 2007 by (Talk | contribs) (Starter Set)

Starter Set

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)

Additions / Ideas

Top Ten Eclipse UI Guidelines

Should we mention something about Accessibility in the Good Practices list ?

Raji Akella


Top Ten Eclipse UI Violations

5. Bastardized property pages

You may choose to use friendlier language, but it pains me every time I come across a property pages that don't adhere to what the platform uses (normal or tabbed).

Just a pet-peeve ;)

Chris Aniszczyk

Useless dialogs

(Found on Steve Northover's blog:

Kim Peter

Another one for Violations regarding messages:

Creating messages with concatenated strings. They have the potential for losing their meaning when they get translated.

Raji Akella

My favourite Eclipse-specific UI blooper is:

7. Doesn't play well with others. A plug-in that assumes it is more important than others, and over-uses global real-estate such as top level toolbars and menu, adds perspective extensions that clutter the menus of other perspectives, insert views into other perspectives, clutters popup menus with excessive object contributions, adds startup hooks to run user jobs on startup, etc.

John Arthorne

John’s item (7) is on top of my list too and wonder how we could make it more concrete. We should also keep in mind counter examples, e.g. it can be better to add your one view to an existing perspective than to burden the user with a whole other perspective. Here’s my quick pass at a rough guideline for an extension that should play well with the SDK.

  • Don’t add more than [0] top-level menus to the menu bar. Use existing menu paths whenever possible.
  • Don’t add more than [6] always-visible toolbar items.
  • Don’t add more than [3] always-visible object contributions to popup menus.
  • Don’t add a new perspective if it only adds a view or two, add a viewShortcut instead

I wonder if Europa projects could try to follow such a guideline and help us refine it in the process.

Mik Kersten

Back to the top