Mobile Instant Messaging

October 22, 2009 / BY / IN Articles

(The following article was drafted for a chapter in a book Scott Weiss proposed, Case Studies in Mobile Design, uniquely considering product design from the multiple perspectives of business, technology, and the user. The publisher never granted final approval for the book project, so the chapter is presented here in unabridged form.)

 

Summary

Missing out on SMS in Europe, Americans didn’t have a compelling reason to use T9® Text Input to type on their mobile phone. But Instant Messaging, a quiet phenomenon growing as rapidly as the Internet, was being used by teens and professionals alike; could it become a “killer app” for mobile as well? Numerous technical and design challenges would have to be addressed to realize an acceptable user experience for Instant Messaging on mobile phones.

 

Background and Business Context

Instant Messaging

Instant messaging is a type of Internet-based communications service that manages an exchange with another individual in order to communicate in real-time, analogous to a telephone conversation but using text-based rather than voice-based communication. [1] Participants typically create a screen name or alias which allows some anonymity. The instant messaging system supports the creation of a personal list of contacts, [2] similar to an address book, and indicates whenever somebody on that list is available to exchange messages. Unlike email and Short Message Service (SMS) text messaging, the conversation usually occurs only when both participants are logged into the system and available.

Most IM systems also host public or private “chat rooms” which allow a number of people to participate in one conversation, and provide privacy and security controls to avoid the kind of spam that has decreased the benefits of e-mail. The availability, or “presence” information, is distributed from central servers to all interested users, but in some IM systems the content may be transferred directly between clients.

 

AOL’s Buddy List, AIM, & ICQ

Buddy List feature on desktop AIM AOL first added the Buddy List® feature to its proprietary dial-up client and allowed instant messages to be exchanged between AOL members who were online. Later, the AOL Instant Messenger® (AIM) desktop client offered the features in a free downloadable application, extending the AOL community to other Internet users. The AIM desktop client continued to reflect the competitive market by adding new features in regular releases, while AOL’s full service client added features more conservatively to maintain its easy-to-use character. [3] AOL also acquired the company responsible for ICQ and spent a few years adapting ICQ’s unique features to run on AOL’s large IM infrastructure. [4]

Other IM service providers have the same basic features, but slightly different benefits and restrictions. Other companies have created “multi-headed” clients (e.g., Trillian) to permit the user to exchange messages with users in different online communities from a single desktop application.

 

Commercial Opportunity

By 1999, the management at Tegic Communications was generally pleased with how things were going for T9 Text Input. Most of the leading handset manufacturers had at least licensed it, SMS use in Europe and elsewhere was growing exponentially, and the new Chinese version of T9 gave Tegic a strong entry into that huge potential market.

But the US mobile industry was still a mess, transitioning its subscribers from analog to digital and dealing with many incompatibilities. Only a few wireless carriers [5] supported SMS, and initially only within their networks. They competed on signal strength and voice plans, not data. Without text messaging, T9 was not even a “nice-to-have” feature. [6]

In the meanwhile AOL, Microsoft, and others were riding the wave of user growth as more Americans connected their home PCs to the Internet. AOL and ICQ members were already exchanging millions of instant messages; Yahoo! launched their own IM service; and Microsoft released MSN Messenger for Hotmail users. [7]

Here was the opportunity to accelerate mobile messaging and solidify T9’s value – connecting desktop IM to mobile SMS. In the US, where the carriers couldn’t interoperate, wireless IM could exploit the Internet to bridge network systems and connect desktop and mobile users. Since PC users in the US were already active users of instant messaging, wireless IM would let current desktop users “go mobile”. In Europe, where SMS already enjoyed wide popularity, wireless IM could offer the additional advantage of “awareness” or “presence”. [8]

Soon after Tegic’s launch announcement, Mobile Insights projected that wireless IM would be used by over 200 million people worldwide by 2002.

The carriers were Tegic’s primary customers for wireless IM, with the IM service providers as strategic partners. Tegic offered to provide a proxy server between the IM service provider and the carrier’s wireless data systems. [9] But instead of settling for a strategic partnership, AOL acquired Tegic at the end of 1999 to help AOL enter the wireless market. As a result, the scope of the product plans narrowed to support and market AOL’s own instant messaging services (AIM and ICQ) rather than the service-independent proxy servers and clients that Tegic’s management had envisioned. [10]

 

Product Plan

The history of innovation is littered with the discarded pages of business plans which failed to account for the current (and continuously evolving) state of technology. The wireless industry was changing very rapidly, and in the US especially with a number of company mergers and technology transitions. System vendors were racing to establish their own technology as the standard for mobile applications, even if it wasn’t always ready for prime-time.

Within that context, Tegic leaders had chosen a phased approach for wireless IM, minimizing time-to-market while maximizing use of existing and expected handset and network capabilities:

1.   Provide basic user awareness and message distribution, using the SMS infrastructure and an on-board SIM Toolkit applet [11]

2.   Improve how users send and receive messages and view the status of other users, using WAP [12]

3.   Deliver full IM capabilities, using built-in clients developed through partnerships with OEMs and portable downloadable (e.g., Java) clients

4.   Reduce message delivery delays to make them more “instant”, using new technologies as they were deployed

5.   Extend wireless instant messaging to support related applications. [13]

Following this product plan, [14] Tegic’s business development team and wireless technology experts proposed basic service requirements and a minimum set of features based on what they thought was possible and acceptable to the carriers. The minimum feature set fell into two main categories, configuration [15] and operation. [16]

The business team also addressed carriers’ concerns about security and spam. It was no small thing for a carrier to open up its network to third-party servers and to millions of users who were not their customers. [17]

 

Product Design

Methodology

Product management accepted the basic IM service requirements and feature set, but it was likely that the mobile usage environment and technical constraints would change the importance of some desktop features. [18] So I started over, using the Conceptual Design methodology [19] to ensure that user needs were being served and not just propagating accumulated desktop IM features to a new platform. [20]

Though lacking the formal training of an ethnographer, I began by exploring and using instant messaging myself, asking questions of other regular users, and observing my teen daughters juggling 3-5 IM conversations at a time. [21]

The results of the Conceptual Design process included the following artifacts and considerations that guided future design efforts:

•    User profiles (further developed into a set of personas [22] in the Target Audience, following)

•    Usage environment (including social/geographical relationships between users)

•    User requirements [23] (including relative priority of IMs, dealing with unknown users, and disclosing availability)

•    Task model (workflows of key activities)

•    Usability objectives (later developing into Usability Goals, below)

•    Constraints (the myriad technical limitations including message delivery delays and storage, device capabilities, and cross-platform inconsistencies)

•    and a basic UI model.

early concept of tabbed conversations For Mobile IM these considerations suggested that the UI model should employ a list-plus-details paradigm [24] to manage the contacts and conversations, a split-screen conversation display to allow concurrent reading and writing, and contextual menus to improve efficiency. The Buddy List feature needed to be ordered by activity (rather than divided into buddy groups as on the desktop) so that the most recent conversations and/or contacts were visible at the top of the list. Some UI elements like tabbed conversations would be optional, and support for chat rooms could be deferred until later.

In addition, I theorized that some existing features would be needed for new reasons, [25] but given the dynamics of the mobile environment there was no way to know for sure until people started using them.

 

Target Audience

an ICQ user named Ben The personas representing typical users included a young mother, a teen girl, a mobile professional salesman, and a college guy. [26] These personas, however, were never integrated into the product development process. [27]

Usage scenarios experienced by these personas included both their initial service discovery or setup situation and a daily-use scenario. Completing this exercise helped identify the challenges facing users who needed to gather enough information to use a wireless service for the first time.

