Convert EditPage.php to use OOUI rather than MW UI
Open, NormalPublic

Description

TypeBeforeAfter
Anonymous editing
User editing

Change 231600 had a related patch set uploaded (by Florianschmidtwelzow):
Convert EditPage buttons and summary input to OOUI

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

Specifically, I think we should do T30856 (and not ship it with the MediaWiki core tarball) in favour of re-writing it in OOUI, which I think would be mis-spent effort.

He7d3r added a subscriber: He7d3r.Oct 27 2015, 9:07 PM

Specifically, I think we should do T30856 (and not ship it with the MediaWiki core tarball) in favour of re-writing it in OOUI, which I think would be mis-spent effort.

Hmm, I'm a bit confused. The linked task mentions the toolbar, only, not the whole "editor". If I understand your comment right, you mean, that the source editor should be separated from EditPage.php into something like a PlugableEditor and that extensions can provide an additional "editor" using a new interface? A wiki sysadmin could set one of the installed source editors as default by a configuration variable. Is that what you mean? If so, I think, that the linked task doesn't cover that :)

Change 231600 abandoned by Florianschmidtwelzow:
Convert EditPage buttons and summary input to OOUI

Reason:
Not sure, if this will be merged, and not working on it, currecntly (see the task). Can be re-opened later.

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

Change 231600 restored by Jforrester:
Convert EditPage buttons and summary input to OOUI

Reason:
No, let's work on this.

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

Specifically, I think we should do T30856 (and not ship it with the MediaWiki core tarball) in favour of re-writing it in OOUI, which I think would be mis-spent effort.

Hmm, I'm a bit confused. The linked task mentions the toolbar, only, not the whole "editor". If I understand your comment right, you mean, that the source editor should be separated from EditPage.php into something like a PlugableEditor and that extensions can provide an additional "editor" using a new interface? A wiki sysadmin could set one of the installed source editors as default by a configuration variable. Is that what you mean? If so, I think, that the linked task doesn't cover that :)

Yeah, that's fair. Sorry for the imprecision. T30856: Move classic edit toolbar into an extension is about just getting the core 'EditToolbar' out of core, but not the UI of EditPage.php itself (and the related issues like the save buttons, checkboxen, etc.).

My more general desire is indeed the PlugableEditor concept; I've created T120414: RFC: MediaWiki should provide a pluggable registry for editor interfaces for this.

Ok, it seems we (mainly me :P) misunderstood each other :) So let's continue the work on the change!

Btw.: I like the idea of a pluggable editor, I already thought about that and a "big picture" :)

Urbanecm removed a subscriber: Urbanecm.Jan 15 2016, 7:04 PM

Isn't a change in T110555 colision with this? On testwiki this was a preview three months ago:


and now? What color (button class) of Save button will be there in order to make it different from remaining two if green is not supported anymore?

Isn't a change in T110555 colision with this? On testwiki this was a preview three months ago:


and now? What color (button class) of Save button will be there in order to make it different from remaining two if green is not supported anymore?

It'll be blue in the MediaWiki theme.

Zppix moved this task from Unsorted to Working on on the Editing-Department board.Apr 26 2016, 2:34 PM
Tpt added a subscriber: Tpt.May 26 2016, 8:12 PM
Ladsgroup edited the task description. (Show Details)Feb 11 2017, 2:21 PM

One important (missing) thing from a user experience perspective would be to use frameless ButtonWidgets for the “Cancel”/“Editing help“ links.
When dealing with mobile viewports it's easier to make them adapt and they also shouldn't be in text color.

matmarex added a comment.EditedFeb 13 2017, 9:31 PM

Looking at the screenshots only – the "Editing help" link is a link, not a button. It just links to the page with help about editing – it does not perform any action, like buttons do. It should remain a regular, blue link. (Slightly related: T156885)

Yes, @matmarex thanks for pointing this out. My shared concern was mostly about sudden change to text color and Cancel. Agreed, “Editing help” should be a link.

Quiddity added a subscriber: Quiddity.EditedFeb 14 2017, 12:57 AM

+1 to "Editing help" being normal linked blue text.

