Warning:
This wiki has been archived and is now read-only.
RequirementsAndUseCases-FinalReport
Contents
- 1 Core Use Cases
- 1.1 Account creation, management/maintenance (personalization)
- 1.1.1 Creation of a new profile
- 1.1.2 Entering and modifying (updates to) personal information
- 1.1.3 Setting mood indicator
- 1.1.4 Managing presence
- 1.1.5 Setting/choosing music to stream from personal profile
- 1.1.6 Adjusting location-awareness service settings
- 1.1.7 Blocking others’ ability to engage (privacy from unwanted users)
- 1.1.8 Managing stored social media (personal content)
- 1.1.9 Checking status or popularity indicator (e.g., page views)
- 1.1.10 Choosing avatars
- 1.1.11 Exporting & Importing personal data
- 1.2 Create, edit and share/post
- 1.3 Associate people, social objects and people/objects
- 1.1 Account creation, management/maintenance (personalization)
- 2 Optional Use Cases
- 2.1 Annotate/interact with social objects of others
- 2.2 Discover, explore, Consume (read, view) social objects
- 2.2.1 Viewing and downloading user-generated images (photos) with or without tags
- 2.2.2 Viewing and downloading (with or without purchase) user-generated video content with or without tags
- 2.2.3 Viewing and purchasing (download or streaming) professionally created video (media): music and stories (mobisodes)
- 2.2.4 Viewing and purchasing (download or streaming) professionally created or independent music
- 2.2.5 Downloading professionally published games (download to handset)
- 2.2.6 Downloading applications (utilities) to handsets
- 2.2.7 Searching catalogs of social media
- 2.2.8 Searching catalogs of social media based on tags
- 2.2.9 Browsing catalogs of social media
- 2.3 Initiating real time session via user’s profile page
- 2.4 Transactions in communities/between communities and merchants
- 2.4.1 Community members buy/sell from one another
- 2.4.2 Community member purchases from merchant receives the goods or services personally
- 2.4.3 Community member purchases from merchant and “gifts” the object or service to a third party
- 2.4.4 Loyalty points accrued /received by a user for inviting another user non-community member to join the community and they (the person who invited receives credits, points) joins
- 2.4.5 Purchasing of products and/or services by a community member as a result of a community member recommendation (loyalty points/credits)
- 2.5 Use of contextual data
- 2.5.1 My history as context
- 2.5.2 My current location or vector as context
- 2.5.3 My pre-set preferences as context for social network actions
- 2.5.4 My friends as context
- 2.5.5 My current time of day as context
- 2.5.6 My weather/environment (indoor vs. outdoor) as context
- 2.5.7 My current time or place as a context (ephemeral networks)
Core 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.
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.
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…
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
Users should be able to download and easily re-use their own data. A single user may want to control their own data from social networking sites, and would like to aggregate their data, and store a local copy, even if the data is distributed amongst several sites. For example, the user may want to copy data from a social networking site to their mobile phone address book and their local e-mail address contact book. The intended effect is that the user can use a single-sign in technology to aggregate their information across multiple web-sites, and back this valuable personal data up somewhere.
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.
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.
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?)
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.
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).