Skip to main content

[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


Mik, I agree with your concrete numbers.

There's still the question in my mind about the difference between guidelines and best practices.  Some of the discussion on this thread has helped me to see one difference in approach:

- guidelines are more black and white (you should do this, you shouldn't do that)
- best practice is more conversational, covering the gray areas (e.g. Mik's numbers below, which I wouldn't state as part of the guideline, but are worth thinking about)

To that end, what would people think if we constructed a best practice section more like a conversation?  Rather than trying to distill down people's comments in this thread to a few bullets (which probably would not do them justice), it could be more interesting to just capture the thread as a discussion.  As a model, I recall Ed Yourdon's book Death March had a mix of questions he posed on his website and conversational threads with those who responded.  It worked quite well.

Kevin




"Mik Kersten" <beatmik@xxxxxxx>
Sent by: ui-best-practices-working-group-bounces@xxxxxxxxxxx

03/23/2007 04:12 PM

Please respond to
User Interface Architecture Working Group        

To
"'User Interface Architecture Working Group'" <ui-best-practices-working-group@xxxxxxxxxxx>
cc
Subject
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
_______________________________________________
ui-best-practices-working-group mailing list
ui-best-practices-working-group@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/ui-best-practices-working-group


Back to the top