Interesting dichotomies also surfaced: the primary use was personal (for informal messaging) rather than business (where email and BlackBerry continued to reign); the users were presumed to be AOL members, but more of them were not (AIM and ICQ users formed a larger audience); and teens formed a large target demographic for Mobile IM, yet they were under-represented in AOL’s usability research (due to parental consent complications).

 

Usability Goals

I defined a few objectives (represented by the terms “Functional”, “Intuitive”, and “Fun” [28]) to ensure that key aspects of the desktop experience transferred to the mobile environment. Eventually, these objectives became the “Five factors that make an acceptable Mobile IM user experience”:

Consistent – internally and/or externally

Easy – e.g., minimizing steps for the most frequent tasks

Interactive – calling for dynamic displays

Conversational – focused on the message exchange

Controllable – including privacy, security, and user preferences.

Usability goals need objective measures and thresholds to make them actionable. They also need the support of executives outside of the design team to enforce the consequences of an occasional failing grade. We did not always obtain that support, but as noted below, our attempts to establish a minimum acceptable user experience for Mobile IM were moderately successful.

 

Improvement Cycle

Even in the typical hi-tech organization where “time-to-market is everything”, iterative design is possible; it doesn’t always happen contiguously, however. As there was rarely time for user input and design evaluation before development commenced, we tried to apply what we learned as we completed one platform and moved on to the next.

The Mobile IM design improvement cycle might have been described as the following:

Design – Determine the constraints of the particular platform and the best way to offer the minimum feature set; create exploratory prototypes when possible; and complete a UI spec, illustrating desired outcomes and identifying key behaviors (from the user’s perspective).

Build – Help design workarounds to unexpected constraints, and update the UI spec as needed; define key service metrics and advocate instrumenting the client and/or server to track them; and work with the Technical Communications team to document issues that users are likely to face.

Observe – Determine the actionable usability problems and concerns to be tested by users; run small, quick studies; [29] inspect the available service metrics; lobby for usage questions in later marketing surveys; and contrive new usability study techniques along the way. [30]

Repeat – Advocate for more than just bug fixes in the next release; merge lessons learned into the design for the next platform; and/or delegate – handing off responsibility for each platform to another designer introduced a new perspective, allowing old assumptions to be questioned, more usability issues to be identified, and the overall design to be improved. [31]

Every platform eventually benefited from design improvements in at least one subsequent major release.

 

Design Challenges and Compromises

Since we were often developing on the “bleeding edge of technology”, some important element of the client platform or the wireless infrastructure inevitably failed to match its promised capability until some time after the new product was launched.

A measurable amount of the design effort became re-design effort; that is, looking for workarounds and trying to keep the overall user experience acceptable. Significant constraints and design challenges included:

system state diagram

Capability – Protocols for “push” notifications [32] were implemented on handsets inconsistently; the typical mobile operating system (OS) was not hospitable to background applets; [33] lists and other basic UI elements often provided only rudimentary attributes; claiming space on the status line was a constant battle; and, of course, the softkeys [34] never followed any standard.

Reliability – SMS delivery was not usually guaranteed because the system overhead for delivery confirmation was prohibitive. We proposed an “Uncertain” user status to represent the vagaries of wireless service, but it needed live data from the wireless infrastructure – also prohibitive. [35]

Consistency – A constant challenge, especially regarding appearance and terminology. [36] We maintained a bias for consistency within rather than between devices. It remained unclear which Mobile IM elements were important to keep consistent with the desktop version, and whether that consistency mattered at all to the emerging mobile-only user.

Infrastructure inertia – The existing deployments of the instant messaging and wireless data infrastructures made it possible to roll out Mobile IM quickly and broadly. But a number of desirable features, e.g., the “Uncertain” status or simplified Privacy settings, were not practical if even the smallest change to these large complicated systems was required.

Costs – Though sometimes not considered by designers, in this case the billing model had a significant impact on the perceived value and the optimal use of each platform. The wireless carriers’ billing systems were often unable to support different charges for system overhead vs. IM content. The carriers’ data plans and conditions of use were poorly understood by most of their subscribers.

