Date of last revision: January 15, 2010.

Our work builds on a number of premises. The first is that every user operates in different social contexts with distinct members. These contexts have a social meaning and can hence be labelled. For instance, I might want to distinguish between family, colleagues, professional acquaintances, and friends, whereas the reader might want to distinguish entirely different categories, depending on their personal goals and uses of a particular social network. We call these social groups “collections”. Each of the collections consists of a number of known contacts of the profile owner.

Our point is that the platform provider (we) certainly can not provide the entire social complexity; there is no need for us to do this in the first place. Users are fully capable of representing whatever works for them. They can decide on the necessary granularity as well as on the labels they want to stick to their social categories. 

While users should be able to define their own audiences within the SNS, others should not be able to inspect how a user has compartementalised their world. I may call a certain collection “idiots”, but there is no need that the members of this collection are aware that they are considered idiots. Users should also be capable of deciding which of their contacts belong to the different collections. Of course this is not static, but we expect changes in the overall structure to be relatively scarce. Maintaining ones network by no longer involving ex-lovers into all communication is something that is done in the real world as well. Collections can be managed by dragging contacts in or out a particular collection. Figure one also shows another feature of the prototype, the possibility to maintain different faces within the same SNS. The picture shows my professional face, one in which my real name is known. It also shows two contexts in which I operate under pseudonyms (Romix and DepronDave). These two identities represent me in my hobbies. Clique allows me to maintain my different spheres within the same software environment. This allows the user to manage a single address book and easily share data between these different spheres while still being able to control linkability.

Figure 1

Our second assumption is that we presume that each SNS user has a core audience in the SNS which basically reflects the primary reason for being present in the SNS. For a majority of SNS users, their core audience will consist of their immediate friends (Facebook, Hyves), for some networks, the core will more likely consist of professional contacts (Linked-in). This allows us to make assumptions about the users’ behaviour. A sensible default is to assume that the user primarily wants to disclose information to this core audience, and if so, no special action should be required. This is implemented as follows. Posting information on the SNS requires the user to press the [publish] button. Subsequently a save information dialogue appears such as shown in figure 2.

Figure 2

By default, custom will be selected and within custom the default collection – the user’s core audience – will be pre-selected (as shown in figure 3). Under most circumstances this represents what the user wants to do, so pressing [submit] will do to publish the information on the SNS. Showing the user the currently selected audience (as in figure 3) will help prevent accidental data spills.

Figure 3

This publication mechanism applies whenever the user creates or modifies any ‘blob’ of information on the SNS, such as posting a comment, writing a blog entry, or modifying a profile attribute. The save information dialogue allows the user to customise the audience by either selecting private, their own contacts, logged-in users, public, or make more fine grained choices in the Custom panel where they can drag contacts and collections in or out the audience for the particular blob of information (see figure 3). The mechanism as implemented nudges the user to disclose information to their likely intended audience (their preferred collection)without hindering making different choices.

The third assumption is that access control policies should be set on on all data disclosed in the SNS and should be as easy as possible. These policies should be as simple as possible. The access control mechanism in Clique allows the user to specify which collection and/or individuals have access to certain information. In the case of collections it should be able to exclude individual members from certain information. For instance, I may want to exclude a particular friend from discussions about a birthday present in order to maintain an element of surprise during her birthday party, something we also do in real life.

All information in the SNS contains visual indicators of the current audience. Figure 4 shows that the Google blog entry is open to the public at large (green globe icon), while the “Not for the faint of heart” post is restricted to a collection (two figures icon), in this case the PrimeLife members, minus “Hans”. Each item on the SNS can be assigned its own access control policy (see figure 5 for an example of the profile page).

Figure 4

Figure 5

One can also view one’s own profile from the perspective of another user (figure 6). Contact icons feature a contextual menu (activated by mousing over the bottom-right corner of the icon) which, apart from options such as remove from my contact list, contains an option ‘view my profile as this user’). These visual indicators should help the user to determine whether the image of themselves they think they project conforms to what others within the SNS actually see of them. This helps them maintain control over their audiences. 

Figure 6