Let Them Pee: Avoiding the Sign-Up/Sign-In Mobile Antipattern

by:   |  Posted on

This is an excerpt from the upcoming Android Design Patterns: Interaction Design Solutions for Developers (Wiley, 2013) by Greg Nudelman

Anything that slows down customers or gets in their way after they download your app is a bad thing. That includes sign-up/sign-in forms that show up even before potential customers can figure out if the app is actually worth using.

It’s a simple UX equation

This antipattern seems to be going away more and more as companies are beginning to figure out the following simple UX equation:

Long sign-up form before you can use the app = Delete app

However, a fair number of apps still force customers to sign up, sign in, or perform some other useless action before they can use the app.

Example

The application SitOrSquat is a brilliant little piece of social engineering software that enables people to find bathrooms on the go, when they gotta go. Obviously, the basic use case implies a, shall we say, certain sense of urgency. This urgency is all but unfelt by the company that acquired the app, Procter and Gamble (P&G), as it would appear for the express purposes of marketing the Charmin brand of toilet paper. (It’s truly a match made in heaven—but I digress.)

Not content with the business of simply “Squeezing the Charmin” (that is, simple advertising), P&G executives decided for some unfathomable reason to force people to sign up for the app in multiple ways. First, as you can see in Figure 1, the app forces the customer (who is urgently looking for a place to relieve himself, let’s not forget) to use the awkward picker control to select his birthday to allegedly find out if he has been “potty trained.” This requirement would be torture on a normal day, but—I think you’ll agree—it’s excruciating when you really gotta go.

Registration Torture
Figure 1: Registration Torture: Sign Up/Sign In antipattern in SitOrSquat app.

But the fun does not stop there—if (and only if) the customer manages to use the picker to select the month and year of his birth correctly (how exactly does the app know it’s correct?), he then sees the EULA (Figure 2), which, as discussed in the previous article, End User License Agreement (EULA) Presentation (Boxes and Arrows January 2nd, 2013), is an antipattern all to itself.

EULA on a mobile device
Figure 2: Reading the EULA while wanting to pee should be an Olympic sport.

SitOrSquat’s EULA is long, complex, and written in such tiny font that reading it while waiting to go to the bathroom should be considered an Olympic sport, to be performed only once every four years. Assuming the customer gets through the EULA, P&G presents yet another sign-up screen, offering the user the option to sign in with Facebook, as shown in Figure 3.

Sharing bathroom habits
Figure 3: Finally! Sharing my bathroom habits on Facebook has never been easier!

I guess no one told the P&G execs that the Twitter message “pooping” is actually a prank. They must have legitimately thought that they could transfer some sort of social engineering information about the person’s bathroom habits to “achieve and maintain synergistic Facebook connectivity.” I would have to struggle hard to find monumental absurdities from social networking experiments that are equal to this. I can’t imagine that anyone thinks “Finally! Sharing my bathroom habits on Facebook has never been easier!”

Assuming that the user is a legitimate customer looking to use the bathroom for its intended purpose, and not a coprophiliac Facebook exhibitionist, we may hope that he will naturally dismiss the Facebook sign-in screen and come to the next jewel: the Tutorial, shown in Figure 4.

Tutorial is a sub-par Welcome experience pattern. Here it is another impediment to progress.
Figure 4: Tutorial is a sub-par Welcome experience pattern. Here it is another impediment to progress.

SitOrSquat tutorial is an extra screen that provides very little value, other than impeding the use of the app for its intended purpose. (If you need a tutorial, I recommend a much more effective contextual Watermark pattern, which I discuss in Chapter 5 of the Android Design Patterns book.)

50 Taps and 7 Screens of Antipatterns

Note that the entire app outside of registration consists of basically four screens (if you count the functionality to add bathrooms!). However, if you include all the sign-up antipattern screens (including my initial failure to prove that my potty training certificate is up to date, as referred to in Figure 1), it takes seven screens of the “preliminary” garbage before the content you are looking for finally shows up (refer to Figure 5). If you count the number of taps necessary to enter my birthday, that becomes almost 50 taps!

The Glory of 50 taps needed to get through the Sign Up/Sign In antipattern in SitOrSquat app.
Figure 5: The Glory of 50 taps needed to get through the Sign Up/Sign In antipattern in SitOrSquat app.

One of my favorite UX people, Tamara Adlin (who coauthored The Persona Lifecycle: Keeping People in Mind During Product Design with John Pruitt) wrote brilliantly: “For Heaven’s Sakes, Let Them Pee.” I believe that never before has this line been so appropriate. In the absurd pursuit of social media “exposure” coupled with endless sign-up screens, with heavy-handed “lawyering up,” P&G executives completely lost sight of the primary use case: letting their customer SitOrSquat.

Long sign-up screens detract from the key mobile use case: quick, simple information access on the go. Overly invasive sign-up/sign-in screens presented up front and without due cause will cause your customers to delete the app.

There is no reason to force anyone to register for anything

When deciding whether to force the customer to perform an action, consider this: If this were a web app, would you force the customer to do this? If you have Internet connection, you can save everything the customer does and connect it back to his device using a simple session token and a guest account. And even if you don’t (for example, while riding in a subway, using airplane mode, and so on), today’s smartphones have plenty of on-board storage you can use for later syncing with your servers when the mobile network eventually becomes available.

This means there is simply no reason to force anyone to register for anything, other than if they want to share the data from their phone with other devices. As a general rule, rather than forcing registration upon download or at the first opportunity, it is much better to allow the customer to save a piece of information locally on the phone without requiring that he log in. Wait until the customer asks for something that requires registration, such as sharing the information with another device or accessing information already saved in his account; at that point completing the registration makes perfect sense.

For example, imagine how absurd the Amazon.com shopping experience would be if the app asked you for your home address, billing address, and credit card upfront—before allowing you to see a single item for sale! Yet entering the home address (where would you like to have the items shipped?) and credit card (how would you like to pay for this?) makes perfect sense during the checkout, after the customer selects a few items and indicates she would like to complete the purchase.

Finally, remember that “Forms suck,” as brilliantly quipped by Luke Wroblewski in his book Web Form Design (Rosenfeld Media, 2008). Only ask for what you strictly need to proceed to the next step and omit extraneous information. (Effective mobile data entry controls and forms is a huge topic to which I devote chapters 10-12 of my upcoming Android Design Patterns book (Wiley March 11, 2013), now available on Amazon.com).

End User License Agreement (EULA) Presentation

by:   |  Posted on

This is an excerpt from the upcoming “Android Design Patterns: Interaction Design Solutions for Developers” (Wiley, 2013) by Greg Nudelman

The first thing your customers see when they download and open your app is the welcome mat you roll out for them. Unfortunately, this welcome mat commonly contains unfriendly impediments to progress and engagement: End User License Agreements (EULAs). Like the overzealous zombie cross-breed between a lawyer and a customs agent, this antipattern requires multiple forms to be filled out in triplicate, while keeping the customers from enjoying the app they have so laboriously invested time and flash memory space to download. This article exposes the culprit and suggests a friendlier welcome strategy for your mobile apps.

Antipattern: End User License Agreements (EULAs)

When customers open a mobile website, they can often engage immediately. Ironically, the same information accessed through apps frequently requires agreeing to various EULAs, often accompanied by ingenious strategies that force customers to slow down. EULA is an antipattern.

When and Where It Shows Up

EULAs are typically shown to the customer when the application is first launched and before the person can use the app. Unfortunately, when they do show up, EULAs are also frequently accompanied by various interface devices designed to slow people down. Some EULAs require people to scroll or paginate to the end of a 20-page document of incomprehensible lawyer-speak before they allow access. Others purposefully slow people down with confirmation screens that require extra taps. Truly, things in a torture department have evolved nicely since the days of Spanish Inquisition!

Example

Financial giant Chase provides a good example of a EULA. As shown in figure 1, when customers first download the Chase app, they are faced with having to accept a EULA even before they can log in.

figure1
Figure 1: EULA antipattern in Chase app.

 

 

 

 

 

 

 

 

 

 

What makes this example interesting, is that the same information is accessible on the mobile phone without needing to accept the EULA first: through the mobile web browser, as shown in Figure 2.

 

figure2
Figure 2: There is no EULA on the Chase mobile website.

 

 

 

 

 

 

 

 

 

 

 

 

Why Avoid It

The remarkable thing is not that the EULA is required. Lawyers want to eat, too, so the EULAs are an important component of today’s modern litigious society. Dealing with a first-world bank in the “New Normal” pretty much guarantees that you’ll be faced with signing some sort of a legal agreement at some point in the relationship. The issue is not the EULA itself—it is the thoughtlessness of the timing of the EULA’s appearance.

