Non-touch screen browser UI

On Friday I posted a few screen shots and descriptions of my proposed user interface for non-touch screen phones. The assumption is that these devices will have QVGA screens (240x320 pixels), a 5-way directional pad and two soft keys. The discussion page is here, please feel free to check it out and leave feed back. Also, I’ve created a firefox extension let’s you check out the work in progress. It creates a 240x320 pixel window using the new chrome. I’ll keep that updated as I make changes, and it should get updated through the add-ons manager.

The central idea of the dialogs has been to simplify the navigation. Most dialogs and actions are accessed through the main menu which is mapped to the right softkey. Dougt suggested combining bookmarks, history and the address bar into one unified places dialog. I like that idea and I hope to get to it in the next week or so.

The feature I find the most intriguing is the scrolling and zooming with the virtual cursor. Currently, it works like this (or at least its supposed to):

• A virtual cursor indicates where the browser’s current focus is. It also allows navigation of complex UI items such as drop down menus and roll overs.
• Short clicks of directional pad map into Dougt’s spatial navigation, bringing the focus to the nearest selectable element as indicated by the virtual cursor.
• Long presses of the directional pad begin smooth scrolling. Instead of jumping from link to link, the cursor moves in one direction at a steady speed.
• After a set amount of time, the page begins to zoom out. This is implemented with Firefox 3’s full page zoom feature. An intended side effect of zooming out as we scroll is that the scroll is accelerated. It also allows the user to look ahead as they scroll at these higher speeds, similar to how a driver fixes their eyes further down the road at 65 mph than they do at 35 mph.
• The OK/Select key maps to the left click of a mouse. A key down event triggers a mouse down, a key up event triggers a mouse up event and a key press event triggers a mouse click event.
• The Left softkey maps to the right mouse button in the same way, providing access to context menus (not implemented yet).
• One item to be added to the standard context menu is begin selection. This will have the same effect of pressing an holding the mouse button. The browser will highlight the text and other elements as the user moves the mouse until another OK/Select or left soft key press is detected. The effect will be to allow users to select and copy text.

It should also be noted that the assumptions in the first paragraph is considered a bare minimum for functionality. We’d also like to do something useful (an hopefully intuitive) with any other controls that are available. The obvious ones are numbering menu items, using a click wheel or volume control to scroll and mapping clear, send and end call into things like back, forward and stop.

Some non intuitive ideas include mapping the number keypad onto spacial location of the screen. So for instance if there if a user wanted to go to the bottom right hand corner of the screen they could press the ‘#’ key. Alternatively we could use those keys for fast scrolling (holding the 9 key would fast scroll down and to the right). We could also map the number keys into the bookmark system (long pressing one navigates to google.com, 2 brings you to your blog site etc.).

But this brings up another point. How do we determine what the “right” mix of default settings is? And even more importantly, how do we let users customize these settings with a minimum of pain?