GlobalProfile/design

'''This document is a work in progress. Comments are appreciated but it is not a final draft.'''



This document describes the design and behavior of a MediaWiki feature intended to better provide identity to users of Wikimedia Foundation sites. It is a broad feature, with a wide-range of targeted applications.

The feature is most immediately targeted at aiding Change Patrollers. Since the various mechanisms of change patrol (e.g., Special:RecentChanges) is invariably the point of "first contact" between new editors and experienced editors, it stands to reason that a feature designed to reduce the frustration of Change Patrollers could have an overall impact to the lifecycle of new editors.

Please note that this feature may break compatibility with certain gadgets (such as Twinkle). Rigorous testing is advised.

Rationale and Hypothesis
There are two primary rationales for this feature. One involves the process by which new editors are first engaged by the community; the other involves how new (and experienced) editors perceive themselves and their contributions to the projects.

Community First Contact
One of the greatest challenges to the "survival" of a new editor on Wikipedia is the crucial first encounter with other members of the editing community. Unfortunately, this encounter is rarely initiated by the new editor in a manner of their choosing (which might provide a measure of confidence).

Instead, this first encounter occurs from the other direction (the experienced finding the newbie), and through a highly machined and impersonal system: edit patrolling.

The various interfaces for edit patrolling (watchlists, page history, recent changes, etc.) are highly impersonal and over time a certain set of behaviors have cropped up regarding reversions and treatment of new editors through them.

One of the primary "causes of death" to new users is, in fact, that that do not have a user page. When revisions are patrolled, edits by accounts that do not have a user page (a "redlink user name") are significantly more likely to be reverted on-sight, many times without being reviewed.

There are many conclusions that can be drawn about this behavior and its motivations. The most obvious one is that, in general, the population of edit Patrollers, rightly or wrongly, with or without intent, have a systemic bias towards new editors because:


 * New editors are often vandals (have impure motivation)
 * New editors are often confused (have poor experiences with the editor, for example, or do not understand talk pages)
 * New editors are sometimes perceived as having entitlement (e.g., consider themselves "experts", or have "experience with the internet", and do not "get" Wikipedian culture)

One solution to this is to automatically create user pages and talk pages for new editors upon account creation (thus removing the "red links"). However, this actually cripples Patrollers, as the metadata given by knowing that a user is new can be invaluable.

It is therefore desirable to have a system whereby new users are identified as such and yet also can be seen as serving in "good faith".

Ownership and Identity
Users of modern web sites have come to expect the ability to provide degrees of identity and personalization to their experience. While MediaWiki allows a degree of personalization (through preferences and gadgets), it does not provide easy-to-use and understand mechanisms for displaying identity.

User identity is one of the cornerstones of any "social network". When a user feels that they have identity, they innately feel closer to their own contributions to a system - a kind of "caretaker" effect. Identity helps to provide reputation currency and, most importantly, helps to foster constructive communication.

When humans interact with one another in a (fairly) anonymous system (like Wikipedia, or any other internet community), there is a direct correlation between the degree of anonymity of the participants and the quality of the conversations.

It is extremely easy to dismiss the comments of a someone when you know nothing about them. Further, it is easier to become hostile and "bitey" when the person you are interacting with appears to be nothing more than text on a screen.

The addition of identity helps to alleviate this problem. Studies have shown that users are far less likely to be hostile to someone when they can achieve a degree of empathy with that person. Identity helps in this regard.

Identity helps new users by:


 * Helping existing community members see them as "real people"
 * Providing a sense of pride and accomplishment in their contributions
 * Helping them to find other, like-minded individuals with whom they may collaborate

Benefits to the existing community include:


 * Being able to easily find potential new members for WikiProjects by being able to browse indicated interests
 * Being able to more easily determine a user's motivations at a glance
 * Be given the impression that the new user is a human being

The "New User" Preference
A new preference shall be added to user accounts, labeled "I am a new user". Users with this preference enabled will be identified as such within various contexts (such as revision histories and recent changes).

The preference will be enabled automatically for users upon account creation and will remain enabled until such time as the user disables it themselves (there will be no automatic unsetting of the preference). Experienced editors, if they so desire, may enable this preference at will.

The reason why a preference shall be used for this kind of identification rather than something event-driven (like edit count or account creation date) is because different users mature at different rates. Some users "get" the system at only 5 or 10 edits while others require upwards of 50. Thus, edit count is not a fair metric to determine one's overall experience level.

Knowing that preferences exist, and then disabling the "I am a new user" preference is enough to indicate a level of maturity.

Structured Profiles
During the account creation process, after the account has actually been created, new users will be invited to share more information about themselves in order to create a profile. It will be made extremely apparent that this step is entirely optional but will be useful.

This will be a series of screens that ask the user various questions about themselves. Where possible, the screens will use automatic searching and completion in a pull down (like the standard search box) for things that can benefit from this (such as interest collection).

This data will be stored in a structured manner. This will allow for it to be easily searched, collated, displayed, and edited.

Users will be allowed to modify their profiles at any time. Profiles will not be limited to new users; any user with an account will be able to create and view their profile.

The data collected in profiles can expand (or contract) over time, as needs be.

Collected Data
The data that is to be collected should be of use to the mission of Wikipedia. While Wikipedia is a "social network", it is a social network with a specified mission. As such, data elements collected should be useful within the context of the mission.

