Micro Design Improvements

Group:	Features
Start:	2012-08-21
End:	2012-11
Team members:	Munaf Assaf, Vibha Bamba, Rob Moen, Benny Situ
Management:	Howie Fung, Oliver Keyes

Micro Design Improvements is a project to target small design issues - the "low-hanging fruit" of MediaWiki - in a way that we can optimize the first few touch-points for new editors, carries a low developer overhead and gives advance notice to the community (with an opportunity for comment). This is stuff that is critical to the user experience but may never be large enough to become a roadmap item on account of editor retention priorities. 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.

Current project: Improve the organization of information in the edit mode

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:

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.
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.
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.
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.
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.
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 (see talk pages on Wikipedia and Commons), 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! :)

Currently, User needs to read every label to discover the Save Action. Emphasizing the Save Action using the Agora Color Palette is critical in the near term: http://www.mediawiki.org/wiki/Wikimedia_Foundation_Design/Color_Usage
There is instrumentation that helps us understand what functions are heavily used and the Layouts + interactions must be optimized for this: http://meta.wikimedia.org/wiki/Research:Edit_form_clicktracking
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 thought 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."
If we're keeping "this is a [[link|minor edit]]" could we look into having a better tooltip or similar? Delinking here is good. Okeyes (WMF) (talk) 14:04, 8 October 2012 (UTC)[reply]

Postpone edit summary. The idea is to remove the edit summary initially. When the user saves, he receives a confirmation that the change was saved, indicating that the change has not description. The user can modify his and aids can be provided to use a previous message or apply the provided message to the last changes. Rationale: let the user achieve their goal quicker and then ask for metadata. Pginer (talk) 08:15, 23 October 2012 (UTC)[reply]

Proposed future projects

Watchlist Star Visibility

Make the watchlist star visible to logged out users, and show them a notification to login/sign up when they click on it. Users who go through the login/sign up workflow will have the article that they watched automatically added to their watchlist (or removed if the article was already on their watchlist).

Since mid-February 2013, this is the current workflow on the Wikimedia mobile web, and the result has been a steady growth in new accounts (about 800 new accounts registered globally per day), with most created via the watchlist star. (See: meta:MobileBetaWatchlist/Logging)

Help user with linking to new uploads

The Upload File page gives samples of how to write links to an upload. They are couched in terms of a mythical file called File.jpg etc. That's nice.

What would be a lot more valuable would be similar hints in the resulting File: page. That makes for a simpler workflow for the user. The hints could use the actual filename, enabling trivial cut-and-paste for link insertion.

Edit window changes

1. Emphasize Critical actions

Save needs to be an emphasized action when a user squints at the page
Preview needs to be less emphasized

2. Introduce Images for Terms of Service

Provide visual associations for the CC BY-SA Licenses for the copy
Move the Show Changes to a different place. [See Data: http://meta.wikimedia.org/wiki/Research:Edit_form_clicktracking ]
Remove the Add to watchlist action. [See Data: http://meta.wikimedia.org/wiki/Research:Edit_form_clicktracking ]

2. Improve the 'Show Preview' experience

There is evidence that Show Preview is a widely used function by new and advanced editors:
http://meta.wikimedia.org/wiki/Research:Edit_form_clicktracking

The following link carries a brief initial proposal to improve the preview user experience
http://commons.wikimedia.org/wiki/File:A_Simpler_Preview.pdf

Key Goals with improving Preview are:
1. Highlight the Preview so a user can actually see where they inserted content.
2. The Save Widget persists in place so a user does not have to scroll for it, it does not disappear below the fold.
3. An Easy Continue Editing Link is available at the top of the page.
4. Keyboard accelerators for previewing and continuing to edit.

Similarly the data reveals that Show Changes is used by an extremely small percentage of editors and needs to have lower visibility.
It need not be grouped with the other critical action i.e: Save/ Preview and Cancel Vbamba (talk) 08:01, 2 October 2012 (UTC)[reply]

3. Show me if someone is editing this article

Add a simple real-time notification that shows you if other people are editing this page. Brandon reports there's code already written for this by Ian that just needs reviewing and committing.

5. Long-term: Add wiki-characters to the edit toolbar's "special characters" section

The enhanced editing toolbar has a special characters section that doesn't actually include wiki-markup. It seems like it would be useful to add it there so that people don't have to persist on relying on the edit tools.

6. Fix up the edit toolbar special characters section

The special characters section kinda sucks overall. A few problems:

If I want to load a character set, the only way to do this is to load every single character set, which could include up to 15 I don't need. This is an unnecessary sucking-in of resources for our users.
Once I load all of the character sets I don't want (and the one I do want), I'm presented with the characters in a tiny window with a scroll-bar. This would be a much bigger window, but the section also provides another window (also with a scrollbar) that contains all of the other character sets I didn't want. This takes up a third of the space. So, to display the character set I want, we have a window, inside a window with a scrollbar, that contains within it two more windows, each with their own scrollbars, one of which displays something I actually want.

It seems more sensible to have something like the following; I hit "special characters", I'm presented with a dropdown that asks me to select which character set I want. When I select one, it loads that character set (and only that character set) without a big display of all the other ones I could be using. This means that we have more space for actual characters. Stuck in at the top right of the charset is a "back" button that'll close it and open the dropdown again. We provide the user with less unnecessary information, display what they want, and have more space to display that stuff in. This is me talking as a newb and non-designer, so Vibha, hack away at the idea as much as you want :). Okeyes (talk) 15:31, 25 September 2012 (UTC)[reply]

The list of symbols is not loaded on-demand. Examining the output it's included in the minified JS as an array of strings. This is a fairly efficient representation (might be a little more if it wasn't all \u encoded). And it's cached with the rest of the js. So loading shouldn't be a big problem.

