MediaWiki UI Forms - Design - lists.wikimedia.org

Steven Walling

28 Aug 28 Aug

9:08 p.m.

On Thu, Aug 28, 2014 at 1:40 PM, Jon Robson <jrobson(a)wikimedia.org> wrote:

On bug 65317 [1] it is suggested that the preferences page should have buttons aligned to the right and should be ordered so constructive is the last. I've written a fix for this and I would appreciate some code review. This had me wondering, should this apply to all forms? e.g. the editing form If so I think we probably need to get this into the style guide in some form, detailing how buttons should be ordered. We may want to introduce mw-ui-button-group or mw-ui-form-button-group. [1] https://bugzilla.wikimedia.org/show_bug.cgi?id=65317

I think before we make a decision we need to think this through, by asking two questions: 1. What do most users expect here, in terms of ordering? If we don't know, how can we learn what they do expect? 2. If users expect the primary action to be on the right, how would this change core forms other than Preferences, such as signup, login, editing (in wikitext and VE)? In the mean time, the simplest thing to do is not to rewrite Preferences to make a new divergent standard, but just update the button classes without mucking with the ordering. That's the minimum viable release for updating Preferences to match mw.ui styles. This will provide the most benefit with the least effort. -- Steven Walling, Product Manager https://wikimediafoundation.org/

Reply

Jon Robson

11:24 p.m.

Sure. I completely understand and have written a patch for the preferences case, but I was just having a more bigger picture thought around this. Our job is to identify patterns and improve documentation in the style guide so developers are empowered to build the right thing based on advice from designers. To take the editing form for example [1] Currently we have Save | Show Preview |Show pages | cancel | editing help at the bottom of the form My question is 1) should all submit buttons be aligned right in forms 2) Where multiple buttons exist in a form, how do we order them. There is no guidance on how multiple buttons in a form should be rendered in the style guide. Is there some logical way to order buttons? Do constructive / destructive always come last? Does progressive come before those? There are plenty of people, including a bunch of volunteers, keen to help with building out consistency across our projects, so we should work out what needs fixing should document any decisions on bugzilla [2]. Even if we don't know the right answer right now, it is good to start this discussion now. [1] http://mwui.wmflabs.org/wiki/Foo?action=edit [2] https://bugzilla.wikimedia.org/enter_bug.cgi?product=MediaWiki&componen… On Thu, Aug 28, 2014 at 4:12 PM, Jared Zimmerman < jared.zimmerman(a)wikimedia.org> wrote:

...

Jon, what controls are you referring to, this should only affect [Save] Restore all default settings (in all sections) <https://en.wikipedia.org/wiki/Special:Preferences/reset> and be right aligned to the page. Restore default settings <- Quite destructive [ Save ] <- Normal constructive. I agree with Steven that we could just move forward with styling first and layout later. *Jared Zimmerman * \\ Director of User Experience \\ Wikimedia Foundation M +1 415 609 4043 \\ @jaredzimmerman <http://loo.ms/g0> On Thu, Aug 28, 2014 at 2:08 PM, Steven Walling <swalling(a)wikimedia.org> wrote:

On Thu, Aug 28, 2014 at 1:40 PM, Jon Robson <jrobson(a)wikimedia.org> wrote:

On bug 65317 [1] it is suggested that the preferences page should have buttons aligned to the right and should be ordered so constructive is the last. I've written a fix for this and I would appreciate some code review. This had me wondering, should this apply to all forms? e.g. the editing form If so I think we probably need to get this into the style guide in some form, detailing how buttons should be ordered. We may want to introduce mw-ui-button-group or mw-ui-form-button-group. [1] https://bugzilla.wikimedia.org/show_bug.cgi?id=65317

I think before we make a decision we need to think this through, by asking two questions: 1. What do most users expect here, in terms of ordering? If we don't know, how can we learn what they do expect? 2. If users expect the primary action to be on the right, how would this change core forms other than Preferences, such as signup, login, editing (in wikitext and VE)? In the mean time, the simplest thing to do is not to rewrite Preferences to make a new divergent standard, but just update the button classes without mucking with the ordering. That's the minimum viable release for updating Preferences to match mw.ui styles. This will provide the most benefit with the least effort. -- Steven Walling, Product Manager https://wikimediafoundation.org/ _______________________________________________ Design mailing list Design(a)lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/design

_______________________________________________ Design mailing list Design(a)lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/design

Reply

Steven Walling

29 Aug 29 Aug

12:40 a.m.

On Thu, Aug 28, 2014 at 4:53 PM, Jared Zimmerman < jared.zimmerman(a)wikimedia.org> wrote:

...

