Talk:Micro Design Improvements

Editing toolbar
There's a ton of stuff that needs to be cleaned up in the editing toolbar. I know the VEpocalypse will annul work on that to some extent, but just getting rid of all those terrible unreadable icons and only displaying "Help", "Cite", and "Advanced" would tremendously improve the usability of that tool for the time being. Maryana (WMF) (talk) 23:20, 17 August 2012 (UTC)
 * m:Help:Edit toolbar is a better link, there's a lot of en.wiki specific crap. --Nemo 10:56, 25 August 2012 (UTC)
 * And there is also the duplication of functionality of the Edittools mentioned on w:MediaWiki talk:Edittools/Archive 8 and commons:MediaWiki talk:Edittools. Helder 16:17, 25 August 2012 (UTC)

Annotations
This might be of interest: Helder 03:22, 22 August 2012 (UTC)
 * w:Wikipedia:Sticky notes
 * w:Wikipedia:Village pump (idea lab)/Archive 3
 * w:Wikipedia:Village pump (proposals)/Archive 76
 * etc...

Back to Beginning
Links of interest: Helder 03:27, 22 August 2012 (UTC)
 * w:Wikipedia:Back to top
 * w:Wikipedia talk:WikiProject User scripts/Scripts
 * w:fr:Special:PrefixIndex/MediaWiki:Gadget-FlecheHaut


 * Support in principle, if optional and not too intrusive. Use of tablet computers diminishes previous arguments about kb shortcuts. -- Trevj (talk) 09:58, 27 September 2012 (UTC)

Move to rename
Renaming "Move" to "Rename" has been proposed many, many times, and it never got consensus, and it probably isn't going to. --Yair rand (talk) 05:43, 22 August 2012 (UTC)
 * Maybe that was not accepted on English Wikipedia, but there are plenty of other wikis out there. Helder 23:57, 22 August 2012 (UTC)
 * What English-language wiki did you have in mind? It wouldn't make any sense on Wiktionary, and anyway the move function is barely ever used there. Wikibooks, maybe? The proposal doesn't seem likely to get consensus anywhere... --Yair rand (talk) 02:19, 28 August 2012 (UTC)
 * Sorry, I was thinking about other languages, actually. Helder 03:29, 28 August 2012 (UTC)
 * Oh, I figured you meant specifically changing those that use the English word "move". Do other languages typically use translations of "Move"? I figure they just choose whatever wording fits the concept. French Wikipedia uses "Renommer" already, so clearly not all wikis use translations of "move". --Yair rand (talk) 03:56, 28 August 2012 (UTC)
 * Just like not all languages use actual translations of "history". I can also imagine the opposite, for instance "rinominare" in Italian is rather long and in this meaning either wrong or quite recent and technical (it's a semantical calque from English, normal meaning is re-nominate alias re-elect), so the translators could stick to "sposta" (move) or invent something else. --Nemo 07:28, 28 August 2012 (UTC)


 * Yair rand: do you have links to previous discussions? I'm curious about the counter-arguments. --MZMcBride (talk) 02:35, 31 August 2012 (UTC)

Missing User Page Red Link
Redirecting feels icky. It seems that the best solution would be to simply not provide a user link across the wiki for users with non existent user pages. The red user link would be displayed as-is to the actual user, thus allowing them to learn about their user page and create it. Of course, for existing user pages the regular (blue) link would be shown for the username.


 * To restate: if a user page doesn't exist, then the user name (in, for example, a history page or on a talk page) should be text only (black), rather than a red link. I can see the advantage of this, since it's pretty much against the rules to create someone else's user page (the only rationale for providing a link in the first place). I do note that it's not clear whether the extra effort to make an exception for the user him/herself (to show the link in red) is really worthwhile in terms of extra coding/complexity versus likelihood of use. John Broughton (talk) 03:56, 5 September 2012 (UTC)

Low hanging
What's the definition of low hanging? "Edit Conflict Workflow", "Grouping for User Contributions" and "Annotations" seem quite hard. (Also the edit toolbar mentioned above was perhaps the main result of the Usability initiative which cost more than a million dollar, but I don't understand what change is being requested, so maybe it's cheaper than that.) --Nemo 11:46, 25 August 2012 (UTC)
 * At the moment we're just flinging ideas around: for now these should be considered "things which look small from a design and interaction perspective". We're going to run through and filter out the developmentally difficult stuff after we've finished this first test of the waters :). Okeyes (WMF) (talk) 07:12, 28 August 2012 (UTC)
 * Thank you. Makes sense, especially because only devs are actually able to tell us what's difficult and what's not. --Nemo 07:22, 28 August 2012 (UTC)
 * Agreed! So, ideally I'd like to see the team focus on things which are low cost in terms of development, fast to do and with a small community footprint in terms of backlash. The issue we've got at the moment is that the team is two weeks old :). We're still calibrating what is low cost, fast and has a small footprint, and while we'll exercise our best judgment I think it's going to be interesting to see what happens. We could underestimate or overestimate, and we'll adjust accordingly. But this will inevitably require developing something with a high development cost, slowly, that the community or loves, or something easy, fast and that the community doesn't. We are human and therefore fallible :). I think depending on the project that could be either a learning experience or a change that is justified despite the cost, but we'll see. Okeyes (WMF) (talk) 10:04, 28 August 2012 (UTC)

