Page MenuHomePhabricator

Convert Special:MovePage to OOUI-based form
Closed, ResolvedPublic

Description

Let's convert Special:MovePage to OOUI-based form. That will make for a very pretty usage example and will not be very painful.

Related Objects

Event Timeline

There are a very large number of changes, so older changes are hidden. Show Older Changes
matmarex raised the priority of this task from to High.Jan 15 2015, 12:43 AM
matmarex added subscribers: Jdforrester-WMF, matmarex.
Restricted Application added a subscriber: Aklapper. · View Herald TranscriptJan 15 2015, 12:43 AM
matmarex claimed this task.Jan 15 2015, 1:32 AM
gerritbot added a subscriber: gerritbot.

Change 185591 had a related patch set uploaded (by Bartosz Dziewoński):
[WIP] SpecialMovepage: Convert form to use OOUI controls

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

Patch-For-Review

matmarex set Security to None.
matmarex added a subscriber: TrevorParscal.

So I tried to do this and here's how it currently looks:

BeforeAfter

And in context of the whole special page:

BeforeAfter

Not bad, but I don't quite like it. I think there's a bit too much whitespace here, inside and outside the fields. There's nothing to bring the form together like the blue frame did, too. The form fields design needs a bit of a revision.

(Note that the dropdown field is not fully styleable with the current approach, we'll be able to fix it after we implement T74716.)

(The patch above depends on unmerged OOUI patches https://gerrit.wikimedia.org/r/#/c/185376/ and https://gerrit.wikimedia.org/r/#/c/185576/.)

cscott added a subscriber: cscott.Jan 28 2015, 12:44 AM
matmarex added a subscriber: Prtksxna.

I have added some more technical blockers to this. Accessibility issues (for keyboard users, for screen readers, for older browsers) must be resolved before we start pushing OOUI as a replacement for existing important interfaces.

Looks like the dropdown is still unstyled…

Yes, and the form still looks unpleasant per T86865#983556. The work is progressing, as you can see from the dependent tasks being created and closed, but I am the only person working on this (in spite of my requests for design input; I guess I'm just doing it the way it feels right to me, then), and I have other responsibilities too.

matmarex lowered the priority of this task from High to Normal.Mar 12 2015, 2:32 PM

@matmarex the UI standard group decided a while back that we'd try to first style existing form by swapping out the new controls in situ. Certainly this could cause some forms to look longer, wider, or just very different than they do now, but this was the first goal. Then and only then would we start reevaluating the layout of the forms, either simple switches like the ordering of buttons at the bottom (move primary button to the rightmost position) or much more drastic refactoring of the layout as needed.

@Prtksxna can elaborate if need be, he was the one that did much of the audit, and even started thinking about the next step of refactoring some forms/special pages.

Let's stay true to that decision and have this task only be a straight swap of the old controls for OOJS versions. So in that case the feedback it sounds like you need from Design is "stay true to the layout, control ordering, and general structure of the current form while updating the technology of how controls are drawn"

@matmarex Can you update the screenshot, now that T91153 has been resolved? Then @Jaredzimmerman-WMF and @Prtksxna can sign off on whether this is sufficiently "true to the layout, control ordering, and general structure of the current form while updating the technology of how controls are drawn". (From the previous screenshot, once the border is drawn (that was T91153) it seems like the only significant change will be increased whitespace, but maybe I'm missing something.)

@matmarex the UI standard group decided a while back that we'd try to first style existing form by swapping out the new controls in situ. Certainly this could cause some forms to look longer, wider, or just very different than they do now, but this was the first goal. Then and only then would we start reevaluating the layout of the forms, either simple switches like the ordering of buttons at the bottom (move primary button to the rightmost position) or much more drastic refactoring of the layout as needed.

Interesting. I knew nothing about this. Out of curiosity, which group was that, since I was under the impression that I am a member of at least one frontend standards group? :)

Let's stay true to that decision and have this task only be a straight swap of the old controls for OOJS versions. So in that case the feedback it sounds like you need from Design is "stay true to the layout, control ordering, and general structure of the current form while updating the technology of how controls are drawn"

I'm not sure if this approach will work in this case, I feel that it'll result in enlarging some parts of the form disproportionately. I can try and supply screenshots, though.


I would still like to get T91152 resolved before we continue introducing OOUI widgets into MediaWiki pages. Such size inconsistencies can be very jarring.

Spage added a subscriber: Spage.EditedApr 5 2015, 10:40 PM

@matmarex the UI standard group decided a while back that we'd try to first style existing form by swapping out the new controls in situ. Certainly this could cause some forms to look longer, wider, or just very different than they do now, but this was the first goal. Then and only then would we start reevaluating the layout of the forms, either simple switches like the ordering of buttons at the bottom (move primary button to the rightmost position) or much more drastic refactoring of the layout as needed.

Interesting. I knew nothing about this. Out of curiosity, which group was that, since I was under the impression that I am a member of at least one frontend standards group? :)

Jared may be referring to some iteration of UX standardization, in which developers pursued applying the mw-ui- styles throughout core (not really "swapping out the controls"). The idea goes back years. Since https://gerrit.wikimedia.org/r/#/c/150635/ was merged 6 months ago, you get the new MediaWiki appearance in most core forms if you set $wgUseMediaWikiUIEverywhere = true. For grins here's Special:MovePage on my local wiki with this setting:

What is the status of T72424: Set $wgUseMediaWikiUIEverywhere = true? If we're abandoning it to instead convert everything to OOjs UI, let's say so.

Status update:

The form:
In context:
In action:
In MonoBook (using Apex theme):

I think this is passable.

Looks good to me.

matmarex raised the priority of this task from Normal to High.Jul 20 2015, 7:25 PM
Jdforrester-WMF closed this task as Resolved.Sep 15 2015, 10:32 PM

Change 185591 merged by jenkins-bot:
SpecialMovepage: Convert form to use OOUI controls

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

If there is a bug with this change do I add it here or open a new task? Hopefully someone who is subscribed to this gets it to the right place.

Anyway, the problem I have is that when you try and move a page to a target that already has a history (essentially you want to perform a delete and move) when the new page loads telling you "The destination page "X" already exists. Do you want to delete it to make way for the move? (Check the edit history.)" you lose whatever you've previously written in the "reason" field. This didn't use to happen.

Also, as more of a general comment from someone who does a lot of moves, does the thing have to be so darn BIG? It seems unnecessary to have to scroll to actually click the "move" button.

Wbm1058 added a subscriber: Wbm1058.EditedSep 24 2015, 8:42 PM

I've been told that https://en.wikipedia.org/wiki/Template:RMassist no longer is prepopulating the "reason" field; though I haven't looked at it myself, this seems to confirm "you lose whatever you've previously written in the "reason" field" above. Please back off this change until you fix this. Thanks.

Confirmed the issue here https://en.wikipedia.org/w/index.php?title=Wikipedia:Requested_moves/Technical_requests&oldid=682613393

Note the source code:
&wpReason={{Urlencode:Requested at [[WP:RM]] as uncontroversial ([[Special:Permalink/{{REVISIONID}}|permalink]])}}

but click on "move" and it's not there in the "reason" field.

This is documented here and here:
https://www.mediawiki.org/wiki/Manual:Creating_pages_with_preloaded_text
https://www.mediawiki.org/wiki/Manual:Parameters_to_index.php#Edit_and_submit

I trust that the full functionality as documented there is being maintained?

I'm interested in this bug for the same reasons as Wbm1058 and Jenks24. My guess is that the problem will not be that hard to fix.

jrbs added a subscriber: jrbs.Sep 25 2015, 12:12 AM

I posted a bug about this at T113718 before seeing this.

Yes, apologies, I unintentionally broke that feature. Please watch the linked task for updates, I'll try to get the fix (which indeed is very simple) deployed as soon as possible.

Also, as more of a general comment from someone who does a lot of moves, does the thing have to be so darn BIG? It seems unnecessary to have to scroll to actually click the "move" button.

This is a fair point, I filed T113953 where I proposed some ideas.