Reflection, Direction

Both Carolyn and I are thinking we'll push CLUSTER into the new year, so before our brains go on complete holiday, I want to get a few (possibly off topic) points down:

Women: Carolyn and I both spend a lot of time thinking about women. How they code, how they communicate, how they integrate with male engineers on and off the academic or professional clock. Carolyn goes so far as to blog about it over at tech-women.blogspot.com and one post she made this quarter (The After Hours Old Boys Club) really resonated.

In general, I don't discuss technical things with my engineer friends outside of our direct academic interactions. Color me weird, but networks and compilers don't whip me into a frenzy of off hour excitement, certainly not at the level that it draws many of my (predominantly male) colleagues. So it's been somewhat of a change of pace for us because we talk about CLUSTER all the time. When we're in lab, when we're at lunch, when we're out beering... it's always there, and I'm pretty sure this is the first time for both me and Carolyn that we've been completely absorbed in and engaged by a technical project. I won't do myself or women the disservice of drawing conclusions, I probably shouldn't have even started this observation on the "women" note, but I think that the connection is not irrelevant.

Experience Sampling: Our competition is dealing with location and privacy in a MUCH looser way than we are. We'd love to get our hands on their user studies, but that isn't really an option. More realistically, we need to get our hands on some of those smart phones and do another round (or five) of experience sampling, preferably in some statistically legitimate manner. Also, I didn't like the ESM tool, so I'd like to find out more about their thought process there, and what sort of flexibility it has. Also, I want to know more about phone APIs.

The Whole Design: I don't think we like it.

The "look": We need one.

I lost steam, I don't have the blogging brain bit that Carolyn possesses, more posting later, more pudding now,

Sierra

Finals Sign Off

The Final Exam for this half of the course is today. Good luck, Team Cluster.

This is the last of all the "end of the quarter" stuff before we'll take a few weeks off. On Thursday, I gave the last of our presentations for the quarter in front of the class and some industry guests. Afterward there was a poster session where we got to mingle and talk about our design with some of the people that do this type of thing for a living. It was very helpful to reflect back on what we've done so far and also to get some perspective from the experts on where we should be headed.

Sierra and I hope to continue with Cluster in the next quarter of the course but we'll have to wait and see if the logistics allow us to play it out that way. If it works out, we'll ramp all this up again in January. But if not, it's been a great quarter and a fascinating project to work on. I hope everyone has a great couple weeks off regardless of what happens after the break.

Happy Holidays!

Disney Mobile and Helio

It looks like social location-tracking is rapidly becoming the must have feature in a mobile phone. Here are a few more companies that are buying into the "see where your friends are" service.

Disney Mobile has their "Family Locator" feature which allows for anyone who shares the plan (e.g. anyone in the family) to see where other members are. It displays the GPS coordinates of the phone you're looking for as a red dot on a map and also includes an accuracy gauge and a nearby street address. To protect privacy, the user must enter a PIN to be able to view anyone else's location.


Helio has "Buddy Beacon" though they don't go into much detail on their site about how it works. It allows you to broadcast your location to your friends so you can "Turn it on when you're up for a party" but "switch to cloaking mode when you're going low profile." It sounds like your Buddy Beacon follows you around, constantly updating your location to your friends until you turn it off. All locations show up on a Google Map.

It would be interesting to get more detailed information about the design of these products and how they relate to Cluster, but as I don't know anyone who has Helio or Disney Mobile, that would prove to be a bit difficult. What I can say is that Disney seems to have addressed the privacy concerns by really locking down the information whereas Helio has gone with an open-door policy, leaving it up to the user to guard themselves. Cluster's design falls between the two.

Cluster Poster

The Cluster Poster (aka Assignment 9) is completed and has been submitted to Kate to be printed in time for our final presentation tomorrow. You can view it in PowerPoint from the docs section of the project web or here.

Note its disctinct lack of artistic value. This class has been great for teaching us how to make things functional and less confusing, but what class do I take to learn how to make things pretty?

Last night update:

Dodgeball NEVER updated me to Fred's location.