The app has no idea if you have turned on the mobile access on or have your password set up properly. (Most people have at least a few issues with this.) Therefore, the app has no idea if the bank can serve you on this device. However, already, the bank managed to warn you that doing business on the mobile device is dangerous and foolhardy and, should you choose to be reckless enough to continue, the bank thereby has no reasonable choice but to relinquish any and all responsibility for the future of your money. This is hardly an excellent way to start a mature brand relationship.

What should happen instead? Well, the mobile website provides a clue. First, it shows what a customer can do without logging in, such as finding a local branch or an ATM. Next, the mobile site enables the customer to log in. Then the system determines the state of the EULA that’s on file. If (to paraphrase Eric Clapton in “The Tales of Brave Ulysses”) the customers’ “naked ears were tortured by the EULA’s sweetly singing” at some point in the past, great—no need to repeat the sheer awesomeness of the experience. If not, well, it’s Lawyer Time. Consequently, if customers do not have Bill Pay turned on, for example, they don’t need to sign a Bill Pay EULA at all, now do they? The point is that the first page customers get when they first launch your app is your welcome mat. Make sure yours actually says “Welcome.”

Additional Considerations

Has anyone bothered asking, “How many relationships (that end well) begin with a EULA anyway?” How would Internet feel if every website you navigated to first asked you to agree to a EULA, even before you could see what the site was about? That just does not happen. You navigate to a website and see awesome welcome content immediately. (Otherwise, you’d be out of there before you could spell E-U-L-A.) When you use a site to purchase something, you get a simple Agree and Proceed button with a nearby link to a EULA agreement (not that anyone ever bothers to read those things anyway, especially on mobile) and merely proceed on your way.

If you can surf the web happily, taking for granted the awesomeness of the smorgasbord of information on the mobile and desktop, without ever giving a second thought to the EULAs, why do you need to tolerate a welcome mat of thoughtless invasive agreements on a mobile app platform?

Additional Information

You can find 70 essential mobile and tablet design ideas and antipatterns in my new book, Android Design Patterns: Interaction Design Solutions for Developers (Wiley, 2013) now available for pre-order at http://AndroidDesignBook.com where you can also sign up for the next free monthly Android Design Question and Answer session.

Four Key Principles of Mobile User Experience Design

by:   |  Posted on

Prior to becoming a senior UX designer at Popular Front Interactive, I spent two years as a mobile UX researcher within the Georgia Institute of Technology’s Mobile Technologies Group – a lab tasked with both future-casting and then rapidly prototyping innovative mobile experiences.

As I transitioned from academia to industry, I discovered that while mobile UX was discussed, it wasn’t discussed from the same broad frame of reference that I was used to within the confines of a research-based institution. Although more recent mobile UX conversations I have found myself in have undoubtedly benefited from the ongoing smart phone revolution, overall I still find these conversations to be needlessly driven by tactical adoration and lacking a conscious consensus regarding the fundamental principles of the mobile-user experience.

I do not presume these following principles to be all-inclusive or ultimately authoritative; rather, it is my hope that they are received as an anecdotal summation of my findings that might then spark and contribute to the larger conversation and consensus-building process.

 

PRINCIPLE #1: There is an intimate relationship between a user and their mobile device.

While an intimate relationship between an individual and their mobile device may seem like a given, the depth of that relationship probably goes deeper than most initially realize. In fact, I argue that the relationship extends to a physical level and the exchange of bodily fluids.

Imagine that it is a hot summer day and someone asks if they may borrow your mobile device to make a call. You hand it over. What level of trust does this simple act portray? Consider those around you right now: How many of them would you loan your mobile device to without hesitation? In your social circles, is it acceptable to decline such a request? How does context influence this scenario? What if you are at work? At a bar? How about a family reunion?

Let’s assume that this person is noticeably respectful of your device and the personal data it contains while making their call. At the call’s completion, the individual immediately and graciously returns it, whereupon you notice that it has accumulated an amount of … goo (perspiration, humidity, etc.) that is typical of mobile device use on a hot, sticky summer day…but then again, it isn’t your goo.

From a gooey physical level to a level of data privacy and security, there is an intimate bond between an individual and their mobile device, the strength of which often elevates the mobile device to the status of iconic personification. I am my phone. My phone is I.

In order to meet user expectations, mobile experiences should assume a semi-guarded state of primary usership; however, we must also responsibly protect our users. As the trend of embedding ourselves into our mobile devices increases, so does the cost of our devices being compromised. Assume primary ownership, allow for secondary usership, and plan for what might happen should we lose ourselves.

In a worst-case scenario, a compromised mobile device containing a significant amount of personal data would become the networked equivalent of a voodoo doll, where actions performed via the mobile device could cause actual harm to the individual personified by the device. In cases such as this, a remote wiping of all data on the device may be a user’s only recourse. 

 

PRINCIPLE #2: Screen size implies a user’s state. The user’s state infers their commitment to what is on the screen.

Imagine that you have been looking forward to seeing a particular blockbuster movie since the day it was green lit, and now that the day of its release has finally come you are going to get the most out of the experience by going to see the movie on the largest IMAX screen in the tri-state area.

Let’s say that when you finally take your seat in the sold-out theatre, you notice the person sitting next to you has a very annoying laugh. There is nowhere else to sit in the theatre, and you’ve been dying to see this movie for more than a year. What are the chances you abandon the experience and walk out? Probably fairly slim to none.

Now let’s say that you were backpacking through Europe when the above blockbuster was released, and that you have been equally anticipating the movie’s Blu-Ray release. To celebrate the release, you and your friends are gathering at the home of the friend who has an impressive home theater featuring a 52-inch HD screen, and again you find yourself seated next to the guy with the annoying laugh. Now how likely are you to abandon the experience? Probably more so than above, but still not likely.

What if this scenario played out in a college dorm room and the movie was being viewed on a 22-inch computer monitor? What if you were sitting next to the guy with the annoying laugh? The chances that you might abandon the experience are probably increasing.

What about a mobile device’s 3.5-inch screen? Is there any way you would sit next to some random person with an annoying laugh for 90 minutes to watch that movie? Probably not.

Although there are any number of social and environmental factors that would affect the user abandonment rate in the experiences described above, it is consistently possible to estimate a user’s level of commitment to an experience based upon the size of the screen through which they are engaging it.

Since mobile devices are likely to be the smallest screens in a user’s experience, the design of mobile experiences must accommodate the user’s varying commitment and distributed attention. How an experience accommodates these conditions will change depending on experience type — game, banking application, or the like — but the underlying impetus remains the same.

 

PRINCIPLE #3: Mobile interfaces are truncated. Other interfaces are not.

A dreaded task that usually accompanies getting a new mobile device is the act of transferring your data from the old device to the new. In years past, this meant arduously re-entering all of your contacts via the device’s, most likely E.161 (12 key), keypad.

There were a few early, notable attempts to ease this burden. GSM service providers pushed device manufacturers to save all user data to the devices SIM card by default, but the card’s limited storage capacity produced a poor user experience. On the other hand, CDMA service providers began automatically transferring address books between devices as a customer service. Even early on it was widely acknowledged that although an individual wanted to use information on their mobile device, they would go to great lengths to avoid having to manually enter that information.

Palm, and later Research in Motion, sought to improve this fact of mobile user experience by introducing and then proliferating the practice of syncing. This concept paired the truncated mobile interface with a full-sized desktop interface, allowing the user to easily and reasonably efficiently enter their address book data via a familiar QUERTY keyboard. Although this feature was initially limited to smart phones, it has since been incorporated into a wide swatch of consumer-grade devices. In fact, the notion of syncing has become so ubiquitous in mobile computing that the syncing of one’s entire networked identity is a core plank of Google’s Android operating system.

Even as miniaturized QUERTY became and becomes a more standard feature for all mobile devices, the truth remains that mobile interfaces are truncated and better used for manipulating data rather than entering it. One might conclude that as mobile devices continue to incorporate increasingly impressive sensor arrays, even standard, consumer-grade devices will provide powerful data collection capabilities. Regardless, data collection is not data entry, and data entry is not likely to become a mobile-appropriate activity. 

 

PRINCIPLE #4: Design for mobile platforms — the real ones.

There is a prevailing tendency is to discuss mobile platforms in terms of device manufacturers and service providers. This is understandable. It is fun and easy to get caught up in the moment of the latest tech demo, press release, or rumor. However, in needlessly binding the dialogue to the news of the day, we create unnecessary segmentation across an already complex landscape. The overall conversation is better served by focusing on the mobile platforms that have emerged as constants over time. Those four platforms are voice, messaging, the internet, and applications.

 

Voice

Voice was the original mobile platform, but it is also the platform with the most nebulous future. Don’t get me wrong: People will always need to make an occasional phone call. However, the frequency with which we are doing so is declining. Why? Mobility is as much about efficiency as anything else, and telephony (vocal communication and vocal response interfaces) has proven more difficult to optimize compared to other methods of interactivity.

For example, let’s say that you wanted to verify that your paycheck had been deposited. Most banks offer both tele-banking and online account access. Which interface are you likely to use, and why? How about if you wanted to order a pizza? Would you rather call, be placed on hold for five minutes, and then dictate your order to a multi-tasking teenager, or would you rather just use a GUI to do it?

 

Messaging

Friedhelm Hillebrand, the architect of the messaging (SMS) specification, described the platform’s limit of 160 characters as “perfectly sufficient.” The question we must ask ourselves in considering this mobile platform is, “Perfectly sufficient for what?” Although Hillebrand can provide several reasons for how he arrived at the 160-character limit, the one that I have always found the most interesting is that his team discovered that most postcards typically contain 150 characters or fewer.

Have you received or sent any postcards recently? If you have, they were likely either brief social communications (“Having a great time. Wish you were here!”) or they were simply task-oriented such as RSVP-ing for a wedding or canceling a subscription.

Messaging trends today continue to affirm Hillebrand’s postcard comparison. The vast majority of SMS traffic consists of social interactions within small groups of individuals. The second tier of usage is comprised of simple task-based transactions such as voting, entering contests, and receiving notifications.

In both cases, SMS and postcards, content-heavy experiences are a minority occurrence as the media is not designed to accommodate such a level of engagement. Furthermore one could argue that due to the designed efficiency of the messaging platform, that a content-heavy experience would be far from appropriate. 

 

The Internet

The Internet is the most awkward of the mobile platforms in that it is the one that is the least natively mobile. Currently almost 95% of all Internet users experience the web via displays with resolutions of 1024×768 or greater. As such, 1024×768 is observed as a fairly universal standard and is what a significant portion of Internet-based experiences are designed to. Given that mobile displays typically range between resolutions of 60×120 and 480×320, it is fairly obvious that most Internet-based experiences aren’t designed with mobile users as a primary consideration.

As a means of making Internet-based experiences more accessible to mobile users, most mobile web browsers have been designed to include adaptive methodologies for displaying larger experiences on smaller screens. While these adaptive tactics, which typically employ pan and zoom-esque interactions, have undoubtedly made more of the Internet accessible to mobile user, one could hardly argue that it has resulted in a desirable user experience. In fact, if browsing the Internet from a desktop is regarded as a scanning activity, than browsing the Internet through the adaptive lens of a mobile browser might best be described as a squinting activity.

As mobile web usage has continued to emerge as a somewhat common activity, the assumption that Internet-based experiences are to be automatically adapted for mobile users has given way to the design of alternative experiences specifically for mobile users. While this trend has provided mobile users with more efficient and scannable web experiences, it also has the potential of overplaying the users’ expectations for Internet-based mobile experiences.

As Internet-based mobile experiences have become more device-centric and sophisticated, they have begun to resemble mobile applications, thus creating a scenario where users might expect the Internet-based experience to function as a mobile application would. The distinction between desktop applications and Internet-based experiences may be rapidly evaporating, but it remains germane in the mobile experience. Although there are several differences between the platforms, the primary point of contrast I will draw here is that applications are able to use device-level services such as sensors, ad-hoc networking, and optics, whereas Internet-based experiences cannot. While mobile browsers are beginning to make some of these services available to Internet-based experiences, each platform will always have affordances the other doesn’t. As such, and to manage user expectations, if an experience looks like an application and attempts to behave as an application would, then it should be an application — and vice-versa.

 

Applications

From a technical standpoint, applications represent executables that are native to a specific mobile environment, have been selectively installed, and have access to the device’s full array of available functionality. However from a UX standpoint, they represent a specialized interaction design that caters to an affluent, sophisticated, and targeted mobile user base.

As few as 24 months ago, the seemingly basic task of locating and installing an application on a mobile device required a fairly developed skill set. With the recent proliferation of “app stores,” this task has become more user friendly; however the percentage of users who are able to install an application on their mobile device nowhere near approaches that of those who know how to make a phone call or send a text message. So, regardless of recent improvements to the overall process of acquiring and installing a mobile application, the user who can perform this task would still be considered sophisticated compared to the overall segment.

All things considered, mobile applications might best be described as the boutique mobile platform. As is the case with most boutique experiences, a comparatively small audience will compensate for itself through fervor and zealotry. However, since the success of an application-based mobile experience is based almost entirely upon acceptance within that small audience, extraordinary attention must be paid to the particulars of the target audience’s needs and behaviors. What existing need is the application attempting to mobilize? What efficiencies can a focused interface bring to that workflow? How can the specific affordances of a mobile device augment and improve upon that experience in contrast to using one of the other mobile platforms?

Mobile applications are powerful tools…for a relatively small segment of individuals who want them and know how to use them.

 

Conclusion

Someone tweeting on behalf of Punchcut once wrote, “In mobile UX, don’t confuse precedence with standard.” I couldn’t agree more, but as I hope that I’ve successfully illustrated, this statement is well ahead of where the conversation should be. Both standards and precedence are both tactical perspectives. Within our context, they both represent distinct libraries of interactions and are either redefined as the landscape evolves or simply replaced as more elegant solutions are brought to market.

The variable nature of each of these categorizations only further demonstrates why it is best for the current mobile UX conversation to focus on higher-level principles rather than tactical particulars.

As mobile UX designers, we have both opportunity and choice in front of us. The opportunity is to establish the foundation principles of a stable, yet still emerging, experiential space. The choice lies between getting caught up in the excitement of the fad du jour or asking ourselves the difficult question of what foundational principles am I following, or establishing, with the work that I am currently doing.

The only unfortunate part is that the time we have to make this decision is quickly running out.

Lessons From Google Mobile

by:   |  Posted on

Google’s NYC office hosted a sold out last month’s meeting of the New York City Usability Professionals Association (NYC UPA), featuring a presentation by Leland Rechis, a UX designer in their mobile team. Exactly the sort of hyper-intelligent bespectacled geek one hopes to meet there, Rechis surveyed the key insights the UX group learned while building Google’s “mobile search product”:http://www.google.com/mobile.

Taken aback by the scale of the development effort, I began to wonder how many of the lessons learned were even relevant if you aren’t Google, or at least Google-sized. The basic problems of translating existing services and brands over to the mobile space concern many smaller organizations, but Rechis demonstrated that becoming a global mobile presence presents extraordinary challenges.

Basic problem solving still completely swamps any other creative concern when working on mobile sites. A refreshing blast of Spartan usability problems, mobile site design is uncluttered with your typical mamby-pamby web problems. Can a user get the information, and fast? Answer this question and you’re far ahead of everyone else.

The design process described was quite effective at powering through a lot of basic usability problems, but struck me as potentially ill suited to a younger project that might still be finding itself.

Here are four key points I took home. Continue reading Lessons From Google Mobile

Location and Presence in Mobile Data Services

by:   |  Posted on
“Mobile technology is expanding our design toolkit beyond the desktop, and those who embrace this technology to enhance the core functions of their products will offer their users a superior experience.”The emergence of a handful of popular mobile data services has changed the way we interact with our phones. Now, several technologies on the immediate horizon are about to change the way we (and our phones) interact with the world. Imagine…

  • You’re about to call your friend, but when you highlight her name in your address book, you see that she’s driving in the city. Since it’s just a social call, you decide to leave her a voicemail instead.
  • Your phone rings while you’re in a crowded movie theater. You automatically know the call is urgent; otherwise, your phone would have automatically silenced itself.
  • You’re wandering through the Paul Klee exhibit at the MOMA, enjoying the audio tour—and enjoying the fact that you didn’t need to borrow a special audio player; a hidden transmitter next to each painting delivers the content to your phone.
  • You’re out and about, and your phone beeps to tell you there’s an open house nearby that meets the requirements you specified through an online real estate service. You don’t have time to tour the house, but you do have time to drive by. You stop in front of the For Sale sign, which contains a transmitter that delivers detailed information about the house to your phone.

All of these scenarios are made possible by location-awareness and presence—two concepts now making their way into mobile devices and promising to enhance everything from social networking to marketing and advertising. Location-awareness enables a device (and the person carrying it) to be geographically located, while presence allows a user to know the status of another user.

Gartner predicts that the number of American businesses and consumers using location-aware computing will skyrocket from 150,000 in 2002 to 42 million in 2005. One reason for such lofty expectations is a 1996 FCC mandate requiring that by December 2005 all mobile carriers be able to locate any subscriber making an emergency 911 call to within an accuracy of 50 to 100 meters.

Even if these projections are overly optimistic, location-awareness and presence will surely change the way people use networked services. We, as designers, need to start thinking about the ways that mobility and location-awareness could enhance each service and application we design. Mobile technology is expanding our design toolkit beyond the desktop, and those who embrace this technology to enhance the core functions of their products will offer their users a superior experience. It’s time to take the Internet out of the office and into the streets.

A Brief History of Mobile Data Services
A mobile data service is any service on a mobile device other than voice calling. It’s worthwhile to present a brief history of mobile data as a backdrop to our discussion of location and presence because of the role these concepts will surely play in the mobile data services of the future. It’s also helpful to provide a sense of the overall market for mobile data.

