Micro Design Improvements

This is a list of some low hanging fruit that I would like to address via staff and community collaboration. UX improvements that are meant to fix areas where interactions dont make a lot of sense or user behavior is not well supported.

Status quo
There is a need to make the guidance and actions more cohesive and easy to understand when the user edits an article. At the moment:
 * Relevant instructions on how to make useful edits appear below the edit window and "save" action;
 * Guidance for the user is scattered and repetitive;
 * Formatting toolbars appear below the save action;
 * The infrequently-used "Templates" and "Categories" elements add a lot of visual noise and distract from a focussed editing experience.

Changes
The mockup to the right suggests how guidance and actions will be streamlined so they appear correctly in the workflow and intuitively support a user's mental model. Briefly summarised, the changes and the thinking behind them are:


 * 1) Moving what is currently the first line of text under the edit window "content that violates any copyrights..." (MediaWiki:wikimedia-copyrightwarning) above it.
 * Rationale: This line is primarily composed of guidance as to what sort of content is appropriate for Wikipedia. (Several projects moved such guidance here from MediaWiki:Edittools when this message was introduced after the license switch.) Having it below the edit window almost ensures that people will only read it after they have tried to make changes - it is of little use. On the other hand, if we move it above the edit window, we have an opportunity to educate people about what is or is not appropriate before they start writing.
 * 1) Removing the reference to a help page (MediaWiki:Edithelppage).
 * Rationale: At first glance, this might appear counterintuitive. The logic is that the advanced editing toolbar (which all new users are presented with by default) already includes a link to a "cheat sheet" of markup. The help page linked in the text, on the English Wikipedia, is a similar cheat sheet, creating duplication and taking up unnecessary space. Other projects link more useful pages, for instance w:it:Wikipedia:Come scrivere una voce which includes a one minute video tutorial.
 * 1) Removing half of the "if you do not want your writing..." line (MediaWiki:wikimedia-editpage-tos-summary) – that bit concerned with the Terms of Use – and moving the other half above the edit window.
 * Rationale: Again, the message (even the legal text) has been customised by the English Wikipedia and several projects added here information/warnings previous shown in the edittools; the advice will be of most use if it is shown to a user before they have contributed. At the moment, this text is not only after the edit window but also after the "save page" button – people may not even see it before submitting their changes. The text relating to the Terms of Use, which refers to the case that the user doesn't own the copyright on the content nor is copying a public domain resource, but rather a freely licensed one (such as another Wikimedia project), looks a duplication of the existing disclaimer, and one that Legal concludes serves no purpose.
 * 1) Moving the "by clicking Save Page..." text to below the edit summary window.
 * Rationale: The action is related most closely to "save page". Under the current workflow, someone is presented with it, then presented with unrelated options (edit summaries), and only then given the "save page" button. Moving it more closely ties the advice to the action it relates to.
 * 1) Putting the lists of templates and hidden categories under small drop-down menus.
 * Rationale: both elements have some use cases (for example, identifying subtle template vandalism), so we certainly don't want to remove them, but they're not much use for most editors: they just take up space and present users with a lot of text and links that serve (to them) no clear purpose. A nice middle ground is to stick them under dropdown menus: if they're wanted, they can easily be found – if not, they don't take up as much space.

Current status
At the moment, we have (almost) finalised the design and are awaiting internal feedback - external feedback via the talkpage is also very much welcome :). Once we've got a final specification, Rob Moen is planning on building it and deploying it on a test wiki so that people who are interested in the project can see what it looks like and how it works. If all goes to plan, we will then begin discussing the enhancement with the community and plan deployment times.

Future iterations
Here are some ideas for future enhancements in this field. Feel free to chip in with your own! :)


 * Moving the buttons around to enhance the prominence of "save page" and "cancel".

Working Special:Recentchanges
Just Make enhanced recentchanges the default, very easy.

Email notifications making sense
Two configuration changes:
 * Set "E-mail me when a page or file on my watchlist is changed" (enotifwatchlistpages) to true by default for new users
 * Set "Add pages I edit to my watchlist" to true by default (for users who didn't set it explicitly)

Special query pages
Users surely don't expect to be presented years-old results in the special pages they happen to see. Periodical run of currently disabled special pages is trivial and needs only some coordination between ops to decide how often and which.

Missing User Page Red Link
Red Link for a missing user page when a users name appears in the format John (Talk | Contribs) Should these take you to John's contributions page (like for unregistered users) instead of the missing user page? You really shouldn't be posting anything there unless you are John. Red links follow traditional behavior today, but does it make sense in this case given the user intention.

Back to Beginning
What are the reasons a back to top button has not been built, im sure it has been considered. Some Wikipedia articles are fairly dense and manually scrolling all the way to the top is fairly difficult. Although the Table of contents (hide show) helps, the problem of back to the beginning quickly still exists.

Change the word Move to Rename
Understand better what purpose Move serves and make it more intuitive. Its key usage is renaming an article. Propose changing tooltip to 'Change article title' (when in main namespace); or, in this wiki, 'Change title'.

Grouping for User Contributions
Currently there is no grouping to see what topics users have edited. This feels important for new users to have a sense of activity and contribution. This is also a core part of a user's identity.

Edit Conflict Workflow
Fix the Edit conflict workflow. Currently a use has no idea that someone else is editing this page and the edit conflict solution is confusing.

Show me if someone is editing this article
A simple real time notification that shows you if other people are editing this page.

Streamline edit templates

 * ''Note: en.wiki-specific

Any user editing while logged out is currently shown this message, which can dovetail with two or three more (a BLP warning message, a pagenotice, so on, so forth). The effect is to push the edit window itself a long way down the page. As part of streamlining edit mode, we should look at simplifying and cutting down templates such as this. I have spoken to Swalling and he has confirmed that doing so won't muck up the registration experiments E3 are performing. Okeyes (WMF) (talk) 19:19, 24 August 2012 (UTC)

Annotations
The editor workflow would be greatly improved by the ability to annotate articles while you're reading, and toggle annotations on/off. Permitted or encouraged annotations would be suggestions for how articles could be improved in a very specific context (e.g. by highlighting a sentence and suggesting that someone find a reference for it). This accomplishes several things, especially in a Visual Editor context:
 * It would let editors mark annotations and then resolve them, rather than having to recall the issues they wanted to fix
 * Readers would be encouraged to participate in the editing process on a basic level by providing annotations
 * Readers could be drawn into making basic edits if the annotations are clearly instructive