Warning:
This wiki has been archived and is now read-only.

FinalUseCases

From Social Web XG Wiki
Jump to: navigation, search

Contents

Appendix: A: Social Web Use Cases

The Social Web Incubator group worked through a number of iterations of use case descriptions in order to refine an agreed view of the properties of the Social Web. What follows is a selection of these use cases.


Account creation, management/maintenance (personalization)

This use case category (including all extensions) describes tasks which the user does to set up, manage and maintain one or more identities or profiles on the Social Web.

Covers all system set up/user account management/profile maintenance, settings (choose how and when to be seen, receive notifications). Interactions with devices and/or service portals could be envisaged.

NOTE: Need to decide if we recommend a unique user have multiple identities and multiple profiles, one unique identity and multiple profiles, etc.

Creation of a new profile

The goal of this use case is to set up (create for the first time) a user’s personal profile and to make it "visible" in one or more social applications or to those in the community of users. Profiles may be distributed.

See profile management below.

Should take into account:

Entering and modifying (updates to) personal information

When setting up a profile (use case above), a user is not required to complete all the property fields about themselves. They may wish to create new (custom) fields in a profile. And there may be, in the future, a desire to modify the content of those fields filled in/populated in the past (favorite music, movie, relationship status, etc).

A user's multiple profiles (business profile, family profile, friends profile, etc) may be managed through a single platform or service.

Profiles are "associated" with a unique user's digital identity. Use care not to mix identity with profiles.

Setting mood indicator

Mood is an indication of the actor’s emotional state. There is no universal set of mood definitions. The user’s mood is an important element of context. This should be adjustable and then the change in state (status) propagated so that any application that monitors a user’s mood is updated, as well as the current state appearing when those with permission request to see/view the mood indicator.

Managing presence

The user’s “state” is a description of the condition between the terminal/user device and the presence server (managed/operated by presence management provider). Possible presence states may be binary: logged in/logged off, in a call/not in a call, typing/not typing, in motion/stopped (see context services), in a dark place/well lit place…

NOTE: This is a mine field.

NOTE: See Seesmic client announcement/vision

Setting/choosing music to stream from personal profile

In the management interface of an account or profile, the user may elect to have a personal audio stream (music or speech) associated with all, some or none of their profile, all, some or none of their “friends” on a list.

This can be a logical extension on existing ringback tone service for mobile subscribers. If a subscriber selects a ringback tone for incoming calls this might also be applied to profile.

Policies may include conditions on use of commercial or User Generated content.

Adjusting location-awareness service settings

In the management interface of an account or profile for a service which supports location awareness, there must be settings for adjusting when the location is detected, by whom and the level of accuracy (granularity) of the location. Companies providing location aware services are developing agreement on how to share location between services, but there must be consistent ways for the user to control the data stream/publication of location.

Blocking others’ ability to engage (privacy from unwanted users)

A user must be able to adjust the “visibility” others have relative to their personal/profile information and some or all social media. In some scenarios this can be called “blacklisting”. Control can be binary: permit this person to send messages/do not permit this person to send messages, permit to see my profile/do not permit to see my profile, permit this user to see my presence status/do not… Settings can be more general: hide me and all my media from anyone who is not already known to me (prevents people from identifying me on a photograph?)

Managing stored social media (personal content)

This is a use case which is related to but separate from uploading/sharing of personal social media objects (category 2 of 8). This use case covers management of stored social media. Management has (at least) four aspects: packaging (put this object in an album, leave this object out of an album, remove from an album), annotation (associate key words, names, etc), visibility to others (some social media are public, private, shared with some but not all), monetization (controlling any rights for distribution, downloading, etc).

Checking status or popularity indicator (e.g., page views)

As part of this use case, the user clicks a button or navigates to a menu for information of several types (extensions of this use case). For example, the user can see their rank among community members (popularity), see who has responded to invitations to join community or check the “trail” of visitors (footprints of who has been viewing what part of the social media). There should be reports which show activity levels over time. This is popular in Japanese community platforms.

Choosing avatars

An avatar permits the user to be more and different than they really are and to engage imagination, fantasy and the digital avatar is more efficiently transmitted (low bandwidth) over mobile networks than a full resolution photograph/image. Avatar accessorizing is a huge business in some societies/communities. As part of a set up menu, or as part of a continuing personalization feature set, the user can modify what their virtual personae looks like, how it sounds and other parameters.

