GNOME.org
 

[Usability][Fwd: SUMMARY: command button ordering/placement]

I have no desire whatsoever to stir up this debate again  :)  But for
reasons of interest only, here were the responses when somebody asked on
the ACM's CHI-WEB list (composed mostly of usability professionals) what
button ordering and alignment they should use in their web
applications...

Cheeri,
Calum.

-- 
CALUM BENSON, Usability Engineer       Sun Microsystems Ireland
mailto:calum benson ireland sun com    Desktop Engineering Group
http://www.sun.ie                      +353 1 819 9771

Any opinions are personal and not necessarily those of Sun Microsystems
--- Begin Message --- 
Recall that the original topic was the recommended button alignment (left or
right) and ordering of most intended action (left or right).  Here are all
the different viewpoints I collected (either previous postings, those
directly to me or other research)

PROPONENTS of right alignment/right ordering might suggest:

1) (previous posting) "I myself am left handed and place mine in the reverse
order: "<< Go Back" "Clear" "Submit Changes".  Our customers seem to like it
this way. (Elizabeth Gee, October 30, 1998)"

2) (previous posting) "...I tend to put them in the same order used by the
well designed OSes (MacOS). Cancel on the left and Continue/Submit on the
right. Cancel gives off an air of retreat or escape or returning to the
page/place/state you just left, while Continue/Submit conveys an idea of
forward-motion.  Cancel = left , Submit = right,  simply makes more sense to
me. (Mar Orlygsson, February 19, 2000)",

3) the 'cancel' represents a backward action while the 'okay' represents a
forward action. Since we are designing for web applications, the users apply
traditional web models (i.e. back button left, forward button right) to the
actions they perform in their web applications.

4) The Mac standard - ordering buttons by importance from right to left but
always right aligned. This Mac standard has existed since the introduction
of the GUI (Graphical User Interface) by Macintosh in 1984.  Applicable
links include:

Apple:
http://developer.apple.com/techpubs/mac/HIGOS8Guide/thig-2.html
http://pla-netx.com/linebackn/guis/a2desk.html
Others:
http://pla-netx.com/linebackn/guis/gsos.html
http://developer.gnome.org/projects/gup/proposals/dialog.html

5) The Mac standard has an intuitive twist to it, which the PC standard
doesn't have. Even though the button representing the most important action
should be placed on the right side, it doesn't necessarily mean that this is
the action you want the user to perform and therefore the emphasis could be
on a different button. For example, if the user is suppose to 'cancel' out
of a dialog box, the 'cancel' button would never be placed on the farthest
right side using the Mac standard, because the 'okay' button is viewed as
more important, but that 'cancel' button might be the one emphasized.

6) corners and edges of the screen are empirically proven to be faster and
more accurately acquired targets for pointer (i.e. mouse) movement.  Thus
the most frequent mouse target should be in a corner, less frequent targets
along some other edge.  Similarly-scoped action buttons should be grouped
together, rather than scattered around the edges of the screen; therefore
once you've placed the most frequent target, your choices of location for
similarly-scoped target actions is relatively limited.  In browsers, the
eyes of people who read left-to-right associate movement to the right with
'forward' or advancing, and to the left with 'back' or undoing.  With this
button order, the action the user is most likely to perform is always in the
same place and is always the most noticeable. Hence, 'okay' belongs in the
lower right corner, with 'cancel' somewhere to its left, and other buttons
grouped nearby backing out to the left.

7) 'cancel' is usually interpreted as a negative action while 'okay' is
positive. We felt that in a sense forward moving is a positive action and
therefore all positive actions should be on the right of a negative
equivalent, such as previous - next. Sometimes the designs we have assisted
with even have several button groupings with each group having an emphasized
button in it, but in each case the forward moving actions are always right
and the backwards actions left.

8) Users read from top to bottom, left to right and upon
assimilating/completing a page/container/form visually end up on the bottom
right.

9) (Previous Posting) Progression is usually indicated by rightward
movement, such as on a clockface (Bev Parks, February 23, 2000) and on
CD/cassette players, wizards, and other interfaces that we're accustomed to
using on a regular basis (Michael Fry, February 23, 2000)

10) I've always been partial to Apple's approach, not because it's Apple but
because it has an explanation that goes beyond just "it's the way we always
do it." I always put the buttons at the bottom right corner of a screen
which uses English language because that's where the screen "ends". We read
left to right, top to bottom, so if the button is meant to be the
confirmation of the contents it ought to be positioned at the end of the
contents. And I also put the default button at the far right. My personal
feeling is that this is the most logical arrangement and anecdotal evidence
suggests that it's the one least prone to user error and also the most
efficient in terms of user performance. (adam, chi-web)