In light of the phased approach and subsequent to the Conceptual Design process, we identified three or four different versions of the Mobile IM client that might be implemented. [37] The variations were due to differences in the ability of the mobile device platforms to support the same characteristics of IM that made the desktop experience effective and enjoyable.

 

Training and Help

Another challenge with advanced mobile applications was that most devices were not able to support much in the way of instruction. Severe limits on both storage and display space made the typical help offerings ineffective. The 100-plus-page printed owner’s manuals were already packed with details, and reportedly were rarely read by users anyway. The economics of a new unproven service like Mobile IM discouraged the distribution of in-the-box informational flyers.

AOL’s MyMobile Web site became the fallback informational source for all of the mobile services. There another tradeoff soon emerged: whether to maintain very general descriptions and FAQs which didn’t directly apply to any handset on the market, or to create and revise phone-specific guides for a quickly-expanding collection of handset models from multiple manufacturers on multiple wireless networks. [38]

The availability of information about a product can impact its success – whether via ads that set expectations or quick-start guides that help users over initial hurdles. “Technical and end-user communications should not be left until the last minute” was an often-repeated (but too-often-ignored) refrain by AOL Mobile’s technical and marketing communications team. They wanted the opportunity to review each proposed product, ideally by the time development began, to ensure that it could be explained to the customer through an effective (and cost-effective) channel.

 

Projects and Platforms

The carriers’ push to monetize their new wireless data capability drove the Mobile IM product plan, which followed the phased approach surprisingly closely. Each carrier seemed to focus on a different platform for first deployment. The design team tried to apply the design improvement cycle as we progressed from project to project.

AOL Mobile eventually attempted or delivered at least one version of the Mobile IM service for each of the platforms below. How well did they come out? In describing and evaluating the resulting clients and/or services, I have considered them in terms of one or more of the following:

Context and/or Considerations – The unique situation created by the technology or carrier relationship that the product design had to account for.

UI – Elements of the user interface that were particularly challenging or otherwise notable.

Usability – Key studies for the platform which confirmed the design or offered guidance for future revisions.

Successes and/or Surprises – What worked, what didn’t, what was unexpected.

 

SMS

Millions of GSM [39] handsets across the US and Europe were already able to exchange text messages, a compelling installed base to target first. Tegic’s proof-of-concept IM system [40] had already extended the Internet to SMS. So AOL Mobile engineered a scalable version for commercial deployment.

AIM for SMS screen shots

The product team assumed that the entire minimum feature set for this “Functional” product was needed by the savvy SMS user. [41] Each contact’s screen name became a Phonebook entry with a unique short code [42] so that a message could be addressed like any other SMS, and arriving messages were thus tagged with the sender’s name. [43] Additionally, each IM feature or command received a Phonebook entry (e.g., “AIM-SignOn”) to which the user would send the command’s parameters in a text message, such as his screenname and password. Messages from another user could be simply forwarded to the Phonebook entry of the command (e.g., “AIM-Decline”) that you wanted to invoke on the other user’s screen name. [44] Unfortunately, we soon discovered that none of the other carriers could fully support remote programming of the Phonebook; the process either didn’t work on all phones or was too onerous. [45]

Even after configuration was taken care of, the number of operational steps needed to carry on an IM conversation via the text message Inbox made it tiring rather than “Fun”. For example, a single message receive-and-reply might require these steps:

•    Menu key / Messages / Inbox / select and read message

•    Options / Reply / type response message

•    Options / Send / confirm number

•    Options / Delete / confirm delete (to prevent the limited Inbox from filling up). [46]

We ran a couple of usability studies to ensure that the configuration and usage instructions on the carrier Web site were effective. We gathered user feedback on each major release via online surveys, usually during Beta programs or carrier “soft launches”. [47] Some carriers also provided summaries of customer service calls that were related to instant messaging, though sometimes it was a concerned call from an executive who had an unexpected or unwelcome experience. [48]

