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  top-level menus to the menu
bar. Use existing menu paths whenever possible.
Don’t add more than  always-visible toolbar items.
Don’t add more than  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. The Platform is doing a great job
leading UI guidelines by example, but it seems that Europa needs to do so tool.
If others like the idea I can bring it up at the next Europa meeting (to some
inevitable push back ;)
[mailto:ui-best-practices-working-group-bounces@xxxxxxxxxxx] On Behalf Of John
Sent: Thursday, March 22, 2007 6:55 AM
To: User Interface Architecture Working Group
Subject: Re: [ui-best-practices-working-group] Top 10 UI lists -- Please
add your ideas
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.
Please respond to
User Interface Architecture Working Group
Top 10 UI lists -- Please add your ideas
As per the conversation at our workgroup meeting today, we are going to
come up with a top 10 list for good and bad UI practices for Eclipse to be
used as a base checklist.
I've taken a quick stab, but welcome your contributions to make this truly
solid and in keeping with what we believe can lead to a great Eclipse UI,
or a bad one. If you think any of these suck, don't hesitate to say so.
Let's expand the list initially as needed then pare back. Note Mik
suggested we reference the Performance Bloopers page:
Top Ten Eclipse UI Guidelines
1. Use the Eclipse look and feel if extending or plugging into
2. Use common SWT controls to get what SWT offers for cross-platform
3. Be familiar with APIs for the UIs you are building
4. Use icons and graphics consistent with the Eclipse style,
states, and quality
5. Understand the conventions of the OSs you are developing for
6. Use understandable messages to help people recover from error
7. Don't initiate dialogs or wizards in an error state
8. Use quick fix and quick assist mechanisms
10. Reserve time for "polish"
Top Ten Eclipse UI Violations
1. Low quality graphics or not consistent with the Eclipse style
2. Poorly organized dialogs
3. Oddly sized dialogs and wizards
4. Cryptic error messages
ui-best-practices-working-group mailing list