Recent Blog Posts

Most mobile news offerings are web sites or applications that display the same old news, merely repackaged. Unfortunately the same old news is available on television, on the radio, in newspapers, in podcasts, and on full-sized computers. In many ways, reading news on small screens is the least efficient of all these delivery methods.

There has to be a reason to go through the hassle of reading on the small screen. One could be boredom or fitting productivity in otherwise unproductive time. Another is that the news is extremely relevant to the user. And that's where the magic of RSS feeds come in.

An increasing number of blogs and news sources provide these feeds for reading content away from the standard site. This gives the user significant control over presentation of information as well as the ability to select exactly the information desired and have it delivered to a single location. It also enables reading content that is only available on a full-sized computer elsewhere.

For a mobile RSS reader, I've been using Quick News for the Palm, by Stand Alone Inc. The software is very buggy on my LifeDrive, which several issues that make me unwilling to pay money for the software. However, the experience has been interesting and has exposed some key design issues.

RSS feed discovery is the first challenge. This is something I prefer to do on my full-sized computer. I recently saw an estimate of 20 million active blogs world wide; finding the right ones is difficult. A mere list of blogs and feeds would be insufficient. Quick News has an importing mechanism for users willing to learn what "OPML" is and with a desktop tool that generates it.

Quick News allows the categorization of news feeds, which was very nice for prioritizing my time. Unfortunately I then wanted to read all articles in the category in a single list, as the category was my industry news list. I believe this is a critical feature for mobile access, and the Safari built-in RSS reader has this feature.

I found myself using a split screen version of the reader, with 4 lines of titles at the top, and the balance of the screen devoted to the actual article. If I had a smaller screen, I would have stuck with single-article display. Of course, the worst part of the Quick News design implementation was the lack of a "Read More ..." link allowing me to see the rest of the article.

This is also one place where a list item should not scroll. I need to be able to scan the post title quickly to understand the context of the post. The information, "the telecom maker is rated a strong buy" might be the entirety of the text - if I don't know which telecom maker it is, the information is meaningless. With Quick News, I to wait 15 seconds for the entirety of the title to scroll.

When I read an article & it is marked as read, re-updating should not make the article become "unread" or "new". This is extremely important to my experience.

Finally, while Quick News allows me to flag an article, I found this insufficient. I would like to save important stories to computer via (a) bookmark list, (b) email, © desktop file, (d) to do list, or (e) stickies. If I am going to do anything important with the information, like further research or forwarding the article, I am very likely to do that on my main workstation.

Fitt's Law (circa 1954) states that the time to acquire a target is a function of the distance to the target and the size of the target. The further the target is away from the user's current position, the longer it takes to move to the target. The smaller the target, the more the user has to use fine muscle control and hence take more time to move.

The implications of Fitt's law varies with design field; what we have learned over the past 20 years only somewhat applies to mobile devices. Some interpretations of Fitt's Law:

• Mouse driven interfaces (software) — the "large" controls are the edges of the screen, as they are really infinitely large in one direction. Corners are larger still. Thus frequently used items should go around the edges. The existence of a cursor gives a precise definition of "close," so contextual menus can be truly context driven.
• Mouse driven web sites — when a link is activated, the screen changes, possibly completely, and the edges of the screen are not accessible by the web page. Thus "where the cursor is" is the largest target, and cultural visual scanning practices are used to place most elements. Consistency between pages helps the visual scanning process. Note: modern web development techniques allow for an interaction style more closely resembling software.
• Stylus driven interfaces (small screens) — the concept of "distance" is almost meaningless, as the entire screen is smaller than the hand and there is no cursor. Thus size and predictability of location become the key issues for speed of target acquisition.
• Scroll-and-select interfaces (small screens) — the number of keypresses to access a target is a good measure of distance, and size is reasonably represented by whether the target is currently displayed or not. As more devices display several font sizes, target size will be a combination of visibility and target size.

Note that in these examples, the keyboard is a known distance away (short distance) but suffers the challenge of no visual display-control association (small size).

