[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
RE: [ui-best-practices-working-group] Top 10 UI lists -- Please add your ideas

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