Accessing lots of content on the small screen

Tags: Design,  Devices
January 5, 2006 by Barbara

Imagine, if you will, your phone a few years from now. It has 20 gigabytes of storage, on which you have a few hundred contacts, a hundred or so bookmarks, a thousand songs, video clips, electronic receipts from your physical and online purchases, your resume and other key documents, and so forth.

No matter what the input capabilities of this phone (iPod-like wheel, gesture, facial recognition, voice), the screen is still small, at least most of the time. It still fits in your pocket, and any large-screen equivalent (built-in glasses heads up display, projection, wireless connection to nearby screens) will be at best a part time viewing solution. So all the problems you have finding data on your computer today will be exacerbated by the small screen.

How many steps will it take to call Aunt Betty, who is not on speed dial? How about going to your favorite web site? And what about a web site bookmark? Only a small number of applications can be at the "top level" of the user interface and everything else will have to be navigated to.

I believe that the basic tree hierarchy that is the core UI architecture for contemporary phones and PDAs is about to reach its end of life, and we need to develop something different for multi-function mobile devices.

Sprint's partial solution to the problem is to create a Favorites list. You can add any application (downloaded or native), contact, web address, or specific contact field (Betty's mobile phone) to the list. This frees the user from managing multiple Favorites (speed dial, bookmarks, ...) but requires a lot of management from the user. It is also probably not scalable to our multi-gigabyte phone.

Windows Mobile's "Today" screen, particularly as modified by Palm, is another partial solution. The main screen displays frequently dialed contacts and so forth. Metacontent data will help, particularly as we try to find a specific user-created photo. The photo should be tagged with time, date, location, and ideally content via image recognition algorithms. Again, this is a partial solution.

These solutions all help, but they do not address the core problem.

My recommendation: create three methods of interaction on the phone.
  1. Dock/Today Screen/Launch Pad/etc. The standby screen of the device should display currently relevant information and access to frequently used applications. Hardware buttons can be considered an extension of the standby screen.
  2. LaunchBar - like text-based access, paired with a full alphabetic keyboard, perhaps provided by Digit Wireless
  3. A menu hierarchy to allow visual exploration.

Of this list, only text-based access is new. I propose using the ideas from LaunchBar, a Mac OS X utility that gives the user the ability to launch programs, switch between applications, go to a specific bookmark, view a contact's details, navigate the file structure, and run Google or any other site search ... in an unobtrusive way, with minimal necessary configuration, that learns how the user thinks, with a single global key combination.

How it works for a new user: activate it, type 1 or more letters that are somewhere in the name of the program/bookmark/contact/etc. you want to activate (in order). If you want to view your gmail account (bookmark), you might enter "gm" or whatever made sense to you. A list of matches appears at the top of the screen. Select the match and it is activated. For an experienced user, the match would be at the top of the list already because the letter combination had been used to access the item already.

They use a frequency of use approach to order matches, so very frequent items will be first. To avoid moving to the mouse for lower frequency items, simply type more of the item's name.

On a phone, extra hardware buttons might limit the search: after activating the search and typing a letter, the web hardware button would limit results only to bookmarks and perhaps browser history. The contacts button would limit the results to contacts only. Metadata as well as item names and other fields would be searched.

The cognitive load for remembering how to access infrequent items dimishes - to nothing if the user remembers some of the name of the item. In the current situation, the user would have to figure out where on the device the item might be, perhaps searching several branches in the tree before finding it in a list.

A LaunchBar-like solution also results in an extremely personalized experience, which is appropriate for a mobile phone.


«« Phone Cameras?  |  On the use of tabs to organize content »»

2 Comments

  1. Curious, why wasn’t “Tab interfaces” mentioned above? I believe it is a great way to organize the application and its information on small screens…

    ceo

    Comment by C. Enrique Ortiz — January 7, 2006 @ 11:39 am

  2. I’m lukewarm on the subject of tabs. As information organization, they sometimes make sense. You should use special caution when using them on a scroll-and-select device because they might make the rest of the screen difficult to access – getting to something on the fourth tab requires scrolling through the first three tabs, selecting the tab, then knowing to scroll down to get to the rest of the screen.

    In a J2ME canvas this isn’t too bad, aside from numerous clicks, as you can map left and right to navigate between the tabs and use up and down to navigate the rest of the screen. In a browser page, the user will have to scroll downward to bypass the tabs to interact with the rest of the page (many browsers focus on the top) and I’m not a sophisiticated enough coder to implement tabs without tables or Javascript – both of which are not a good idea on a mobile web page (for now).

    The biggest issue with tabs is that they are absolutely limited in how much content they can organize … Hey – this is about to be a new blog entry. Thanks.

    Comment by Barbara — January 7, 2006 @ 2:55 pm

RSS feed for comments on this post. TrackBack URI

Sorry, the comment form is closed at this time.