The first mobile data service of any significance was SMS (Short Message Service) which was originally developed by carriers as a way to send up to 160 bytes of data (including emergency alerts, special promotions, and even software upgrades) from a central point directly to their customers’ handsets. Carriers soon recognized the potential of SMS as an alternative mobile-to-mobile communication protocol, and they began to aggressively market the service toward business professionals–but it didn’t sell.

As it happened, however, limitations in their billing systems made it impossible for carriers to charge their prepaid customers—mostly teenagers and young people—for text messages. As soon as these users discovered they could send text messages for free, the volume of text messages increased quickly enough to threaten the network’s capacity to handle them. (Interestingly, for the youth segment, the usability barriers inherent in mobile message composition became a selling point, since these difficulties meant that the adults in their lives were largely unable and unwilling to use the service.)

If the popularity of prepaid plans—especially among youth—was the key driver for the success of SMS in Europe, then the lack of carrier interoperability was the key roadblock in the United States. US carriers have since resolved this issue, and the text messaging gap has closed quite a bit. The latest statistics show that US mobile users sent 2 billion text messages in April of this year, surpassing the UK for the first time.

After SMS text messaging came a series of SMS-based services, including ringtones, subscription-based information alerts, and SMS-based m-commerce (for example, purchasing items from a vending machine by sending text messages to a special number).

Shortly thereafter, WAP (Wireless Application Protocol) came along, with lots of hype and high expectations, but it was terribly slow and difficult to use. Most users were unwilling to wait several minutes to access a few lines of text displayed on a monochrome screen. In attempting to adapt desktop applications for wireless, carriers and content providers failed to offer any compelling services at all. WAP soon earned the nickname, “Wait And Pay.”

Mobile email and instant messaging had more success, since it was fairly easy to view mobility as an enhancement to these services. Also, the time-based content and flat structure of these services happened to work well on WAP. Mobile instant messaging introduced the concept of mobile presence and pioneered the connection between the desktop and the mobile in a single, continuous user experience. Users who are signed in to a mobile messenger client can communicate just like their buddies on a PC; the core messaging functionality is basically the same on any device.

Other mobile data services of note include mobile games and picture messaging (also known as multimedia messaging or MMS). These have become highly successful, vindicating carriers and analysts who have stood firmly by their belief in the future of mobile data—WAP notwithstanding.

The bottom line is that with an industry as young as mobile data, we can’t always predict what will fly and what will flop. What little data there is suggests that communication-based services are generally more successful than content-based ones.

One thing we know for sure is that users will continually surprise us by reinventing what vendors and designers produce, and it is this unpredictability that makes the mobile design space so exciting. The ubiquity of mobile devices and the willingness of early adopters to experiment means that any flexibility added by designers will be noticed by users.

The Introduction of Location and Presence
Presence management will change the way we use all person-to-person communication media and will affect almost every network service. Knowing a friend’s location and status in advance eliminates the need for a voice call when the only reason for calling is to find out that very information. Additionally, knowing a friend’s mood and activity helps determine which method of communication, if any, is most appropriate. For example, if I’m calling a friend just to chat, it would be useful to know she isn’t busy or in a bad mood. On the other hand, if I’m calling an associate with an urgent business question, I’d like to be able to convey this urgency, to encourage him to answer. More information about all parties in a communication is certain to enhance the communication itself.

Instant messaging introduced us to this concept of “pushed” presence—that is, the ability to see (without specifically requesting) the status of one’s friends. Since its introduction, presence data has become more accurate and more specific. In the beginning, we could merely see whether our buddies were online, offline or away. Later, we could see whether they were active or idle, and for how long. Then came a whole bunch of user-set choices (for example, out to lunch, in a meeting). Now we get real-time feedback, telling us for example when a user is typing. The introduction of location-awareness enables even richer presence data.

When designing presence into applications, designers need to understand the two basic types of presence: system-generated status and user-set status. “Online” and “idle” are examples of system-generated status. Location is another. “Busy,” “bored,” and “invisible” are examples of user-set status. System-generated status is important because it ‘s accurate, reliable, and objective, but it risks revealing things the user does not want to reveal. Therefore, the system, should give the user the ability to suspend, change, or override system-generated status unless there’s a compelling reason not to do so.

In general, systems should not use presence data to set limits that second-guess the user. Rather, systems should use the data to enable the user to make informed choices. For example, even if a user has set her status to “EXTREMELY BUSY,” the system should not prevent someone from calling her.

Designing for presence in general makes for an interesting discussion, but presence has especially profound implications for the design of mobile data services.

The Location Detection Infrastructure
A mix of technologies will make up the location and tracking infrastructure of the future:

  • Cellular triangulation — A mobile phone communicates with the closest cell (cellular antenna or tower). In an urban environment, one’s phone likely to be within range of several other cells as well. Using triangulation, these cells can locate a device indoors or outdoors to within about 120 meters. The precision decreases in rural areas, where a device is often within range of just a single cell. However, in a setting like this, a cell can be modified to detect the angle of transmission-reception in order to locate a device to within a mile or so.
  • Global Positioning System (GPS) — A few manufacturers have begun to sell mobile phones with built-in GPS, which uses a satellite grid to locate a device outdoors to within 3-15 meters.
  • WiFi (Wireless Fidelity) Networks — Several companies have begun to test prototypes of mobile phones outfitted with WiFi (the technology used in home wireless networks), which could be used to locate people indoors or outdoors to within 1-20 meters.
  • Ultrawideband — A few researchers and small companies (as well as the US military) are looking at ultrawideband as a promising location detection technology. It’s extremely accurate (to within centimeters) and requires very little power, but the technology is not very far along in development.

A Design Philosophy for Mobile Data
When thinking about designing the user experience for the next generation of mobile services, it is extremely important to recognize that WAP failed because it attempted to cram desktop computing into tiny devices. So first and foremost, designers need to move away from the WAP legacy and start thinking about mobile devices not as limited desktop PCs, but as versatile, connected, multi-modal devices.

Rather than thinking about the differences between a PC and a mobile phone, think about the difference between someone with a mobile phone and someone without one. Imagine yourself standing on a corner in a bustling neighborhood, and think about what a mobile phone adds to your capabilities (also, imagine standing there and trying to operate a desktop computer, or even a laptop).

Interpolation: On Terminology
As user experience designers, let’s use the term “mobile device” instead of “wireless device” or “mobile phone.”

“Mobile” speaks to the very nature of the device and its advantages over other devices, whereas “wireless” binds it to its relationship with other, older technologies. Mobile tells me what a device is, while wireless tells me what it is not.

“Device” doesn’t denote a particular technology or use, whereas “phone” carries with it many decades of expectations.

That said, “mobile phone” just sounds better in certain contexts, and we shouldn’t expect the mass market to use our preferred designer terminology.

The Multi-Modal User Experience (or, The UX Designer’s Toolkit)
In their latest generation, many mobile devices combine:

  • An audio interface (microphone and speaker)
  • A graphical interface (screen)
  • A physical/tactile interface (keypad)
  • Signal reception and location-detection (cellular, GPS, WiFi, etc.)
  • Connectivity (cellular, Bluetooth, IP)
  • Memory for storage of contacts, messages, photos, etc.
  • A camera
  • A variety of built-in applications (such as a contacts list, calendar, calculator)

This makes for an amazingly rich user experience designer’s toolkit. Right now, as user experience designers, we’re still largely at the mercy of the device manufacturers, but before long we’ll be able to define how these various interfaces and components can be leveraged and combined in a given application.

The Multi-Client User Experience
Beyond this designer’s toolkit, consider the fact that many services will have a user experience that is not confined to a single device. PCs will always have their strengths–a large display, a full QWERTY keyboard and mouse, a fast processor, lots of storage–but we must also recognize the strengths of mobile devices. The most obvious strengths are that they’re mobile and connected. They’re also locatable, and above all, they are designed for communication.

From a user experience design perspective, it’s exciting to think about how a user’s interaction with a particular service can be initiated from one client to another. With PCs, the user typically initiates the interaction and the PC demands her full, undivided attention throughout the process. With mobile devices, however, the application itself often initiates the interaction (for example, by ringing or beeping). This, combined with location-awareness and presence, gives user experience designers an extremely powerful opportunity to deliver the information and functionality best suited to the immediate situation.

The best services will leverage the advantages of each client.

A popular Japanese “item hunt” game called Mogi provides a good illustration of the potential for multi-client location-aware services. In the game, players organized into teams acquire currency by collecting items around the city of Tokyo – the actual city, not a virtual reality simulation of the city. Players using mobile phones are able to see a limited “radar” view of their immediate surroundings. They can see nearby players, and they can collect nearby items. Players using PCs get a macro view of the game. Using various full-city map views and a powerful interface, they can direct the efforts of their team. So mobile players can see less at one time, but they can move about the city, collecting items and engaging each other. PC players, on the other hand, can see much more, but they’re bound to one location, and they can’t collect anything.