PROPONENTS of right alignment, but OPPONENTS of right ordering

1) In my work I have found that the right-justification of the command
button group works best and is most expected among users. However, I would
urge you to stick with the standard of the most used or default button being
the LEFTmost button rather than rightmost. My guess would be that this is
western-culture-centric since it probably evolved from our left-to-right
reading, but it is cited as a standard placement default (or most-used)
command button placement in the Windows and Java guidelines. (Jenny
Monesson, Ph.D.)

2) Aligning at the right bottom is a good layout decision. However I would
put the conforming option before the Cancel option. The confirming button is
normally used more than the Cancel and putting confirmation before Cancel is
consistent with the Windows guidelines.  New users will have no problem with
this order (they will find what they need the most before the less likely
option). Users accustomed to Windows applications will recognize the order
from other applications (if these are following the Windows guidelines). Rik
Manhaeve, Belgium

3) While looking for the follow up I saw your post on command buttons.  For
an IBM project I came up with the same design you described [right aligned],
but we decided to go with the windows standard which puts the default button
left-most instead of right-most.  Fitt's law doesn't really come into play
since windows with buttons are rarely butted up to one side of the screen...


OPPONENTS of right alignment/right ordering might suggest:

1) It has been the Windows standard for years and IBM's latest guidelines
(as well as Nielsen) advocate left alignment of buttons - enough said.

2) There is no control over the button order for certain parts of Swing
(file-choose), which by default is left aligned.

3) If there are 3rd party products used by the main software, there is no
control over button ordering and placement of 3rd party buttons (could be
left aligned, middle or right)

4) I'm not convinced that it is possible to institute one standard that
works equally well for both desktop UIs and for HTML-based UIs.  The right
alignment/right ordering are nearly 100% driven from an HTML perspective
with little regard to the needs of Swing-based UIs.

5) End-users do NOT look at "OK" and "Submit" buttons and do a conceptual
mapping to the "Next page" arrow of a web browser when they are using
Swing-based UIs.  The HTML paradigm is for HTML.  It has limitations.  These
limitations (and the whole HTML paradigm) should not be forced upon the
Swing-based user interfaces and their users (or even prolific Windows
users).

6) Some people think these buttons should be aligned on the left in case the
user's screen resolution is less than the width of the page (you should of
course try to design resolution independent pages); in addition, if
everything is aligned left, it's easy to scan the left edge & not miss
anything like a button.  (leslie carter, march 13, 2001)

7) (previous posting) (Most) users are accustomed to seeing Windows-based
apps, in which 'OK/submit' is on the left and 'cancel' is on the right. We
should apply the same to Web sites. Ostensibly, this would provide
consistency *and* present the user with the frequent actions--the
'OK/submit' buttons--earlier rather than later, thus expediting task
completion. (Michael Fry, February 23, 2000)

8) We felt that reading order was the most important factor for deciding
which order to place things.  Put the one you thought they wanted first on
the list - the left.  The cancel and help were common negative/auxiliary
actions so they were always at the end.  The left alignment was a practical
solution to changes in window size.  At the time there was very little
screen layout created with the capability to reposition controls as the
window changed.  So, if you left aligned the buttons you had a bigger chance
of still seeing the button you needed when the window size changed - the
default change for the window size meant that you truncated from the right.
I have not seen any evidence over the past years to convince me that there
was any need to change this.  As you may recall we say that visuals only
contribute 10% to the usability of the product anyway.  This means I would
think it was much more important to get the verbs right that it was to worry
how the pushbuttons were ordered and aligned.  (although that's a bit of a
simplification). (input from an IBMer who worked on original CUA guidelines)

9) For users whose native language is written from left to right, this
implies that the intended action will be read last. I wonder if this is a
good thing? Do users read a row of buttons in the same way as text? Anyone
done any work on this topic?


laura seargeant
senior design analyst
Tel. (1)  512 531 3748
Fax (1)  512 477 3792
laura seargeant frogdesign com
http://www.frogdesign.com

    --------------------------------------------------------------
        Tip of the Day: Email mailto:chi-web-request acm org
               with any comments, questions or problems
               About CHI-WEB: http://www.sigchi.org/web/
         Vacations, holidays and other subscription changes:
             http://www.sigchi.org/web/faq.html#vacations
    --------------------------------------------------------------

    [You are currently subscribed as &WHOM;]

--- End Message ---
[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]