Back in 1998, an industrial designer introduced me to the flexible display concept, specifically E Ink. His vision was (among other things) that product packaging could be made with such displays, which are persistent, only requiring power to change the display. He had the idea that the packaging could change from "buy me" in-store graphics to as-needed user instructions, all on the same surface.

I was intrigued, and learned a bit about the technologies and the companies involved. The displays do not emit light; they instead change the reflective characteristics of the surface. Since the change is mechanical, it has a slow refresh rate but also stays put once the refresh is made. The manufacturing process also allows for arbitrarily large (just limited by the size of the machinery) displays.

Gyricon developed a similar technology and had access to interesting supporting technologies such as plastic circuit boards. They focused on the easy-to-implement changable signs. Xerox, the parent company, has decided to close down Gyricon and there is no indication on their site that they are serious about "licensing the underlying technologies" - a search of their site for ;flexible displays" generates only one hit, almost two years old. To me, this seems like yet another example of Xerox's long history of developing great technologies and being completely unable to commercialize them.

Xerox relinquished, and the E Ink technology is being actively developed.

While I liked the Xerox technology slightly better, the E Ink product vision was a lot closer to mine, with a (future) focus on mobility. And this year, things are finally starting to look interesting. I'll leave the book readers for a future post.

Ambient Devices is making good use of E Ink with their 5 Day Weather Forecaster, making a clean, easy to read display with low power requirements. Lexar did something even more interesting: they created a pocket drive with a capacity used meter.

The Lexar product is an example of how E Ink might transform the nature of some of our information devices. A laptop computer might have a display on the outside with its owners name, possibly including corporate tracking data. This would make asset management easier for corporations. A handheld device might have static information on the outside, including contact information in case the device is lost - I would be more willing to lock my device if that were in place.

Alternately, an Ambient-style display on the outside of my phone could let me know the time, current weather/stock/traffic information, and whether I have missed calls or received messages - all with negligible power draw. This would be less expensive, less fragile, and more informative than current sub-LCD screens.

I'm also particularly interested in truly flexible rollable displays Phillips has prototyped. This concept solves the problem of how to get a large screen into your pocket: roll it up! I'd love to see a GPS/map device with this type of display, as tiny maps do not help me understand how to get where I am going.

As a trained ergonomist with family members with severe repetitive stress injuries like carpal tunnel syndrome, I've long wondered when the first mobile-related RSIs would show up. I knew it would be a while because few people use their phone for hours without break, but some people do.

I was particularly worried about holding a phone up to an ear for hours (one reason why I don't like finger phones) because of the major strain on the elbow and the fact that people do talk for hours. This, to my mind, is the primary value of hands-free headsets.

Well, among youth there are certainly people who type (or game) extensively. There's been evidence of use-driven structural changes in the hands of gaming and texting youth. This has been recognized by the term "Thumb Generation" ("Thumb Tribe" in Japan). However, nobody had yet talked about RSIs among this group.

I've now seen my first mobile-related RSI story, from the CBS Chicago affiliate. Indeed, people are getting RSIs in the elbow due to talking on the phone. There are even cases of injuries induced by typing on the Blackberry.

So everybody: use headsets or a speakerphone if you talk for long periods. If you don't, switch ears periodically. Take longer breaks between using the phone ... and don't use the computer mouse or mobile phone keypad to fill in the time. And take a break from the typing.

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. Even Amazon.com's desktop site has abandoned tabs as its primary organization (one tab is now labeled "all 32 product categories"). On a mobile phone, perhaps 4 tabs can be used if you want to use text labels; only 10 if you want to risk small icons. I wouldn't go for icons unless the user is going to be using the application several times a day, more or less every day - too much to remember otherwise.

Thus tabs as a method of organization are more limited in amount of information than are menus. Their biggest advantage is that you can leave the navigation on the screen at all times. Only sometimes is this desirable for a mobile application because there isn't that much screen available for the application and more content may be more desirable.

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.