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?
Wednesday, November 29, 2006
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
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.
"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.
Tuesday, November 28, 2006
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.
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
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.
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.
Monday, November 27, 2006
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.
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.
Sunday, November 26, 2006
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:
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
Friday, November 24, 2006
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:
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.
"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
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.
Wednesday, November 22, 2006
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:
App Home Screen:
Levers:
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.
Subscribe to:
Posts (Atom)