Adding D-pad navigation to an existing web application: Resources?

Question

I have a web application (HTML5) which works well in Google Chrome with mouse navigation, and I am adding d-pad navigation support.

I have asked on StackOverflow about programming models for d-pad support. I am hoping UX folks here can point to best practices on adding d-pad support, the kinds of questions I have are:

1. Is it better to provide a virtual pointer or to provide cues to the user as to which actionable item currently has focus? A virtual pointer is easier to implement, but it then requires the user to click more to get to the right spot and click, and also allows user to navigate to spots where a select click does nothing
2. If in my layout of actionable items (e.g. buttons) I am at the rightmost button, what should the right arrow do? Should it then jump to the leftmost?
3. If I am changing screens, and I include a "back" button at the top left, should I put focus there, or on the first non-back button?
4. For modal and nonmodal new windows, how do I decide if I should put focus on the newly visible elements?
5. For scrollable containers with content not currently visible, if I navigate downward, should that scrollable always scroll, is it acceptable to simply place focus (I am currently using a WebTV-style focus outline) on the next item.

That's a selection of the issues that come up. Any resources on this issue are most welcome.

UPDATE: Feel free to answer only sub-questions if there are no general resources out there on this issue. I'm sensing d-pad navigation is getting less attention since direct manipulation/touch seems to be available for many devices these days. I wonder if there are resources for implementing d-pads in gaming or television devices out there.

Answer 1

For #1: Fitts's law can provide some hints as to which type of input could be simpler and less error prone. Your hypothesis here is correct: A virtual pointer will require more effort in navigating to different actions. Traversing action items becomes a single flick of the d-pad when you restrict the users to only being able to "tab" through options using the d-pad. Something to keep in mind is keeping the layout of action items intuitive. Is the next action item intuitively reached when hitting up or down?

#2: The best way to answer this question would be to try both methods out and determine which feels more intuitive. However, I can't imagine a cyclical navigation structure being detrimental (my guess is that it would be used as a navigation feature for more expert users).

#3: What's the primary action on these pages? Perhaps if the page is purely information, then the only action is to go back, so in these cases a default focus on the back button would be appropriate. Otherwise, focus the default on supporting the user's goals.'

I hope this is a helpful start.

Answer 2

1
The pointer is hard to use with a dpad, go for the "tab like" navigation.
Google TV as some good pointers on navigation here:
http://code.google.com/tv/android/docs/gtv_android_patterns.html
A good example of UX Design for TV is Boxee:
http://whitneyhess.com/blog/2010/01/27/the-ux-design-process-for-the-boxee-beta/

4
Focus on the main / most common task as a good default. Using Boxee's example when you select a movie to play it opens a modal with several tasks: play, mark watched, etc. Here the most common task is play, so it is focused when you open the modal.

Answer 3

Is it better to provide a virtual pointer or to provide cues to the user as to which actionable item currently has focus? A virtual pointer is easier to implement, but it then requires the user to click more to get to the right spot and click, and also allows user to navigate to spots where a select click does nothing

In TV-like interfaces, pointers are usually bad because they're hard to control by remote, because TV interfaces are very slow (so the speed difference is multiplied) and because, thanks to the low resolution of TV viewports, TV interfaces have only a few buttons, so they can be manipulated by a control with only a few buttons. I don't know GoogleTV well, but it looks like most applications for it don't use virtual pointers, so a pointer won't win out through familiarity, either.

If in my layout of actionable items (e.g. buttons) I am at the rightmost button, what should the right arrow do? Should it then jump to the leftmost?

I would recommend that the right arrow act as 'select' in this context. Why?

• because in most TV-like interfaces, there's no reason to hover over a button without wanting to select it. Users who have pressed right want to go right
• because remote controls have latency, and it's quite possible a user will press right >1 times, but only want the right selection
• because if you don't have a pointer, a user who wants to go left need only press left once. There's no extra efficiency in letting users 'roll over' back to the left side

If I am changing screens, and I include a "back" button at the top left, should I put focus there, or on the first non-back button?

It depends on the function of each 'screen', but typically no - you should expect that your users are visiting page X because they want to do X. Adding an extra barrier to them adds frustration. If your users can get to page X by mistake, revise the navigation for the pages before X - don't cripple X itself.

For modal and nonmodal new windows, how do I decide if I should put focus on the newly visible elements?

For a TV interface with low resolution, I'd avoid child windows in the first place. In any case, I'd put my focus on the new element. Focusing on a page that's obscured is quite strange - the new window is open because the user has requested that content, or there's something important. If the new window doesn't have important or requested content, it shouldn't be there in the first place.

For scrollable containers with content not currently visible, if I navigate downward, should that scrollable always scroll, is it acceptable to simply place focus (I am currently using a WebTV-style focus outline) on the next item.

If your user wanted to interact with the bottom item of the first page, they could have just focused on that. Not focusing on new items creates a barrier to those who want to interact with the rest of the page, and adds little extra to users who realize they aren't interested, who have probably already assessed the other elements, and will only use the native 'back' or 'exit' controls rather than scrolling back up. The only exception is a form where the user might want to look ahead to understand earlier questions - but then again, such a form is probably poorly designed.