Micro Design Improvements

Micro Design Improvements is an Engineering project to target small design issues - the "low-hanging fruit" of MediaWiki - in a way that is fast, carries a low developer overhead and gives advance notice to the community (with an opportunity for comment). This page lists what we are currently working on; suggestions and comments should go on the talk page, along with any proposals for new things :). Bear in mind that the current list of proposals is very much "throwing stuff at the wall and seeing what sticks"; we will be filtering and prioritising them once we've finished our current project.

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..." (w: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.
 * 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.
 * 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 is 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.
 * 1) Removing the "edit tools" toolbar after "save page" (w:MediaWiki:Edittools).
 * Rationale: A lot of the functionality here is duplicated in the advanced editing toolbar, which has been enabled by default for accounts old and new for a long time. In addition, its current placement makes it of little use: people are only presented with it after they've made their changes.

Current status
At the moment, we have finalised the design, and Rob Moen is almost done making the technical tweaks needed for this to come into effect. Once he's done, we plan on deploying the changes to a server on Wikimedia Labs so that people who are interested in the project can see what it looks like and how it works - although in the meantime, feedback here is very much welcome :). If all goes to plan, we will then begin discussing the enhancement with the community and planning deployment times. Our current plan calls for it to be deployed exclusively to the English-language Wikipedia for the time being. This is because we're not yet sure of the impact it will have, and a lot of other projects have their own formats for the templates. We're going to hold off there until we can check that the changes won't cause any problems.

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".
 * Rationale: these are the actions that people primarily take. We are currently waiting to analyse data that Ori Livneh has gathered on what buttons are used the most (and how often that is) so we can see if there is room to rearrange them or potentially remove unnecessary ones.
 * Widening out the changes we've made to cover all users, not just people on Vector.
 * Rationale: Having inconsistent formatting and features between different skins (including skins we're willing to support) gives users an inconsistent interface, which is to be avoided. It's attractive to minimise the footprint of new features, because it also minimises the social cost of them if the reaction is negative, but I (Oliver) don't want us thinking within constraints. We should think big, idealistic thoughts, and then act within restraints. If the changes we're already making don't promote a torrent of ill will, we need to look into widening them out.
 * Widening them out to more than enwiki.
 * Rationale: Same as above, largely. An additional barrier is communicating with other projects; generally speaking, widening it out past vector would probably involve widening it out past enwiki.


 * From User:Kumioko on enwiki; "I had a suggestion for the edit window that I thougth about some time ago but never brought up. Would it be possible to create an edit window or something similar that would show the contents of the main page (as it does) and show the talk page below it? For myself and I believe others it would be greatly beneficial to be able to look at/modify them both from one central point rather than have to edit one and then the other. Maybe have something like a show Talk that expands (similar to the one for categories on the new example) or show Main if on a talk page. That way, the page doesn't have to take as much of a performance hit if you don't want to see them both. I would also say that the function should be opt in as maybe a gadget. Anyway just something I thought I would mention as a potential future improvement that would make things better."

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

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.

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