Suggestions for current project, "Improve the organization of information in the edit mode"
Moved from the "possible future iterations" section:


 * The in-page AJAXy "preview" and "show changes" tabs that are an optional part of WikiEditor are pretty sweet, though they might make more sense underneath the edit box (because they happen after your changes and before your save in the workflow). Jdforrester (WMF) (talk) 22:48, 28 August 2012 (UTC)
 * Agreed :). We're actually getting data on how/how often the buttons are used right now (it's a 120mb data file, compressed, oy) and should be able to make data-informed calls on this in a tick. Okeyes (WMF) (talk) 07:49, 29 August 2012 (UTC)
 * A count-down in the save message box to show how many characters are left (like the save dialogue in VisualEditor). Jdforrester (WMF) (talk) 22:48, 28 August 2012 (UTC)
 * That would be awesome. Okeyes (WMF) (talk) 07:49, 29 August 2012 (UTC)
 * Im assuming you mean a max character limit for Edit summary. Are we talking about introducing a limit here. Agree that it would be awsome. Vibhabamba (talk) 21:41, 30 August 2012 (UTC)
 * Moving the "Briefly describe the changes you have made" prompt into the save box as the default text, to disappear when people click into it. Jdforrester (WMF) (talk) 22:48, 28 August 2012 (UTC)
 * I've never used the first (is there an accesskey for it?) but the other two seem very good and uncontroversial: especially the edit summary, while the counter should be enabled for all summary/reason fields (beware, some socialnetwork-haters might complain that we're not Twitter blabla). --Nemo 07:29, 29 August 2012 (UTC)
 * That would certainly cut down on size. Excellent! Okeyes (WMF) (talk) 07:49, 29 August 2012 (UTC)
 * Agree, Oliver can we do this/ it seems logical. Vibhabamba (talk) 21:42, 30 August 2012 (UTC)


 * I added some more information about those interface elements. In general, my suggestion is, really, to check what our many projects have done with those messages, unless you're planning to do these changes on en.wiki only (it's not clear on the page): sometimes they are made worse, but sometimes there are also useful ideas (not necessarily on the biggest projects). Moreover, moving current messages in another location (reusing the current text) or replacing them (dropping the old text) is quite a drastic change, so be sure to notify well; adding a very brief notification, just with links to an explanation of the proposed changes and to the prototype, to the MediaWiki_talk: of all affected messages is a must. (Ideally, this would not replace an early effort on your own to check what has been done.)
 * MediaWiki:wikimedia-copyrightwarning and wikimedia-editpage-tos-summary are often heavily customised, sometimes blanked and often greatly expanded, so moving them above as is will often take a lot of space and throw a lot of ugly warnings in the face of the user. If you don't leave some system message below the save buttons for customisation, it's more likely for such warning to be made more prominent rather than to disappear.
 * Is this the text 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)? It's really strange that the legals found "If you did not write this yourself, it must be available under terms consistent with the Terms of Use, and you agree to follow any relevant licensing requirements" (ToS 7c) to be a duplicate of the other warnings (articles 7a-b), I suggest further investigation; the en.wiki local text is not very clear so it's not a good example to examine.
 * MediaWiki:Edithelppage: if you remove it, ensure the projects have some other message to customise with a link to the help page they feel most relevant. Other projects link more useful pages, for instance w:it:Wikipedia:Come scrivere una voce which includes a one minute video tutorial.
 * Nemo 07:29, 29 August 2012 (UTC)
 * So, I've removed some of the suggestions, I'm afraid :(. The "current projects" section is more an explanation for the outside world and a set of features specifications for our own use than it is an etherpad instance. We should've made that more clear (and I will do so) - the fault is on our end. I also need to clarify how we're planning on handling deployment :). Basically we're going to have it be a config setting; people will remain with whatever interface they have right now, unless and until we switch everyone over or people request it. But for the time being we're deliberately only going to hit enwiki. After that we can look into throwing it out to other projects when we've got a better idea of their current way of doing things. I'll make that point clearer too :). Okeyes (WMF) (talk) 07:54, 29 August 2012 (UTC)
 * No worry, I just moved the suggestions/questions to the message above; I only meant to add useful links so that people understand what that's about (screenshots are not that useful and they can show only a single site of course). Thanks, Nemo 08:05, 29 August 2012 (UTC)
 * Thanks for understanding! I felt awful removing someone's good work I do a lot of NPP on enwiki. The worst is the case of "I wrote an article about my recently-deceased grandfather and you are deleting it?!" Okeyes (WMF) (talk) 08:08, 29 August 2012 (UTC)

