Overview:

Pollen Mobile develops location-based communication platforms for the consumer and business markets. Mamjam is their first public facing product. Mamjam is a location based, social entertainment service that runs through mobile phone Short Messaging Service (SMS).

The team comprising Timo Arnall and Jack Schulze were responsible for the interaction design. The system works in a similar way to internet based chat rooms, connecting users who are 'online' at the same time, with the extra dimension that they are in the same physical place. Mamjam supports private, one-to-one communications only: users can't shout to groups or broadcast messages. Once a user has found a chatting partner the system simply directs the text traffic between them until one party decides to pursue some one else, or signs off.

Phones, cells and SMS

Designing for an SMS based system, we found several pivotal issues we needed to resolve. SMS is a functionally limited system, with few opportunities to create rich, seamless user experiences.

Mobile phone handsets provide no navigation services between multiple messages, no indication of user status or location, and have no practical means of viewing session history. People are used to using SMS for quick functional communication, rather than extended contact with other people, and certainly do not rely on the messages for any kind of complex interaction.

Each transaction between user and server is a sessionless operation. Each message contains only the time it was sent, the number it was sent from and the content of the message[1]. Unlike http systems, the server cannot rely on location and session information being stored in the message address. This is complex from a user experience perspective because people are used to responses and behaviours exhibited by systems that do carry session information and behave quite differently[2].

Text messages are managed by the networks with cells, each cell carries messages particular to that region. Cells are notoriously unreliable, and we found that it was common for messages to hang in the system for over ten minutes. This presented some serious problems. Satisfying communications rely on a high level of continuity, and the timing between messages becomes a social tool. Since the time between messages was not a reliable indication of the user’s behaviour, it also made timing out of modes or users problematic.

Mamjam’s USP is that the service is location based. Users are in contact with other users in the same area. However the existing generation of phone handsets cannot determine their location, and although their positions are triangulated by the network, this information is not publicly available. This meant that location had to be manually provided by the user, in a way that then could be usefully interpreted by the server. Which meant finding and developing a reliable language for users to identify their location.

Regarding modes

A system like this one could conceivably be built without the use of modes [3]. A modeless system is attractive from a technical point of view as the server is more likely to correctly interpret instructions. From the users point of view a modeless system seems overly time consuming, where every message must be prefixed with exact commands and instructions for the server.

Process

Iteration one

We worked with Pollen to draw up several topline scenarios outlining how we would expect users to interact with the system. From these scenarios and our evaluation of the technology we identified the following requirements:

• Users must be able to join the service immediately, not just from a website prior to use
• The service should accommodate new and returning users
• People are likely to be exposed to the service through all sorts of channels, and therefore signing up should accommodate all points of entry
• The structure should be designed to accommodate expansion of the service
• Although the system was for Mamjam, the basic structure of the handshake should carry to other SMS systems Pollen may choose to develop

An initial brief was developed from these requirements.

The initial interaction architecture outlines our first intentions for the system. This structure required users to enter a lot of information about themselves before they could initiate contact with one another. We felt this was valuable in order to reduce the interaction load while chatting. This also resulted from a slightly too strict adherence to the ‘internet chat room’ model.

For legal reasons you can't download the interaction maps I drew up, so these low resolution images will have to do.

Iteration two

The first system was implemented on Pollen’s test servers, and we organised user testing sessions. This revealed several problems:

The sign up process was off putting. Users motivation for this product is for entertainment and social contact: they weren't happy to tolerate long sign-up processes. This early architecture required four messages for new users to sign up. In some cases the user would be spending the equivalent of a 10 minute call before they had even connected with someone to chat. It was clear that users needed a quick ‘n’ dirty method of signing up.

Users signing up for the first time went through a different interaction process from those signing up for a second time. There were also several different methods of identifying your location. This meant that there were four or five possible entry points into the system. Unforeseen, this caused more modal problems than could possibly be imagined, as the system had to work extremely hard processing the language and matching patterns to interpret the first message accurately.

It became clear that the three biggest problems for the interaction process were:

• Aligning the systems perception of the user condition with the users actual condition.
• Making sure the users have an accurate perception of the system condition.
• Maintaining a rich connection between users, allowing users to interpret and react to one another accurately.

This discrepancy between user perception and system perception can be referred to as ‘slippage’. Typically, slippage is most problematic during the initial handshake between users, when the users are insecure about their request and about the system itself.

As mentioned previously, text messages to and from SMS servers rarely arrive as punctually as they seem to in normal use. This meant it was possible for one of two users, both having agreed to start chatting, to reject the other on the basis that they had failed to reply to their confirmation. In fact the rejected user had replied with confirmation, but their message had been held up. The message would then arrive with the first user who had since moved to a new part of the interaction process. Their reply would potentially interrupt another process or get lost in the system, confusing and infuriating both users. Serious slippage!

We also found, as predicted, that users did not read back through their old messages. Some phones have a very limited capacity for storing messages and no phones facilitate simple navigation of previous messages, so the current message was the only one through which we could usefully rely upon for users to react to.

The second interaction architecture was developed with the problems described above in mind. Some changes have been made to the system since, mostly around modal issues, and the commands through which users communicate with the server. Although there are still issues regarding slippage, the second iteration makes this much less of a problem. The system is basically modeless, except for the first transaction. All users (new and existing) enter the system in the same way, new users are chatting within three messages, and existing users are potentially chatting after their first message.

For legal reasons you can't download the interaction maps I drew up, so these low resolution images will have to do.

Conclusions

Upon final testing of the system, we feel that the best solution to the original requirements has been found, bearing in mind all the restrictions described above. There are certainly limits to SMS communications, particularly while handsets do not facilitate any session information to the user, and networks offer little facility to develop services outside of their own internal structures. The research has generated a lot of ideas surrounding asynchronous communication structures, and the development of packetswitch networks for mobile devices.

At the time of writing, the Mamjam number is +44 7970 158 158. Just send any text message to sign up and test it for yourself.

Footnotes

[1] Some phones support greater functionality than others, the Mamjam system needed to support a broad demographic so only the bottom line functionality was available to us.

When sending a message from a server it can be set to "Flash" mode, causing the message to open in the users phone immediately. Some cells also support a "broadcast to cell" function, whereby a single message can be sent to all phones within that cell. This function is expensive and only available to phones on a given network. back

[2] Information transferred with HTTP is also sessionless, but browsers and servers are afforded with functionality to help them overcome modal issues, like cookies, history bars and links for example. There are other interface restrictions to consider regarding the manipulation of text like the absence of cutting and pasting for example. back

[3] The most comprehensive discussion of modes I have come across is in The Humane Interface by Jef Raskin, pp37.back

Case study by Jack Schulze ©2001