Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.
Difference between revisions of "Top Ten Lists Working Page"
m (→Top Ten Eclipse UI Violations) |
(→Starter Set) |
||
| Line 15: | Line 15: | ||
==== Top Ten Eclipse UI Violations ==== | ==== Top Ten Eclipse UI Violations ==== | ||
#Low quality graphics or not consistent with the Eclipse style | #Low quality graphics or not consistent with the Eclipse style | ||
| − | #Poorly organized | + | #Poorly organized or sized dialogs and wizards |
| − | + | ||
#Useless dialogs | #Useless dialogs | ||
#Cryptic error messages | #Cryptic error messages | ||
#Messages with concatenated strings | #Messages with concatenated strings | ||
#Property pages that don't adhere to platform uses (normal and tabbed) | #Property pages that don't adhere to platform uses (normal and tabbed) | ||
| + | #Assuming more importance than other contributions (see John/Mik comments below) | ||
| Line 63: | Line 63: | ||
John Arthorne | 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 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. | ||
| + | |||
| + | Mik Kersten | ||
Revision as of 19:25, 23 March 2007
Contents
Starter Set
Top Ten Eclipse UI Guidelines
- Use the Eclipse look and feel if extending or plugging into Eclipse
- Use common SWT controls to get what SWT offers for cross-platform adaptability and accessibility
- Be familiar with APIs for the UIs you are building
- Use icons and graphics consistent with the Eclipse style, decorations, states, and quality
- Understand the conventions of the OSs you are developing for
- Use understandable messages to help people recover from error conditions
- Don't initiate dialogs or wizards in an error state
- Use quick fix and quick assist mechanisms
- Reserve time for "polish"
Top Ten Eclipse UI Violations
- Low quality graphics or not consistent with the Eclipse style
- Poorly organized or sized dialogs and wizards
- Useless dialogs
- Cryptic error messages
- Messages with concatenated strings
- Property pages that don't adhere to platform uses (normal and tabbed)
- Assuming more importance than other contributions (see John/Mik comments below)
Additions / Ideas
Top Ten Eclipse UI Guidelines
Should we mention something about Accessibility in the Good Practices list ?
Raji Akella
Ref: http://wiki.eclipse.org/index.php/Platform_UI/Accessibility_Features
Top Ten Eclipse UI Violations
5. Bastardized property pages
You may choose to use friendlier language, but it pains me every time I come across a property pages that don't adhere to what the platform uses (normal or tabbed).
Just a pet-peeve ;)
Chris Aniszczyk
Useless dialogs
(Found on Steve Northover's blog: http://inside-swt.blogspot.com/2007/03/useless-dialog-of-day.html)
Kim Peter
Another one for Violations regarding messages:
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 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.
Mik Kersten