Producing, consuming, annotating (Social Mobile Media Workshop, Stanford University)
Today I’m attending the Social Mobile Media Workshop at Stanford University. It’s organized by researchers from Stanford’s HStar, Tampere University of Technology, and the Naval Postgraduate School. What follows is some still jagged thoughts that were prompted by the presentation this morning, rather than a straightforward account of the presentations.1
A big theme of the workshop this morning has been transitions among production and consumption — and the critical role of annotations and context-awareness in enabling many of the user experiences discussed. In many ways, this workshop took me back to thinking about mobile media sharing, which was at the center of a good deal of my previous work. At Yahoo! Research Berkeley we were informed by Marc Davis’s vision of enabling “the billions of daily media consumers to become daily media producers.” With ZoneTag we used context-awareness, sociality, and simplicity to influence people to create, annotate, and share photos from their mobile phones (Ahern et al. 2006, 2007).
Enabling and encouraging these behaviors (for all media types) remains a major goal for designers of participatory media; and this was explicit at several points throughout the workshop (e.g., in Teppo Raisanen’s broad presentation on persuasive technology). This morning there was discussion about the technical requirements for consuming, capturing, and sending media. Cases that traditionally seem to strictly structure and separate production and consumption may be (1) in need of revision and increased flexibility or (2) actually already involve production and consumption together through existing tools. Media production to be part of a two-way communication, it must be consumed, whether by peers or the traditional producers.
As an example of the first case, Sarah Lewis (Stanford) highlighted the importance of making distance learning experiences reciprocal, rather than enforcing an asymmetry in what media types can be shared by different participants. In a past distance learning situation focused on the African ecosystem, it was frustrating that video was only shared from the participants at Stanford to participants at African colleges — leaving the latter to respond only via text. A prototype system, Mobltz, she and her colleagues have built is designed to change this, supporting the creation of channels of media from multiple people (which also reminded me of Kyte.tv).
As an example of the second case, Timo Koskinenen (Nokia) presented a trial of mobile media capture tools for professional journalists. In this case the work flow of what is, in the end, a media production practice, involves also consumption in the form of review of one’s own materials and other journalists, as they edit, consider what new media to capture.
Throughout the sessions themselves and conversations with participants during breaks and lunch, having good annotations continued to come up as a requirement for many of the services discussed. While I think our ZoneTag work (and the free suggested tags Web service API it provides) made a good contribution in this area, as has a wide array of other work (e.g., von Ahn & Dabbish 2004, licensed in Google Image Labeler), there is still a lot of progress to make, especially in bringing this work to market and making it something that further services can build on.
References
Ahern, S., Davis, M., Eckles, D., King, S., Naaman, M., Nair, R., et al. (2006). ZoneTag: Designing Context-Aware Mobile Media Capture. In Adjunct Proc. Ubicomp (pp. 357-366).
Ahern, S., Eckles, D., Good, N. S., King, S., Naaman, M., & Nair, R. (2007). Over-exposed?: privacy patterns and considerations in online and mobile photo sharing. In Proc. CHI 2007 (pp. 357-366). ACM Press.
Ahn, L. V., & Dabbish, L. (2004). Labeling images with a computer game. In Proc. CHI 2004 (pp. 319-326).
- Blogging something at this level of roughness is still new for me… [↩]
Update your Facebook status: social comparison and the availability heuristic
[Update: This post uses an older Facebook UI as an example. Also see more recent posts on activity streams and the availability heuristic.]
Over at Captology Notebook, the blog of the Stanford Persuasive Technology Lab, Enrique Allen considers features of Facebook that influence users to update their status. Among other things, he highlights how Facebook lowers barriers to updating by giving users a clear sense of something they can right (“What are you doing right now?”).
I’d like to add another part of the interface for consideration: the box in the left box of the home page that shows your current status update with the most recent updates of your friends.
This visual association of my status and the most recent status updates of my friends seems to do at least a couple things:
Influencing the frequency of updates. In this example, my status was updated a few days ago. On the other hand, the status updates from my friends were each updated under an hour ago. This juxtaposes my stale status with the fresh updates of my peers. This can prompt comparison between their frequency of updates and mine, encouraging me to update.
The choice of the most recent updates by my Facebook friends amplifies this effect. Through automatic application of the availability heuristic, this can make me overestimate how recently my friends have updated their status (and thus the frequency of status updates). For example, the Facebook friend who updated their status three minutes ago might have not updated to three weeks prior. Or many of my Facebook friends may not frequently update their status messages, but I only see (and thus have most available to mind) the most recent. This is social influence through enabling and encouraging biased social comparison with — in a sense — an imagined group of peers modeled on those with the most recent performances of the target behavior (i.e., updating status).
Influencing the content of updates. In his original post, Enrique mentions how Facebook ensures that users have the ability to update their status by giving them a question that they can answer. Similarly, this box also gives users examples from their peers to draw on.
Of course, this can all run up against trouble. If I have few Facebook friends, none of them update their status much, or those who do update their status are not well liked by me, this comparison may fail to achieve increased updates.
Consider this interface in comparison to one that either
- showed recent status updates by your closest Facebook friends, or
- showed recent status updates and the associated average period for updates of your Facebook friends that most frequently update their status.
[Update: While the screenshot above is from the “new version” of Facebook, since I captured it they have apparently removed other people’s updates from this box on the home page, as Sasha pointed out in the comments. I’m not sure why they would do this, but here are couple ideas:
- make lower items in this sidebar (right column) more visable on the home page — including the ad there
- emphasize the filter buttons at the top of the news feed (left column) as the means to seeing status updates.
Given the analysis in the original post, we can consider whether this change is worth it: does this decrease status updates? I wonder if Facebook did a A-B test of this: my money would be on this significantly reducing status updates from the home page, especially from users with friends who do update their status.]
Using a Wizard of Oz technique in mobile service design: probing with realistic motivations
As I’ve blogged before, I spoke at the Texting 4 Health conference on the topic of research methods for mobile messaging. One method I covered was an interesting use of Wizard of Oz techniques for designing mobile services. I’ve since started getting some of this material in writing for the Texting 4 Health book. Here is a taste of that material, minus the health-specific focus and examples.
——-
Just like the famous Wizard of Oz, one can simulate something impressive with a just a humble person behind the curtain — and use this simulation to inform design decisions. When using a Wizard of Oz technique to study a prototype, a human “wizard” carries out functions that, in a deployed application or service, would be handled by a computer. This can allow evaluating a design without fully building what can be expensive back-end parts of the system (Kelley 1984). The technique is often used in recognition-based interfaces, but it also has traditional applications to identifying usability problems and carrying out experiments in which the interaction is systematically manipulated.
Wizard of Oz techniques are well suited to prototyping mobile services, especially those using mobile messaging (SMS, MMS, voice messaging). When participants send a request, a wizard reads or listens to it and chooses the appropriate response, or just creates it on-the-fly. Since all user actions in mobile messaging are discrete messages and (depending on the application) the user can often tolerate a short delay, a few part-time wizards, such as you and a colleague, can manage a short field trial. As you’ll see, this can be used for purposes beyond many traditional uses of a Wizard of Oz.
Probing photo consumption needs with realistic motivations
One use for this technique in designing a mobile messaging service is a bit like a diary study. In designing an online and mobile photography service, we wanted to better understand what photos people wanted to view and what prompted these desires.1 Instead of just making diary entries, participants actually made voice requests to the system for photos – and received a mobile message with photos fitting the request in return. We didn’t need to first build a robust system that could do this; a few of us served as wizards, listening to the request, doing a couple manual searches, and choosing which photos to return on demand. Though this can be done with a normal voice call, we used a mobile client application that also recorded contextual information not available via a normal voice call (e.g. location), so that participants could make context-aware requests as they saw fit (e.g. “I want too see photos of this park”)
In this case, we didn’t plan to (specifically) create a voice-based photo search system; instead, like a diary study, this technique served as a probe to understand what we should build. As a probe it provided realistic motivations for submitting requests, as the request would actually be fulfilled. This design research, in additional to other interviews and a usability study, informed our creation of Zurfer, a mobile application that supports exploring and conversing around personalized, location-aware channels of photos.
It is great if the Wizard of Oz prototype is quite similar to what you later build, but it can yield valuable insights even if not. Sometimes it is precisely these insights that can lead you to substantially change your design.
This study design can apply in designing many mobile services. As in our photos study, participants can be interviewed about the trigger for the requests (why did they want that media or information) and how satisfied they were with the (human-created) responses.2
- This study was designed and executed at Yahoo! Research Berkeley by Shane Ahern, Nathan Good, Simon King, Mor Naaman, Rahul Nair, and myself. [↩]
- Participants were informed that their requests would be seen by our research staff. Anonymization and strict limits of who the wizards are is necessary to protect participants’ privacy. Even if participants are not informed that a wizard is creating the responses until they are debriefed after the experiment, participants can nonetheless be notified that their responses are being reviewed by the research team. [↩]
Laptop + shopping cart = mobile
This guy can roll up with laptop and webcam to record robots (photo CC from violetblue):
But in Silicon Valley, combining laptops and shopping carts is just a way to get chores done. When at Whole Foods in Los Altos, I saw a man pushing a shopping cart with a laptop in the part where you can sit your toddler. I suppose he was reading a recipe or something. (I, and I’m sure other Valley folks, do that on a phone.)
A bit odd, but then again, I used to be (I’ve fallen off a bit) judicious about capturing the contents of my shopping cart with ZoneTag.