Mogi is a good model because it effectively breaks large tasks into parts and assigns these parts to users with the most appropriate devices, leveraging the strengths of each device in a way consistent with how we generally use the devices. The game could easily be re-skinned as a system to dispatch taxis, monitor a truck fleet, manage emergency services or provide commuters with a view of public transit.

The upshot of all this is that it illustrates how designers will need to think about which components in the designer’s toolkit would best enhance the service they’re designing, and which aspects of the user experience are right for which type of client. With such a rich toolkit, mobile applications should offer users as many communication channels, device modes and client interfaces as possible. Applications should also provide enough information to enable users to make highly informed choices and reach their communication goals effectively.

The true promise of presence is that it will enable users to pay less attention to the system and give user experience designers more opportunities to design the interfaces out of the process. Presence will also enable designers to tailor the user experience more than ever before. It’s exciting to imagine a generation of services in which the user experience moves from a computer screen to phone speaker and back, based on the user’s location, situation, and step in a process, and it’s exciting to imagine being able to design for such immediacy and relevance.

Jonathan Grubb designs mobile software applications in hopes of making phones a little more fun and useful. He is currently designing Yahoo!’s new line of downloadable Java applications, which aim to extend Yahoo!’s services beyond the desktop. He was previously with Vodafone in the Bay Area and in Düsseldorf, Germany, where he designed mobile sites and applications for consumer audiences in the U.S., Western Europe, Australia, Africa, and Greece. He is also an artist, showing regularly in San Francisco galleries.

Shawn Smith is a Senior Information Architect at Avenue A | Razorfish. Previously, he managed a User Experience design team at Vodafone, where he was part of the team that created the first prototypes for Vodafone’s mobile data services portal (Vodafone Live!). He also co-managed the development of Vodafone’s first set of mobile interaction design guidelines for developers. Fun fact: He is Shawn Smith VII in the Internet Movie Database.

Solving Mobile Challenges with Psychology-driven IA

by:   |  Posted on
“In privacy-related issues, our mission as IAs is to make the user feel safe. We are dealing with the human mind and emotions, and it is therefore imperative that we understand what makes people feel safe, and what is important to them as users.”As the field of information architecture matures, we are beginning to understand the new challenges it raises for wireless media. This article suggests that some of these challenges can be best addressed through an approach called “psychology-driven information architecture” (PDIA), which bases design decisions and solutions on the psychological profile of the end user.

As an example of how psychology-driven IA can be applied to wireless applications, the article focuses on a service called friendZone, a commercial, location-based community and communication service available across Europe and Asia. Specifically, I will demonstrate how a psychology-driven design approach can address one of the predominant challenges of the wireless user experience: ensuring privacy. Along the way, I will illustrate how psychology-driven IA can be applied to the design of any interactive medium.

The challenges of wireless IA
When dealing with wireless IA, there are three main limitations that first come to mind: limited screens, limited screen display space for links and data, and limited bandwidth. As technology advances, it will grant us higher bandwidth, more screens, and sufficient screen space for all the relevant content we want to present (as we can already see in handsets such as the XDA Pocket PC). However, these are technological solutions to technology limitations. Even with greater numbers of higher-quality screens and more bandwidth, there are other significant conceptual issues that will not be resolved simply through technological advances. Privacy is one such issue.

Privacy problems appear in almost any interactive, networked medium like the internet or interactive television. But in the wireless medium this problem is even more acute, for several reasons:

  • It’s always on: The mobile phone is always with the user and always connected (to both voice and data networks).
  • It’s personal: The wireless medium enables each user to be uniquely identified by his handset, unlike the internet, for example, which on a home computer can be accessed by several users.
  • It’s location-aware: The wireless medium is the only one that commonly offers the possibility of knowing the physical location of each user. Most of the European carriers have already launched several location-based services.

About friendZone
friendZone is the world’s first location-based wireless community, and was developed by a company called AxisMobile (formerly known as Valis, of which I was a co-founder). friendZone was first launched in Switzerland in May 2001, with the local Swisscom wireless carrier. Four of friendZone’s key services are: location-based dating, enabling users to look for people in their vicinity who match specific profiles, location-based chat, and a friend-finder tool that enables users to physically locate groups of consenting friends. friendZone also serves as the application infrastructure for local wireless brands targeted at the youth market. As of April 2003, friendZone communities exist in Switzerland, Portugal, Germany, Israel, and China.

The location-based privacy puzzle
To better understand the concerns of friendZone’s target users, the design team asked teenagers who had used friendZone for more than a year what they thought about protection, privacy, and tracking services—specifically chat, dating, and the friend finder. The common response we received (accompanied by puzzled looks) was: “Why shouldn’t we feel protected? The only people who know our location are our friends—and we want them to know where we are.” I found this response surprising, since privacy concerns were frequently raised in background interviews conducted with focus groups prior to friendZone’s launch.

Intrigued by this apparent contradiction, I checked the quantitative usage statistics of three carriers in Switzerland, Israel, and Portugal. They indicated that there was almost no use of friendZone’s built-in privacy management tools. These tools offer two main functions: a “disable location” command, and control of a “black list,” which lets users allow (or deny) people the ability to see their location. Total usage of the privacy management features accounted for just 1–5 percent of the total usage of the system. Interestingly, the carrier with the most use of the privacy management tools was also the one in which the system was the least successful. Overall usage of the friendZone system, however, ranked as one of the top three data services offered by the carriers.

Considering the attitudes of the friendZone users and the usage statistics, we can draw one of two conclusions:

  1. Privacy is not an issue, or
  2. In matters concerning privacy, relevant technology and features are only part of the solution.

Conclusion A seems unlikely to be true (common sense tells us privacy must be an issue at some level), so B must be correct. But what is the rest of the solution?

My research and experience suggest that it is possible for users to feel secure even if they don’t actually use the conventional measures of protection (such as disclaimers and blacklists). There is some other element, apart from the traditional privacy measures, that allays the privacy concerns of the users. This invisible link is the psychological aspect of users’ reported sense of security. To best address and fill users’ need for a sense of security, I employed principles of psychology in the design of the friendZone system.

Understanding the target audience
In privacy-related issues, our mission as IAs is to make the user feel safe. We are dealing with the human mind and emotions, and it is therefore imperative that we understand what makes people feel safe, and what is important to them as users. This approach, which operates from a psychological rather than legal or technical perspective, is the essence of PDIA.

Note that recommendation and use of PDIA does not in any way contradict or reject use of legal measures, such as disclaimers, or technological tools. PDIA complements, rather than replaces, traditional legalistic and technological approaches to privacy and other end-user concerns.

In order to better understand how to implement the PDIA approach, we first need to understand who our users are. I will use friendZone as a case study.

TeenZ
The leading location-based services (LBSs) are community tools and entertainment. (See Appendix A for supporting research.) These two fields are generally associated with young users. The term “young user,” however, is a little misleading in this case. The phrase usually denotes an age group, whereas here it refers to a larger public defined instead by its mindset. People in this group are at a time in their life when their world revolves around friends rather than work or family. A 30-year-old single person could fit this description, while an 18-year-old workaholic would not. To retain this distinction, in this article I refer to this group as teenZ (a moniker we coined during the design of friendZone).

What are the characteristics of teenZ in general? Research shows that teenZ are:

  • Constantly changing and unstable.
  • In a process of self definition—transitioning from the world of family and parents to a new, self-defined world of friends and peers.
  • Often in conflict by trying to both be part of a group and establish themselves as individuals.
  • Enigmatic: The attitudes and behaviors of teenZ you meet today might be completely different tomorrow.

At an individual level, a look at the psychological profile of a member of the teenZ group reveals the following needs:

  • Belong to a group
  • Have contact with other members of his peer group
  • Possess status symbols for self-definition
  • Be adventurous–the need to “check out” the world
  • Be in control

(For methodology, see Appendix B.)

A design that can fulfill these needs for teenZ will help them feel more secure and will, in turn, be rewarded with their confidence and loyalty.

TeenZ and privacy
Next, it’s important to understand what teenZ’s concerns are regarding privacy: What are their fears? What do they need to protect? Over what do they need privacy control?

Privacy means different things to teenZ than to other groups. For teenZ, by and large, privacy equals individuality. As teenZ are in the process of defining and forming their own individuality, privacy from parents and parent figures is of the utmost importance. The most essential type of protection teenZ desire is protection from authority. That authority may be parents, teachers, or a boss at work. TeenZ don’t want their parents to know whom they are dating and where they go. In many ways, teenZ try to define themselves in direct opposition to whatever they perceive to be the definition of authority. For teenZ, parents and teachers are the true oppressors. Thus, it is crucial to communicate to teenZ that the “oppressors” will not use the system.

TeenZ also need privacy from their own peer group and security from peer pressure. This need is common among teenZ, but is often neglected. Consider this typical situation: A group of friends wants to do something—for example, go to a certain movie. One member of the group doesn’t want to go, but also doesn’t want to confront the group. What should this member of the group do? If the system can offer a solution or assist in solving such problems, it can instill confidence in teenZ that will make them much less worried about other privacy matters.

Another privacy issue related to peer groups is the need to preserve intimacy. For example, a teen may be dating a new girl, but hasn’t yet decided if it is cool to date her or not, and he doesn’t want his buddies to know about the relationship. At the same time, adding to the complexity of this situation, the teen doesn’t want his friends to know that he is keeping this secret.

Finally, teenZ have the need to protect their image—they must look cool all day long. Thus, they only want their location disclosed when they are at places that are considered “cool.” They’re comfortable letting their friends know they are at a club, but when they are visiting their grandmother, they don’t want anyone to know it.

friendZone implementation of psychology-driven IA
The wireless community itself addresses some of the needs of teenZ by helping users stay in contact with their friends and enabling them to sample, or “check out,” the world and meet new people. In addition, wireless communities are still regarded as a new and cool technology, filling at least partially teenZ’s desire for new technologies and status symbols. Responses to the other needs of teenZ, however, must be designed into the system.

In friendZone, we addressed the relevant psychological factors by incorporating them into the design of three different levels of the system: packaging, tools, and services. Each of these aspects of friendZone utilizes specific subcomponents:

  • Packaging: Language, feel, and alerts
  • Tools: Privacy management tools
  • Services: Traffic generating program and community management

Packaging: language, feel, and alerts
The packaging of friendZone mainly answers the need for protection from authority, the need to be part of a group, and the need for status symbols.

TeenZ-oriented language
Offering teenZ a unique language is beneficial in several ways. First, it helps teenZ feel protected from authority. Having a unique language strengthens teenZ’s sense that their parents will not understand the system. The logical conclusion is that if parents cannot understand the system, they will not use it, thus instilling in the user a sense of protection from authority. (Background interviews in Germany and China indicated that local teenZ prefer English terms because those are less likely to be understood by teenZ’s parents.)“TeenZ tend to have an emotional relationship with their handset. They love it, miss it, dream of it, etc.”

Use of a unique language also promotes a sense of community. TeenZ are likely to feel that if they share specific terms that no one else understands, it contributes to the exclusivity of their community. Finally, from a marketing point of view, creating brand-supporting terms can help raise brand awareness.

When developing a system language to be used by teenZ, I recommend using friendly, comforting terms rather than computer lingo. For example, in friendZone we avoided terms such as “available” or “disable”—we do not normally “disable” our friends, and teenZ might feel uncomfortable doing so. We changed “disable” to “freeze,” and “available” to “free.”

Similarly, it is important not to use authority-related terms—i.e., any words or phrases that might remind teenZ of authority figures in their lives. Try to avoid terms such as “error.” TeenZ already suffer frequent exposure to such terms, usually with a negative connotation, in school and at home. Instead, it may be better to offer a friendly note (“Oops, I think we’ve got a mistake.”) or suggest a solution (“We don’t know the ‘fond’ command, did you mean ‘find?’”).

It is also important to strike a balance between innovative teenZ lingo, and plain, friendly, adult language. Using “cool” terms and cryptic language in excess might end up alienating part of the teenZ audience—some might feel they are dealing with manipulative authority figures in disguise, or just find the system unclear or not user-friendly.

Feeling that the system is your friend
TeenZ tend to have an emotional relationship with their handset. They love it, miss it, dream of it, etc. By taking this into account when designing the friendZone system, we helped make the phone a friend. Remember, teenZ have much fewer privacy concerns toward their friends, so if they regard the system as a friend (to some extent), and not as an authority figure, they will feel more comfortable with it.

One way to provide this friendliness is to design a dialogue with the user to make her feel more comfortable. For example, teenZ don’t want to feel that they are alone or don’t have friends, so in friendZone, all system messages are phrased in a collective, first-person voice (“we” rather than “you”). This helps the user at least subconsciously feel that someone is always there with him or her. Another example of this approach in friendZone is what happens when a user’s name is deleted from a peer’s contact list: the system allies itself with the user. Instead of telling the deleted user, “You were deleted by Sharon,” its message reads: “Don’t bother with Sharon.” (These messages are, of course, adapted to the local culture.)

Segmented marketing campaigns
The marketing campaign for a product aimed at teenZ can also be a tool for protecting them from authority and establishing the product as a status symbol.

One of the cardinal rules of advertising is that the best way to reach teenZ is to distinguish them from both their parents and younger siblings. Key to achieving this distinction is not to market the product in the same way to both teenZ and other target audiences. Technically, a product like friendZone could be sold as part of a fleet management system (to track the location of employees or vehicles) or as a mobile nanny (to track the location of young children), but it would have to be marketed and branded completely separately from the teenZ network. Consumers, and especially teenZ, must never have an inkling that these systems are in any way related.

Tools: privacy management
Privacy management is a basic component of most of the community services offered on friendZone. There are several things worth keeping in mind when designing privacy management tools.

Protection from peer pressure
Protection from peer pressure is implemented in various parts of the friendZone system, but most clearly in the privacy management options. A good example is the command for disabling location awareness (known as “freeze” in friendZone). In friendZone, there is one uniform system notification to inform peers that a certain user’s location cannot be determined. This same notification appears whether the user disables his location, turns off his phone, or even if there is some technical malfunction. This allows users a veil of confidentiality as to why they cannot be reached, and enables them to obscure whether their unreachable status is of their own volition or due to some technical situation. There is also a command that enables the user to disable peers and have those people know that they have been disabled (“X” in the system lingo), which affords a clear distinction between hiding and just being unavailable.

Controlling privacy
An effective privacy management tool for teenZ must address the need for privacy-related information and offer a sense of control. The first can be achieved by providing information regarding the whereabouts of friends, while the second can be achieved by including features that allow users to manage the flow of that information in the system. friendZone test cases showed that 60–80 percent of privacy management usage is spent by users just looking at their black list, without making any further use of privacy management tools.

Statistics show that much of teenZ actual usage of these lists is like “window shopping” to see which peers they approved or disapproved and who asked permission to know their location.

This window-shopping behavior is important for several reasons. All are connected, again, to the need of being in control:

  • It is important for teenZ to know who their friends are. TeenZ want to know both who is on their list and whose lists they are on. TeenZ think that anyone who wants to know their location probably considers them a friend, would like to be one, or has otherwise expressed some level of interest in them.
  • TeenZ always hope that maybe the coolest girl or boy will want to know their location, because such interest could make them more popular among their peers. Thus, it is also important that teenZ have a way of presenting their lists to their friends.
  • Relevant lists can become a kind of popularity index. The person who has the largest number of people on his or her list is, by implication, considered to be the most popular.

Services: traffic-generating programs
Finally, an important and often overlooked aspect of helping users feel their privacy is being protected is the formal management of the system itself. In friendZone, this management was handled by a traffic-generating program (or TGP). While the primary goal of a TGP is to increase usage and adoption of the system, it can also enhance the feeling of being part of a group, which can reduce the various privacy-related fears of teenZ.

The friendZone TGP utilizes several approaches that are relevant to psychology-driven IA:

  • Team management: First and foremost, the TGP is managed by a team of teenZ who are part of the community itself and fit a specific, targeted psychological profile.
  • Feedback: The TGP managers arrange online surveys and conversations with community members, which are intended to give users the sense that if they experience a problem or are bothered by something, there is someone there to listen to them.
  • Hosting: There are always people using the system, so a user will never be alone in a chat room. An effort is also made to have every user be approached at least once a session or a day in the dating section. The concept of hosting is designed to protect the user from ever feeling alone or unpopular.
  • Monitoring: The system tracks and controls deviant behavior to protect users.
  • Newsletters: Users periodically receive a message (via WAP or email) that describes the community’s recent developments and culture. The newsletter strengthens the sense of community, the feeling that “we are part of a unique, cohesive group.” Its aim is also to ultimately strengthen users’ general sense of security.

Conclusion
To summarize this article in a few sentences: Location is important for the wireless community and medium—it enhances the benefits of the wireless medium and contributes to a sense of being in touch and not being alone. At the same time, location introduces significant privacy concerns: It reveals information about us that we may not be accustomed to sharing (such as our exact current location), thus it may be perceived as invasive.

The best way to solve these problems is through use of a psychological approach—by seeking to understand and allay the fears and needs of the users through the design of the system. This approach is psychology-driven information architecture.

This article focused on problems connected to the location-based services, but psychology-driven IA can be applied to any design problem in which privacy is a major concern, as well as other broader information architecture challenges.

