A small display is a magnifying glass for usability problems, says Carl Zetie, VP of Giga Information Group. To solve the problem, examine the user's and application's context.
Have you ever wondered why most software is so annoying? Even the most user-friendly applications can be frustrating at times, and the worst are like having an eager but inexperienced intern constantly asking, "Can I help with that?" This intern knows how to do anything you tell it to do, step by step, but never figures out for itself what you're trying to do and--worst of all--never gets any better at its job. Think Microsoft Office Assistant, a feature so annoying that Microsoft actually advertised its removal as a reason to upgrade to Office XP. Most applications' user interactions are, in one word, naïve.
Move to the domain of mobile devices, and difficulties are heightened. The desktop, with its large screen, mouse, and keyboard, is reasonably forgiving of naive applications. On a mobile phone with just a few lines of text and a keypad, or a PDA with a few square inches of real estate, the frustrations are exacerbated. A small display is a magnifying glass for usability problems, and consequently, an intense focus on usability has long been acknowledged as key to success by leading practitioners. Examples include Palm's PIM application design; Handspring's software integrating PDA and phone functions in the Treo communicator; and Sprint PCS, which, despite popular perceptions, actually has significant traction for its Wireless Application Protocol service.
Design Challenges Despite these commendable efforts, adoption by consumers of generic, "horizontal" mobile portal services in particular has been very disappointing for service providers.
Part of the problem is that the browsing philosophy of the Web doesn't translate well either to mobile devices or, more importantly, to mobile users. For the most part, mobile users are purposeful: They have a specific goal in mind, whether it's to buy a movie ticket or to find driving directions. The challenge for mobile applications is to figure out exactly what the user is trying to do, then make the task as efficient as possible.
Although classic usability can help, it's constrained by the limits of up-front analysis to identify tasks. To determine and support what a user is trying to do from moment to moment, something more dynamic is needed. The solution to that challenge may be a thing called "context"--and if it pays off, it will be applicable not only to mobile applications but also to Web services and maybe even desktop applications.
Mobile service providers--both carriers and content providers--are aware of the need to better understand what the user is trying to do. That's one reason you're going to hear a lot about location services as the missing "magic sauce" for mobile applications. (In the United States, the FCC has mandated "E911" service, which is helping to kick-start implementation by wireless carriers.)
Unfortunately, many providers are likely to be disappointed by the results. To see why, just consider the most frequently posited example of a consumer location-driven service. As you're passing a coffee shop, your phone goes off with a special offer delivered by WAP Push or Short Message Service: "Step into the coffee shop now and get 50 cents off a latté." Now consider in how many different ways this "push" alert could be the wrong thing to do: You're in a hurry and don't have time for coffee. You don't drink coffee, only tea. You were driving down the street, not walking (and already got buzzed by five business you passed at 30 miles an hour). It's midnight and the shop is closed. Or perhaps worst of all, you were already intending to step in and buy a latté, so the coffee shop just gave away 50 cents it didn't need to.
What this example highlights is that location is just one dimension in a long list of information that applications need in order to make smarter adaptive decisions; that long list makes up the user's context, and the opposite of naïve applications is context-aware applications.
Looking For Context
A few examples exist of context-aware applications or applications that come close. Let's examine some of them.
Outside the consumer realm, consider a field-service application that dynamically schedules engineers to fix problems. To do so effectively, the application needs to know where all engineers are, what they're working on (and its relative importance), when their shifts are supposed to end (because of overtime cost), and whether they have both the skills and the replacement parts to effect the repair.
On the desktop, Amazon.com uses a lot of contextual information, ranging from what you've bought in the past and what people of similar taste also liked to the listings you explored most recently and newly published items that might interest you. The result is a user interface that's continuously updated with content and products that Amazon thinks will be most relevant to you. Furthermore, Amazon is constantly refining its design, identifying what works and what doesn't, to make the experience better.
In the world of mobile portals, OracleMobile.com introduced some innovative ideas, such as promoting to the top of selection lists the most frequently used items (such as a stock ticker) or most relevant items (such as the most imminent travel itinerary), and passing information from one "portlet" to another. For example, if you find a restaurant listing appealing, you don't have to re-enter the address to get the driving directions.
Context-aware applications draw on information gathered over a variety of time spans: relatively static facts such as roles, skills, and tasks, identified through usability and classic analysis; evolving information such as purchase history, events booked in your calendar, and user-specified preferences; and instantaneous information such as recent actions, time of day, status of tasks in progress, and of course, location. To build such applications, you'll need adapters that can draw information from a variety of back-end (enterprise resource planning, customer-relationship management, calendar) and front-end (location, presence, availability) sources. You'll need sophisticated processing of that information (using rules determined by task analysis) to figure out what the user needs most right now; unlike naive applications, which rely on explicit information, context-aware applications rely heavily on inference and implication. And you'll need a flexible, dynamic user interface that can make the most useful tasks and information most readily accessible.
None of these technologies is unique by itself, but context-aware applications combine them to unique effect. Products that package some of these capabilities are emerging even now.
Although the most obvious initial applications will be in improving mobile applications, there could be a tremendous impact on Web services. Suppose you want to dynamically invoke a service from another business: Which company you contact, what terms of business you offer, and how you interface could all be determined dynamically based on factors from credit terms to quality of previous service to urgency.
And maybe, eventually, context awareness will find its way back into desktop applications, and we'll get an Office Assistant that's just a little less annoying.
5 Top Federal Initiatives For 2015As InformationWeek Government readers were busy firming up their fiscal year 2015 budgets, we asked them to rate more than 30 IT initiatives in terms of importance and current leadership focus. No surprise, among more than 30 options, security is No. 1. After that, things get less predictable.
Join us for a roundup of the top stories on InformationWeek.com for the week of December 14, 2014. Be here for the show and for the incredible Friday Afternoon Conversation that runs beside the program.