Exporting & Importing personal data

Originally: Re-Use Your Data and Drag and Drop.

Access Control

Should include

Also, Access Control should not only encompass assets uploaded but also profile information, annotations, groups created and Friendship Relations, hence the repetition of this subsection in other parts of this document.

The right to be forgotten

Originally: Removing Data or Changing Data Permissions.

Must clearly specify the data concerned can include not only Profile data but also:

  • List of friends;
  • Content shared;
  • Comments and ratings given;
  • Payment information;
  • List of purchases.

Setting a last will for online data

Originally: Last Will For Online Content / Account Last Will.

Create, edit and share/post

This next group of use cases includes everything which can be considered “Create, Undo, Remove, etc”. It spans all variations and media from writing a text message to post to no one in particular (or to everyone), posting (upload and annotate) photos, videos, sound files, anything which has media and metadata associated with it. Includes having user context associated with the media object.

This category covers only use cases with the user as the source (original) of the content and where the user has sole rights.


Uploading, publishing user-generated text (blog post) with or without tags

The user generates social media objects by way of keyboard or voice (in a voice-to-text engine) and posts with or without tags to one or more profiles.

In the simplest scenario this is just a WordPress post. The post is published to one or more profiles.

Properly documented use case should have mention of moderation requirements/regulations and latency. Moderation is required in some but not all communities.

There needs to be a standard for metadata which the user/owner of the media associates with an object.


Uploading, publishing user-generated images (photos) with or without tags

The user generates social media object by way of still image camera (on a mobile handset or separate appliance-camera) and transmits it to the destination.

“Destination” can be the personal digital media locker or to the distribution/aggregator interface, or directly into one account or profile on a platform.

There needs to be a standard for metadata which the user/owner of the media associates with an object.

Should have some recognition of moderation and policy for latency between publishing and appearance to audiences. The user should also be able to see how many views an image has had.


Uploading, publishing user-generated video content with or without tags

Similar as for photos. Difference is there will be use case extensions which illustrate workflow options. for example, when the user is mobile: compression on handset before transmission (upload), whether the transmission is performed in real time (avoids storage on handset, lowers handset power consumption) and notifications to the user regarding completion of upload.

There needs to be a standard for metadata which the user/owner of the media associates with an object. Should have something about moderation and policy for latency between publishing and appearance to audiences.


Access Control

Should include

Also, Access Control should not only encompass assets uploaded but also profile information, annotations, groups created and Friendship Relations, hence the repetition of this subsection in other parts of this document.

The right to be forgotten

Originally: Removing Data or Changing Data Permissions.

Repeated here and in other places as what we share, how we comment, etc. defines us as much as our profile. This story needs to be adapted in each case.

Associate people, social objects and people/objects

This category of use cases covers requests for associations and all extensions regarding permissions, expiration of social objects, includes establishing as well as removing or deleting links-could say it covers all “creation and manipulation/changes of connections or associations”.

The use cases in this category should all be focused on “social” activities, regardless of whether unidirectional, bidirectional or multidirectional.


Establishing a connection across social networks

Goal Alice wants to add Joe to her list of contacts, across social network providers.

Summary

Actors

  • Alice, user of Social Network A (Person)
  • Joe, user of Social Network B (Person)
  • Social Network A (System)
  • Social Network B (System)

Preconditions

  • Alice and Joe are not connected yet
  • Social Network A and B need have no prior knowledge of each other
  • Joe is not on SN A
  • Alice is not on SN B

Basic course of events

  • Alice somehow has an identifier for Joe's profile on SN B
  • Alice requests (through SN A) to make a connection to Joe [somehow] on SN B
  • Joe is informed by SN B that Alice is requesting a connection
  • SN A provides access to relevant information (which may not be public) to Joe (possibly via SN B) about Alice's profile
  • Joe approves the connection request on SN B [not necessary in the case of a twitter-like connection]
  • Joe appears as Alice's connection on SN A
  • Alice appears as Joe's connection in SN B

Alternative paths

  • Alternative path 1: Joe appears as Alice's connection SN A but Alice does not appear as Joe's connection on SN B [more like the Twitter type of connection]
  • Alternative path 2: Alice requests (on SN B) to make a connection to Joe; Alice provides SN B with her identity on SN A; SN A asks Alice for a confirmation if she is making the request; Alice confirms; Joe appears as Alice's connection on SN A
  • Alternative path 3: SN B doesn't directly participate in the request but is informed after the fact by crawling publicly available information (e.g. FOAF profiles)
  • Alternative path 4: Joe rejects Alice's request
  • Alternative path 5: A "relationship" is also specified as part of the connection, refer to next use case...

