up/down; forward/back; right/left

19 Dec 2006 - 8:29am
7 years ago
7 replies
371 reads
Dave Malouf
2005

Hi gang,

I'm working on a project where we are trying to figure out in a horizontal
layout for physical buttons that are used for navigating a list of options
(primarily) that are layed out vertically how would you layout these
buttons.

So you have a button on the left and another one on the right.
while button goes up the list and which button goes down?

Here are some cursory thoughts.
#1 Forward = add = up
Based on that a "volume control" seems to be the most used example and
adding volume (going up) is always on the right.

#2 If we look though at the same metaphor which is a knob.
turning right goes up for volume. So that seems compatible with #1 where
"going right" = clockwise from the top.

#3 Back/forward buttons are written back = left and forward = right in
many circumstances again confirming that flow. But this does not have a
"list" alegory.

#4 here is where it gets different.
previous/next are probably the closest allegory
but "next" which is usually on the right, actually goes "down" when
navigating a list, which scrolls the screen "up" creating a paradox for
communicating.

I know for me, when I navigate my channels on my cable provider's DVR
(don't know about TiVO) they list the channels in the guide #1 at the top
and #1000 at the bottom. But the down actually takes me to a higher
channel b/c they put the visual ahead of the numeric presentation.

#5 On the click-wheel of an iPod, the clock-wise sequence is "forward" and
thus going down (descending) the list.

My only thought here is that if I had a D-pad with 5 buttons the down and
up would work by
Down button: would move the selection visually under the previously
selected item.
Up button the opposite.

since these are clearly UP & DOWN, I would hold to the allegory to the
up/down for numeric purposes like the volume control or knob example.

I realize there might be people saying:
1. Why not make it vertical? We can't
2. Why not use clearer lables than up/down icons? No space.

So these are the design constraints. We can only change the mapping of the
buttons, not the placement or the labels of the buttons.

What are other people's thoughts?

-- dave

--
David Malouf
dave at ixda.org
http://ixda.org/

Comments

19 Dec 2006 - 9:31am
Bruce Esrig
2006

Hi Dave,

It does get tangled because of the two opposing perspectives that you
mention. Buttons to navigate the list versus scrolling, which moves the
content.

1. Buttons. I would say that what to put on the buttons depends on what
functions the users think they are performing.

In a list of options, the functions are "previous" and "next". (There might
be some lists that are sequential, but if there are prominent lists that
are used early on that are not sequential and are navigated using the
buttons, then even when navigating sequential lists, the users might be
able to think in terms of previous and next.) If the list of options is
presented vertically with the first option at the top of the list, then
"previous" is compatible with "up" and "next" is compatible with "down".

In left-to-right languages, you would put "previous" on the left and "next"
on the right.

2. Scrolling the content. Scrolling is a naturally contrary phenomenon.
Moving the control down in the scroll bar moves the contents up, and that's
just how the facts are. To counter this, you need a control that drags the
content. Would you want to use a content-dragging method (such as a hand)
to scroll through the list of options?

It might be counterintuitive to use buttons to scroll content, so the
"previous" / "next" conclusions may remain valid.

Best wishes,

Bruce Esrig

At 08:29 AM 12/19/2006, David Malouf wrote:
>Hi gang,
>
>I'm working on a project where we are trying to figure out in a horizontal
>layout for physical buttons that are used for navigating a list of options
>(primarily) that are layed out vertically how would you layout these
>buttons.
>
>So you have a button on the left and another one on the right.
>while button goes up the list and which button goes down?
>
>Here are some cursory thoughts.
>#1 Forward = add = up
>Based on that a "volume control" seems to be the most used example and
>adding volume (going up) is always on the right.
>
>#2 If we look though at the same metaphor which is a knob.
>turning right goes up for volume. So that seems compatible with #1 where
>"going right" = clockwise from the top.
>
>#3 Back/forward buttons are written back = left and forward = right in
>many circumstances again confirming that flow. But this does not have a
>"list" alegory.
>
>#4 here is where it gets different.
>previous/next are probably the closest allegory
>but "next" which is usually on the right, actually goes "down" when
>navigating a list, which scrolls the screen "up" creating a paradox for
>communicating.
>
>I know for me, when I navigate my channels on my cable provider's DVR
>(don't know about TiVO) they list the channels in the guide #1 at the top
>and #1000 at the bottom. But the down actually takes me to a higher
>channel b/c they put the visual ahead of the numeric presentation.
>
>
>#5 On the click-wheel of an iPod, the clock-wise sequence is "forward" and
>thus going down (descending) the list.
>
>My only thought here is that if I had a D-pad with 5 buttons the down and
>up would work by
>Down button: would move the selection visually under the previously
>selected item.
>Up button the opposite.
>
>since these are clearly UP & DOWN, I would hold to the allegory to the
>up/down for numeric purposes like the volume control or knob example.
>
>
>I realize there might be people saying:
>1. Why not make it vertical? We can't
>2. Why not use clearer lables than up/down icons? No space.
>
>So these are the design constraints. We can only change the mapping of the
>buttons, not the placement or the labels of the buttons.
>
>What are other people's thoughts?
>
>-- dave
>
>--
>David Malouf
>dave at ixda.org
>http://ixda.org/
>
>[ previous footer snipped ]

19 Dec 2006 - 10:03am
Bill DeRouchey
2010

Hey Dave,

I tend to think it's okay for the button on the right to move Down the
list. They both connote Forward.

But it sounds like you're getting tripped up on how pushing Right/Down
moves the list up. How you move the cursor through the list can help this
situation. Are you using a slot machine (cursor fixed in center, list
adjusts with every move) or a TV guide (only cursor moves, list stays
fixed until paging up/down) approach? We've found the slot machine
approach creates a lot of confusion. I think we think better when we move
in a list instead of the list moving around us. But it does depend on the
number of visible items in the list.

If you use a TV guide approach, then the cursor will move down, matching
better to pushing the button on the right.

I hope this provides a different way of thinking about your challenge.

Bill

On Tue, 19 Dec 2006, David Malouf wrote:

> Hi gang,
>
> I'm working on a project where we are trying to figure out in a horizontal
> layout for physical buttons that are used for navigating a list of options
> (primarily) that are layed out vertically how would you layout these
> buttons.
>
> So you have a button on the left and another one on the right.
> while button goes up the list and which button goes down?
>
> Here are some cursory thoughts.
> #1 Forward = add = up
> Based on that a "volume control" seems to be the most used example and
> adding volume (going up) is always on the right.
>
> #2 If we look though at the same metaphor which is a knob.
> turning right goes up for volume. So that seems compatible with #1 where
> "going right" = clockwise from the top.
>
> #3 Back/forward buttons are written back = left and forward = right in
> many circumstances again confirming that flow. But this does not have a
> "list" alegory.
>
> #4 here is where it gets different.
> previous/next are probably the closest allegory
> but "next" which is usually on the right, actually goes "down" when
> navigating a list, which scrolls the screen "up" creating a paradox for
> communicating.
>
> I know for me, when I navigate my channels on my cable provider's DVR
> (don't know about TiVO) they list the channels in the guide #1 at the top
> and #1000 at the bottom. But the down actually takes me to a higher
> channel b/c they put the visual ahead of the numeric presentation.
>
>
> #5 On the click-wheel of an iPod, the clock-wise sequence is "forward" and
> thus going down (descending) the list.
>
> My only thought here is that if I had a D-pad with 5 buttons the down and
> up would work by
> Down button: would move the selection visually under the previously
> selected item.
> Up button the opposite.
>
> since these are clearly UP & DOWN, I would hold to the allegory to the
> up/down for numeric purposes like the volume control or knob example.
>
>
> I realize there might be people saying:
> 1. Why not make it vertical? We can't
> 2. Why not use clearer lables than up/down icons? No space.
>
> So these are the design constraints. We can only change the mapping of the
> buttons, not the placement or the labels of the buttons.
>
> What are other people's thoughts?
>
> -- dave
>
> --
> David Malouf
> dave at ixda.org
> http://ixda.org/
>
> ________________________________________________________________
> Welcome to the Interaction Design Association (IxDA)!
> To post to this list ....... discuss at ixda.org
> List Guidelines ............ http://listguide.ixda.org/
> List Help .................. http://listhelp.ixda.org/
> (Un)Subscription Options ... http://subscription-options.ixda.org/
> Announcements List ......... http://subscribe-announce.ixda.org/
> Questions .................. lists at ixda.org
> Home ....................... http://ixda.org/
> Resource Library ........... http://resources.ixda.org
>

19 Dec 2006 - 10:31am
Mark Schraad
2006

I iterally have to overcome this everytime I pick up my new remote (going on 5 months now) and it never occurred to me that the [-] was intended to map to scrolling down. Maybe I am dense... well I feel dense right now. Thanks Dave...

Mark

>I know for me, when I navigate my channels on my cable provider's DVR
>(don't know about TiVO) they list the channels in the guide #1 at the top
>and #1000 at the bottom. But the down actually takes me to a higher
>channel b/c they put the visual ahead of the numeric presentation.

19 Dec 2006 - 2:40pm
.pauric
2006

I've used onscreen mimics of the buttons to indicate their contextual
function. I did have the buttons physically labeled A/B but could have
easily done without.

So, your mimic would have up/down arrows on the respective virtual buttons,
once learned the user could switch off the help mimic if your screen space
is limited.

You said you dont have space to label, cant you print or emboss on to the
buttons themselves? Assuming your two buttons have other function/meaning
within the menu (I didnt follow all of your post) you could use bi/tri
colour LEDs behind opaque rubber buttons to indicate contextual
functionality. E.g. the right button is green, the left button is red which
reflects an OK/CANCEL option on the screen.

regards - pauric

19 Dec 2006 - 2:43pm
.pauric
2006

correction got my left and right mixed up :"E.g. the right button is green,
the left button is red which reflects an OK/CANCEL option on the screen."

left button = green = OK, right = red = cancel

On 12/19/06, pauric <radiorental at gmail.com> wrote:
>
> I've used onscreen mimics of the buttons to indicate their contextual
> function. I did have the buttons physically labeled A/B but could have
> easily done without.
>
> So, your mimic would have up/down arrows on the respective virtual
> buttons, once learned the user could switch off the help mimic if your
> screen space is limited.
>
> You said you dont have space to label, cant you print or emboss on to the
> buttons themselves? Assuming your two buttons have other function/meaning
> within the menu (I didnt follow all of your post) you could use bi/tri
> colour LEDs behind opaque rubber buttons to indicate contextual
> functionality. E.g. the right button is green, the left button is red
> which reflects an OK/CANCEL option on the screen.
>
> regards - pauric
>

--
Jnr. designabilityhitect & interinfofaceactioneer.
The more I learn, the less I seem to know.

20 Dec 2006 - 12:12am
Ripul Kumar
2005

There are many dimensions for any design element. Changing a single dimension can change semantics. Here are the design dimensions for a button:

a. Shape
b. Size
c. Color
d. Placement
e. Label

In your situation, I can clearly see that changing the shape of the buttons can solve the problem. An up and a down triangular shape with "up button" placed on the right of "down button".

Buttons need not be rectangular!

Cheers,
--
Ripul Kumar
Director, Usability Consulting & Outsourcing
Kern Communications Pvt. Ltd.
http://www.kern-comm.com

* Usability in India *

21 Dec 2006 - 2:32pm
Carrie Burgener
2006

I looked at some other physical devices...

My desk phone has two horizontally positioned buttons that go up and down
through my messages, and saved phone numbers. Incidentally right is down
and left is up.

I also checked the four-way on my cell phones ...right goes through the
list of items...moving the 'page' up exposing items at the bottom of the
list, left moves the 'page' down moving back up to the top.

Carrie

Syndicate content Get the feed