Additions / Ideas

Top Ten Eclipse UI Guidelines

The labeling/layout rules for dialogs and wizards are already part of the existing document, but rarely any dialog gets it right the first time. Maybe the new document can add a dialog checklist, wizard checklist etc...

Dialog titles should

Use headline style capitalization

Relate to the action that brought up the dialog ('Apply Patch', 'Package Selection')

Be short and unique so they can be referred by in bug reports / documentation

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 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

+1 for Johns item (7), here are some more items:
Use action/wizard page terminology that works well with other contributions :

A context menu action called 'Analyze...' is too general. Think about an own sub menu that gives more context

A wizard page group called 'Data' is too technical

Martin Aeschlimann

Useless borders/gaps in the form-based editors and especially in Views. Those borders just take screen real estate and fairly unpractical.

Large data shown in the tree widget based UI without support for quick filtering or search

Too much useless logging to the platform log (and Error Log view). Recoverable errors should be reported in the UI (i.e. decoration, tooltips, but not popup dialogs)

Lousy presentation of the progress for background tasks in the Progress view. Watch how progress and completion is reported there.

Creating custom/new views instead of reusing existing views (especially in the IDE). The good candidates for reusing are: Search, History, Console and Properties. Problems view can be efficiently used with custom markers.