[ creation of a connection - especially in the case of asymetric connections - could be implicit - e.g. based on sharing data ]

Post-conditions

  • SN A and SN B both think Alice and Joe are connected to each other
  • Alternative path 1: SN A & B both know that Alice is connect to Joe
  • Joe knows Alice's identifier on SN A

Business rules

Author and date

Misc

  • There are many different kinds of connection based on the types / definition of connection in SN A vs. SN B. In this case, Social Network B would impose its rules on establishing that connection.
  • A connection request is not like following an RSS feed - in this case, SN B must be involved.
  • [does Alice needs to accept SN B's terms and conditions?]

DanBri's story about asymmetric relationships on Orkut should be noted

We should use relationships.

Managing relationships across social networks

Goal Once a connection is established, this connection can be categorised in different ways including allowing for negotiation and agreement between parties on these categories.

Summary Categories can include membership to groups, the "this is me" relationship, family, friend, classmates, colleagues, co-workers, pets, etc...

Actors

  • Alice, user of Social Network A.
  • Bob, user of Social Network B.

Preconditions

  • Alice has established a connection to Bob
  • Bob has a reciprocal connection to Alice

Basic course of events

  • Alice categorizes her connection to Bob [e.g. Bob is a "frend of" Alice]
  • Alice chooses to ask Bob to confirm this categorization
  • Bob is informed of this categorization request and can choose to confirm it
  • Bob confirms the categorization

Alternative paths

  • Bob can initiate the request as well (the reverse of the above)
  • Bob can ignore, deny, or offer an alternate version of events
  • Bob can "politely block" Alice's request [appears to Alice that Bob as accepted but actually not] - [polite blocking in SIP: RFC 3856, RFC 2779]
  • Bob can block Alice and Alice cannot re-request
  • Bob can choose to unblock Alice

Post-conditions

  • Alice and Bob are friends

Business rules

Author and date

Misc

  • We should use relationships.
  • These relationships once established should be exportable as lists / groups
  • Multiple relationships can exist on top of a connection


Forwarding/recommending to a friend

This is an action which is taken when a user sees/reads/hears something which they believe is of interest to another person or a group. It must be extremely easy to recommend or forward. The model for this use case is forwarding an e-mail or retweeting. Ideally the user can see what happens to the recommendation (did the recipient open? Go to the social media object?)

Should include: Tracking Sources?

Adding and removing people from friend and contact lists

These (adding and removing) are two separate actions. There is also a difference between adding and removing a group (the group use case is below).

In the case of the distributed profile the user maintains their own address book and it is linked to the profiles of anyone in the address book. Current information is “retrieved” by way of a common API between one user’s address book and the profile (file, server?) of the person whose name appears in the address book. The API for these associations does not currently exist and needs to be standardized.


This must include the general use case, as well as the following existing stories:

Adding and removing links between user’s profile and third party generated social media objects

These (adding and removing) links are two separate actions.

Adding a link between one person’s profile and a third party’s social media need not always be based on permission or reciprocal links. In other words, a user may link to the social media object of a user who they do not know. The two actors/users are not directly associated.

There should also be the ability to put conditions around a social media object which define if the object can be associated with a third party without first obtaining permissions.


Adding, removing, sharing groups

The user wishes to have an explicit association with a group which has a name, a URL and other identity elements. The required elements to identify/validate a group are not known/standardized.

A group is composed of users/actors and can have its own profile, however, it only publishes social media, does not actively establish links with other groups or individuals.

The manager of a group will be associating people and social media to a group’s profile (page).


Should it also include Automatically Generated Groups?

Anonymous interaction

Several different things to consider here:

  • Whistle-blower scenarios 'à la' wikileaks or for review sites: Anonymous Information;
  • Spamming and trolling problems associated with anonymous posting;
  • Positive effects of anonymity (group spirit, creativity): @TODO: tanglade.

Access Control

Should include

Also, Access Control should not only encompass assets uploaded but also profile information, annotations, groups created and Friendship Relations, hence the repetition of this subsection in other parts of this document.