"Cancel" should either be a quiet-destructive button (per https://doc.wikimedia.org/oojs-ui/master/demos/#widgets-mediawiki-ltr-desktop ) or just normal linked blue text. Black-text should almost never be a link - that just makes all black-text into potential links, which confuses everyone.

I'd encourage making "Preview" into a quiet-progressive button, as "preview before saving" is a really good habit (a best-practice) for all editors.

Elitre added a subscriber: Elitre.Feb 14 2017, 1:05 PM

Screenshot of @Quiddity's changes:

Now
After

We'd still have a black button, but it clearly looks like a button.

What do you think of making "Cancel" button a framed button?

@Ladsgroup I'd not recommend to make “Cancel” a framed button, there's already too much going on.
Two options are somewhat seen critical at the end of a form as general UX approach, here we would end up with four buttons side-by-side.

I'm also strongly against turning “Show preview” into a quiet-progressive button. If that element is so important, we have to think about other ways to emphasize this. From a UX guideline standpoint, there should be at max one primary button per view to guide user focus, here “Save changes”.
The quiet-progressive buttons have been invented for places, where there is not one primary action, like in the edit dialog


but several similar-weighted actions instead.
Mixing the primary progressive button with the quiet-progressive button is not a good idea from a pattern perspective.

Dvorapa added a comment.EditedFeb 16 2017, 8:34 PM

In my opinion if you turn "Show preview" button into a quiet-progressive form, the aggrieved one would be the "Show changes" button, because it becomes less distinct and noticeable.

Similar problem I see in the cancel link/button, because without frame, it is just insignificant and users just don't even notice there is some fourth button/link for cancelling. I'd like to share gadget on cswiki:


As you can see, the effect of primary action is marked by a striking green button, the opposite action to primary is marked by a striking red cancel button and the other two buttons between are marked by less striking blue button and both the same, in order not to stand out among primary ones. Yes, the whole look is a little bit over-coloured, but the concept is clear, simple and user-friendly. I would suggest something like this:


It could be quiet-proggressive or normal, but both the same, not one quiet-proggressive and second one normal.

PS: Sorry for Czech labels, I just used that gadget on cswiki and changed colours in Chrome devtools...

@Dvorapa Where do you get that from:

users just don't even notice there is some fourth button/link for cancelling

@Volker_E I haven't got any statistics, but I can say my experience. I edit Wikipedia pages since cca 2009 (as registered since 2011), and I noticed there is a cancel link in November 2015 (when I discovered OOJS UI and created the gadget shown above). I think the button must be there since current wikitext editor (when was it deployed to Wikipedias?). Maybe some event logging/longage statistics/user testing would say, if I'm the only one exception or if it is more general problem (e.g. in comparison to watch checkbox, which is I think the second rarely used element there, yet still important).

Maybe some event logging/longage statistics/user testing for some possibilities of an appearance of these four links/buttons would help to decide, which possiblities to consider most.

Do we even need a Cancel button?

IMHO, we don't. I would get rid of it.

Quiddity added a comment.EditedFeb 17 2017, 12:35 AM

Do we even need a Cancel button?

IMHO, we don't. I would get rid of it.

I use the Cancel link/button, with some regularity. It's the fastest way to reload the page, into view-mode - the main alternative is scrolling to the top of the window, and clicking the page-tab.

In most circumstances, users can also hypothetically click the browser back-button, but that's less intuitive to non-technical folks who just want to 'cancel' their edit (whether it's an article edit or a new comment they've reconsidered).
[edit: It also doesn't work if I used the preview button at all, which makes the back-button work differently]
It also doesn't work if we used a non-generic method to access the edit page, e.g. via Navigationpopups, or an E:Inputbox link.

In my opinion if you turn "Show preview" button into a quiet-progressive form, the aggrieved one would be the "Show changes" button, because it becomes less distinct and noticeable.

I would suggest that having the 2 buttons in different colors would inspire some new-user-curiosity, versus having them be a matching pair.

Similar problem I see in the cancel link/button, because without frame, it is just insignificant and users just don't even notice there is some fourth button/link for cancelling. I'd like to share gadget on cswiki:

It currently has just plain blue text, which does make it blend in. I think the red text will help make it noticeable to the few people who want that function.
I think making it a full button would emphasize it too much. Especially since colors still have different meanings in different cultures (despite the negative effects of globalization, and standardizing effects of traffic lights!).

I'm also strongly against turning “Show preview” into a quiet-progressive button. If that element is so important, we have to think about other ways to emphasize this. From a UX guideline standpoint, there should be at max one primary button per view to guide user focus, here “Save changes”.

Ok. I do encourage that thinking, then. :-)
I use the Preview button an average of a bit over once per edit, and encourage everyone I mentor to do the same. The preview button is your friend!

Do we even need a Cancel button?

IMHO, we don't. I would get rid of it.

What do you want people to use? Back button or closing the tab? Be aware that users get confused by these.

Rebased and added the suggestions:

I'm also strongly against turning “Show preview” into a quiet-progressive button. If that element is so important, we have to think about other ways to emphasize this. From a UX guideline standpoint, there should be at max one primary button per view to guide user focus, here “Save changes”.

The Chinese Wikipedia uses a different way to emphasize the "Show preview" button: The "Save" button is grayed-out and inoperable until you've previewed your changes. Given their dual-script situation, forcing users to preview the page probably saves them a lot of grief.

Why do I see html as text when I check out the latest patchset?

Rebased and added the suggestions:

Compared to this old screenshot:

(task description)

The buttons now have the same background color as the surrounding area, and they don't stand out much. This is probably caused by rMW3e84bc55f62b: Align editOptions section with WikimediaUI color palette.

Made it a little bit darker and fixed some other stuff:

When will this happen?

When the patch gets merged and deployed. Hopefully in a foreseeable future.

Florian reassigned this task from Florian to Ladsgroup.Wed, Mar 8, 5:33 PM
Restricted Application added a project: User-Ladsgroup. · View Herald TranscriptWed, Mar 8, 5:33 PM

@Ladsgroup Several minor nitpicks:

  • The “Watch this page” checkbox is too close on the “This is a minor edit“ label. I'd recommend a margin-right on latter
  • The containing box should have a border-radius: 0 0 2px 2px as well
  • With cancel becoming a quiet destructive button the padding of Cancel to the pipe should be the same on Editing help's left side
  • Editing help is vertically off due to the different font-weight and line-height in comparison to Cancel

I'm not the biggest fan of using Base80 (#eaecf0) for the edit options background, but I understand the issue with the normal buttons contrast and I think it's good to go with for now. (I'll post this on the patch as well)

Ladsgroup moved this task from Incoming to In progress on the User-Ladsgroup board.Thu, Mar 9, 9:57 PM

I am requesting that this change not happen until https://meta.wikimedia.org/wiki/Tech/Server_switch_2017 is over (regular deployment train should resume on Tuesday, 9 May 2017).

I am requesting that this change not happen until https://meta.wikimedia.org/wiki/Tech/Server_switch_2017 is over (regular deployment train should resume on Tuesday, 9 May 2017).

Since now it's using a config variable, I think we won't enable it until the switchover is done but I hope this gets merged really soon. I'm tired of constant rebasing.