Live Chat System/Help

This page summarizes the current work toward designing a Live Help chat system for MediaWiki. Such a system is intended to allow users in distress one-click access to an experienced (hopefully re-assuring) wiki-denizen to help the user.

System summary
A "Live Help" widget is added in several strategic places across the Wiki. When clicked by a user (requester), the system tracks down an experienced editor to answer questions one-on-one (helper). The requester and helper would then be joined in a synchronous chat window where they could discuss the requester's issue synchronously.

Live Help Widget
The live help widget will be an entry point into the requester's side of the live help system. Depending on the location it appears, this widget may appear as a link, button or article section.

Placement
A link/button invitation to request live help should be placed strategically in order to maximize the likelihood that editors in need of help will see that help is immediately available.

Proposed locations
There are a few interface locations that seem to be likely candidates for capturing a requester's attention when they are ready to request help.
 * Account creation: The account creation wizards is a likely place for new users to need help.
 * Article creation: The article creation wizard is also a good place for asking help.
 * Rejection: New users are likely to be demotivated by having their work rejected . Live help could preserve their motivation to continue working by raising their probability of future success.  Rejection could come in the form of a revert coupled with a warning sent to a user's talk page.  A link to help could be included in such a warning.  Similarly, when a page that an editor recently created is nominated for deletion, there is a template included on the page (already with a button for refuting the proposal) and a template posted on the user's talk page.
 * First n edits: For the first $$n$$ edits of a user, Live Help widget should be prominently placed in the interface with the option of dismissing it.

Discovering good placements

 * Ask: Ask users where they got frustrated or confused when they started editing.
 * Usability testing: Watch a new users register an account and perform a task in Wikipedia. Note where they are when they get stuck.

Helper's Interface
In order to identify questions they'd like to participate in and engage in conversations with the requester, they'll need appropriate functionality added to their interface.

Their primary tasks will be:
 * Entering and exiting the pool of helpers
 * This might be expressed as turning the interface on and off.
 * It will be important that an editor can leave the pool of helpers without leaving their current chat.
 * Entering and exiting a single live help chatroom.
 * Helpers will need to be able to make decisions about which LiveHelp requests to attempt to fulfill.
 * Reporting troublemakers who create help requests in bad faith.

Request notification

 * Pool + OTRS - Help requests are sent to helpers who are currently in the available pool in a round-robin fashion. A helper will then be required to either accept the request or push the request back to the pool.
 * Pros
 * This push style interface could allow an editor to continue with their normal editing activities until they are notified about a help request.
 * Asker would be more likely to be immediately matched with a helper.
 * Cons
 * Does not allow a helper to identify those questions they are most interested in answering.
 * With a large amount of help requests and a small pool, an editor can expect to be constantly interrupted. (Note: An editor could specify a minimum delay between requests.)
 * Poll - Help requests would be listed in part of the UI and helpers will be expected to select requests to fulfill as they appear.
 * Pros
 * Helpers would be able to pick which questions they'd answer.
 * Cons
 * Requires helpers to be constantly monitoring a list that might be easy to ignore.
 * Helpers would not be able to continue with their regular activities while monitoring new help requests.
 * Pool + Push + Poll - Help requests would be listed in part of the UI and an (optional) ping + visual notification would occur for each new help request that is posted to notify all helpers. Helpers could then decide for themselves whether they'd like to accept the request or let someone else have it.
 * Pros
 * TODO
 * Cons
 * TODO

Merit
Previous work shows only a very small proportion of newcomers to Wikipedia who ask for help will do so effectively. By improving the visibility and usability of help systems in Wikipedia we should be able to dramatically improve the new user experience.

In addition to helping new editors understand how to use the Mediawiki software and work within Wikipedia policies, this feature will help experienced editors to understand newbies, integrate new editors into the community, and give article maintainers a way to help guarantee quality aside from policing edits.

Identifying helpers
An ideal implementation might look like this: An experienced editor sets a pref indicating their willingness to lend a hand. Presence information is maintained using the chat system, which is queried when help is requested. We offer the option of helping to 2-3 editors using a notification, and cancel the notification when someone answers. We start by querying a small number of users, and fan out to larger numbers as time goes on (perhaps even posting a link to an IRC channel). This balances finding help in a timely fashion against bothering too many editors with many help requests. Who to ask first could be chosen randomly, or using some sort of more intelligent heuristic.

If collaborative editing is available, the helper who answers the call gets pulled into the editing session. If it's not available, they get a one-on-one chat session.