Statistics on button use
A small notice: I don't know how much this can affect data, but bewar that on some OS the accesskeys are broken now (Siebrand mentioned it), so people with those systems will probably be using the "show preview" and "show changes" buttons less. --Nemo 19:51, 29 August 2012 (UTC)


 * Do we have a list of which OS they're broken on? Steven Walling (WMF) &bull; talk   20:14, 29 August 2012 (UTC)
 * See 37099, 36329, 17689.
 * PS. Can has Lqt on this page? --siebrand (talk) 20:31, 29 August 2012 (UTC)
 * +1 for LQT. Helder 00:20, 30 August 2012 (UTC)

Edit Mode Comments
You know, my suggestion is that you start radical and pare back. For example, if you feel that the style of buttons (and their order) should be changed, include that in your design and include rationales for the changes. It is better to make changes all at once rather than incremental, since the change-control efforts will be smaller. On the flip-side, consensus gathering may be more difficult. However, in my experience, if the rationale for change is solid and backed (either by data or research), it is much easier to obtain consensus.

In short, go ahead and Agora-ify this.--Jorm (WMF) (talk) 03:27, 30 August 2012 (UTC)

What parts might we agorfy..? Emphasize the Save button with a blue color from the pallete ? Vibhabamba (talk) 22:25, 30 August 2012 (UTC)

Wonderful!
This page is great. The edit window changes in particular are desperately needed. I started a page about this at w:Wikipedia:Village pump (proposals)/Simplify the edit window, but never got very far with it (so many other things to do). The new version looks much better. Definitely some low-hanging fruit on the screen that can be safely chopped down.

I also looked at the "list of templates used" on the edit page (it's a real noise problem with any large article). It came up in relation to 38528, where I actually proposed moving the entire list out from action=edit, but that was poorly received. (Logically, I think, it's in the wrong place, but people get comfortable with a particular location.) Collapsing is one option. There are a few others. I meant to file a bug about the issue (I have notes about it... somewhere), but I haven't gotten around to it.

