Recent Blog Posts

interview with Kim Lenox of Adaptive Path

In preparation for Adaptive Path’s UX Week (use discount code UXBB for a 15% discount), Kim Lenox interviewed me. Go take a look!

Tags: Design, Permalink | Comments (0) July 31, 2007

email, SMS, and messaging

There's this odd argument that pundits like Tomi Ahonen assert that texting is the most popular data application on the planet. And they are right.

I think they are wrong about email being for "old folks" and "stodgy American executives." Certainly there's a growing perception that SMS is for conversing with friends, and email is for conversing with elders (I've seen this data repeated in both Japan and Europe). Tomi will tell you all about how SMS is for all ages, so that particular issue may wane.

But do the stodgy American executives have a point? Is Blackberry really on to something?

SMS and email are different media. One is good for short messages, quick response times, time-sensitive communications, information snacking. The other is good for time-insensitive communications (hours/days not minutes), complex thoughts, attachments, good archiving, mailing lists, and so forth.

Even Tomi knows this: his mailing list uses email, not SMS.

160 Characters learned that users expect a response to a text message in 5 minutes, in contrast to up to 24 hours for email. This finding just reinforces the idea that the two messaging types have different purposes, though there is some technical overlap.

Personally I would be quite displeased if my phone buzzed every time I had an incoming communication. I (a backwards American?) use SMS for coordinating with others, for building social ties, and so forth. It's not perfect.

Other messaging types are also quite good. I'd like to see more of "Voice SMS"; only a few people have access to it, and there isn't cross-carrier interoperability.

could an evolved HDML have made thin clients less necessary?

Before Openwave, before Phone.com, before Unwired Planet, was Libris. This company invented Handheld Device Markup Language and related browser, and launched it on the AT&T network. Keep in mind that the wireless connection was around 9600 baud, the phones displayed text, and displays were small. The browser embedded a handful of small graphics into the phone, which a site could call up to enhance its text. In 1998, the company (now Unwired Planet) co-founded the WAP Forum, and WML replaced HDML. UP was unable to leverage all of its excellent design work.
HDML (and its browser) downloaded decks rather than pages. Like WML, HDML was optimized for its very limited environment. But unlike WML, HDML had several features that actually enhanced the user experience.

On such a small screen with limited memory, cache control is very important. Thus HDML allowed the developer to designate a series of cards and decks that, when exited, would be removed from cache en mass. This didn't make its way into WML.

With such a large lag in connection (on most operators' networks, it took 30+ seconds to reconnect to the network; 10 seconds if already connected was typical if I remember correctly), the developer could indicate what content to pre-fetch so the user could get to it faster. This didn't make its way into WML.

The technology's primary drawback was the marketing assertion that it was "the web in your hand". Users took one glance at that, saw that the web could not be displayed on a 4-line text-only display, and "WAP is crap" was born.

The lessons learned 10 years ago have been forgotten. But what if they hadn't?

What if the WAP Forum had branched into a pair of services: HTML-ish and thin-client-ish? If both sides had "won" that debate? If we now had an evolved mature standard to load scripted applets onto the phone, rather than the "15 versions of widget frameworks" we're now finding?

speculating on Sprint-Google (Gnet?)

This is entirely speculative, but I find myself wondering about Google’s deal with Sprint and what might happen if Google would purchase a controlling interest in Sprint, possibly to the point of a buyout.

First, they’d have to avoid all of the pitfalls of the AOL-TimeWarner merger. I’ll leave that to other folks to speculate about.

There would be a culture clash, but Sprint management is apparently happy to handle that.  The blocked merger with WorldCom would have been really bad, and Sprint should give thanks to the government for blocking it. The Nextel merger doesn’t seem to have done a lot of good.

Google, however, brings a number of assets that would make Sprint’s network more valuable, such as long-tail focused advertising via Adsense. Sprint provides the most forward-looking focus on data services, but with major weaknesses in other competencies. Maybe it would work?

Given that Google has five times the market capitalization that Sprint does, they would certainly be in the driver’s seat. I’m thinking free phone service, ad-based revenue models, Wimax connections, and open device access. That last one might have to be verified through the FCC.

With free service and open access, the device manufacturers could flock to serving Gnet customers. Their margins and innovation would go up. The innovation would leak into other operators’ networks if they didn’t want to lose all their customers.

more than just a pretty face

The various user experience (UX) professions have finally convinced the majority of businesses that a good user interface (which thereupon leads to good usability and improved pleasure of use) goes beyond just putting pretty graphics on the screen.

It even goes beyond arranging the screen in a pleasing manner.

It even goes beyond deciding which functions go on which screen.

Companies with little UX exposure have not yet accepted this last one, but it is key. Expect the Sprints, Microsofts, and IBMs of the world to have it right, and many startups to not even consider the possibility.

But a good UX goes much deeper, even when limiting ourselves to product design. Consider an application to display television listings. Sure, you need a good UI to display a grid. But what else? Consider the following:
  • viewing 250 channels is difficult on a large screen, and more so on a small screen
  • most users will want to view a subset of channels, perhaps 15-20 in normal use
  • at a given time, a user might be browsing for something to watch, or may be in the mood for something (comedy, sports, soccer, movie, ...)
  • many channels have a variety of types of shows, not all of which will be appealing to a specific user
  • a TV or Tivo may be present, and a mobile application would have to deliver some type of superior experience despite the limitations of small screen
A simple grid won't help users much. Instead, we'd focus on personalization, social components, and scheduling. Ideally, we'd hook into the user's home system, but that's asking a bit much for a simple application. So, we would consider designing the UI around:
  • Eliminating "never interested" channels from grid
  • Ability to navigate by genre
  • Learning the user's habits to help make suggestions
  • Adding friends, who can chat about and rate shows
  • Make recommendations based on what similar people like
  • Ability to schedule a show, watch it on the mobile, or set an alarm to warn the user
  • Ability to live chat with friends during a show

The marketers ought to be happy with this functionality, and most of it does not require much more sophisticated programming than the simple grid.

Really, we work on helping users meet their needs, desires, and goals through product definition & design. This generally has a positive impact on marketing as well. And this is what we tend to mean by "user experience."

Tags: BusinessDesignTheory, Permalink | Comments (0) July 18, 2007

on widgets & Celltop usability

Alltel, a regional operator in the US, partnered with Frog Design to launch Celltop widgets. I mentioned this briefly in January.

This past week, Scott Weiss of Usable Products announced a usability study comparing Celltop to WAP and native UI for a variety of tasks.

What I found so interesting about the Usable Products study was that they compared the usability of a new interaction (CellTop) to that of well-learned applications (e.g., native UI for looking at call logs). As the entire session was only one hour, which included several tasks attempted both with and without CellTop. Thus the users had a year or two of experience with the native UI and were comparing to a UI with a new interaction paradigm. It's no wonder Celltop fared poorly.

Some tasks did not have quite as steep an experience difference. Checking weather is likely something many users only do occasionally, but the limitations of the mobile browser on the tested device means that the experience was reasonably familiar.

Celltop does indeed break many of the user expectations a bit. Some of this was done with intent. At the Austin Mobile Monday event in April, a key Celltop designer actually mentioned that she did not see the point in softkeys, and she pretty much ignored them. I disagree with her, but perhaps if everybody ignored softkeys the Celltop learning curve would have been more shallow.

In short, before believing that the Celltop widgets were indeed "less usable" than the native and WAP counterparts, I would like to see the test repeated with users who had been using Celltop for a few weeks. Alternately, give the users the opportunity to explore Celltop for half an hour, setting it up as they wish, on their own phones. Then compare task usability.