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. 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 ;)
Mik
From: ui-best-practices-working-group-bounces@xxxxxxxxxxx
[mailto:ui-best-practices-working-group-bounces@xxxxxxxxxxx] On Behalf Of John
Arthorne
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
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
|
Kimberley
Peter/Toronto/IBM@IBMCA
Sent by:
ui-best-practices-working-group-bounces@xxxxxxxxxxx
21/03/2007
07:51 PM
|
Please respond to
User Interface Architecture Working Group
<ui-best-practices-working-group@xxxxxxxxxxx>
|
|
|
To
|
ui-best-practices-working-group@xxxxxxxxxxx
|
|
cc
|
|
|
Subject
|
[ui-best-practices-working-group]
Top 10 UI lists -- Please add your ideas
|
|
Hi *
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:
http://wiki.eclipse.org/index.php/Performance_Bloopers.
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
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.
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
Thanks!
Kim
_______________________________________________
ui-best-practices-working-group mailing list
ui-best-practices-working-group@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/ui-best-practices-working-group