In later deployments, we reduced the number of commands that the user had to learn. For example, when a project extended IM for SMS to deliver picture messages, [49] system messages explained how to access and reply to the picture messages, rather than depending on new commands in the Phonebook. Hindsight also suggested letting the user explicitly add a few of his closest buddies to the mobile contact list. [50]

Eventually the entire feature set was concealed when IM for SMS became two simple services:

IM Forwarding – Automatically rerouted messages from the desktop to the phone when the user stepped away from the PC

IM2SMS – Allowed sending messages from the desktop to any mobile phone number.

These services focused on convenience for the desktop user rather than full IM capability for the mobile user. [51]

 

SIM Toolkit, Java

SIM card SIM Toolkit is a package that allows helper applets to be programmed into the SIM [52] of a GSM phone. Most of the millions of GSM phones that could exchange text messages could also host a helper applet. The hope was that the multiple steps of view, reply, and delete could be reduced by a custom applet that the carrier would load onto all new customer SIMs.

But in spite of our best efforts to build a prototype, a Mobile IM applet was not feasible within the constraints imposed by SIM Toolkit. The handset manufacturers offered only minimal support for the runtime environment; for example, T9 Text Input was not enabled in text input fields, effectively defeating the “instant” nature of the service.

The initial versions of Java on mobile phones also imposed too many limitations for an effective user experience or to reach its promise of portability. Though great for self-contained games, its “sandbox” model was almost incompatible with server-based instant messaging:  the applet was too slow to start up, and shut down when the user tried to use the phone for anything else; network connections automatically timed out and could only be initiated from the client side, so the user might not realize that a new IM was waiting on the server; and some handsets guarded against viruses by having the user reconfirm every SMS Send requested by the applet. As a result, only one Java-based IM client was available prior to 2004.

 

Wireless Web

The Wireless Web was going to be the Next Big Thing. While our built-in IM client had to wait for manufacturers to integrate it into their handsets and ship them, WAP [53] offered a server-only solution that promised to be as easy to deploy as any other Web site. [54]

But in spite of the industry hype about WAP, it was immediately obvious to us that WAP was not ready for prime time. There was too much variation in implementations of the browser, especially how “push” notifications were handled. [55] And, like SIM Toolkit and early Java, there was not enough control over the entire user experience.

SprintPCS, for one, tried to realize WAP’s potential for its users, imposing some UI consistency across devices and creating an application style guide and approval process. [56] We iterated the Mobile IM design until the main functionality worked sufficiently on the first half-dozen handsets.

AIM for WAP wire frames

A quick usability study evaluated whether users could complete the basic IM tasks. The study participants identified some issues with terminology, iconography, and navigation. [57] Fortunately, we were able to address the most significant problems and re-test with users before the first public release. The single, sectioned CONVERSATIONS / ONLINE / OFFLINE list made its debut. [58] This improved design greatly simplified navigation with WAP and made it much clearer where to find new messages and which contacts were online, offline, or not listed at all.

But the system was barely revised after initial release. A year or so later, product management raised the question of whether the user interface – the one element over which we had some control – was a significant factor in customers deciding to stop using the service after a while. [59] An online survey of current and recent AIM for WAP users provided the answer: Yes, along with text input speed, network reliability, and cost/billing issues.

According to the survey, users of AIM for WAP considered the service a fun way to quickly exchange text messages with anyone from anywhere. But many logged in just long enough to see who was online and to exchange a few IMs, apparently under the mistaken impression that their airtime minutes were being used as long as they were logged in. Problems with text input was no surprise; T9 was poorly integrated with WAP browsers on many handsets. The survey indicated that we should try to reduce the frequency and intrusiveness of IM notifications, simplify sending/receiving messages and navigation between conversations, and offer user-customizable quick replies.