1) yes, the "primary action" will be rightmost, this could mean progressive, in the case of a multi-step form form, destructive in the case of process where the primary function is to delete something and constructive in the case of the final step in a single or multi-step process that creates something or finalizes a non destructive process. 2) they should be ordered from right to left in order of importance and frequency of use, there should only be one primary action. secondary actions should have neutral or quiet appearance. We will capture as many patterns and best practices in the mediawiki.ui living style guide as possible, however they will be a guide and set of best practices, and there will likely be exceptions, and places where the patterns break down. Without completely redesigning the bottom of the wikitext editor, the minimal mediawiki.ui version of the WTE bottom could go from [ Save Page ] [ Show Preview ] [ Show Changes ] Cancel to… *Cancel/Discard* (mw.destructive.quiet) *Show changes* (mw.progressive.quiet) *Preview* (mw.progressive.quiet) *[ Save ]* (mw.constructive.normal)

Whether we change to follow this pattern needs to validated with users before we attempt to standardize on it. If we're going to completely flip the order of our actions on forms then we need to demonstrate that it's worth it. -- Steven Walling, Product Manager https://wikimediafoundation.org/

Reply

Jon Robson

2:32 a.m.

On this basis should I not touch the order on the preferences form...? On 28 Aug 2014 18:01, "Jared Zimmerman" <jared.zimmerman(a)wikimedia.org> wrote:

...

Steven I totally agree, I have a meeting with James/Editing team to talk about instrumentation of the WTE which we'll need to move forward with a good comparison here. I would say that we only need to prove that it is not disruptive, rather than measurably better. Do you feel like we'll need to do quantitative tests on every button group or just some key forms like edit, account creation, and maybe one or two others? *Jared Zimmerman * \\ Director of User Experience \\ Wikimedia Foundation M +1 415 609 4043 \\ @jaredzimmerman <http://loo.ms/g0> On Thu, Aug 28, 2014 at 5:40 PM, Steven Walling <swalling(a)wikimedia.org> wrote:

On Thu, Aug 28, 2014 at 4:53 PM, Jared Zimmerman < jared.zimmerman(a)wikimedia.org> wrote:

1) yes, the "primary action" will be rightmost, this could mean progressive, in the case of a multi-step form form, destructive in the case of process where the primary function is to delete something and constructive in the case of the final step in a single or multi-step process that creates something or finalizes a non destructive process. 2) they should be ordered from right to left in order of importance and frequency of use, there should only be one primary action. secondary actions should have neutral or quiet appearance. We will capture as many patterns and best practices in the mediawiki.ui living style guide as possible, however they will be a guide and set of best practices, and there will likely be exceptions, and places where the patterns break down. Without completely redesigning the bottom of the wikitext editor, the minimal mediawiki.ui version of the WTE bottom could go from [ Save Page ] [ Show Preview ] [ Show Changes ] Cancel to… *Cancel/Discard* (mw.destructive.quiet) *Show changes* (mw.progressive.quiet) *Preview* (mw.progressive.quiet) *[ Save ]* (mw.constructive.normal)

Whether we change to follow this pattern needs to validated with users before we attempt to standardize on it. If we're going to completely flip the order of our actions on forms then we need to demonstrate that it's worth it. -- Steven Walling, Product Manager https://wikimediafoundation.org/ _______________________________________________ Design mailing list Design(a)lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/design

_______________________________________________ Design mailing list Design(a)lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/design

Reply

Jon Robson

1 Sep 1 Sep

8:05 p.m.

This patch [1] corrects the colours. Code review welcomed. This patch [2] swaps the alignment. I've -2ed the 2nd patch. Let me know how you want to proceed with that. Jon [1] https://gerrit.wikimedia.org/r/157709 [2] https://gerrit.wikimedia.org/r/157709 On Fri, Aug 29, 2014 at 4:07 AM, Jared Zimmerman < jared.zimmerman(a)wikimedia.org> wrote:

...

I think its ok to apply the mediawiki.ui styles but not reordering the buttons. using constructive primary for Save, and putting the reset action in either quiet or anchor destructive, I'm thinking anchor since the string is so long right now. *Jared Zimmerman * \\ Director of User Experience \\ Wikimedia Foundation M +1 415 609 4043 \\ @jaredzimmerman <http://loo.ms/g0> On Thu, Aug 28, 2014 at 7:32 PM, Jon Robson <jdlrobson(a)gmail.com> wrote:

On this basis should I not touch the order on the preferences form...? On 28 Aug 2014 18:01, "Jared Zimmerman" <jared.zimmerman(a)wikimedia.org> wrote:

Steven I totally agree, I have a meeting with James/Editing team to talk about instrumentation of the WTE which we'll need to move forward with a good comparison here. I would say that we only need to prove that it is not disruptive, rather than measurably better. Do you feel like we'll need to do quantitative tests on every button group or just some key forms like edit, account creation, and maybe one or two others? *Jared Zimmerman * \\ Director of User Experience \\ Wikimedia Foundation M +1 415 609 4043 \\ @jaredzimmerman <http://loo.ms/g0> On Thu, Aug 28, 2014 at 5:40 PM, Steven Walling <swalling(a)wikimedia.org> wrote:

On Thu, Aug 28, 2014 at 4:53 PM, Jared Zimmerman < jared.zimmerman(a)wikimedia.org> wrote: > 1) yes, the "primary action" will be rightmost, this could mean > progressive, in the case of a multi-step form form, destructive in the case > of process where the primary function is to delete something and > constructive in the case of the final step in a single or multi-step > process that creates something or finalizes a non destructive process. > > 2) they should be ordered from right to left in order of importance > and frequency of use, there should only be one primary action. secondary > actions should have neutral or quiet appearance. > > We will capture as many patterns and best practices in the > mediawiki.ui living style guide as possible, however they will be a guide > and set of best practices, and there will likely be exceptions, and places > where the patterns break down. > > > Without completely redesigning the bottom of the wikitext editor, the > minimal mediawiki.ui version of the WTE bottom could go from > > [ Save Page ] [ Show Preview ] [ Show Changes ] Cancel > > to… > > *Cancel/Discard* (mw.destructive.quiet) *Show changes* > (mw.progressive.quiet) *Preview* (mw.progressive.quiet) *[ Save ]* > (mw.constructive.normal) > Whether we change to follow this pattern needs to validated with users before we attempt to standardize on it. If we're going to completely flip the order of our actions on forms then we need to demonstrate that it's worth it. -- Steven Walling, Product Manager https://wikimediafoundation.org/ _______________________________________________ Design mailing list Design(a)lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/design

_______________________________________________ Design mailing list Design(a)lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/design

Reply

Jared Zimmerman

12:25 a.m.

There is a separate bug for Ajax page saves (I'm mobile, it's the weekend) so I don't know the bug number. But yes it would be the preferred behavior. With save button only appearing for noJS users. Sent while mobile

...

On Sep 6, 2014, at 5:09 PM, quiddity <pandiculation(a)gmail.com> wrote:

On Mon, Sep 1, 2014 at 1:05 PM, Jon Robson <jrobson(a)wikimedia.org> wrote: This patch [1] corrects the colours. Code review welcomed. This patch [2] swaps the alignment. I've -2ed the 2nd patch. Let me know how you want to proceed with that. Jon [1] https://gerrit.wikimedia.org/r/157709 [2] https://gerrit.wikimedia.org/r/157709

small correction [2] should be https://gerrit.wikimedia.org/r/#/c/156838/ - Regarding the Special:Preferences page, could we consider putting the Save button at the top-right of the box, instead? There are many users who are used to the modern systems like Gmail - where no manual "save" is needed, but instead happens automatically when anything is changed - and are liable to miss the Save button anywhere at the bottom, especially on longer preference pages. In the RfC for userpreferences, I'd suggested that "The [Save button] is always visible/nearby" should be a high-priority goal. (Or, upgrading to an auto-save system). [1] Having it at the top of the window would be ideal, and possibly even top and bottom, like so: https://i.imgur.com/4Mu9UdQ.png [1] https://www.mediawiki.org/wiki/Requests_for_comment/Redesign_user_preferenc… _______________________________________________ Design mailing list Design(a)lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/design

Reply

Jared Zimmerman

4:06 p.m.

I've found at least 3 instances of users complaining beta features don't work, when the issue was that they were expecting prefs to auto save so they hadn't actually enabled them. Sent while mobile

...

On Sep 9, 2014, at 8:36 AM, quiddity <pandiculation(a)gmail.com> wrote: Ah, that's Bug 56561 - Changes to user preferences should be automatically saved. Thanks.

On Sat, Sep 6, 2014 at 5:25 PM, Jared Zimmerman <jzimmerman(a)wikimedia.org> wrote: There is a separate bug for Ajax page saves (I'm mobile, it's the weekend) so I don't know the bug number. But yes it would be the preferred behavior. With save button only appearing for noJS users. Sent while mobile

On Sep 6, 2014, at 5:09 PM, quiddity <pandiculation(a)gmail.com> wrote:

On Mon, Sep 1, 2014 at 1:05 PM, Jon Robson <jrobson(a)wikimedia.org> wrote: This patch [1] corrects the colours. Code review welcomed. This patch [2] swaps the alignment. I've -2ed the 2nd patch. Let me know how you want to proceed with that. Jon [1] https://gerrit.wikimedia.org/r/157709 [2] https://gerrit.wikimedia.org/r/157709

small correction [2] should be https://gerrit.wikimedia.org/r/#/c/156838/ - Regarding the Special:Preferences page, could we consider putting the Save button at the top-right of the box, instead? There are many users who are used to the modern systems like Gmail - where no manual "save" is needed, but instead happens automatically when anything is changed - and are liable to miss the Save button anywhere at the bottom, especially on longer preference pages. In the RfC for userpreferences, I'd suggested that "The [Save button] is always visible/nearby" should be a high-priority goal. (Or, upgrading to an auto-save system). [1] Having it at the top of the window would be ideal, and possibly even top and bottom, like so: https://i.imgur.com/4Mu9UdQ.png [1] https://www.mediawiki.org/wiki/Requests_for_comment/Redesign_user_preferenc… _______________________________________________ Design mailing list Design(a)lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/design

_______________________________________________ Design mailing list Design(a)lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/design

Reply