But the UI definitely needs some work. You don't need to use it much, but you want to use it quickly. So being in such a small banner is absolutely horrible. There's no point eliminating the list of sets. It doesn't take up much room, and users inevitably rarely know what set they want so they are going to be flipping through multiple sets and a back button based interface will be horrible.

The problem is using a narrow banner like this. This should be a something more like a temporary popup bubble that goes overtop the edit window so it can take up more space and let you fetch your character quicker. Daniel Friesen (Dantman) (talk) 22:33, 2 October 2012 (UTC)[reply]

Also check with the i18n team on this one; there's an experimental on-screen keyboard in the Narayam extension (screenshot), enabled with $wgNarayamUseOSK=true. IMO there should be one solution for this, even if some selections are for common wikitext or symbols, not non-English characters.--Eloquence (talk) 22:57, 2 October 2012 (UTC)[reply]

Good feedback both :). Daniel, can you elucidate on "popup bubble"? A la the "filters" section in Page Curation, sort of thing? Okeyes (WMF) (talk) 14:03, 8 October 2012 (UTC)[reply]

Yeah those filters look like a good example. Except of course the character popup bubble would be much wider, a little taller, and styled differently. Daniel Friesen (Dantman) (talk) 18:00, 8 October 2012 (UTC)[reply]

7. Redesign Templates that appear in the Edit Views of a Page

Even with the de-cluttering of the edit window, there are a lot of templates that automatically appear at the top of articles.
These push critical actions below the fold, fill the space with We can replace them with more lightweight templates that consume less vertical real estate on the page. information, and are generally unfriendly. Particularly common ones are:

Sticky settings and preference changes

A new addition to MediaWiki (from what I know?) is the ability to have "hidden" preferences - settings that don't necessarily appear under your preferences menu, but can be triggered by user actions (and are remembered by MediaWiki). This means we can reduce preferences clutter while not actually reducing the number of ways a user can manipulate the software to suit them. Examples and preliminary implementations below.

Add sticky settings to the watchlist

A good example of sticky settings is the watchlist. Right now, you can manipulate how many changes are shown, how many days these changes cover, what sort of edits appear and so on via the watchlist itself - but any changes are also temporary. The only way to change them permanently is via Special:Preferences: you have to go away from the watchlist to make changes to the settings related to the watchlist.

My suggestion would be that we make the buttons on the watchlist itself make permanent changes, meaning we can dispense with the preferences section that covers watchlists.

Add sticky settings to Special:RecentChanges

Another illustration would be Special:RecentChanges, which has the same deal. Make those buttons sticky, dispense with the preferences section.

Redoing the edit toolbar

Some of the icons are counterintuitive, and the "special characters" section makes no sense:

It doesn't include any of the edittools.js wikimarkup;
It forces you to load every character set.

Working Special:Recentchanges

Just Make enhanced recentchanges the default, very easy.

See this.

Email notifications making sense

Two configuration changes:

Might also be a good idea to reformat how the messages are sent out. "MediaWiki mail" is clear as mud.

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, I'm 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 page title'.

Grouping for User Contributions

Note: there may be some privacy issues, see talk page.

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 user 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