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#Duplication of special characters and commons:MediaWiki talk:Edittools#Duplication of special characters. Helder 16:17, 25 August 2012 (UTC)

Annotations

This might be of interest:

• w:Wikipedia:Sticky notes
• w:Wikipedia:Village pump (idea lab)/Archive 3#Sticky Notes for Easier Editing
• w:Wikipedia:Village pump (proposals)/Archive 76#Sticky notes: contributing, for beginners
• etc...

Helder 03:22, 22 August 2012 (UTC)

Back to Beginning

Links of interest:

• w:Wikipedia:Back to top
• w:Wikipedia talk:WikiProject User scripts/Scripts#Could someone add this nice "back to top" script to the list?
• w:fr:Special:PrefixIndex/MediaWiki:Gadget-FlecheHaut

Helder 03:27, 22 August 2012 (UTC)

• 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) • talk 20:14, 29 August 2012 (UTC)

See bugzilla:37099, bugzilla:36329, gerrit: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)

id.wiki toolbar

id.wiki has perhaps the nastiest toolbar ever seen. It's possible that removing the edittools from edit view will backfire like that on more projects, just like removing the copyrightwarning made some projects move warnings in a more prominent place (tos-summary). --Nemo 12:15, 15 January 2013 (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 bugzilla: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)

Thanks for the links :). And, yeah, they're a bit enwiki centric :(. We do plan to productise them and roll them out everywhere, the "centric" bit is, of course, who we do outreach to. At the moment we're sort of limited in how/where we can go for feedback: sticking it on meta or mediawiki sort of ensures we don't get most people from anywhere. Sticking it on enwiki ensures we don't get most people from anywhere but enwiki. I'm hoping things like Echo can improve our avenues for asking for feedback. Okeyes (WMF) (talk) 14:07, 8 October 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) • talk 05:16, 31 August 2012 (UTC)

bugzilla:41729. --Nemo 12:15, 15 January 2013 (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)

We have discussed it on enwiki :). And, no, it does require technical effort: our rationale is the actions are duplicated, in many respects, in the enhanced editing toolbar. They are not in the outdated one. I can go to enwiki right now and use my admin account to remove it for everyone, sure, but doing something more granular is harder. Okeyes (WMF) (talk) 14:08, 8 October 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

A apply of 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:

div.editOptions {
    background: #F3F3F3; padding:10px;margin: 0 -2px 15px 0;border: solid silver; border-width:0 1px 1px 1px;
}

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

  Yeah; this should be taken as a "random ideas off the top of our heads", as said :). Okeyes (WMF) (talk) 14:05, 8 October 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)

There are already instructions. If they're not clear for you, it might be because en.wiki added lots of crap. Nemo 20:36, 8 December 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)

  So that users who are expecting to land on a user page understand why they're being taken to the contributions page instead. I also agree with the comment above about a redlink still being shown to the user in question. -- Trevj (talk) 23:37, 3 October 2012 (UTC)

Minor edit

This subject appears to have been previously discussed at the Village Pump, so please accept my apologies for any duplication. The en-wp edit page includes the following text next to the check box beneath the edit window:

This is a minor edit

The advice on that page (which appears not to be an official policy or guideline) expands on this and includes:

A minor edit is one that the editor believes requires no review and could never be the subject of a dispute.

I think it would helpful to have a concise summary included along with the link, when editing. How about something along the lines of the following?

This edit could never be the subject of a dispute and is minor

Maybe consensus should be sought on en-wp first. Would a new posting somewhere at w:WP:VP be appropriate? -- Trevj (talk) 23:54, 3 October 2012 (UTC)

That is pretty long. Steven Walling (WMF) • talk 03:52, 4 October 2012 (UTC)

What's pretty long, sorry? And, agreed, Trevj :). We'll see if we can work it in! Okeyes (WMF) (talk) 14:01, 8 October 2012 (UTC)

I agree that "This edit could never be the subject of a dispute and is minor" could probably be reworded more concisely. But IMO the current wording is too concise on its own. -- Trevj (talk) 07:39, 11 October 2012 (UTC)

This is an en.wiki-only issue, please discuss it there and ask only local changes. The other wikis have had enough. Thanks, Nemo 20:38, 8 December 2012 (UTC)

Show references when previewing a section edit

I know this is in bugzilla somewhere but thought it relevant to you - I've always wished that I could see how any footnotes I'm adding to an article will come out. I can do this by clicking "preview" but that only works when I'm editing the whole page. The problem is that when someone edits a section of a page, and presses preview, the footnotes/references section isn't displayed because that portion of the article doesn't contain the RefList template. I was wondering if you could force-display any footnotes in the preview screen for the section currently being edited. See what I mean?

On another note, I'm confused about the different scope of the "micro design" team as opposed to the "E3" team. It seems to be similar kinds of projects you're working on. Can you clarify? Wittylama (talk) 04:53, 4 October 2012 (UTC)

Micro design is just design updates that aren't a part of another project. They're also (mostly) done as part of 20% time by engineers and designers. E3 is a permanent team of 7ish people, and our experiments so far have focused more on delivering new features rather than fixing up stuff piecemeal. Steven Walling (WMF) • talk 20:06, 4 October 2012 (UTC)