Elements (and rationale for them) are:


 * Real Name - entirely optional, this allows users to provide real identity. This element may be discouraged.
 * Interests - a one-to-many association, with a maximum of four or five entries. These elements will be auto-searched and connected to a larger look-up table.  It may be advisable to limit the number of interests a user can connect to.
 * Languages - a one-to-many association, with an extra column to indicate the degree of fluency (e.g., "poor" to "fluent", akin to various user boxes)
 * Associations - a one-to-many association. These elements connect the user to specific groups within the projects, like memberships to various WikiProjects, or additional access rights (e.g., Administrators, Oversight, Foundation Staff).
 * Avatar Image - a photograph that the user feels represents him or her.
 * Motivation - a short, 140 character free-text field (no HTML), designed to give the user a short space to tell other users why they are participating in the project

Future elements or structures can include things like WikiProject memberships, accomplishment badges, gratitude awards, and reputation metrics.

Public Versus Private Data
A possible option that can be applied to any element within the structured profile is the ability to mark the data as "private". In this case, it will not be visible on the profile page.

Note that this is recommended against as this type of data construct will decrease the overall usability of the profile editing interface. However, privacy concerns may advance the priority of such a feature.

Revision List Screen Modifications
For the various "revision list" pages (such as page history, or Special:RecentChanges), the display of revisions will be modified and enhanced in such a way as to grant Change Patrollers greater insight as to the identity and motivations of the user making the change.

New User Icon
Changes made by users who have the "New User" preference set will display a small icon or other identifier, indicating that they are "new users".

This will be a "minimal" icon, and while it must be visible it should not be overly prominent.

Profile Mini-Display Hover
Hovering over the user's name will cause a javascript tooltip to appear that displays an abbreviated version of the user's profile. The specifics of what this mini-profile displays are subject to testing and performance (e.g., including a user's profile photo may be too "heavy", or not needed).

As an initial test, the following should be considered as a first pass:


 * Profile photo (avatar), at reduced size
 * Real Name (if given)
 * Motivation (if given)
 * Account Creation Date
 * Contribution Count
 * Block Status
 * Administrator Status

As new profile elements are added, or additional metrics are identified (e.g., some sort of reputation metric), these should be added to the mini-display as well.

Note that the mini-profile is intended to ease the burden of Change Patrol, not add to it.

Revision Screen Modification
This section describes changes that are to take place on the Revision View screen (the "diff" screen).

New User Icon
Changes made by users who have the "New User" preference set will display a small icon or other identifier, indicating that they are "new users".

In this instance, the new user icon can (and should) be more prominent.

Profile Mini-Display
On this screen, the Profile Mini-Display has two possible options, both of which should be tested.

Option One: Hover Display
The first option is nearly identical to that used in the Change List screen: the mini-profile will appear when cursor hovers over the user's name or profile link.

Additional elements may be included in this tooltip, as there will only ever be two profiles loaded (current and previous diff).

The profile photo should be included at a larger size.

Option Two: In-Line Display
This option likely has a greater usability impact but will have a larger resistance to adoption.

In this option, the most relevant profile data is displayed directly on the page, in the "head" of the diff section. This should be smartly displayed.

Additional information may also be available but only shown with hovers (e.g., interests).

User Page Modifications
The User page will be modified so as to display the profile at the top of the page. The standard, "free-form", wikitext will remain; it will simply be displayed below the main profile.

The profile section displays all the structured data collected as well as other known (but public) metadata, such as:


 * Contribution Count
 * Account Creation Date
 * Block Status
 * Administrator Status

For maximum usability and user experience, all profile sections will have a standard layout.

Profile elements that are missing may or may not be displayed as empty, depending on needs.

Actions Box
The profile section will also include an "actions" box.

User testing has shown that inexperienced users are woefully ill-equipped to accomplish even simple tasks like viewing user contributions. Users have shown to not think deeply outside of the main viewing pane; they do not understand that the "chrome" navigation (like the toolbox) changes based upon context. They expect context changes about the data they are viewing to occur within the viewing pane.

Accordingly, we will add those actions within the viewing pane, tightly coupling them with the expected behavior.

The actions box will contain the following links:


 * View Contributions - goes to the user's contributions list
 * Show Appreciation - activates fires WikiLove
 * Email User
 * Leave a Message - activates a modal dialog that will leave a talk page message
 * View All Messages - goes to the user's talk page

In the future, a mechanism for flagging or reporting problem users may be included. This would automatically add a message to the administrator's notice board.

If a user is viewing thier own profile, the contents of the actions box will be modified thusly:


 * Your Contributions - goes to the user's contributions list
 * Your Sandbox - goes to the user's sandbox
 * Edit Profile - switches to "edit profile" mode
 * View Your Messages - goes to the user's talk page

Other links may be useful here as well (e.g., how to get help).

"Edit Profile" Mode
A user may edit his or her profile page by entering "edit profile" mode directly from the profile page. This will modify the screen so that individual elements may be edited, cleared, or deleted as need be.

Users with certain privileges (Admins, Crats, Oversighters and possibly Reviewers?, for example) will be allowed to edit any user's profile. Otherwise, edit permission is restricted to the profile's "owner". This would necessitate the creation of a "report concern" button so that other users could still alert admins when minors were releasing personal information, or when a userpage is created in order to attack someone of that name. We also need either to allow spam userpages or continue to enable other users to tag them for deletion (this is a policy issue so could change).