Recent Blog Posts

Nicholas Nova over at pasta and vinegar recently wrote about some user experience issues of location-based applications in Location matters but .... He cites the laboratory example of a collaborative treasure hunt game in which users use TabletPC software to achieve a goal.

Group members in this test collaborated with each other more when their location was not presented to their fellow users, although the group's performance (I assume effectiveness at achieving the goal) did not change. They communicated with each other better, and improved their strategy over time. Providing group members with information about each others' positions made them rely on that information rather than each other.

This makes me wonder about what I'll temporarily call the "Video Game Effect": do people, when watching moving avatars on a screen, interact with the avatars rather than the world and each other? I don't have any research to answer that question.

Regardless, it does suggest that there is an optimum amount of data that should be presented to a group of users, and that they will make better decisions if they rely on the environment for a certain class of information.

These collaborative games share a lot in common with business applications. For example, I worked with an application that tracked the location of field repair personnel. A central dispatcher would send the repair guys (almost universally male) to houses around the community. These folks are trying to collaboriatively solve a problem: how to reduce the amount of time they are driving and increase the number of stops they make in a day. The old system of defining territories has several limitations, and they found that they were frequently driving halfway across town when another customer was a short ways away.

If we assumed that the repair crew had no central dispatcher, we could likely take one of these game interfaces and make very minor modifications to help the repair crew make the best decisions. (now, if they could just find my house I'd be happy)

The dream of the "paperless office" was in large part destroyed by the fact that it is simply harder to understand information on a computer screen compared to a piece of paper. So we had more information to parse due to the ease of producing it, and easy access to printers. Thus the amount of paper used skyrocketed. Academic studies demonstrate the difficulty of reading information on the computer screen as well.

Understanding information written on a small screen is harder still. I find that I have little idea of what I've read on a phone. My LifeDrive is better, but still not good for understanding text written for books. There are several reasons why:

• Between-screen continuity is broken. Any time you have to scroll from one page to the next, either on paper or on a screen, you insert a small cognitive task (how to turn the page) and a large physical task (turning the page and finding the beginning of the text). Combined, these tasks frequently cause the flow of text to be lost. On a small screen, there are frequent page turns. For me, this is one of the biggest issues - by the time I get to the new screen I've lost the flow of text.
• Pixel density is frequently lower than on computer screens, making the font harder to read
• Scanning behavior isn't supported. When children learn to read, 70-80% of them scan text, while the rest read each word indvidually. For adults, the amount of information overload currently in society has taught us all to scan quickly, particularly when reading computer screens. Web writers know this, and thus write in very scannable ways. This entry, for example, is readily scannable with its bullet lists and short paragraphs. The small amount of information visible on a small screen breaks down the scanning process into artificial chunks, inhibiting comprehension.
• Phrase scanning is especially unsupported. One common scanning technique looks at phrases (as opposed to, for example, nouns). Lots of word wrapping and information broken between screens makes this technique nearly impossible. Users with this technique will particularly lose comprehension.
• Negative space fails to give cues, especially on the smallest screens. Where information isn't on a screen is a key component in telling your eye how to read the screen. There isn't any room to create meaningful negative space on small screens, so these cues are also lost.

Other issues confounding the problem of understanding text from a mobile device include probability of screen glare and probability of environmental distractions.

Potential design solutions for these problems include rollable displays to create larger screens, e-ink displays to fix the pixel density problem, audio screen reading technologies to make the information enter the head both aurally and visually, and possibly fisheye displays in which the text currently in focus is larger but nearby text is smaller.

Hello Barbara, I am Luca Passani, the WURFL architect. I noticed your blog about the Device Description Landscape document and WURFL. First, I need to thank you for the kind words about WURFL. I agree with a lot of what you say. Also, while there are things that I do intend to comment on, I totally see where you are coming from. After all, I dealt with usability on mobile devices myself, and WURFL (and WALL!) are the way they are because I had user experience in mind all the way.

I'll proceed with order. As far as the Device Description Landscape document is concerned, it was produced by a W3C working group (DDWG) in which both I and Andrea Trasatti (the WURFL maintainer) were explicitly invited as "invited experts" (W3C seats cost companies a few thousand bucks, normally. We got there for free).

Since the landscape document is also our work, it would be pretty unfair for us to betray the happy DDWG gang that
produced it, just because someone gave extra candies to WURFL. Given my experience with other W3C working groups (Best Practices, also part of the Mobile Web Initiative), I can tell you that the people in the DDWG are smart and knowledgeable. In fact, while a lot of work remains to be done in DDWG to get to anything of practical value for developers, we did achieve a clear understanding of the problem and its objectives (which I cannot honestly say of BPWG, Mobile Web Best Practice, for example: this message ).

In short, while the landscape document can appear as a modest achievement to the distracted reader, it is a noticeable result for anyone who is familiar with W3C's excruciating process to achieve consensus. As an aside, I suspect that everyone who knows little about the problem of device fragmentation, will find this document valuable reading.

And now, I'll go for the WURFL. If my job was in sales, I would thank you for all you said about WURFL and chant praise for another half hour. For the good and for the bad, my background is engineering, though. I don't want to misrepresent what WURFL currently does of one inch. While it is true that we have a bunch of useful capabilities in the WURFL, not all of them are equally well supported for all devices. The reason for this is that WURFL is only as accurate as:
- developer reports
- UAProf
- published documentation about devices
- fall back on the capabilities of similar devices
(depending on which one of these techniques the developer community feels to be the most accurate).

The implication of this is that we really got good data for some capabilities, while it is not so good for other capabilities still. I am not claiming that WURFL is a panacea to all issues related to device description. I just claim that WURFL is a hell of a starting point, if all you have, as a developer, is either UAProf or nothing.

One key aspect of mobile development (which, honestly, not many seem to understand) is that not only are all devices different, but also most projects in the mobile space are one-off. What this means in practice is that, no matter how many device capabilities you identify, there will always be new capabilities which were not accounted for, but which are all of a sudden crucial for delivering an optimized user experience on some devices for some new service. Being the usability professional that you are, you came up with a great example: Two great devices with identical XHTML/CSS support, but different input mechanisms. A typical scenario here would be to create two different XHTML UIs for the application: one for the touch screen and one for the roller-selector.

But how do you know which device to assign to which UI? If WURFL contained that info already, that would mean that someone has already done part of your job for you. Generally speaking, this is only happening for the most common capabilities: first, everyone is busy building their own mobile apps, and secondly, even if they had collected those data you need, 99% of the developers in the mobile space are, by default, not inclined to share the information (they don't see the benefit, I guess).

So, why should you be bothered with WURFL then? you should be for two very good reasons:

- WURFL gives you a powerful framework to add your own device info to the repository (patch file). In real projects, you
can model new capabilities (and capability values) for whatever device you are required to support in no time. If you have dealt with UAProf and/or commercial products, you know that this is a huge advantage.

- Secondly, you can decide to become what we call a "capability mentor", have me and Andrea add your capability to the big WURFL, and enable you to share the data with the community. This will give you a much better chance of creating a specialized community of content authors who need the same capabilities. In other words, many of those not inclined to share, are now inclined to share and have everyone benefit from the common effort. Neither UAProf, nor commercial solutions can point to such an enthusiastic army of developers to support them.

In your particular case, you could introduce a capability called (out of thin air):

touch_screen_navigation (true|false)

make sure that it's set to false for the "generic" (unrecognized) device, while setting it to true for devices that implement
"touch screen" navigation decently (probably anything between 40 and 100 devices, but start with the ones you know for sure). At that point, you are done, and you can have your application figure out instantly whether a given device should be directed to the touch screen UI or not.

Bottom line, WURFL may be no magic wand, but if you are serious about your project, it is the tool that makes an otherwise challenging issue manageable, and can bring your application to a level of usability that makes it stand from the crowd.

Luca

The W3C just announced the publication of the Device Description Landscape document. This is an exploration of the current best practices in device description storage, including many of the challenges such as maintaining the database, and accuracy. I remember working with one device that claimed it could support 1492 bytes but would actually crash at 1200 or so.

Device description technologies are useful for being able to intelligently render a web site to a variety of devices. The W3C document cites screen size, supported and preferred markup languages, supported and preferred image types, color support, size limitations, and what features the device supports. These are all useful for site design, but they are woefully insufficient.

WURFL goes a lot further. It has all the above, plus language-specific information for CHTML, XHTML, WML, and J2ME. In XHTML, for example, there are a bunch of known rendering differences between devices. A device:

• may or may not honor the page's background color,
• may or may not render form elements if they are in a table,
• may render select controls differently,
• may or may not support table rendering well enough to use tables as layout (which, by the way, you shouldn't do on scroll-and-select devices),
• may or may not be able to make phone calls,
• may or may not support the wml2 namespace, and
• may have link rendering that gets lost with certain background colors

WURFL supports all of the above, and more. Because some of the above decisions are human judgment rather than feature list, I don't feel as a designer that I can trust the device manufacturer to provide accurate information. Thus an open source solution - particularly one that I can customize - is appealing.

But WURFL doesn't go far enough. It doesn't give enough information to make the best design decisions for user experience.

Consider, for example, two devices with identical capabilities except one is a touch screen and the other is driven by a rocker and select key (scroll-and-select input). Let's say they both have beautiful CSS and table rendering capabilities. Now consider a pretty standard web page, with tabs or breadcrumbs (or both) across the top.

Using tabs or breadcrumbs with a stylus is largely like using them with a mouse, and both common designs are good. Scroll-and-select devices, on the other hand, work more like a blind user with a screen reader, and all that top navigation is just so many steps between the user and the content.

Some devices might support initial cursor positioning, but others don't - so that isn't a site design solution to the problem. Accessibility advocates recommend that if you insist on using a highly visual design with navigation structures up top that you provide a "jump to content" link at the top. Of course, on the mobile device this solution doesn't work so well since that will take a relatively large portion of your screen, and users are reading top-down not content first.

So the best solution is to not use top navigation on a scroll-and-select device, but to use other mechanism or put navigation at the bottom of the screen. This, unfortunately, will look at best odd on the touchscreen device. And unless you build your own device description database, you have no way of knowing exactly which device works how.

What else is missing from device description languages? We as an industry - particularly as designers - should be having this discussion.

My recent post about meaningful news has got me looking at news options on both my mobile devices and my computer. I had a list of RSS feeds but I wasn't particularly happy with the Safari RSS reader - it didn't tell me which ones I had read, it sorted things in an odd order such that some unread items were mixed in with some already-read items, and it was flat out hard to glean information from it.

It turns out (surprise!) that the Google personalized home/search page does the trick for me. I added my several RSS feeds in the "Add Content" area of the screen, then reorganized the screen based on my desires. Things like weather and movies were well below the fold, in the right column. This took care of my needs when on the computer.

The Google home page is the same on my mobile phone and on my Palm, without trying to shove all 20+ sources onto the page. I went ahead and set Google as my home page (on Sprint and many other browsers, choose the Menu softkey, select Preferences, and set your home page - the garden is only walled if you don't use the tool fully).

Because it is a browser application, the link color tells me that I've read the story. The visual organization lets me prioritize what I want to read - some I need to keep up to date with; others are less important. Some are updated several times a day; others are updated weekly or less.

Google made some interesting choices in mapping this screen to the mobile device:

• An "RSS and email" link is the first one on the mobile screen, even above the entry field. This pushes personalized content up to the top, keeps their clean design, and also avoids the problem of not being able to find the cursor when using scroll-and-select devices.
• "Personalized Home Page" is a link at the bottom of the main page - which goes to the same place as the top link. This has the advantage of familiarity, but for some users the "RSS and email" link may never be followed because this one makes more sense. That will make for extra scrolling.
• The default portlets that I still have turned on come first: weather and quote. Never mind the fact that these are buried in the far right column, far under the fold on my main page. This doesn't quite meet my desires.
• The stories on my mobile are organized by source, just as they are on the desktop, with the story titles under each source name.
• Other standard content comes next in the list of stories on my mobile, again ignoring the fact that I've placed them at the bottom of my desktop screen.
• Last comes the content I've fetched via RSS feeds, in an order that seems like it is left-to-right from my desktop screen. Too bad I've got things categorized in columns.

The problems with the Google mobile personalized home page could quickly be solved by letting me define an order in which to display portlets on my mobile. Better yet would be to add a bit of link tracking and not show already-read stories (don't do this on the desktop).

There was a brief mention on the E-Ink site about a rollable display prototype that I recently mentioned. Now this prototype is a full fledged company: Polymer Vision.

This is really exciting as a low-power flexible display allows us to cheat The Carry Principle a bit and create small devices with big displays. It's still necessary to have one dimension of the device be larger than the screen, so we'll probably have a bunch of oblong devices.

This sort of technology may make the clamshell style phone be less popular. Imagine a candybar phone with a small keypad and screen on the main face, a slide-out QWERTY keyboard from one side and a roll-out display on the other side.