[IxDA Discuss] up/down; forward/back; right/left

[Bruce Esrig]

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 ]