Ok, I think I get it - although the scale and subject matter of the projects the two teams work on seem very similar :-) So, does my suggestion belong with the E3 team or the MDI team? Wittylama (talk)

That sounds like something for us :). We're planning on making a pass over the preview page, actually; I'll bear this idea in mind when we're reviewing that proposal :). Okeyes (WMF) (talk) 13:58, 8 October 2012 (UTC)

I would note that I see "fixing stuff up piecemeal" as pretty important, and I'm glad to get a chance to work on it. Platform, which maintains MediaWiki core, has zero designers, zero researchers, zero community liaisons. Product, which has all of those things, has a tendency to chase after "ooh, shiny!" which is, you know, nice, but we've got 10 years worth of code. We could keep working for another 5 on "ooh, shiny" projects and still have a load of outdated cruft that needs love. It's good to be able to inject a design and community perspective into the things we've got, rather than brand new replacements which should be done in Q3 of 2020 assuming that nothing between now and then gets pushed the tiniest bit off track. Okeyes (WMF) (talk) 14:00, 8 October 2012 (UTC)

Read tab

"Read" tab same with "Page" tab. "Read" tab can redesign, similar to readability or instapaper etc. Turns page into a clean view for reading--Shizhao (talk) 15:59, 9 October 2012 (UTC)

Could you explain a bit more? What you're describing sounds like a non-goal. The read tab was introduced because leaving the edit, history, etc... pages by clicking on the currently active namespace tab is unintuitive. Hence we now have a tab to switch back to the standard view/read mode. Daniel Friesen (Dantman) (talk) 21:13, 9 October 2012 (UTC)

Bug 3575 - Usability: Unify permalink and last modified, move print version there

Might be of interest. --Nemo 09:36, 3 November 2012 (UTC)

Thanks :). At the moment we're rather snaggled up on some Agora-related changes - but I'll add it to the wish list! Okeyes (WMF) (talk) 08:37, 6 November 2012 (UTC)

Work on templates

On the November Engineering report I read:

Several templates on the English-language Wikipedia have been redesigned to reduce interface clutter, with some already implemented.

How much effort (like, in work hours) has been put into this? Are there any reusable outcomes of this like template design and wording guide, reusable css styles or perhaps both in a standard package that can be translated and distributed to all Wikipedias, or even further? – Nikerabbit (talk) 20:43, 8 December 2012 (UTC)

I am also curious about this. More drastically than Nikerabbit, I think that WMF employees should never work on en.wiki templates or messages or pages directly like that, unless it's done in parallel on all wikis or on a good cross-section of them; localistic projects are suitable only for fellowships and the like.

This would also reduce surprises and wasted efforts, see e.g. discovering only after the fact that 205 wikis customised MediaWiki:Welcomecreation or that most wikis have already moved the "edit" links ages ago. The biggest resource of experimentation is in our 800 wikis' history.

But maybe Nikerabbit is right and there are things all wikis can learn from. --Nemo 20:51, 8 December 2012 (UTC)

Guys, remember that this project is essentially a 20% time project, aimed at doing design updates that would not normally be a part of a product anyone is working on. In other words: the point is not necessarily to build reusable products, but to fix critical but small parts of MediaWiki design that has an impact on users. Templates and messages that the team has edited so far are seen by many many users, and even if the changes are not universal yet, the design improvements are clearly A) able to be translated in some way, and B) the code and assets are reusable by other projects, since they have to be publicly available to work in English Wikipedia. Steven Walling (WMF) • talk 19:06, 10 December 2012 (UTC)

I think "Mediawiki design" might be being confused with "English Wikipedia design". Are these proposals being made as members of the community, or as WMF employees? Ordinarily, the WMF does not seize control of community pages, right? --Yair rand (talk) 21:05, 11 December 2012 (UTC)

Transpose page and subcategory sections of category pages

On the category pages the member subcategories are listed and are then followed by the member pages. It seems to me that the pages section should appear on top followed by the subcategories section. It is not that the pages are necessarily more important but it just seems to be, well "right". One benefit is that the eponymous article will appear at the top of the category page rather than buried way below the list of subcategories. This may be a minor coding issue (AFAIK) but there may be an outcry at Wikipedia.

While we are at it the "Pages in category "CATEGORY NAME" " need only be "Pages". The rest is redundant. Alan Liefting (talk) 22:40, 9 January 2013 (UTC)

Cancel

Is there any reason why "Cancel" is a normal link and not a button? I think it's because compatiblity reasons, but it doesn't look well. --Nightwish62 (talk) 20:51, 20 January 2013 (UTC)

bugzilla:40601 --MZMcBride (talk) 05:51, 23 January 2013 (UTC)

What are the plans for actually integrating individual improvements into core. There are various improvements live on en.wp that look like they are doing well. It would be really nice to see them in core replacing the ancient thrown together parts of MW. Daniel Friesen (Dantman) (talk) 00:38, 9 February 2013 (UTC)

Watchlist appearance

Some time ago the appearance of the watchlist on the English wiki has been changed (and fortunately not on the Dutch wiki). The difference between seen and unseen now only is a very small dot in colors very close to each other. I have to enlarge text too much to see the difference. Formerly unseen changes were bold. Please make that available again.WeiaR (talk) 12:03, 23 October 2015 (UTC)

That's a local modification, complain with the local sysops. Nemo 12:06, 23 October 2015 (UTC)