The English Wikipedia centrism of these proposals is a little less-than-wonderful, though I suppose some of these changes will propagate to other wikis, in theory. There's an old list at User:MZMcBride/Bugs of other low-hanging bugs, some of which are design-related. For example, category links are buried when previewing a page. And, of course, Bugzilla can always be mined for these ideas. A lot of these issues may already have associated bugs; if so, cross-referencing would be nice, just so the ideas don't get lost and can eventually get acted upon. --MZMcBride (talk) 02:21, 31 August 2012 (UTC)

Edit section links
This has come up a few times previously and I think Trevor and his team did some work on this, but there are design improvements that can be made to section edit links. A lot of people have wanted to move them or turn them into a pencil icon. --MZMcBride (talk) 03:08, 31 August 2012 (UTC)


 * MZ's correct here. This was originally slated (mockup) back in 2009 as part of the Usability Initiative, and while it wasn't rolled out in Vector, it was tested later on in 2011. I'm not sure if the results were shared publicly, but Karyn started to brainstorm a second iteration. I believe the short answer is that the results were marred by the fact that any spiffy new feature that is mass-delivered to readers and editors tends to get some kind of initial bump in use, just from being new. Steven Walling (WMF) &bull; talk   05:16, 31 August 2012 (UTC)

Mediawiki or English Wikipedia?
Many of the points listed here seem not to be about Mediawiki at all, and instead about changing English Wikipedia pages, in a way that could be done by any ENWP admin. What are they doing here, exactly? Removing ENWP's "edittools" is something that would be a community action. It requires no technical effort whatsoever. The community would discuss it at VPR and an admin would edit w:MediaWiki:Edittools to remove it, if there was consensus. Rather than throwing ENWP-specific ideas around here, why not just propose it at the Village Pump, if it's totally not a Mediawiki issue? --Yair rand (talk) 10:38, 4 September 2012 (UTC)

Show me if someone is editing this article
If an editor is editing just one section of an article (which is a best practice, in most cases, for anything but the shortest of articles), then there will be an edit conflict only if (a) another editor is editing the same section or (b) another editor is editing the entire article [not a best practice].

So the logic should be:


 * If editing a section: "show me if someone is editing the whole article, or the same section"
 * If editing the entire article: show me if someone is editing the article

John Broughton (talk) 04:03, 5 September 2012 (UTC)


 * This would be very complex to do with our current architecture. We've got something that may show this through the excellent real-time concurrent editing system that was built by a GSoC student to go alongside the VisualEditor work, but that will take a long time to deploy (as in, some time in 2013), but this probably isn't what you want to hear. :-( Jdforrester (WMF) (talk) 17:31, 5 September 2012 (UTC)
 * Akshully, there is code for this already that was written by Ian that we were going to use for a different project. It's just not been reviewed or committed to core.--Jorm (WMF) (talk) 20:29, 5 September 2012 (UTC)

Templates and hidden categories, file description pages
About putting templates and hidden categories in drop-down menus: I agree that this is generally a good change as they are not needed very often, but there is one important exception: file description pages. File descriptions contain many templates with relatively little other content, where seeing a list of templates (particularly copyright licenses) is useful. Is it possible to have option in preferences to convert the drop-downs to old-style lists in specified namespaces?

This is perhaps not very important currently, but if this change is included in Commons where language selections and other internationalization features use a large number of templates having a simple list of them is very useful. Commons also uses many hidden categories for files. MKFI (talk) 13:16, 6 September 2012 (UTC)
 * Are the file description templates visible in the "edit" window? This only takes effect there - the actual view of the "file" page and its description section will not change :). What we are thinking about is applying it to things like the "global file useage" section; take a look at w:File:Name.jpg, for example. Thoughts? Okeyes (WMF) (talk) 13:22, 6 September 2012 (UTC)
 * Yes, templates used are listed when editing file description pages. See commons:File:Laser_Towards_Milky_Ways_Centre.jpg (edit) and the 70+ templates and 14 hidden categories listed - picking them out from the list is much easier than finding all of them from page source. MKFI (talk) 13:36, 6 September 2012 (UTC)
 * Agreed; I'm not sure if it's worth coding something in to alter it by namespace, though :S. So, the system remembers whether you like them open or closed; if you're on commons, you can just open them once, and they'll remain open thereon in. Okeyes (WMF) (talk) 13:45, 6 September 2012 (UTC)
 * That would be perfect. MKFI (talk) 13:47, 6 September 2012 (UTC)
 * Great! Okeyes (WMF) (talk) 13:48, 6 September 2012 (UTC)

