2.1 Slam User Experience
Broadly, Slam was designed to support messaging between two types of groups: long-standing groups, such as close friends, and temporary groups, such as business travelers coordinating a dinner. Messaging among long-standing groups, which might include family and co-worker groups, is a dominant scenario and is the focus of the experimental field study described below. Even amongst long-standing social groups, a substantial percentage of social interactions involve similar, but different, groups of people: the group of friends a person had dinner with Friday night might have partial, but not total, overlap with the group she went to a movie with Saturday night. A major design goal was to mimic this natural and fluid social grouping process we experience in our real world social lives. Stepping through an example of this dynamic grouping process, the user would begin by creating a new Slam group, likely starting with an existing group and making necessary modifications to the group membership (see Figure 3). Once the new group is created, all messages and pictures shared are distributed group-wide. This group continues to exist in the system so members can view pictures later or leverage this group as a starting point for a new Slam group.
Slam groups are prioritized by recency of activity in the user interface. Thus if a group created for coordinating a big weekend party turns out to have no additional interaction, it simply fades into a history of temporary groups. On the other hand, if the group continues to communicate and interact, beginning to move toward becoming a long-term social group, the group bubbles to the top level of the Slam user interface. Should this group grow into a standing friends group, its membership is likely to evolve through a natural social networking process. For example, the group from the big weekend party might turn into a group of friends who like to go dancing. As group members meet new people or see old friends that also enjoy dancing, they can add these new people to the group. At some point, a subset of members might want to splinter off into their own group. Again, the goal was that the system, and the user interface, supports these naturally occurring social group dynamics.
2.2 Technical Description
Slam was implemented using a client-server architecture (Figure 5). The backend consists of a SQL database, web service, and additional software for integrating a set of phones capable of sending and receiving SMS messages. Any client type can interface with the web service using the HTTP protocol. In our case, the primary client is the dedicated Smartphone application, with client-server communication routed through a standard mobile operator internet connection. The SMS interface required the additional step of connecting each send/receive phone to a computer that handled message queuing and communication with the web service.