Brandon Mechtley

Consent.

Even if you communicate to a user that you’re using his or her information in some way, it’s still necessary to acquire specific consent to do so. This principle is often only understood in terms of what information legally requires consent from a user. Often however, one’s actions have ambiguous consequences, once again increasing the possibility space.

If proper notice exists in a tool without an adequate level of consent, a situation may arise where users are perfectly comfortable with their current state of disclosure but approach interacting with the tool with a high level of anxiety. Result previews (notice), paired with consent at every step can assist in assuaging any anxieties. If it’s undesirable to have an interaction that requires constant interruptions for consent, certain commonplace features such as allowing users to set defaults (e.g. “never ask me this question again.”) can be employed, although these interventions should be minimised to avoid the setting bloat explained earlier. One way to minimise the amount of consent required is to group features with similar consequences. In extreme cases that simply do not allow for consent, a designer may fall back on Recourse, another principle which will be explored later.

A good example of consent can be found in most blogging services, where a user has the option to preview an entry before posting it, or in some cases, such as the Wordpress software, has the ability to save it as a draft as well. Drafts allow for requiring consent without breaking the flow of interaction, as a user is not forced to make a decision immediately.

Going back to the easy example, Facebook has met several problems with consent, the most obvious being the recent mistake of making its Beacon service require strange service-by-service opt-out requests. When the model of how user information was used changed and became dissonant with user assumptions, users spoke out or simply stopped using Facebook. What is particularly interesting about the Beacon incident is that users’ concepts of Facebook were not only changed in terms of how the service works, but were also changed in terms of what Facebook, and the social web in general, is capable of doing. Without explicitly creating a connection between a third-party service and one’s Facebook account, information was capable of being transferred from one to the other. This hidden interoperability and ubiquity has been as of yet unseen on the web by the vast majority of people. It came as a complete surprise.

In this case, as social web technology is a concept emergent from the services that comprise it, it’s not possible for it to require any explicit consent from users for it to change its model. Therefore, it is only natural that such development will come as a surprise and heighten anxiety for many. Altering a society’s conceptions about its own capabilities is a fundamental aspect of technological progress, which is one reason why it is so important that developers of these cutting-edge tools approach them with the utmost care. An explicit opt-in policy from the start would have saved Facebook some hassles, but it would not have completely eliminated the anxiety that comes with new potential. However, introducing such a service in a more considerate manner may have helped people realise that these new opportunities are more exciting than they are frightening.

Choice.

Even with an appropriate level of consent, you still don’t maximise the usefulness of your tool. What does someone do if he doesn’t give you consent to wantonly throw his information around the web? A lot of things requiring our consent in the world are black and white: whether or not you release your rights to something, whether or not you agree to the Terms of Service, etc. What’s a user’s recourse if he doesn’t like the ToS? He won’t use the software.

This leads us to the most important caveat when it comes to Consent: Consent must not be presented as an ultimatum. For every user that agrees to an ultimatum, you’ve probably lost a few more. There ought to be smarter ways to design software such that several user types (or Templates, as will be discussed later) are supported.

Sometimes this isn’t really a possibility, especially when it comes to legal liability centred around the theme of your application. Plus, having software that appeals to everyone might be a bit unrealistic for those developers who value pragmatism a little more than nobility. Either way, we should be cognizant of this and apply more choice where we can. Should I only be able to publish something to the entire world, or maybe just my friends? Should I have to give something to all my friends, or just some of them?

More choice allows users to personalise their experience to behave more like they would expect it to, which is pretty much a free lunch: rather than trying to get the user’s model to more closely match the system, you can simply let the system adapt to their model, without having to pull any psychological tricks or try to guess what they’re thinking. There are obvious trade-offs with the overall complexity of the system, however, and one thing you cannot control is that users change and users forget. Some people’d even say that users aren’t sure what they want. So needless to say, there’s a proper balance that has to be maintained by more choices and simply more notice of the consequences to which users must consent.

In some cases, choice can be abstracted to easily describe a large variety of choices , which can help in those cases where a user can’t be expected to remember every choice he’s made. This is a reductionist strategy that I’ll explain when I talk about Behaviour Templates.

Next on the list is Proximity and Locality.

Some of Facebook’s more controversial decisions: introduction of the news feed, opening up the service to high school students, opening up the service to everyone, third-party application development, and Beacon. These are also the major changes in Facebook’s business model. Why is it that every major change is met with such tremendous backlash? Zuckerberg had to publicly apologise for the Beacon fiasco.

It seems like there must be a better way to reflect these changes in the design such that the transition is much smoother. This is not simply a public relations problem where users need to be convinced that there is legitimate use for a particular change, but it is a problem of changing aspects of the system to meet the goals that inspired those changes while also maintaining the current level of privacy and users’ perception of it.

I’m going to use Facebook as a case study for all my suggestions (i.e. complaints). So first off is . . .

Notice.

Notice involves telling people upfront that information about them or their actions is being used in some way. I’d say this is one of the most overlooked principles in the design of social web tools, and it’s also maybe one of the most important to implement. In terms of one’s understanding of a system, there are generally a myriad of possible mental models, some which are more accurate than others. Proper notice is just a way of minimising that possibility space to more accurately represent the actual system.

Consider Facebook and MySpace. As I see it, when it comes to personal disclosure, the key difference between these two sites is that Facebook is much more private. MySpace profile pages can be accessed by people who don’t have accounts, whereas Facebook creates a complex structure for who is or who is not able to view a page. Additionally, Facebook allows users to specify how and what information is presented to others, depending on his or her relationships with them. Facebook allows configuration of privacy settings for:

1. every third-party application installed
2. personal information in the profile
3. status updates
4. videos
5. photos
6. online status
7. friend list
8. wall posts
9. seven different pieces of contact information
10. email address
11. application visibility in the profile

Multiply that by being able to set visibility to:

1. no one
2. only one’s self
3. only one’s friends
4. a specific set of networks one belongs to and his or her friends
5. all of one’s networks and friends
6. everyone

This probably makes for over 100 different possible profiles for the average user with a few applications. Needless to say, Facebook profile visibility is a complex system.

Given all the controls users have over their profiles, it’s unreasonable to expect them to remember how they have configured these settings or that they have manually configured the settings in the first place. Facebook applies defaults upon registration, but a user must visit a privacy control panel to tune these parameters. It can easily be imagined that many users will approach use of the service with great uncertainty, as at any given point, they cannot be sure who is viewing their profile and what these people will see. After all, the only way someone could know for sure what someone else can see is by logging in as the other user or pouring through their privacy settings. (Or by creating a series of dummy accounts, like I’ve done.) LinkedIn has a perfect, painfully simple approach, as seen in the image.

Not only does this uncertainty contribute to a fear of the tool, but it also significantly reduces its usefulness. The power behind a configurable social networking tool that protects your privacy, such as Facebook, is that it allows users to freely express themselves in front of private, controlled audiences and allows them to use this expression and disclosure to their benefit through discovery of new information about their local and extended networks. Unfortunately, when privacy-conscious users are confronted with uncertainty concerning the publication of their personal information, they will disclose according to what they would be comfortable sharing to the broadest audience imaginable given the notice of the system.

With MySpace, on the other hand, there’s more or less only one possibility for the information users share on their profile pages: complete disclosure to the entire world. This limits the usefulness of the tool in terms of discovery and self expression for privacy-conscious users, but the design is so limited that users are always implicitly confronted with notice of how their information is being shared with the greater audience. This notification is crucial to making users comfortable with the software, and it is most likely why the debates surrounding privacy on MySpace (issues of security, social issues of what people are willing to share) are of a much different variety from the debates surrounding privacy on Facebook (students unwittingly showing pictures of drinking parties to potential employers, changes in privacy model). MySpace users are able to have much more reliable, precise assumptions of the system, whereas Facebook users’ assumptions and desires are most likely quite varied and ambiguous.

A personal example of poor notice on Facebook is that I can never tell if items I hide from my mini-feed are also going to disappear from my friends’ news feeds (or how long that’s going to take, if they do.) In terms of communicating with my friends, I can’t even be sure that my posts and updates will show up on their feeds. Result? I give up and send them a message on Facebook or email them. My model?

Make update -> MAGIC -> Uncertain distribution of my update

In the case of the dating application, my friend probably would have thought twice had he been able to see an accurate preview of the application’s news feed entry. In general, previews are a good solution if you can’t think of anything better. As seen in the image, LinkedIn is a perfect example of how effective and painfully easy adding previews is.

Drafts, previews, reducing or combining configurable parameters, and reducing or combining viewing scenarios are all great, easy ways to give users proper notice of what you’re doing with their information. In reality, especially for complex sites like Facebook, the solution is going to be much more domain-specific, and in most cases, there will be no single Best Solution. Your best bet will be to go with your gut and try to minimise confusion as much as possible. Paying close attention to use cases is always necessary. If you have the resources, user studies may also be appropriate. Try to figure out what models people are making of your system.

Next up will be Choice and Consent.

So within the past two months there has been a boom in Facebook dating applications. I know this because I had a hairbrained scheme to build one but never acted on it–I’d been searching for them last year and never really came across very many. Anyway, I noticed one in my News Feed today. The message goes like this:

[Your friend] was reviewing friends’ friends for dating, using [Application].
[Pictures]
In his network, people have voted [Person 1], [Person 2], [Person 3], and [Person 4] as most desired.

Well it so happens that this friend’s network tends to overlap with mine a bit, this is the first time I’ve seen the application installed. That must be embarrassing for him, considering at least one or two of these girls are in pretty solid relationships. Knowing him, he’s probably too clueless to get the picture. Knowing Facebook, he might not have even seen the news feed item.

I wrote a paper on design principles for social applications a little while ago. Maybe I’ll try to submit it somewhere sometime, but I think I might break it into a few (less dry) blog posts instead, as that seems to be where most of the discussion is going on. Considering I am a passive observer of the market who hasn’t built a legitimate social application and no one knows who I am anyway, probably no one will read it and it will have 0% effect on the stuff that gets thrown out here, but what the hey? The premise was that there have been a lot of Bad Decisions made by Facebook, MySpace, and others, most having to do with security issues unique to social networks. Very few of these decisions actually resulted in Bad News for the users, but every one did result in a huge backlash from the user base, one which required a personal apology from a certain CEO.

There was a paper I read that accumulated a number of key design constraints for ubiquitous computing (which is similar to the social web in its large privacy ramifications), and six of them seemed to fit very well for Social Design: Notice, Choice and Consent, Proximity and Locality (of effect), Adequate Security, Anonymity and Pseudonymity, and Access and Recourse. I gave suggestions in each of these areas, and I included one more derivative suggestion, which was Customisation and Templates, including Contact Templates and Behavioural Templates (Facebook is very slowly adding the former; LiveJournal has essentially hit all these points.)

I’ll explain all these later, but let’s just say that this example represents a possible mistake in all six of those key areas.

I should write a paper about the natural bass reinforcement properties of apartment complexes. It seems if I turn the bass up loud enough, I get pounding on the walls.

It’s a really cool effect.

Homonyms.