Appendix A: Why location is important
Since this paper deals with privacy issues related mainly to location, the first question that should be answered is: Why are location-based services (LBSs) important at all? This question can be approached from two different angles, representing the carriers’ and the end users’ perspectives.

The carrier’s perspective: There is huge revenue potential in location-based services. Analysis Research Consultancy (ARC) predicts that LBS services will account for 40 percent of carrier revenue in 2007. Concise Insight predicts that the LBS market will be worth $7.6 billion by 2009. Analysts at both ARC and research consultancy BCWS predict that the most important location-based services, in terms of usage and revenues, will be in the fields of community and entertainment.

The end users’ perspective: Location information responds to some of the users’ basic needs:

  • Helps the user feel a sense of control
  • Enables the user to know more about his or her peer group
  • Enhances the possibility of being in contact with other people
  • Answers one of the biggest fears of modern times: the fear of being alone. LBS enable users to have information about people and places in their immediate vicinity.

Furthermore, LBS enhances the benefits of the mobile phone in general. The mobile phone affords users the possibility of contacting friends at any time. LBSs take this benefit to the next stage, enabling users to have additional levels of detail about members of their peer group.Appendix B: Psychological methodology
A few words about our psychological methodology: The psychological profiles and insights were developed by Doron Weinstock, the head of the AxisMobile research team. The profiles were first created based on a combination of textbook analysis of teenagers, research conducted by advertising firms (such as the Publicis’s “tween” project), and media companies (such as MTV). This data was combined with results from an ongoing focus group that included eight teenagers chosen to represent teenager archetypes (“the clubber,” “the clueless,” “the idealistic,” “the geek,” etc.). Although all of the teens lived in Israel, they grew up in various counties (Belgium, USA, Russia, Germany, etc.). Additionally, the input received from the ongoing focus group was compared to that gathered from local focus groups conducted prior to each regional launch of friendZone.

The results described in this paper are based on three years of ongoing and local focus group research conducted in Germany, Switzerland, Spain, Portugal, and Israel.

Oded Napchi has been a major force in the Israeli media industry for over ten years. After years of experience in traditional media as the manager of a major radio station, and of the Israeli Children Channel (Israel’s most popular cable network), he played a pivotal role in broadening the horizons of traditional media companies and introducing “new media” concepts and practices. After founding Valis (later re-branded Axis), the world leader in mobile communities, and the first to introduce location-based communities, he is now working as a freelance consultant to television and new-media ventures.

Mobile: The State of the Art

by:   |  Posted on
“…it will certainly become more and more commonplace to see people transacting with their phones at arm’s length instead of speaking into them.”A few months ago, I was on my way home from the San Francisco Airport in one of those door-to-door shuttle vans. At some point I casually noticed the woman beside me thumbing the keys of her mobile phone. Dialing a number, I assumed—a common enough sight. But then she kept dialing and dialing and dialing.

I had just spent the previous three months in Germany working on a mobile messaging application. While there, I had seen many a teenager and young professional similarly engaged with a “handy” and I had become savvy enough about these things to know that the Germans were sending text messages to each other, whereas my neighbor on the shuttle van was surely just having some kind of problem with her phone. Short Message Service (SMS) is so popular in Europe, they’ve turned the acronym into a verb, but on this side of the Atlantic, our “cell phones” are for talking.

To make a long story short, my professional curiosity got the better of me. I asked, and it turned out she was indeed composing a text message to send to her friend. SMS had apparently hit the States while I was away.

In Europe, non-voice (mostly messaging-related) services account for around 10% of mobile operator revenue. The figure is much higher in Japan, where many mobile phones are full-fledged multimedia devices, featuring color displays, integrated digital cameras, and stereophonic ringtones. The U.S. market is a different story, but things are changing.

The popularity of SMS is not likely to explode here like it did in Europe and Asia. But as more powerful devices and better services become available, it will certainly become more and more commonplace to see people transacting with their phones at arm’s length instead of speaking into them. Mobile devices already represent a significant channel—and they will no doubt become the primary channel—for a number of common human-computer interactions. These interactions often take place during brief pauses in transit, in distracting environments, on devices that are difficult to use, and where mistakes can be expensive. Obviously, a highly usable interface is key, and there is a growing demand for IAs who specialize in mobile.

But try to find a good book on the subject.

The world of mobile phones is a jungle of proprietary technologies with few established standards that, in some ways, resembles the early days of personal computing. I intend in this article to paint a kind of impressionistic landscape of this world; to present a survey of the markets, technologies, devices, and key applications, along with some examples of successes and failures, a glimpse of the near future, and some thoughts on what all of this might mean for IAs.

Key markets

Japan
Nowhere has the mobile phone industry burgeoned like it has in Japan. With mobile phones, as with other things electronic, the Japanese have lived up to their reputation for embracing new gadgets as quickly as manufacturers can conceive of them. It remains to be seen whether Japan is a year ahead of the rest of the world or simply a unique market. For the moment, it is safe to assume both are true. The proven success of Japan’s most popular mobile services seems to promise their broader appeal, but the multitude of niche offerings is largely ignored by the rest of the world.

It is worth noting that in their latest generation, Japanese phones are actually a little bit bigger than their predecessors, marking the first reversal of what has been a steady trend toward smallness. The demand for processing power seems to have subjugated the demand for shirt-pocket-sized convenience. Japanese mobile phones double as portable game consoles, music players, and cameras, among other things. They employ an always-on network connection, with data speeds roughly equivalent to dialup modems, so users can download small pictures, sound files, applets, and games cheaply, quickly, and easily.

Europe

The Generations of Wireless

1(st) G(eneration): The analog radio cellular phones that first appeared in the 1970s

2G: Digital voice encoding introduced

2.5G: Increased bandwidth; packet routing

3G: Broadband data speeds; global roaming; enhanced multimedia

Europe has the highest average mobile phone penetration rate in the world, and it’s not uncommon for Europeans to own more than one mobile. European mobiles use removable SIM cards – the small chips inside the phones that store the subscribers’ personal information (phone number, contacts, saved text messages, etc.) and identify the subscribers on the network. The European SIM card is universal, meaning it’s easy to remove a SIM from one phone and insert it into another. Therefore, it’s easy for Europeans to upgrade to a new phone or own a whole drawer full of them.

With non-voice services, Europe is following Japan’s example. Operators are scrambling to introduce new color devices and accompanying services to run on their relatively new 2.5G infrastructures. “i-Mode,” the packet-based service for mobile phones offered by Japan’s leader in wireless technology, NTT DoCoMo, has had recent launches in Germany, the Netherlands, and Spain, and European operators are touting Multimedia Messaging Service (MMS) as the next big thing.

The United States
The United States has lagged behind, but the latest service offerings from the biggest American providers suggest the gap is closing—the technology gap, that is. Adoption rates in the U.S. are a different story. The mobile phone penetration rate here is about 45% (compared to about 75% in Europe and 65% in Japan). American consumers have not embraced mobile like their Japanese or European counterparts for a variety of reasons.

U.S. providers, however, are boldly charging forward. AT&T will reportedly offer i-Mode to its customers this year (NTT DoCoMo holds a 15% stake in AT&T wireless), and Sprint recently launched their “PCS Vision” service, which includes color browsing, downloadable stereophonic ringtones, and MMS.

Mobile technologies

This is where things get messy. There is little in the way of consistency at any level. Developers are faced with a huge number of unique client devices running any of the huge number of proprietary operating systems and integrated browsers, supporting any of a handful of development technologies and markup languages, and communicating with the network via any of several digital data transmission standards.

From the bottom up then…

Transmission standards
The selection of transmission technologies has been somewhat regional. The actual mess of acronyms doesn’t warrant a detailed discussion here, but suffice it to say that when it was time to migrate from analog to digital, Europe took a consensus approach. They chose a standard called Global System for Mobile Communication (GSM) to cover the continent. Japan too, allowing politics to intervene, chose a national standard.

In typical fashion, however, the United States decided to let the market drive the decision, resulting here in the deployment of a mishmash of semi-compatible standards. For voice calling, this is not an issue, but transmission of other data across the various standards has been hindered by a number of roadblocks.

Application development technologies and markup languages
With the exception of DoCoMo’s i-Mode, which uses a language called CHTML (Compact HTML—essentially just what it sounds like), WML is the markup language of choice for the wireless web. WML is simply an XML Document Type specific to mobile devices. HDML, the predecessor of WML, is still mentioned occasionally, but for all intents and purposes it is obsolete. The version history of WML can be a little confusing, especially since WML (the language) and WAP (the protocol) are often used interchangeably in the context of version support (e.g., “device A supports WAP/WML version x.x”).

Significantly, XHTML, XSLT, and even Flash have been gaining support (although Flash more slowly), and many new devices will render a familiar range of image formats. This means that from a technical standpoint, developing for mobile phones will become more and more like any other web development, so the burden will be on IAs to design channel-appropriate interfaces.