Dodgeball Delay

Last night, I was out on the Ave...er... doing some research for our bar hopping scenario (we wouldn't want to subject our usability test users to an unrehearsed scenario, would we?) and the talk turned to Dodgeball. It just so happened that all three of my Dodgeball friends happened to be sitting there, so we decided to try out the system.

The first thing I noticed was that it took Fred a great deal of time to generate the correct text message to send in to the server. Then he got a text message back saying his venue was not recognized so he had to send the message again with a new venue name. Finally, he received a confirmation message indicating that his status had been updated. Twenty minutes later, his friends got text messages with his update.

This experience speaks more to the problems with SMS-based interfaces than it does about problems Cluster might have. These kinds of applications rely too heavily on user recall and intrude on the user by sending so many messages. However, the delay between Fred's update and when the system notified his friends is something that Cluster should avoid. To be useful in the real world, particularly in "come join me" scenarios, Cluster's updates need to be much more timely.

PhoneSpace

For assignment 7, all of the groups were scrambled so that each of us could do a heuristic evaluation of another group's project. I was assigned to PhoneSpace, the OTHER location-based social networking phone application in the class.

The idea behind PhoneSpace is that the social network drives real world interaction by allowing the user to find and friend people who are physically nearby. It also lets you organize the friends you already have based on their location.

I spent a great deal of time walking through their prototype, which they also created with Denim. They have put a lot of work into the display and navigation of social networking functionality on a phone interface and did a great job of keeping these tasks lightweight. It was interesting to see it fleshed out in detail since Cluster shares this functionality with PhoneSapce and we have left those parts of the design largely undone as they were not included in our tasks.

PhoneSpace has a different set of privacy problems than Cluster does. Their system has to decide what range of the user's social information to expose to strangers nearby whereas Cluster only has to worry about exposing one kind of information (location) to people the user already knows. Consequently, their set of privacy levers looks very different than our own. PhoneSpace makes it easy for the user to hide content, and our goal is to make it easy for the user to hide from people.

Assignment 6 Complete

After one very intense week, Assignment 6 aka the Interactive Prototype Assignment aka Project 3 is all done. The e-mail to Kate is in flight at this very moment.

So kick back, relax, and start thinking about posters for next week.

Good job, team Cluster!

Website Changes

There has been a minor aesthetic change to the Cluster Web Page. The Documents are now included in a simple page with links to the docs and images rather than just available through an unsexy peek into the directory itself.

Enjoy!

Our Sort-Of-Working Prototype

The "Working Prototype" of Cluster (and I use the term "working" loosely) that was made using Denim is up on the project web. There are a couple of things to note about it:

• Denim has a bug where buttons cannot function as links AND show text. So, since Cluster is meant to be for a touch screen interface, there are a number of big blank boxes where text would be. They still work as buttons. The .dnm file itself shows the text that SHOULD appear here.
• We do not have a button included to return to the home screen. This is because we're assuming that it would be found on the hardware of the phone and these screens are just the software representation. So if you want to get back to the home screen (and perhaps see a different module), you'll have to back out of the file and start over. The alternative would have been to have a BLANK button on every screen that would take you back there.
• It's not supposed to be pretty - that's not what this kind of prototype is for. So don't hate.
  

Your Web Based Desktop

This isn't about CLUSTER but about our process. We're keeping all our group documents on Google Docs which has so far worked pretty well (minus a couple feature desires) because we all always have internet... And then I went home for the night to see my Parents the Luddites, after 11:00 (when dad heads to bed) the wireless goes off. Three aye em rolls around and lo: no internet, no docs, no ability to work. Of course I peek around the neighborhood for other available wireless and (of course) no dice. Thus: I can't commit to web based computing until reliable interwebs blanket the burbs. It would be really *really* nice if there were slick source control with easy desktop check in/pull down...

Design Decision: Adding Friends

Sierra brought up an interesting point today: it seems like Cluster has no way to add a new friend. This is both true and not true, by design.

First, how Cluster does NOT support adding friends:
Cluster is an aggregator. It consumes social-networking information that is hosted elsewhere (facebook, google calendar, etc.) and presents it with location information in a portable phone interface. We're assuming that everyone has a nice friendly API that allows Cluster to be immediately synched with any social-networking service. So if you add a friend on facebook or in your phone's contact list, Cluster knows it right away. Cluster itself claims no responsibility to this type of information. Only "place" information is actually housed within Cluster. So if you meet someone on the street whom you'd like to add as a friend in Cluster, just add their information into your phone's regular contact module or friend them on Myspace (from your phone's web browser, perhaps?) and Cluster will figure out the rest.

Second, how Cluster DOES support adding friends:
Cluster is a portal into all of your own social-networking identities. You can manage your calendar, your facebook, your buddy list, and any other social-networking paradigm you might have from within the app. So if you meet someone on the street, you can use Cluster to access your own facebook account and friend them right away. Technically you're "in" Cluster while you're doing this, though you're just using it to get to an outside service.

Either way you do it, Cluster sees your new friend. Nifty, huh?

Danyel's Group On Campus

Danyel's research group (from MSR) is giving a talk at the I-School at the end of this week:

When: Friday Dec 1, 1-3pm (reception to follow)
Where: Mary Gates 389

Extension!

In the e-mail that the professor just sent out:
"Given the problems people have had with Denim, I've decided to extend the due date on this assignment to Friday at 5PM."

This extension comes at just the right time. In a move that was 95% my fault, 5% Windows's fault, and 0% Denim's fault, I lost all of yesterday's work when my roaming profile didn't copy the .dnm file to the server. But, we're getting back up and running, albeit slowly, and this extension will certainly help.

Landay is a god among men. At least in my sleep-deprived opinion.

The Competitors

I can't get loopt to ping my phone and I hate dodgeball in every way. I find they're both causing me to reconsider our design a lot. A guy just passed out in the labs so I'm going to go deal with paramdeics. More later.

Design Decision: The Home Screen

We have made the decision to bring content to the Home Screen. The overall idea is to keep the displayed content light so as to not overwhelm the user while still providing enough immediately userful information. The other main goal of this screen is to invite the user into each individual module.

The "Calendar" button at the top will show calendar and event information in text form. It will not include all of the details of the event but will have cues like "..." to indicate to the user that there is more content to be viewed if they push this button. It is important that the final design of this button not lend itself to the idea that each appointment is viewable from here but that this is simply an up-to-date snapshot of the calendar module.

The "Local View" button in the middle will show a list of (at most) the top three closest friends (determined not only by location but also by the amount of time that has passed from the update) in proximity to the user. The only information given for these friends are their name, their distance from the user, and the timestamp within the last 24 hours (so no date information is necessary). If less than three of the user's friends have updated in the last 24 hours, only those who have will be included here. The background of this button is an image of a map which is not detailed enough to either distract the user or imply that it is functional in any way, but rather suggest that there is location and search functionality waiting behind this button. When the user pushes this button, the map that is displayed as the starting point of local search will be zoomed out enough to include (at least) the three friends that were listed on on this button on the home screen.

The "Profile" button at the bottom includes the user's current location (or "No Location Set" if none is set), the list of groups that can see their location information (ending in "..." if there is not enough space to list them all), and the timestamp of their last location update (empty if no location has ever been set). It is important that whatever text describes the groups here conveys to the user that 1) these are the groups whose members can see their last update and 2) these are the groups who would see their next update. The notion of current and future group visibility are not separate.
The Profile module itself will include the list of "favorite" locations (including the option to set one as the current location), the area to make and edit groups, the area to set which groups can see location information, and all social networking functionality. It should also include an easily visible button to erase (i.e. stop broadcasting) a location and return the system to a "No Location Set" state.

The Big Red Button now reads "Make My Current Location" where the current place is derived from the location->place mapping database described in the last post. Pushing this button will update the user's location and this change will be reflected in the "Profile" button at the bottom of the screen. This provides immediate feedback to the user who is also able to see which groups are able to view their location. Because of this feedback, we no longer need an "OK-Cancel" screen after pushing the Big Red Button.

Design Decision: Location vs. Place

With Kate's help, we resolved our location vs. place issue in the design. We're going to assume that Cluster relies on a database that maps GPS (or whatever coordinate system the phone uses to identify location) to actual places. This way, Cluster knows that you are standing inside Tully's Coffee, the CS building, or even Husky Stadium.

You also have the option to save and customize these locations for yourself in a "favorites" feature. For example, you could change the CS building to be broadcast as "The Labs" or your home address as "Home." Once you have these places saved in your favorites, you can easily drill in and set them as your current location (even when you are not physically there) without going through local search. Any place found through local search can be saved as a favorite but the list of favorites itself will be found in the "Profile" section of the Home Screen.

Design Meeting With Kate

The Cluster team met with Kate, the course TA to discuss a few things.

The first thing on the agenda was to discuss our last assignment. There was some concern over the three tasks (easy, medium, and hard) that we outlined in our last report. The tasks that we have been using are very leading, such as "create a group and broadcast your location to that group." We need to abstract them to be more like "send out a location update to your co-workers" so as not to convey the action we expect to our users. There was even some talk of eliminating the first task, since it is so simple, though it might be useful to keep around since we will be making a few design changes. We have made the decision to add the "bar-hopping" task: You are heading out to the bars on the Ave tonight and want to use Cluster to update your location to a small subset of your buddies as you move from place to place. The idea is that this would involve setting up a group as well as updating location. Kate did point out that it will be difficult to mimic context when giving this task since the high fidelity prototype would have to resident on a laptop to be portable.

Kate also helped us arrive at the decision not to do a prototype of the web interface. Though we intend that Cluster in its fully implemented form would have a full web interface that would allow the user to sign up for the service and manipulate groups, all of this functionality is mirrored in the phone interface. This is enough to satisfactorily complete the assignment.

There is some question as to whether the users in our study actually know what information they were broadcasting. In our focus on the security issues that come with broadcasting location, we neglected to be sure that our users understood that their social networking profile information was visible at all times, and not just after they've pushed the big red button.

Another issue we covered today is the ambiguity we have in referring to "location." Are we talking about GPS coordinates, addresses, or names like "Tully's Coffee?" Furthermore, what is the difference between the user's "current location" within the application and their actual physical location? Where in the app does it make sense to display this information? We've already determined that they are separate concepts so how can we convey that to the user? Where does it make the most sense to do this without making them so far apart that the user cannot use the information effectively? These are questions we hope to address in re-designing for the high-fidelity prototype.

The last issue we talked about was the home screen. Danyel has suggested that we bring information to the home screen instead of using it simply for navigation. Kate agreed. She encouraged us to think about ways to put enough information on the page to convey what each section does without overloading the user. She suggested to using cues such as an ellipses (...) or a triangle arrow to suggest that there is more information. Other ways that come to mind are to give each section a 3D "elevated" look to convey to the user that each section is actually a button. As long as we provide the correct functionality when the user touches the screen, the idea of what each section does will still be conveyed. Of course, any design changes would still need to be tested to make sure this is the case.

Even though neither of the final two assignments involve any more user testing, we've decided to take on a few extra run-throughs to make sure we are covering our scenarios solidly.

Dodgeball and the spread of "Friendship"

Today I signed up for Dodgeball because Danyel, our corporate mentor, sent me an invitation. The service took no time to sign up for, I gave them my phone number and two seconds later received a text message with a confirmation code at which point I was able to declare him as a friend.

Immediately I began poking around for other people I know who use the service and figured D's "Friends' of Friends" list was a good place to start: not a one. Turns out, using my usually impeccable "internet search" capabilities I couldn't find a single friend who uses the service.

A couple tidbits that caught my eye:
- Only five people in Seattle have checked in within the past hour.
- The "top ten" Dodgeball users in Seattle (as measured by number of "check ins") average 3.5 check ins a day.
- The "top ten" Dodgeball users in Seattle are all men.

I emailed D again asking for starting points to research the spread of social networks. The root of the question is why people sign up for facebook when they already have MySpace but then shun Orkut. What would make people use CLUSTER when they already have Dodgeball? He pointed to the work of Danah Boyd and the suggested the following books:

• Diffusion of Innovation, by Everett Rogers
• Presentation of Self in Everyday Life, by Irving Goffman
• America Calling, by Claude Fisher

-S

loopt

Danyel cued us into loopt, a startup in Palo Alto that is using maps and GPS locations to keep people networked through their cellphones. From their website:

"loopt turns your cell phone into a friend finder with detailed maps that show exactly who is where."

Your friends show up as pushpins on a city map including a short message they've written, a timestamp for the update, and their distance from your current location. Some of the scenarios they support include:

• Getting alerts when friends are nearby

• Pinging ("Chirping") friends when you find them on the map

• Sending messages to a group

• Sending messages through the web

• Sending proximity messages to anyone within a certain distance of you

There is also a social networking profile associated with your loopt account and you can do cool things like journal and include a photo you take with your camera phone in your status update. The companion web interface is pretty sexy too!

It looks like they've accomplished a lot of the scenarios that Cluster is hoping to, though their emphasis seems to be on location with their own social network as a companion whereas Cluster wants to enhance existing social networking paradigms with location information. The difference might be subtle but it'll be interesting to see how the design will reflect it.

Meeting With Our Mentor

Sierra and I sat down with Danyel, Cluster's industry mentor, at a coffee shop on the Ave today. He had a lot of comments on everything from broader trends in social networking to transparency of functionality to the user. The discussion wound through many different topics but here are some of the major points:

Dodgeball:

Cluster's "Use This As My Current Location" functionality is remarkably similar to services offered by the social networking agent Dodgeball. With Dodgeball, you can update your location via SMS and they will send a message to all of your friends to alert them to the changes. Some of the differences between their services and Cluster is that ours would be built into the application and, at least on the surface, would not rely directly on SMS. Also, we've decided to scale down the level of intrusion on your friends. Your location information is available to them, but only if they take action to go see it. We will be spending more time looking into some of the other design decisions that Dodgeball has made.

App Home Screen:

We had previously envisioned the Application Home Screen as a fork between three monolithic modules: calendar, local search, and social networking functionality. The more we add functionality to the design, however, we've realized that there is no clear distinction between the realms and that all of the tasks between them bleed together. For example, it doesn't make sense that separate information for Tim would show up if I happened to drill in and find him on my local search map rather than through my regular social networking view. Since the home screen was the only real separation between these modules, we're now toying with the idea of providing more generalized information on this screen (high-level updated information) rather than using it as a navigation agent. However, in doing this, we are eliminating cues that provide the user with a sense of the overall geography of the application.

Levers:

Levers, switches, knobs or whatever you want to call "user-controlled settings" are threatening to seriously weigh Cluster's UI down. By having the touch screen interface, we've made toggling privacy options faster than it might be otherwise, but the sheer number of things we want our user to be able to set have become a big problem. What exactly does the user need to see before pushing the big red button can be worry-free? Or does the fact that we have a big red button imply that it should just be that simple - no verification of settings required?

In our user studies from the low-fi prototyping stage, all of our users said that they would never broadcast location information about themselves without first checking who would be able to see the information. So we added an "OK/Cancel" screen that pops up when you push the big red button that shows the groups that would be able to see this update. But there are other kinds of highly relevant information that you might want to send with an update that would need to be verified before sending. For example a "Join me/Don't join me" switch would allow the user to easily switch between sending the message "I'm looking for company" vs. "Just wanted to show you the cool thing I'm doing right now."

In general, levers are a design element that plague a lot of software products and there are a lot of heavy design decisions to be made in this area. The first part is to determine exactly what functionality is necessary to protect the privacy of our users. The second, and perhaps trickier part, is to scale how visible that functionality is. I heard once that perfect software would accommodate all user scenarios without including levers. I fear that having that as a primary design goal for Cluster would severely limit functionality.