[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
[ui-best-practices-working-group] Prep info for discussion on use of ellipsis
|
Hi gang,
Problem Statement
Based on our read of the Vista guidelines,
we changed "Preferences..." to "Preferences". This
triggered bug https://bugs.eclipse.org/bugs/show_bug.cgi?id=226468 which
requested it be changed back. See the bug for the discussion.
In addition to answering the specific
question, there's is of course the general issue of either which guideline
to follow, or how to intepret the Vista/XP guideline.
I thought it'd be fun, since this is
a guideline issue, for us to decide as a group.
Vista/XP
My read of the Vista guideline http://msdn2.microsoft.com/en-us/library/aa511453.aspx,
suggests it shouldn't have ellipsis (my bold):
While command buttons are used for immediate
actions, more information might
be needed to perform the action. Indicate a command that needs additional
information (including confirmation) by adding an ellipsis at the end of
the
button label.
Proper use of ellipses is important to indicate that users can make further
choices before performing the action, or even cancel the action entirely.
The
visual cue offered by an ellipsis allows users to explore your software
without
fear.
This doesn't mean you should use an ellipsis whenever an action displays
another window only when additional information is required to perform
the
action. Consequently, any command button whose implied verb is show another
window doesn't take an ellipsis, such as with the commands About, Advanced,
Help (or any other command linking to a Help topic), Options, Properties,
or
Settings.
Generally, ellipses are used in UI to indicate incompleteness. Commands
that
show other windows aren't incomplete they must display another window and
additional information isn't needed to perform their action. This approach
eliminates screen clutter in situations where ellipses have little value.
"Preferences" is much like
"Properties", which they do specifically mention, and seems to
fit the case description of being an implied "Show Preferences".
With respect to XP, the Windows Interface
Guidelines book (http://www.amazon.com/Windows-Interface-Guidelines-Software-Design/dp/1556156790)
reads approximately the same and calls out Properties as not deserving,
so I don't think there was a guideline change from XP to Vista, just clarification.
I should add that we've always deferred
to the Windows guidelines in cases where there wasn't something Eclipse
specific worth calling out.
Apple
The Apple guideline is more liberal
with use of ellipsis http://developer.apple.com/documentation/UserExperience/Conceptual/OSXHIGuidelines/XHIGText/chapter_14_section_3.html#//apple_ref/doc/uid/TP30000365-TPXREF126
Use an ellipsis in the name of a button
or menu item when the associated action:
...
Is performed by the user in a separate
window or dialog.
For example, Preferences, Customize
Toolbar, and Send Feedback all use an ellipsis because they open a window
(potentially in another application, such as a browser) or a dialog in
which the user sets preferences, customizes the toolbar, or sends feedback.
http://dev.eclipse.org/blogs/kevinmcguire/2007/10/12/ellipsis-for-eclipses/To
see why such commands must include an ellipsis, consider that the absence
of an ellipsis implies that the application performs the action for the
user. If, for example, the Send Feedback command did not include an
ellipsis, it would imply that feedback is generated and sent automatically
by the application.
The Apple guideline is simpler and basically
states that if a new window results than you should use ellipsis. It
specifically calls out Preferences and iTunes indeed has "Edit"->"Preferences...".
One plus of the Apple guideline is that there is no ambuiguity. Another
argument is that it more closely matches what we generally do, although
this may be through a lack of knowledge of the Windows guideline. However,
easier to interpret guidelines IS helpful for Eclipse.
Additional Reading
- The bug that started it all, regarding
"Reset Perspective": https://bugs.eclipse.org/bugs/show_bug.cgi?id=205521
- My blog entry on the subject: http://dev.eclipse.org/blogs/kevinmcguire/2007/10/12/ellipsis-for-eclipses/
Summary
So the questions are:
- Did we correctly interpret the
Vista/XP guidelines?
- Should we always stick to the
Vista/XP guidelines in the absence of something Eclipse specific which
wouldn't be covered by them? (e.g. our view stacks)
- Or do we in this particular
case (and possibly future ones) pick the Apple guideline? Reasons for doing
so are that it matches more closely what we already do, or that its easier
for people to interpret.
Ladies
and gentlemen, the facts are before you. Your verdict?
Kevin
Bob Fraser <bfraser@xxxxxxx>
Sent by: ui-best-practices-working-group-bounces@xxxxxxxxxxx
04/28/2008 04:31 PM
Please respond to
User Interface Architecture Working Group <ui-best-practices-working-group@xxxxxxxxxxx> |
|
To
| UI Best Practices Working Group <ui-best-practices-working-group@xxxxxxxxxxx>
|
cc
|
|
Subject
| [ui-best-practices-working-group] Reminder:
Conference Call: Wednesday, April 30th, 17:00 UTC or 10:00 PDT. Call 613.287.8000
or 866.362.7064 passcode 892048# |
|
Conference Call: Wednesday, April 30th, 17:00 UTC
or 10:00 PDT. Call
613.287.8000 or 866.362.7064 passcode 892048#
Agenda so far:
- Update on UI top ten "Don't do" list
- Discussion on use of ellipses
Notice: This email message, together with any attachments, may contain
information of BEA Systems, Inc., its subsidiaries
and affiliated entities, that may be confidential, proprietary,
copyrighted and/or legally privileged, and is intended solely
for the use of the individual or entity named in this message. If you are
not the intended recipient, and have received this message in error, please
immediately return this by email and then delete it.
_______________________________________________
ui-best-practices-working-group mailing list
ui-best-practices-working-group@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/ui-best-practices-working-group