One other mobile development technology bears mentioning: Java. Sun created a slimmed-down version of its language and called it J2ME. It is designed to accommodate the limited computing power of mobile devices and allow them to run small, self-contained applications. Computing power isn’t always the only limitation to be accommodated, however. Bandwidth, as well, is an issue for applications that are to be delivered for over-the-air downloading.

Operating systems and browsers
The mobile world is in the midst of its own browser wars, and most often a device’s built-in browser is tightly integrated with its operating system. The biggest players are Nokia/Symbian, Ericsson and Openwave, although Microsoft has recently begun to move into the wireless space.

Nokia, the leading handset manufacturer, has recently begun to peddle a productized version of its software to other device manufacturers. Alternatively, Openwave, whose main business is software, has seen their Phone.com browser installed in a wide range of handsets. That, however, has far from guaranteed any kind of consistency. Openwave’s software has been deeply customized for certain manufacturers, and there are even different customizations of the software for different handsets by the same manufacturer.

This means the same markup is rendered differently on different devices. It also means the interaction between the hardware, the software, and the remote application—the physical mapping of the phone’s keys to the application’s functions—cannot easily be predicted or specified.

Devices
The range of devices on the market continues to expand, with new devices being introduced much more rapidly than old devices are being retired. The best way to make some sense of it all is to take a zoological approach, to impose a classification system on the multitude of species.

There are two useful facets of such a system: degree of mobility and amount of computing power. Focusing on mobile phones, I divide these into two classes. The more common, and therefore more familiar, of these is the set of monochrome data-capable phones. The other class is the set of more powerful phones with large, full-color displays. My chosen differentiators in this case are rendering capability and navigation method (as expressions of computing power).

This classification system obviously has its limitations. Some monochrome phones, for example, support Java, and some don’t. Some color-capable phones don’t support four-way scrolling. And there are always anomalous devices that defy easy classification altogether, like the Handspring Treo 180—a powerful “Smartphone” that happens to have a large monochrome screen.

Key applications

At the moment, a common perception is that mobile computing is little more than a poor imitation of desktop computing. Critics wonder why anyone who has access to a computer would bother to agonize their way though an m-commerce (ecommerce on a mobile device) transaction. The simple answer is: they wouldn’t.

The mobile applications most likely to succeed will be those that take advantage of their mobile-ness. I have mentioned i-Mode as an example of an application that has succeeded, but it’s useful to focus on the broader categories that this example and others represent.

Messaging
By far, the most successful non-voice application in the mobile world is SMS. Remarkably, it was originally conceived not as a consumer product but as a way for mobile service providers to send data—anything from promotional messages to technology upgrades and patches—to their subscribers. These subscribers quickly embraced it as an inexpensive way to send short messages (originally 160 bytes maximum, at about 15 to 25 cents each) from mobile to mobile. According to the GSM Foundation, Europeans send as many as a billion text messages every day (compared to 12 million in the United States).

More recently, various enhanced messaging services are gaining popularity, including different mobile implementations of popular Instant Messaging services like Yahoo! Messenger and AOL Instant Messenger, and Multimedia Messaging services.

Browsing
Outside Japan, browsing content via the wireless Web has arguably flopped. “WAP is crap” goes the saying. However, the introduction of new color devices and the rollout of higher-speed networks have brought renewed hope for the future of mobile browsing in general. Most people believe that the browsing applications most likely to succeed are those that provide targeted, on-demand information (e.g., sports scores, stock quotes, and weather reports) quickly and easily, and obvious and immediate utility (e.g., travel and event booking, auction bidding, and gambling).

Games
Research has shown that people who use their phones for non-voice applications often do so as a way of killing time while commuting, for example, or waiting in line. Games provide an ideal distraction. Some amazingly simple games have been a hit with mobile phone users, demonstrating that people who expect their PCs to immerse them in minutely-rendered 3D worlds are nonetheless willing to spend 15 minutes a day playing “Snake” while they ride the bus.

Games can be delivered in several ways. They can ship with the phone as built-in applications; they can reside on the network to be played during active sessions; or they can be delivered as complete applications via one-time over-the-air downloads.

Personal information management (PIM)
Most phones on the market today include a suite of built-in PIM applications such as an address book and calendar. Some phones also include email and synchronization support for Outlook or other PC clients, and WAP (Wireless Application Protocol) portals like Yahoo! and MSN provide mobile support for their popular Webmail clients, as well as POP support. Mobile PIM applications show special promise for enterprises looking to support a mobile workforce, and PIM applications are primary candidates for full, frequent multichannel use.

Location awareness
Location awareness is an application enhancement, not an application category. The architecture of the mobile telecom environment makes subscribers locatable geographically, though not with GPS-like precision. Operators are adding location features to messaging services and games, as well as to more utilitarian applications like restaurant and club finders. Obviously, privacy protection is a key concern for services that incorporate locatability.

The Role of the IA

All the basic tenets of our profession certainly apply to the discipline of mobile user interface design, but these underlie a number of unique considerations.

Mobile usage patterns are distinctly different from what we associate with the desktop PC. Mobile sessions often occur in public places, during brief pauses. Unless the user is idly browsing or playing a game to pass the time, she is probably seeking a piece of very specific information or trying to accomplish a single very specific task. Time is often—literally—money, so there is effectively no margin of error. If the user navigates down the wrong path or downloads the wrong file, she pays for the mistake.

IAs obviously need to understand the contexts within which a given application will be used, to understand the physical environments, the motives and circumstances, and the target devices. There are many questions that apply especially to mobiles: Will the user be moving or standing still? Will he be operating the device with one hand or two? What are the most likely distractions or obstacles? What if the connection is dropped?

It is important to remember that in many cases, users’ attention will be divided. They will interact with an application while walking down a flight of stairs or while half listening for their flight number to be called.

Because of the variety of device capabilities currently in use, IAs must frequently decide whether to exploit the advantages of a given device or to design something more generic to accommodate a broader range of devices. Screen sizes on mobile phones range from the tiny to the miniscule, so IAs must abandon notions of point-and-click in favor of click-and-flow.

Since users are presented with so little information at any given point, it becomes especially important for them to know where they are within the system (and where they were, and where they can go). Wireless data speeds are usually equivalent to a dialup connection or slower, and devices have very little storage capacity or processing power. Finally, users don’t have the luxury of familiar input devices like a mouse or alphabetical keyboard, and many users are only roughly familiar with the behavioral quirks of their chosen clients.

Most mobile phones currently in use support only one-color graphics. This severely limits visual branding opportunities, and while it may be possible to an extent to brand interaction design, it is more important to stick to familiar user interface conventions and metaphors as much as possible. Users are likely to encounter more than enough uncertainty without our help. We don’t need to create more uncertainty in the pursuit of distinctiveness or innovation.

We declare all the time that less is more. With mobile phones, one would think perhaps we don’t have a choice. Even so, the maxim applies. The simplest interfaces are the most successful. Wizards, for example, generally work better than forms because of their one-step-at-a-time simplicity. A login process requiring a username and password, then, should be a three-step, three-screen process (1. username 2. password 3. submit). On the other hand, perhaps such extreme simplification would be maddening to power users. There’s only one way to find out…

Test. Conducting usability tests on mobile applications is difficult. There are few software or hardware tools designed for testing mobile phones, and there are few documented guidelines or best practices. But that’s also part of what makes it exciting. As with all frontiers, we are required to imagine, to innovate. I worked quite a bit with a firm that used an awkward-looking setup involving a miniature spy camera and duct tape, but it gave us exactly what we needed.

Any of the points above could of course warrant at least an article all its own. I look forward to the opportunity to discuss in much greater detail some of the particulars of mobile user interface design.Acronym Soup

ARPU Average Revenue Per User
CDMA Code Division Multiple Access (a digital voice encoding format)
CDMA-2000 The broadband CDMA standard developed by Quaalcom and Lucent for 3G
CHTML Compact HTML
GPRS General Packet Radio Service (a packet-switching protocol designed to improve data speeds on GSM networks)
GSM Global System for Mobile (the most common worldwide mobile communications standard)
HDML Handheld Device Markup Language
J2ME Java 2, Micro Edition
LBS Location Based Services
MMS Multimedia Messaging Service (mobile-to-mobile transmission of images, video, sound)
OTA Over-the-air
PCS Personal Communications Services
SIM Subscriber Identity Module (a sometimes removable microchip that stores a subscriber’s personal data and the information necessary to identify the subscriber on the mobile network)
SMS Short Message Service
T9 Text input on nine keys (a text-input helper application that employs a database of commonly-used words)
UMTS Universal Mobile Telecommunications System (a 3G transmission standard)
WAP Wireless Application Protocol
W-CDMA Wideband CDMA (a 3G standard)
WML Wireless Markup Language


Standards organizations

Developer sites

Other resources

Shawn Smith has worked as an IA and user experience designer since 1996. Currently he develops applications and UI standards for Vodafone, the world’s largest mobile operating company.