Apply MicroDesign on zh.wp
--Shizhao (talk) 13:01, 14 September 2012 (UTC)
 * Hopefully we will! :). We're hoping to roll the changes out everywhere, eventually. Can you let me know if there are any particular changes you'd like to see, even if they aren't listed here? Okeyes (WMF) (talk) 14:43, 17 September 2012 (UTC)


 * mediawiki:common.css add:

--Shizhao (talk) 09:10, 18 September 2012 (UTC)
 * Thanks :). Is there anything else you'd like us to do as well? Okeyes (WMF) (talk) 12:02, 18 September 2012 (UTC)

Helpful to save equal size preview snapshots of edit mode
It would be nice to have equal-window size snapshots of the pre- and post- changes for edit mode. Current the pre-change image has a huge window and makes it annoying to compare to the post- snapshot. Jason Quinn (talk) 13:00, 23 September 2012 (UTC)
 * Yeah, we're looking into how to handle changes :). What do you think of just displaying it as an article, rather than a diff, which changes highlighted? Okeyes (WMF) (talk) 14:13, 23 September 2012 (UTC)

Grouping for User Contributions -- privacy issues?
Grouping user contributions in topics may result in profiling, which might make some users uncomfortable. Of course, the information is publicly available from users' contributions, but having an algorithmic way to discover patterns in data may amount to what some people might consider an invasion of privacy. For instance, current edit counters in the toolserver have to abide to its privacy policy (the third paragraph deals with profiling). --Waldir (talk) 03:59, 27 September 2012 (UTC)
 * That's a fair point :). At the moment these are just random ideas off the top of our heads when we started working in this field; we're actually drafting up a new list now, which we plan to throw out here as soon as it's comprised of more than "so, Oliver had this idea, and..." or "so, Vibha had this idea, and...". Okeyes (WMF) (talk) 04:00, 27 September 2012 (UTC)


 * Oppose if implemented by default. While I don't personally have a problem with this, some users might and could be driven away or discouraged from signing up. It might be useful as an option, but a user should choose to enable it and be able to disable at will, without previous data still being presented. But what happens if a user enables it and subsequently changes their mind after losing their login details? -- Trevj (talk) 10:03, 27 September 2012 (UTC)

Email notifications making sense
If enotifwatchlistpages is changed to be true by default for new users, then such emails need to include a prominently placed link and instructions (at the top of the email) to disable the feature. Imagine someone (perhaps a previous IP editor) signs up, makes loads of edits and watches a stack of pages - with the intention of coming back to monitor things. Their inbox gets unnecessarily clogged and they can't find how to prevent the messages arriving! This is especially the case if "Add pages I edit to my watchlist" to set to true by default. I'd suggest asking new editors how they'd feel if this were to have been the case at the time they signed up. -- Trevj (talk) 09:48, 27 September 2012 (UTC)

Missing User Page Red Link

 * Support linking to the user's contributions page (like for unregistered users). Would it also be possible (and hanging low enough) to include a prominent note at the top of the Special:Contributions results along the lines of "User:John hasn't created his/her user page yet."? -- Trevj (talk) 09:52, 27 September 2012 (UTC)
 * To indicate why you're there? Seems sensible, at least as a temporary thing :). Ironholds (talk) 10:54, 27 September 2012 (UTC)