We were given the go-ahead for a redesign to improve what we could. The redesign capitalized on the new features and visual appeal of the WAP 2.0 specification, which was now based on XHTML and supported by a new generation of color-screen phones. A follow-on user study confirmed the redesign’s improvements to the overall user experience.

 

i-mode

i-mode mock-up In the meanwhile, the Japanese wireless carrier DoCoMo had built its own version of the Wireless Web called i-mode. It defined strict browser behavior and UI standards. DoCoMo and AOL launched a joint venture to supply i-mode users with AOL email, IM, and other content.

But the only “push” notification available in i-mode was the “short mail” service. Employing it would have provided an ungainly user experience:

•    Receiving a text message in the Inbox containing a long cryptic link to the IM conversation and a preview of the IM

•    Following the link to the IM conversation, displayed by the i-mode browser, to be able to view and reply to the message

•    Remembering to return to the Inbox to delete the notification.

Though I designed a complete IM solution within i-mode guidelines, DoCoMo AOL wisely chose not to develop and deploy it.

 

Built-in Client

PDAs were the first mobile devices to benefit from an open platform OS and publicly-available development tools. A team in the AOL Devices group designed and built AIM clients for Palm and PocketPC which mirrored the desktop client’s look and feel. Those PDAs had poor connectivity, however, relying on dial-up modems over wireless; that defeated the desired IM-anywhere-anytime experience.

In a cooperative venture with RIM, the AOL Devices team also implemented custom e-mail and IM clients on a custom BlackBerry called the AOL Mobile Communicator. Though the software was appropriately designed for the task, the pager-and-belt-clip styling didn’t appeal to the young target market, and the economics [60] were ultimately unworkable.

A built-in, custom-designed application always holds the potential for the best user experience and platform integration; and, given the limitations of the other platforms, it offered the best opportunity to replicate instant messaging’s conversational user interface. [61] Unfortunately, each mobile phone manufacturer had its own proprietary system. Tegic had dealt with that before, earning the trust of its partners by delivering and helping integrate T9. A Mobile IM client, however, presented new challenges as many more parts of the handset needed modification, and integration and testing among the parties required extreme coordination skills. Instant messaging was also outside of the expertise, and personal experience, of many in the wireless industry. [62] As a result, we had to educate every new group we worked with about the basics of IM and the expected mobile experience to ensure that it didn’t get treated just like SMS.

first built-in IM client When we started developing the built-in client, the next-generation high-speed wireless data networks had not been deployed. So the Mobile IM client-server protocol was tuned for transport via SMS with a future upgrade path to IP connectivity. Maintaining efficiency over SMS eliminated some desirable features, most notably near-real-time contact status updates. [63]

The first built-in client on the market hadn’t incorporated the lessons learned from developing and testing AIM for WAP. So we ran a quick usability test to ensure that the typical AIM user could accomplish the basic tasks and that the overall user experience was acceptable. It confirmed that most participants could and would use that version of IM if it was on their phone. But although no “show-stoppers” were discovered, a number of suspected usability problems were confirmed during the test. Unfortunately, at that point, late in the development cycle, few of the problems could be fixed before release. [64]

Those experiences prompted us to run a series of small studies examining the mental models and expectations of desktop AIM users approaching Mobile IM for the first time and the usability of key design elements. [65] We used paper prototypes to walk the study participants through the unimplemented design. In many respects, paper prototyping helped keep our focus on issues that we could control [66] and ignore the issues that would differ for each handset anyway. [67]

paper prototype testing The first study indicated that new users would be able to complete the basic IM tasks without too many problems, but the navigation and menu structures needed to be improved and simplified. The physical limitations and navigation models on most phones created real challenges, but a hybrid solution between desktop and phone UI conventions seemed to offer the best results. A follow-on study confirmed that the hybrid design would increase usability without causing unacceptable side effects.

A third study closely paralleled the first, this time with ICQ users; navigation again posed the greatest difficulty. Support for a few desktop ICQ features [68] had been deferred until a later release, but the study participants didn’t consider the features optional. Also, subtle differences between the desktop and the mobile client seemed to be more of a problem for these ICQ users.

Additional user feedback came in the form of online surveys mailed to current and former Mobile IM users, plus a set of focus groups. The habits and perceptions of six user segments [69] were evaluated. Not surprisingly, those users with built-in clients and/or T9 proficiency were the most satisfied with Mobile IM. But there continued to be a lack of awareness during service sign-up and handset selection and uncertainty about the cost and billing of wireless data. The participants of the focus groups were teen girls, women, and men who regularly used Mobile IM. Their responses mostly echoed the findings of the surveys, and indicated that improvements in the marketing and education of the service could increase uptake and usage. [70]

Even at this point in the evolution and propagation of Mobile IM, we continued to observe users signing on and then signing off again shortly thereafter. We thought the promise of “always on” communications and “IM anywhere” was a compelling reason for users to stay online so that others could contact them, but evidently they had reasons for the contrary. First, the user was just looking to see if anyone he knew was online at that moment. Second, we theorized that since the typical mobile device only presents one menu or application at a time, some users assumed that they had to sign off the IM client / service to do anything else with the phone. Third, users expressed concern about receiving unwanted messages from spammers, or chatty friends, if they remained signed on. [71]

 

Wireless Village

The eventual acceptance of Mobile IM among carriers and handset manufacturers may have hinged on leveling the playing field through open standards. Multiple handset models with different features for different carriers are added overhead and a management headache that manufacturers resist. So, for Mobile IM clients to be cost-effective, the manufacturers pushed for an open protocol so that they could ship an IM-enabled handset model and have it work with whichever IM service the carriers arranged. [72]

The open protocol was forged under the Wireless Village Initiative, later consolidated under the Open Mobile Alliance. As it looked forward to GPRS-level or greater wireless bandwidth, the proposed open protocol carried a much higher overhead so an SMS-only transport was not practical. The protocol also did not initially support several IM features that we knew were important – a conventional SMS perspective undoubtedly influenced the WV system design.

screen shot of Wireless Village client It was yet another design iteration of the built-in IM client; we identified the constraints imposed by the open protocol and determined the best user experience for our AIM and ICQ users. New challenges included working within the generic feature set and appearance supporting the different IM services, and finding a middle ground between our original server-centric point of view (where all user information is hosted on the service) and the handset manufacturer’s phone-centric point of view (where all user information originates from and stays stored on the handset).

As the responsibility for designing and developing the clients moved further away from AOL Mobile, it became even more important to have clear and complete guidelines for designing the AIM and ICQ variants of the multi-branded clients. Our custom UI specification evolved into a general UI Guidelines document for WV clients, which has since influenced the overall design of many of the mobile phone IM clients on the market today.

As with the custom client UI specification, we executed a few small studies to confirm the design presented in the UI Guidelines. In addition, we ran a usability study on one of the first WV clients completed by one of our partners. The potential problems uncovered there [73] also reinforced the importance of the design elements we had specified in the UI Guidelines.

 

Epilogue

Mobile instant messaging services required a design approach that went beyond interaction design to consider everything that impacted the user experience. Constraints were imposed by the wireless data infrastructure, the existing IM service behaviors, the limited and varied handset user interfaces, and the needs and expectations of the users. The design for each platform had to accommodate the constraints while striving for an overall user experience that was fun as well as functional. Occasionally, a platform just couldn’t deliver a service that was worthwhile.

As each constraint loosened over the years, with wireless data and mobile phone technology maturing and converging on new standards, the wireless carriers have recognized the market opportunity of mobile instant messaging. In 2006, GSM operators announced a “Personal IM” system that would work somewhat like SMS (sender pays) across carrier networks, and invited the major IM service providers to interoperate.

Though industry analysts both underestimated the timeframe and overestimated the global reach, Mobile IM has fulfilled its promise for millions of wireless subscribers in the U.S. and elsewhere. [74] Not bad for what started out as just some idle chat