Now that the new button styles and classes are headed for core (https://gerrit.wikimedia.org/r/#/c/103494/), we should decide on a rollout strategy for using the classes. Basically one of:
1. All at once (do https://gerrit.wikimedia.org/r/#/c/52169) 2. Continue piece by piece (e.g. https://bugzilla.wikimedia.org/show_bug.cgi?id=58296, wpSave, wpPreview, and wpDiff, which Tony Thomas just took).
I'm inclined to #1, for horizontal consistency.
Matt Flaschen
Matthew Flaschen wrote:
Now that the new button styles and classes are headed for core (https://gerrit.wikimedia.org/r/#/c/103494/), we should decide on a rollout strategy for using the classes. Basically one of:
- All at once (do https://gerrit.wikimedia.org/r/#/c/52169)
- Continue piece by piece (e.g.
https://bugzilla.wikimedia.org/show_bug.cgi?id=58296, wpSave, wpPreview, and wpDiff, which Tony Thomas just took).
I'm inclined to #1, for horizontal consistency.
I don't know what "horizontal consistency" means. Haven't there already been colored UI buttons in the wild for months now?
Option 2 sounds sa[fn]er to me.
MZMcBride
While in general I'd love to see a big unveiling, I don't want us to hold anything up because one control isn't ready year, I know this means that we have some consistency but really we have tonnes of that already, so that isn't that big a deal to me.
What I think would be a good middle ground, e.g. all of the primary buttons, all of the dropdowns, all of the check boxes, etc. keep the rollouts to a specific control type, rather than an all or nothing approach.
*Jared Zimmerman * \ Director of User Experience \ Wikimedia Foundation
M : +1 415 609 4043 | : @JaredZimmermanhttps://twitter.com/JaredZimmerman
On Thu, Jan 2, 2014 at 8:32 PM, MZMcBride z@mzmcbride.com wrote:
Matthew Flaschen wrote:
Now that the new button styles and classes are headed for core (https://gerrit.wikimedia.org/r/#/c/103494/), we should decide on a rollout strategy for using the classes. Basically one of:
- All at once (do https://gerrit.wikimedia.org/r/#/c/52169)
- Continue piece by piece (e.g.
https://bugzilla.wikimedia.org/show_bug.cgi?id=58296, wpSave, wpPreview, and wpDiff, which Tony Thomas just took).
I'm inclined to #1, for horizontal consistency.
I don't know what "horizontal consistency" means. Haven't there already been colored UI buttons in the wild for months now?
Option 2 sounds sa[fn]er to me.
MZMcBride
Design mailing list Design@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/design
Once someone +2s the new styles, all the forms already using Agora will update. Matt Flaschen is discussing how we expand use of the styles to more forms.
On Fri, Jan 3, 2014 at 11:26 AM, Jared Zimmerman < jared.zimmerman@wikimedia.org> wrote:
While in general I'd love to see a big unveiling, I don't want us to hold anything up because one control isn't ready year [yet?]
Incomplete is OK (and will always be the case), but looking wrong would be unfortunate, especially when gadgets and extensions copy what we do.
Specifically, do you want to release the new Agora "beveled bottom" buttons without the new blue bar text field input focus that Flow is already using? Click in one of the text fields in http://ee-flow-extra.instance-proxy.wmflabs.org/wiki/Special:UserLogin , the new buttons together with 2013's "glow" input focus feels jarring.
What I think would be a good middle ground, e.g. all of the primary
buttons, all of the dropdowns, all of the check boxes, etc.
So I would add blue bar text field input focus to that list. As I recall there were some technical issues with the new Agora checkbox (it's in the Beta features preference pane but not the login form above) that kept it out of core mediawiki.ui.
Voltaire (sort-of) said "Perfect is the enemy of the good"; but people didn't critique early screenshots of his work :)
There are a lot of form types, while I want them all to exist, I don't know what the timeline to create them is, I've included most all of them below. The date picker is the most complex I didn't include all of the states for it, because its almost a project unto itself.
So I see both sides, perhaps we should make a decision based on how long we feel it will take to implement these form fields [image: Inline image 2]
*Jared Zimmerman * \ Director of User Experience \ Wikimedia Foundation
M : +1 415 609 4043 | : @JaredZimmermanhttps://twitter.com/JaredZimmerman
On Fri, Jan 3, 2014 at 10:13 PM, S Page spage@wikimedia.org wrote:
Once someone +2s the new styles, all the forms already using Agora will update. Matt Flaschen is discussing how we expand use of the styles to more forms.
On Fri, Jan 3, 2014 at 11:26 AM, Jared Zimmerman < jared.zimmerman@wikimedia.org> wrote:
While in general I'd love to see a big unveiling, I don't want us to hold anything up because one control isn't ready year [yet?]
Incomplete is OK (and will always be the case), but looking wrong would be unfortunate, especially when gadgets and extensions copy what we do.
Specifically, do you want to release the new Agora "beveled bottom" buttons without the new blue bar text field input focus that Flow is already using? Click in one of the text fields in http://ee-flow-extra.instance-proxy.wmflabs.org/wiki/Special:UserLogin , the new buttons together with 2013's "glow" input focus feels jarring.
What I think would be a good middle ground, e.g. all of the primary
buttons, all of the dropdowns, all of the check boxes, etc.
So I would add blue bar text field input focus to that list. As I recall there were some technical issues with the new Agora checkbox (it's in the Beta features preference pane but not the login form above) that kept it out of core mediawiki.ui.
Voltaire (sort-of) said "Perfect is the enemy of the good"; but people didn't critique early screenshots of his work :)
-- =S Page Features engineer
Design mailing list Design@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/design
On Fri, Jan 3, 2014 at 11:55 PM, Jared Zimmerman < jared.zimmerman@wikimedia.org> wrote:
There are a lot of form types, while I want them all to exist, I don't know what the timeline to create them is, I've included most all of them below. The date picker is the most complex I didn't include all of the states for it, because its almost a project unto itself.
The only use case for a date picker I can think of is to set a date in an infobox or other template (such as cleanup templates, which like to know the month + year they were assigned). However, right now in VE templates don't actually have full VE-enabled GUIs for editing their parameters. Just autosuggest search and wikitext input areas. Correct? Another typical use for a date picker, such as marking date of birth on a user profile, is something we don't yet support and which should have Legal involved before we do.
*TL;DR*: we'll build things like a date picker when we need them. It's cool to have designs, but also really confusing to put them in mocks or a style guide when they're not used. I'd encourage the UX team to make a special "future/experimental" category that separates out these form types that don't exist yet. This will reduce confused questions. ;)
On 01/04/2014 04:56 PM, Steven Walling wrote:
On Fri, Jan 3, 2014 at 11:55 PM, Jared Zimmerman <jared.zimmerman@wikimedia.org mailto:jared.zimmerman@wikimedia.org> wrote:
There are a lot of form types, while I want them all to exist, I don't know what the timeline to create them is, I've included most all of them below. The date picker is the most complex I didn't include all of the states for it, because its almost a project unto itself.The only use case for a date picker I can think of is to set a date in an infobox or other template (such as cleanup templates, which like to know the month + year they were assigned).
Dates are used by core directly, for protection and block expiry dates (maybe more). I believe both durations (e.g. expires in 1 week) and expiry dates can be used (of course, it's two sides of the same coin), but in the log it clearly shows as a date (or a datetime to be exact).
Matt Flaschen
On 01/04/2014 01:13 AM, S Page wrote:
Specifically, do you want to release the new Agora "beveled bottom" buttons without the new blue bar text field input focus that Flow is already using? Click in one of the text fields in http://ee-flow-extra.instance-proxy.wmflabs.org/wiki/Special:UserLogin , the new buttons together with 2013's "glow" input focus feels jarring.
I think it's fine as an incremental step. I don't think it will look jarring to a typical user. Both are nice styles in their own right (regardless of the fact there is a new spec for textbox focus coming up), and they don't really clash.
Matt Flaschen
On 01/03/2014 02:26 PM, Jared Zimmerman wrote:
While in general I'd love to see a big unveiling, I don't want us to hold anything up because one control isn't ready year, I know this means that we have some consistency but really we have tonnes of that already, so that isn't that big a deal to me.
What I think would be a good middle ground, e.g. all of the primary buttons, all of the dropdowns, all of the check boxes, etc. keep the rollouts to a specific control type, rather than an all or nothing approach.
I like this idea. I assume you mean one of those (e.g. "all the primary buttons"), not all of them ("all the primary buttons" *and" "all of the dropdowns" ...).
However, I would amend it slightly to be all of the basic rectangular buttons (including mw-ui-constructive, mw-ui-progressive, mw-ui-destructive, mw-ui-quiet).
Matt Flaschen
On 01/02/2014 11:32 PM, MZMcBride wrote:
Matthew Flaschen wrote:
Now that the new button styles and classes are headed for core (https://gerrit.wikimedia.org/r/#/c/103494/), we should decide on a rollout strategy for using the classes. Basically one of:
- All at once (do https://gerrit.wikimedia.org/r/#/c/52169)
- Continue piece by piece (e.g.
https://bugzilla.wikimedia.org/show_bug.cgi?id=58296, wpSave, wpPreview, and wpDiff, which Tony Thomas just took).
I'm inclined to #1, for horizontal consistency.
I don't know what "horizontal consistency" means.
It basically means the same components on different pages look the same, on the same wiki, at the same time. As a hypothetical example, suppose all text input boxes on all pages glow (regardless of whether other aspects of the new design are there).
Haven't there already been colored UI buttons in the wild for months now?
Yes, but there are still a huge number of buttons (including important ones like save/preview/show changes) that don't. That does mean it's not horizontally consistent in that regard.
Hence, the question.
Matt Flaschen
To explain more, as a followup to MZ's question about what "horizontal consistency" means...
On Thu, Jan 2, 2014 at 9:02 AM, Matthew Flaschen mflaschen@wikimedia.orgwrote:
- All at once (do https://gerrit.wikimedia.org/r/#/c/52169)
This would apply mw.ui buttons styles to most of the essential forms in core. Including edit forms everywhere, history pages, all logs, and (as far as I can tell) anything using HTMLForm. So we'd be applying the new button styles across the board almost universally.
This is riskier and bigger change, but it's what people seemed to want back in the day, when we first started rolling out mw.ui styles in core for login/signup etc. People were extremely mad that we were introducing inconsistent typography and button styles in core. (The typography has since been removed and put in Beta Features.)
The requirement for doing this is that we are *much more diligent* about doing a design review of every interface this patch touches and looking for major flaws that would impair use. If we're going to move forward with that patch, I want us to not push this out hastily. Let's make a checklist for design review to work through systematically on Beta Labs and also perhaps a separate Labs instance.
- Continue piece by piece (e.g. https://bugzilla.wikimedia.
org/show_bug.cgi?id=58296, wpSave, wpPreview, and wpDiff, which Tony Thomas just took).
This is less risky, but the cost is inconsistency in the UI. I am usually a fan on incremental change, I think Matt has a point here. If we're going to apply to fundamental forms like edit, we should just go ahead and apply the button styles everywhere in core ala patch 52169. The social cost of doing History, Logs, etc. separately is higher than doing it all in one fell swoop.
Matt/Juliusz/anyone: is applying mw.ui to HTMLForm *required* to merge 52169 and apply the buttons to EditPage, History, Logs, etc.? I am thinking maybe it might be good to break the HTMLForm work in to a separate and simultaneous patch, just because the design audit required seems much more varied for HTMLForm than edit, history, logs, revdelete, and so on. Just an idea.
On 01/04/2014 05:11 PM, Steven Walling wrote:
This is riskier and bigger change, but it's what people seemed to want back in the day, when we first started rolling out mw.ui styles in core for login/signup etc.
The main risk is just that someone uses the wrong class, or misses one, so it's (more) inconsistent or looks a little weird. The risk of making it unusable is much lower.
The requirement for doing this is that we are /much more diligent/ about doing a design review of every interface this patch touches and looking for major flaws that would impair use. If we're going to move forward with that patch, I want us to not push this out hastily. Let's make a checklist for design review to work through systematically on Beta Labs and also perhaps a separate Labs instance.
Probably, a separate one would make more sense, since it has to be in master to make Beta Labs, which means it will be deployed in a few days.
Matt/Juliusz/anyone: is applying mw.ui to HTMLForm *required* to merge 52169 and apply the buttons to EditPage, History, Logs, etc.?
https://gerrit.wikimedia.org/r/#/c/52169 could potentially exclude HTMLForm (as a way to split the patch), though it should be noted that HTMLForm already has an opt-in vform option.
I am thinking maybe it might be good to break the HTMLForm work in to a separate and simultaneous patch, just because the design audit required seems much more varied for HTMLForm than edit, history, logs, revdelete, and so on. Just an idea.
That's reasonable to think about. I posted on the patch.
Matt Flaschen
just realized that on Special:Contributions there is a control that could be a date picker, but is currently a stepper and dropdown control combo.
[image: Inline image 1]
*Jared Zimmerman * \ Director of User Experience \ Wikimedia Foundation
M : +1 415 609 4043 | : @JaredZimmermanhttps://twitter.com/JaredZimmerman
On Sat, Jan 4, 2014 at 6:47 PM, Matthew Flaschen mflaschen@wikimedia.orgwrote:
On 01/04/2014 05:11 PM, Steven Walling wrote:
This is riskier and bigger change, but it's what people seemed to want back in the day, when we first started rolling out mw.ui styles in core for login/signup etc.
The main risk is just that someone uses the wrong class, or misses one, so it's (more) inconsistent or looks a little weird. The risk of making it unusable is much lower.
The requirement for doing this is that we are /much more diligent/ about
doing a design review of every interface this patch touches and looking for major flaws that would impair use. If we're going to move forward with that patch, I want us to not push this out hastily. Let's make a checklist for design review to work through systematically on Beta Labs and also perhaps a separate Labs instance.
Probably, a separate one would make more sense, since it has to be in master to make Beta Labs, which means it will be deployed in a few days.
Matt/Juliusz/anyone: is applying mw.ui to HTMLForm *required* to
merge 52169 and apply the buttons to EditPage, History, Logs, etc.?
https://gerrit.wikimedia.org/r/#/c/52169 could potentially exclude HTMLForm (as a way to split the patch), though it should be noted that HTMLForm already has an opt-in vform option.
I am thinking maybe it might be good to break the HTMLForm work in to a
separate and simultaneous patch, just because the design audit required seems much more varied for HTMLForm than edit, history, logs, revdelete, and so on. Just an idea.
That's reasonable to think about. I posted on the patch.
Matt Flaschen
Design mailing list Design@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/design
