Support WMF communities in run-up to switching EditPage over to OOUI
Open, HighPublic8 Story Points

Description

The buttons underneath the wikitext editor (Publish changes, Show preview and Show changes) will change. They will fit in with the OOUI look that is replacing the old design for all of MediaWiki.

User typeBeforeAfter (still showing Save changes button label instead of Publish changes)
Logged-out
Logged-in

This change was made in MediaWiki in T111088, and is now ready for deployment to Wikimedia wikis.

How you can help

Related Objects

There are a very large number of changes, so older changes are hidden. Show Older Changes

Yeah, but in some cases it's not just that for example. This is resolved by this edit (adding a parent() to checkbox selector)

TerraCodes added a subscriber: TerraCodes.EditedMay 14 2017, 2:16 AM

Thank you very much for this information, Ladsgroup.

I'm looking at some of your changes, such as this on fawiki. For the most part, is it as simple as "anything using '#wpSummary' instead of 'input#wpSummary, #wpSummary > input' is going to break"? If so, we could run that in Tech News for a week or two before releasing this to any other wiki.

Ye, a this should probably be ran in the tech news. (its also going to break enwiki's defaultsummaries gadget)

We could get a shell user to do a mwgrep for wpSummary to identify affected scripts.

Johan added a comment.EditedMay 14 2017, 4:11 AM

Ye, a this should probably be ran in the tech news. (its also going to break enwiki's defaultsummaries gadget)

It was mentioned in 2017/18, which doesn't mean it can't be repeated with more detail/new information if necessary.

Ye, a this should probably be ran in the tech news. (its also going to break enwiki's defaultsummaries gadget)

It was mentioned in 2017/18, which doesn't mean it can't be repeated with more detail/new information if necessary.

Maybe just a little stronger warning that things could be broken after deploy.

We could get a shell user to do a mwgrep for wpSummary to identify affected scripts.

Just exclude wpSummaryLabel, this is a part of new look actually

Johan, I was thinking about either running a simple line in the next Tech News with information about how to identify and fix scripts (if it's really just a simple search-and-replace task). But if it's more complicated than can be communicated in two sentences, then I should probably start at page at mw.org with explanations.

@TTO, I agree with you that a list of affected scripts would be really useful. Tech News could include link to it.

Rather than changing countless uses, and also annoying downstream users and developers, why don't you let the input keep wpSummary id?
That seems a much nicer solution, instead of repurposing an id that has been used that way for nearly 12 years.

Rather than changing countless uses, and also annoying downstream users and developers, why don't you let the input keep wpSummary id?
That seems a much nicer solution, instead of repurposing an id that has been used that way for nearly 12 years.

It does seem like we should just do that.

I submitted a patch to change this (see T165854: Change OOUI EditPage inputs to keep the old 'id' attributes on the <input> elements). I hope you haven't updated too many gadgets that will need to be fixed again :( (The ones that used $( 'input#wpSummary, #wpSummary > input' ) etc. should work fine with the proposed HTML too, no further changes needed.)

Old HTML:

<input ... id="wpSummary" name="wpSummary">

Current OOUI HTML:

<div id="wpSummary" ... class="... oo-ui-textInputWidget ...">
	<input ... id="ooui-123" name="wpSummary" class="oo-ui-inputWidget-input">
	...
</div>

Proposed OOUI HTML:

<div id="wpSummaryWidget" ... class="... oo-ui-textInputWidget ...">
	<input ... id="wpSummary" name="wpSummary" class="oo-ui-inputWidget-input">
	...
</div>

This has been delayed a bit because of the unfortunate difficulties with the deployment train, but that may be resolved soon. Therefore, we might be able to make some progress on this next week.

I don't really want to do all the wikis at once, because this requires a changes to some older scripts, and tech-savvy editors are a precious commodity (and might even be thinking about summer holidays, now that it's June). @tarlocesilion and @matmarex : Assuming that this latest patch improves matters/doesn't break anything else at fawiki, I'd like to test this change at plwiki next. If all goes well, then we could approach the bigger wikis (as originally planned) after that. Do you have any objections to my plan?

It's not my decision to make. But I can be available to respond to questions, fix up gadgets, and so on.

@Whatamidoing-WMF Can we create a short help page on Meta about this change, that we could link to when announcing the change or when editing gadgets with corrections, and where Phabricator-averse users could comment on a talk page? Something similar to https://meta.wikimedia.org/wiki/Change_to_section_edit_links from back in the day.

Hmm, I see now that https://www.mediawiki.org/wiki/OOjs_UI/Fixing_scripts_and_gadgets seems to be the help page. It's actually nicely written, but I don't like how it's framed as part of the main OOjs UI documentation – this is really only for this one-time change to the edit page buttons, and is unlikely to be still relevant in a year or two except for historical reasons. I think we should rename it to something more specific, and remove it from the OOjs UI navbox – I'll do some editing if you don't mind?

TheDJ added a subscriber: TheDJ.EditedJun 9 2017, 12:49 PM

@matmarex I think we should do these kinds of things in a style similar to how we do Incident documentation (templated, chronological, single spot).

I know this might be time-consuming, but please consider expanding the section 'Why'. Users should understand the reasons not only for this small change, but for the direction of changes as well. They should understand your motivation. Lately, I've been receiving some extremely negative feedback on this. The problem isn't mainly about the color or shape (experienced users have been editing despite of our UX), but about a lack of user-friendly explanation for any related change.

Therefore: please use simple, straightforward words, no hashtag-like expert terms. Give details. Don't assume that people skilled at writing encyclopedias know IT. Attention, I'm going to act like a devil's advocate:

  • Accessibility - how this helps us to be more accessible? can blind people see big blue buttons better? does this make our devices faster?
  • Internal consistency of the user experience - what does 'user experience' mean? why should we care? why can't it stay inconsistent? who benefits from that?
  • Code development and maintenance - is the current one difficult? how much? for whom? why should we care? why can't it stay as it is?
  • What is OOjs UI? why do we need this? why does an encyclopedia/a dictionary/etc. need this?

When the answers are published, your decisions will be defendable more easily and effectively, and you'll avoid another bad reception.

I hope it's helpful :)

It's a wiki, and you are all welcome to improve the page. The worst-case scenario is that I'll revert you. ;-)

@matmarex if you don't like the location of the page, then you should feel free to move it. I'd prefer that it stayed at mw.org (rather than Meta), since it's fundamentally a technical project. You might consider using a naming convention similar to https://www.mediawiki.org/wiki/Contributors/Projects/Columns_for_references (as one option).

Thank you, but I don't know the answers to many of those questions. :) I might guess, interpret, post sth on a personal blog, but I'm not competent to write anything on the behalf of the Prod... Audiences department. I'm a Wikipedian and I can help to communicate your answers to the communities.

Note, it isn't a personal request to Whatamidoing. The answers can be published by anyone professional/competent (maybe also responsible).

TheDJ added a comment.EditedJun 12 2017, 8:15 PM

I think we forgot to test this in monobook...


There is a significant margin-top on those inline checkboxes for some reason.

Screenshot of mediawiki.org btw.

I definitely didn't forget to test it on MonoBook. That must be a new issue. I'll look into it later.

Change 359514 had a related patch set uploaded (by Jforrester; owner: Jforrester):
[operations/mediawiki-config@master] Enable OOjs UI buttons on EditPage for plwiki

https://gerrit.wikimedia.org/r/359514

Change 359514 merged by jenkins-bot:
[operations/mediawiki-config@master] Enable OOjs UI buttons on EditPage for plwiki

https://gerrit.wikimedia.org/r/359514

Mentioned in SAL (#wikimedia-operations) [2017-06-19T13:21:08Z] <hashar@tin> Synchronized wmf-config/InitialiseSettings.php: Enable OOjs UI buttons on EditPage for plwiki - T162849 (duration: 00m 42s)

Change 360370 had a related patch set uploaded (by Jforrester; owner: Jforrester):
[operations/mediawiki-config@master] Enable OOjs UI EditPage buttons on es/fr/it/ja/ru-wiki

https://gerrit.wikimedia.org/r/360370

Change 360371 had a related patch set uploaded (by Jforrester; owner: Jforrester):
[operations/mediawiki-config@master] Enable OOjs UI EditPage buttons on all Wikipedias

https://gerrit.wikimedia.org/r/360371

The deployment to the Polish Wikipedia found some small-ish bugs, but it seems to have mostly gone smoothly so far. (I speak under correction.)

Next up are the French, Spanish, Japanese, Russian, and Italian Wikipedias and Meta, which I've scheduled for Wednesday, 5 July 2017. The Portuguese Wikipedia (and/or any other site) is welcome to volunteer for this first group.

Change 360370 merged by jenkins-bot:
[operations/mediawiki-config@master] Enable OOjs UI EditPage buttons on es/fr/it/ja/ru-wiki and meta

https://gerrit.wikimedia.org/r/360370

stjn added a subscriber: stjn.Wed, Jul 5, 9:12 PM

Right of the bat: red "Cancel" draws too much attention, OOjs UI really should’ve not change the default behaviour of quiet buttons (mw-ui-quiet) from original MediaWiki UI where they were blue/green/red only on hover. I think this is a very major flaw of new design. It was not noticeable when this feature was available only via URL parameter, but it is more prominent issue now.

See the discussion starting from here, T111088#3023190 TLDR: It's a UX decision to make people aware that this button exist (and it's useful to them)

stjn added a comment.Wed, Jul 5, 9:41 PM

See the discussion starting from here, T111088#3023190 TLDR: It's a UX decision to make people aware that this button exist (and it's useful to them)

Well, this is disappointing. It looks like a red link (which is a big ‘no’ against any red quiet buttons) and it draws too much attention to the element which is not the most useful in the form. This should've been somehow evaluated before the deploy, IMO.

Od1n added a subscriber: Od1n.EditedWed, Jul 5, 10:28 PM

Just to point out the new summary input sometimes feels really laggy on my gipsy computer.

Have you noticed how many callbacks there are on this input??

It looks like a red link (which is a big ‘no’ against any red quiet buttons)

Agreed. You can reopen T165122 and add your comments there.

stjn added a comment.EditedThu, Jul 6, 6:22 PM

Another annoying regression after converting to OOjs UI: selected suggestions for ‘Preview page with this template/module’ can’t be autocompleted by going through the list, although in previous version this worked absolutely fine. Maybe we can at least disable it for TemplateSandbox gadget until this is fully resolved?

Edit: sorry for misinforming.

Whatamidoing-WMF raised the priority of this task from Normal to High.Mon, Jul 10, 6:08 PM
Restricted Application added a subscriber: Dereckson. · View Herald TranscriptMon, Jul 10, 6:08 PM

Under Monobook still no progress...

  • no OOjs UI "accessible" styling of inputs (standard tiny checkboxes)
  • strange bathroom-green gradient publish button, inconsistent with blue-gray skin visual
  • large vertical indent between summary and checkboxes

(2017-07-11 snapshot from enwiki using &ooui=1&useskin=monobook flags)

Any plans to make the look&feel more consistent between Monobook and Vector?

Od1n removed a subscriber: Od1n.Tue, Jul 11, 8:18 PM

Text above edit summary on cswiki (Czech Wikipedia) is wrapped unnecessarily. Compare following screenshots:

oldnew

@Teslaton, I can't reproduce the gap between the edit summary and the tick boxes. (MonoBook is not meant to look like Vector.)

@Dvorapa, I can't reproduce that. Would you please check and see whether it's been fixed for you?

@Whatamidoing-WMF No, it is still wrapped.

Screen resolution: 1366x768; maximized window size: 1299x741; OS: Linux; DE: Gnome

Dvorapa, would you check to make sure that it's wrapping for you in a private/logged-out/incognito window? (Anyone else who's checking: You have to check this at cswiki, with &uselang=cs, because there's a lengthy custom message there instead of the regular label.)

@Whatamidoing-WMF I don't expect them to look the same. What I do expect, is that the accessibility aspects (sizes and contrasts of relevant widgets, in this case) would get improved in the same way, regardless of a skin. Otherwise, there is no real benefit of change like this for non-vector users.

The gap seems to be reduced by ~16px in the current release (enwiki). Indents are still a bit larger than in ooui=0 mode, but that may be intentional.
https://en.wikipedia.org/w/index.php?title=User:Teslaton/Test&action=edit&ooui=0&useskin=monobook
https://en.wikipedia.org/w/index.php?title=User:Teslaton/Test&action=edit&ooui=1&useskin=monobook

@Whatamidoing-WMF I don't expect them to look the same. What I do expect, is that the accessibility aspects (sizes and contrasts of relevant widgets, in this case) would get improved in the same way, regardless of a skin. Otherwise, there is no real benefit of change like this for non-vector users.

Yes, you're right, the interface for Monobook does not have many of the accessibility improvements we're bringing to users. This is intentional prioritisation for the billion users of Vector (as the default skin on Wikimedia wikis) against the thousands of users of Monobook (which isn't). We will continue to address accessibility issues for all users, including for Monobook users, but there is less benefit for you right now, I agree.

Not logged in, private browser window:

This looks like the fundamental sizing bug in Linux's font manager that we keep having users run into (where fonts are rendered ~10%+ larger in some distros Linux than Windows/Mac/Android/iOS), but I'm not sure why it's triggering in one mode and not the other.

This is intentional prioritisation for the billion users of Vector (as the default skin on Wikimedia wikis) against the thousands of users of Monobook (which isn't).

I can understand the reasoning, but I don't see the significance of Monobook to be that marginal:

  1. according to https://en.wikipedia.org/wiki/Wikipedia:Database_reports/User_preferences#Skin (2015), Monobook usage was quite far from "thousands" (2,182,546 is 22% of the total of 9,865,515, although there's no details of the metric used).
  2. Wikipedia "power users" seem to be quite biased towards using (or keeping use of) Monobook. On our wiki (skwiki), as far as I know from discussions, the majority of long-term active editors still do prefer Monobook. The following statistics is from 2013, but the preference of Monobook among power users was >60% at the time: https://meta.wikimedia.org/wiki/Turning_off_outdated_skins/stats#Global_skin_usage
stjn added a comment.Tue, Jul 18, 6:57 PM

I can understand the reasoning, but I don't see the significance of Monobook to be that marginal:
...

Well, it still is not part of the same task since IIRC Monobook uses a different theme for UI elements (Apex) and it is not fully compatible with OOUI. The reasonable thing to do is to drop Apex theme in favour of OOUI for all skins, but it probably requires global changes that go beyond the scale of this particular improvement (and this task).

Change 360371 merged by jenkins-bot:
[operations/mediawiki-config@master] Enable OOjs UI EditPage buttons on all Wikipedias

https://gerrit.wikimedia.org/r/360371

Mentioned in SAL (#wikimedia-operations) [2017-07-18T23:22:27Z] <thcipriani@tin> Synchronized wmf-config/InitialiseSettings.php: SWAT: [[gerrit:360371|Enable OOjs UI EditPage buttons on all Wikipedias]] T162849 (duration: 00m 47s)

Od1n added a comment.Sat, Jul 22, 4:54 PM

What a coincidence, I was just about to report the exact same issue for French Wikipedia.

It's present since the beginning of the switch to OOui, and indeed it is caused by this max-width:50em CSS.
Although the issue is cosmetic, it should be fixed as it is an unexpectedly inherited property.

@Od1n, what's your browser/OS?

Od1n added a comment.Wed, Jul 26, 6:57 PM

An override rule such as #wpSummaryLabel .oo-ui-fieldLayout-header { max-width: none; } should be added.

Od1n removed a subscriber: Od1n.Wed, Jul 26, 6:57 PM

If you're talking about the width of the edit summary field, that has not significantly changed (a few pixels) – it's been 80% width for a while now, but I agree that it should take the full width instead. However, this isn't the right venue for that discussion, as it's unrelated.

@Jdforrester-WMF We are talking about the width of its label, which is even shorter than the summary field and it looks broken on cswiki and frwiki (at least)

@Jdforrester-WMF We are talking about the width of its label, which is even shorter than the summary field and it looks broken on cswiki and frwiki (at least)

Example links and screenshot:

Screenshot (before and after) confirming that turning off that CSS rule does fix it: