Agora specs[1] introduce expanded button semantics, but the "Buttons" visuals on p. 3 don't name or explain them.
I added that image and some explication to the existing page "Patterns and components"[2] <mildflame on>Don't ignore existing specs just because you didn't work on them! Update pages when designs change, don't leave them to rot and mislead.</mildflame>
Because the semantics are changed, some current styles in mediawiki.ui don't cleanly map: * mw-ui-primary (the main button, e.g. [Login]) * mw-ui-constructive (an alternative, e.g. "Don't have an account? [Join Wikipedia]" button)
The new specs distinguish continue and completion actions for the primary button, and a constructive alternative is just a plain button. mw-ui-primary can either remain the style for the complete form action (changing from blue to green!) or be a deprecated synonym for a new mw-ui-completion style, since I don't think any multi-step forms use Agora yet. I think mw-ui-constructive becomes a deprecated no-op.
Flow's CSS uses "mw-ui-button mw-ui-text" for actions that don't appear as a button (the two top rows).
[1] https://www.mediawiki.org/wiki/File:Agora_specs.pdf [2] https://www.mediawiki.org/wiki/Wikimedia_Foundation_Design/Patterns_and_comp...
Thanks for this summary S, the "living style guide" mentioned in https://www.mediawiki.org/wiki/UX_standardization will include not only the visual styling of agora controls but best practices for using them. e.g. things like order of buttons (primary CTA rightmost) and what types of buttons should be disabled when invalid input is detected (places where a post would result in an error) as well as when to use different styles of buttons.
*Jared Zimmerman * \ Director of User Experience \ Wikimedia Foundation
M : +1 415 609 4043 | : @JaredZimmermanhttps://twitter.com/JaredZimmerman
On Tue, Nov 5, 2013 at 6:47 PM, S Page spage@wikimedia.org wrote:
Agora specs[1] introduce expanded button semantics, but the "Buttons" visuals on p. 3 don't name or explain them.
I added that image and some explication to the existing page "Patterns and components"[2] <mildflame on>Don't ignore existing specs just because you didn't work on them! Update pages when designs change, don't leave them to rot and mislead.</mildflame>
Because the semantics are changed, some current styles in mediawiki.ui don't cleanly map:
- mw-ui-primary (the main button, e.g. [Login])
- mw-ui-constructive (an alternative, e.g. "Don't have an account? [Join
Wikipedia]" button)
The new specs distinguish continue and completion actions for the primary button, and a constructive alternative is just a plain button. mw-ui-primary can either remain the style for the complete form action (changing from blue to green!) or be a deprecated synonym for a new mw-ui-completion style, since I don't think any multi-step forms use Agora yet. I think mw-ui-constructive becomes a deprecated no-op.
Flow's CSS uses "mw-ui-button mw-ui-text" for actions that don't appear as a button (the two top rows).
[1] https://www.mediawiki.org/wiki/File:Agora_specs.pdf [2] https://www.mediawiki.org/wiki/Wikimedia_Foundation_Design/Patterns_and_comp...
-- =S Page Features engineer
Design mailing list Design@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/design
On Tue, Nov 5, 2013 at 7:01 PM, Jared Zimmerman < jared.zimmerman@wikimedia.org> wrote:
Thanks for this summary S, the "living style guide" mentioned in https://www.mediawiki.org/wiki/UX_standardization will include not only the visual styling of agora controls but best practices for using them. e.g. things like order of buttons (primary CTA rightmost) and what types of buttons should be disabled when invalid input is detected (places where a post would result in an error) as well as when to use different styles of buttons.
Can the UX team please write the copy for these best practices now, rather than later? We could really use the text accompaniment now, as we begin to build and test the revisions to mediawiki.ui.
For developers, having simple explanation of the intended patterns will ease the transition to a new mediawiki.ui look. For product managers, we'll be able to help make sure that our individual products conform to the general style guide.
Flow is not the only new product that is starting to conform to parts of the new mediawiki.ui spec. For Growth team projects like anonymous editor acquisition, onboarding, and article creation, Pau is already producing mockups that incorporate elements of the new design. If you can produce a single page guide with these best practices you describe, they can be used now and incorporated in to the more interactive living style guide later.
Steven
As a developer, +infinity to everything Steven said. A 'living' document that gets changed frequently is vastly better than no document at all.
I'm beginning to catalog behaviors here https://www.mediawiki.org/wiki/Wikimedia_Foundation_Design/Agora_Control_Lib...
I'm using the format of questions to capture behaviors, that won't be the final state of this, but its helpful to capture some of the places that will need clarity, like the control UI style guide itself this will grow and change over time, as people interact with it.
I'm done for the night, so if you have questions to add, please do so, I'll be expanding on answering the questions, and beginning to write guidelines and create images to illustrate some of the principals.
*Jared Zimmerman * \ Director of User Experience \ Wikimedia Foundation
M : +1 415 609 4043 | : @JaredZimmermanhttps://twitter.com/JaredZimmerman
On Tue, Nov 5, 2013 at 7:25 PM, Yuvi Panda yuvipanda@gmail.com wrote:
As a developer, +infinity to everything Steven said. A 'living' document that gets changed frequently is vastly better than no document at all.
-- Yuvi Panda T http://yuvi.in/blog
Design mailing list Design@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/design
On Tue, Nov 5, 2013 at 8:49 PM, Jared Zimmerman < jared.zimmerman@wikimedia.org> wrote:
I'm beginning to catalog behaviors here https://www.mediawiki.org/wiki/Wikimedia_Foundation_Design/Agora_Control_Lib...
It sounds like you're going to write a new < https://www.mediawiki.org/wiki/Wikimedia_Foundation_Design/Patterns_and_comp... , but two levels down. If you can't adapt that, please Be Bold and move it to /Old and move yours up.
I'm using the format of questions to capture behaviors, that won't be the final state of this, but its helpful to capture some of the places that will need clarity, like the control UI style guide itself this will grow and change over time, as people interact with it.
Explaining behaviors is good, but the biggest boost to clarity will come when designers add consistent text and names to the excellent specs and mockups you've already built. Or you chop the specs up to fit these wiki pages, which seems a lot of work. Maybe there's wiki markup to, e.g. show a portion of page 3 of Agora_specs.pdf within a wiki page; I couldn't figure it out and so took a cropped screenshot for < https://www.mediawiki.org/wiki/Wikimedia_Foundation_Design/Patterns_and_comp... , which sucks when you revise the original.
Clarity will also come when the LESS files use the same names and reference wiki pages in their comments.
For example, the names in < https://www.mediawiki.org/wiki/Wikimedia_Foundation_Design/Agora_Control_Lib... like "Neutral, Progressive, Destructive, and Constructive" are very helpful, but they're not in the mockups. I love your "Quiet action"[1], but what does it look like? Is it a secondary action that doesn't have a button outline?
I'm done for the night, so if you have questions to add, please do so,
The highest priority are the grid of buttons in Agora specs.pdf page 3 "Buttons" , we need good class names for their LESS implementation, and decide what to do with the current mw-ui- classes. Let's nail 'em down tomorrow.
The Behaviors terminology is different from its parent page < https://www.mediawiki.org/wiki/Wikimedia_Foundation_Design/Agora_Control_Lib.... Terms that appear in one and not the other include:
Behaviors: primary, secondary, CTA, action buttons action bar
ACL: Quiet action, neutral null state. action rail
[1] subtle Human League ♩♫ reference :-) Cheers,
I'd like to propose we go with "*N*eutral, *P*rogressive, *D*estructive, and *C*onstructive" for the actual names in code.
Primary = button boundary is drawn (uses *N,P,D,C* states above) Secondary = stylized text with custom hover effects, but no button boundary (uses *N,P,D,C* states above) Quiet = a name I just made up for a button that is one of the* P,D,C*states above when in hover, click, or clicked, but *N*eutral when there is no user interaction, Its currently used for Thank in flow.
Action rail/bar = what we've (in design) been calling the icons that are right aligned in flow for things like watch,, permalink, edit, flag. As well as being used in the mockups for multimedia actions like flag, thank, share, use, for images.
Neutral null state = Primary Neutral (buttons) in a state where a user is not interacting with the control, wasn't trying to to be obtuse.
CTA = Call to action = Button we want user to press to move a process flow along
*Jared Zimmerman * \ Director of User Experience \ Wikimedia Foundation
M : +1 415 609 4043 | : @JaredZimmermanhttps://twitter.com/JaredZimmerman
On Wed, Nov 6, 2013 at 9:28 PM, S Page spage@wikimedia.org wrote:
On Tue, Nov 5, 2013 at 8:49 PM, Jared Zimmerman < jared.zimmerman@wikimedia.org> wrote:
I'm beginning to catalog behaviors here https://www.mediawiki.org/wiki/Wikimedia_Foundation_Design/Agora_Control_Lib...
It sounds like you're going to write a new < https://www.mediawiki.org/wiki/Wikimedia_Foundation_Design/Patterns_and_comp... , but two levels down. If you can't adapt that, please Be Bold and move it to /Old and move yours up.
I'm using the format of questions to capture behaviors, that won't be the final state of this, but its helpful to capture some of the places that will need clarity, like the control UI style guide itself this will grow and change over time, as people interact with it.
Explaining behaviors is good, but the biggest boost to clarity will come when designers add consistent text and names to the excellent specs and mockups you've already built. Or you chop the specs up to fit these wiki pages, which seems a lot of work. Maybe there's wiki markup to, e.g. show a portion of page 3 of Agora_specs.pdf within a wiki page; I couldn't figure it out and so took a cropped screenshot for < https://www.mediawiki.org/wiki/Wikimedia_Foundation_Design/Patterns_and_comp... , which sucks when you revise the original.
Clarity will also come when the LESS files use the same names and reference wiki pages in their comments.
For example, the names in < https://www.mediawiki.org/wiki/Wikimedia_Foundation_Design/Agora_Control_Lib... like "Neutral, Progressive, Destructive, and Constructive" are very helpful, but they're not in the mockups. I love your "Quiet action"[1], but what does it look like? Is it a secondary action that doesn't have a button outline?
I'm done for the night, so if you have questions to add, please do so,
The highest priority are the grid of buttons in Agora specs.pdf page 3 "Buttons" , we need good class names for their LESS implementation, and decide what to do with the current mw-ui- classes. Let's nail 'em down tomorrow.
The Behaviors terminology is different from its parent page < https://www.mediawiki.org/wiki/Wikimedia_Foundation_Design/Agora_Control_Lib.... Terms that appear in one and not the other include:
Behaviors: primary, secondary, CTA, action buttons action bar
ACL: Quiet action, neutral null state. action rail
[1] subtle Human League ♩♫ reference :-) Cheers, -- =S Page Features engineer
Design mailing list Design@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/design
On Wed, Nov 6, 2013 at 10:15 PM, Jared Zimmerman < jared.zimmerman@wikimedia.org> wrote:
I'd like to propose we go with "*N*eutral, *P*rogressive, *D*estructive, and *C*onstructive" for the actual names in code.
I've heard a bit about this before, but I'm still confused about why there need to be different Progressive and Constructive button types.
I think as far as users are concerned, there are only essentially two kinds of buttons they look for: Yes or No. (e.g. Confirm or Cancel, Save or Discard, and so on). We definitely need a neutral button type for "third options" like Preview or Review changes. But two types representing positive response and moving forward? Seems like we're maybe overcomplicating things.
Most multi-step process UI patterns include something for a "which step am I on" wayfinding, the big question is usually how few steps can you get away with not showing this UI element, 2? 3? 4? its murky. Since we don't have that many complex multi-step processes, this was an idea to sidestep the whole issues. button is blue, "I'm not done," button is green, "I'm done" I think it will be a subtle distinction for most users, some may not even notice, and thats fine. If in the end we declare it a total failure we can just clone mw.ui.button.constructive over mw.ui.button.progressive and call it a day. The rules for when you use one over the other are pretty clear in most cases. In general we always look to existing patterns we can borrow or steal, but sometime we invent something new. This is that case, we could use one of the many breadcrumbs, pagination hacks, progress bars, etc. but these feel over-designed for our simple 2-3 step processes, and are more cognitive weight for users that we really want. We could try to use an off the shelf pattern and adjust it for our needs, or we could try something new. let's try something new.
p.s. Preview would be a progressive action, not a neutral one, since the user would need to Save to finish the process flow of making an edit.
*Jared Zimmerman * \ Director of User Experience \ Wikimedia Foundation
M : +1 415 609 4043 | : @JaredZimmermanhttps://twitter.com/JaredZimmerman
On Wed, Nov 6, 2013 at 10:29 PM, Steven Walling swalling@wikimedia.orgwrote:
On Wed, Nov 6, 2013 at 10:15 PM, Jared Zimmerman < jared.zimmerman@wikimedia.org> wrote:
I'd like to propose we go with "*N*eutral, *P*rogressive, *D*estructive, and *C*onstructive" for the actual names in code.
I've heard a bit about this before, but I'm still confused about why there need to be different Progressive and Constructive button types.
I think as far as users are concerned, there are only essentially two kinds of buttons they look for: Yes or No. (e.g. Confirm or Cancel, Save or Discard, and so on). We definitely need a neutral button type for "third options" like Preview or Review changes. But two types representing positive response and moving forward? Seems like we're maybe overcomplicating things.
-- Steven Walling, Product Manager https://wikimediafoundation.org/
Design mailing list Design@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/design
On Wed, Nov 6, 2013 at 10:51 PM, Jared Zimmerman < jared.zimmerman@wikimedia.org> wrote:
p.s. Preview would be a progressive action, not a neutral one, since the user would need to Save to finish the process flow of making an edit.
This is an example of why I think having the two states is potentially too big a burden on the user. In your scheme, Save and Preview would each be a large colored button, one green and one blue, correct? This seems potentially detrimental, since they're right next to each other, and thus would seem like they have the same priority.
On login right now, we're using something like the scheme you proposed, but the visual hierarchy is really really obvious because of the placement in the vertical form. It's a login submit button and then a CTA.
I'd just like to say that Steven makes rather good points here, and I agree.
On 07/11/13 07:05, Steven Walling wrote:
On Wed, Nov 6, 2013 at 10:51 PM, Jared Zimmerman <jared.zimmerman@wikimedia.org mailto:jared.zimmerman@wikimedia.org> wrote:
p.s. Preview would be a progressive action, not a neutral one, since the user would need to Save to finish the process flow of making an edit.This is an example of why I think having the two states is potentially too big a burden on the user. In your scheme, Save and Preview would each be a large colored button, one green and one blue, correct? This seems potentially detrimental, since they're right next to each other, and thus would seem like they have the same priority.
On login right now, we're using something like the scheme you proposed, but the visual hierarchy is really really obvious because of the placement in the vertical form. It's a login submit button and then a CTA.
-- Steven Walling, Product Manager https://wikimediafoundation.org/
Design mailing list Design@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/design
On Wed, Nov 6, 2013 at 11:08 PM, Isarra Yos zhorishna@gmail.com wrote:
I'd just like to say that Steven makes rather good points here, and I agree.
Thanks Isarra.
I feel like I should add that I'm seriously behind the general direction we're taking with the revisions to mediawiki.ui controls, including the new color scheme and so on. But even the basic semantics of "constructive", "destructive", and so one we previously attempted for mediawiki.ui seemed to confuse some folks, and isn't quite right.
What if we retain your scheme Jared as described, but add a rule regarding behavior of Progressive and Constructive actions being adjacent? I like the "Quiet" state you guys are using for Thank buttons in Flow. Might Preview behave the same way?
On 2013-11-06 11:05 PM, Steven Walling wrote:
On Wed, Nov 6, 2013 at 10:51 PM, Jared Zimmerman <jared.zimmerman@wikimedia.org mailto:jared.zimmerman@wikimedia.org> wrote:
p.s. Preview would be a progressive action, not a neutral one, since the user would need to Save to finish the process flow of making an edit.This is an example of why I think having the two states is potentially too big a burden on the user. In your scheme, Save and Preview would each be a large colored button, one green and one blue, correct? This seems potentially detrimental, since they're right next to each other, and thus would seem like they have the same priority.
On login right now, we're using something like the scheme you proposed, but the visual hierarchy is really really obvious because of the placement in the vertical form. It's a login submit button and then a CTA.
-- Steven Walling, Product Manager https://wikimediafoundation.org/
I do see a need for 4 buttons states but I don't agree with this NPDC structure either. Specifically I do not like calling the dark blue button "Constructive". I don't consider Constructive to be Blue nor do I consider Green to be a form of progress through the form.
From my perspective a green button implies a form of creation or
sometimes success (however green as "success" is typically reserved for messages, progress bars, etc... not buttons). This implication differs from that of the dark blue button (which in other UX such as bootstrap's I've seen called "primary") and I think that both of them are necessary.
My perspective is that these states are needed (colours are for my/our culture but may be substituted if another culture or even design has different expectations): Neutral = Grey Destructive = Red Constructive = Green Primary = Blue
On the edit page the submit button would be Primary (Blue) while the others are Neutral (Grey).
Constructive buttons are the antonym to Destructive buttons. Destructive buttons imply you are about to destroy something or do something hard to take back. Constructive buttons imply you are about to immediately create or add something new. In general most of our current forms wont start using Constructive right away. Our edit form, login forms, move, etc... typically have the implication of submitting a form rather than truly creating something and for those forms the submit button should be Primary.
However Constructive buttons may find situations they are useful in future creations. A good example for the use of Constructive buttons is something where something you're modifying is laid out as a vertical table of entries. You may have red Destructive items for each entry on the table. And a green Constructive button down at the bottom as part of a UI for adding a new entry.
I don't necessarily mean a table editor but something where the individual entries in the database are simple enough to be laid out as a table. For example a special page listing interwiki prefixes with a green Constructive button to either add a new interwiki or open a larger form to add a new interwiki (which one it does is implied by whether the button is part of an inline form or alone). Another example is on a larger type of edit page form (maybe something like one in a Semantic Form's UI) that has a blue Primary submit button at the end there may be a list or table of stuff somewhere in the middle (say one listing categories or template sub-entries in the form) with a green Constructive button on the same page below the list that adds a new entry before you save.
~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://danielfriesen.name/]
On Wed, Nov 6, 2013 at 11:40 PM, Daniel Friesen daniel@nadir-seen-fire.comwrote:
Neutral = Grey Destructive = Red Constructive = Green Primary = Blue
Should we start a new thread about this, and keep the conversation on the topic of button semantics and the according CSS? :)
For reference: https://www.mediawiki.org/wiki/File:Agoraswatch.png is the current palette.
Great conversation everyone, looking forward to seeing everyone weigh in, I don't want to get too far down into the weeds of form design though. Let's leave that for the designers of individual features. My hope is that we'd have some general principals and a system that is flexible enough to implement them. Designing theoretical UI libraries and coming up with possible issues with them is something we could probably do until the end of time.
I propose we try this proposal in code, on real process flows that actually exists and inform our decisions of what to change and how to change it on actual user feedback and testing.
The subtleties of color and arrangement will change, I have no doubt, but let's not get so caught up in the what ifs that we don't actually make things.
Sent while mobile
On Nov 7, 2013, at 12:00 AM, Steven Walling swalling@wikimedia.org wrote:
On Wed, Nov 6, 2013 at 11:40 PM, Daniel Friesen daniel@nadir-seen-fire.com wrote:
Neutral = Grey Destructive = Red Constructive = Green Primary = Blue
Should we start a new thread about this, and keep the conversation on the topic of button semantics and the according CSS? :)
For reference: https://www.mediawiki.org/wiki/File:Agoraswatch.png is the current palette.
I propose we try this proposal in code, on real process flows that actually exists and inform our decisions of what to change and how to change it on actual user feedback and testing.
I totally agree with this. However, in my opinion there are some aspects that we need to support better for this to work in practice:
- *Make it easier to contribute from projects.* With previous incarnations of Agora I tried to contribute changes: a loading indicator control (GitHub pull request https://github.com/wikimedia/agora/pull/7that I later converted into Gerrit patchset https://gerrit.wikimedia.org/r/#/c/53353/ when the GitHub repo was deprecated) and a spacing fixhttps://gerrit.wikimedia.org/r/#/c/75079/. Nothing got merged nor requests for improvement were made. I think this is due to: - The fact that this involves merging into core, so it makes it hard to accept a component that works for a specific project and will become more generic in the future by iterating. - The lack of a clear discussion process: Since this involved different roles and teams it is hard to solve, but we need clarity on who should contributors ask to reviewing and approve those changes. - The difficulty to review UI code without context. Even for a simple change of colour or padding, the person reviewing the change needs to answers many questions (how dis it look before? how does it look now?, is it affecting the look of any other component anywhere else in the system?) which require a lot of work to answer. Make it easy to view the UI components would facilitate this process (which leads to the next point). - *Make it easy to check the current status.* If the current state of the style is embedded into a specific project, or a local installation of Mediawiki is needed, we are putting too much barriers for most of our users (think on the steps that a volunteer designer at a Hackathon should do to view the Agora buttons and suggest a different tone of blue). Ideally we should be able to provide a single source of truth that can be easily viewed, shared, and contributed to. The more replication and barriers, the hardest it will be to put a quick iterative process to work.
Don't take the above as a complaint. Making a process that involves many teams and roles work fluently is really hard. I just wanted to share some of the issues I found when tried to go through this process in previous attempts so that we can learn from previous experiences.
Pau
On Thu, Nov 7, 2013 at 10:52 AM, Jared Zimmerman jzimmerman@wikimedia.orgwrote:
Great conversation everyone, looking forward to seeing everyone weigh in, I don't want to get too far down into the weeds of form design though. Let's leave that for the designers of individual features. My hope is that we'd have some general principals and a system that is flexible enough to implement them. Designing theoretical UI libraries and coming up with possible issues with them is something we could probably do until the end of time.
I propose we try this proposal in code, on real process flows that actually exists and inform our decisions of what to change and how to change it on actual user feedback and testing.
The subtleties of color and arrangement will change, I have no doubt, but let's not get so caught up in the what ifs that we don't actually make things.
Sent while mobile
On Nov 7, 2013, at 12:00 AM, Steven Walling swalling@wikimedia.org wrote:
On Wed, Nov 6, 2013 at 11:40 PM, Daniel Friesen < daniel@nadir-seen-fire.com> wrote:
Neutral = Grey Destructive = Red Constructive = Green Primary = Blue
Should we start a new thread about this, and keep the conversation on the topic of button semantics and the according CSS? :)
For reference: https://www.mediawiki.org/wiki/File:Agoraswatch.png is the current palette.
-- Steven Walling, Product Manager https://wikimediafoundation.org/ _______________________________________________ Design mailing list Design@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/design
Design mailing list Design@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/design
*Make it easier to contribute from projects. *— brought this up with the team working on the mediawiki.ui/oo.ui UX standardization work, great point, and critical to the success of the projects.
*Make it easy to check the current status.* — Jon is working on this, it will be the focus of the next mediawiki.ui hack day on the 11th.
*Jared Zimmerman * \ Director of User Experience \ Wikimedia Foundation
M : +1 415 609 4043 | : @JaredZimmermanhttps://twitter.com/JaredZimmerman
On Thu, Nov 7, 2013 at 2:59 AM, Pau Giner pginer@wikimedia.org wrote:
I propose we try this proposal in code, on real process flows that
actually exists and inform our decisions of what to change and how to change it on actual user feedback and testing.
I totally agree with this. However, in my opinion there are some aspects that we need to support better for this to work in practice:
- *Make it easier to contribute from projects.* With previous
incarnations of Agora I tried to contribute changes: a loading indicator control (GitHub pull requesthttps://github.com/wikimedia/agora/pull/7that I later converted into Gerrit patchset https://gerrit.wikimedia.org/r/#/c/53353/ when the GitHub repo was deprecated) and a spacing fixhttps://gerrit.wikimedia.org/r/#/c/75079/. Nothing got merged nor requests for improvement were made. I think this is due to: - The fact that this involves merging into core, so it makes it hard to accept a component that works for a specific project and will become more generic in the future by iterating. - The lack of a clear discussion process: Since this involved different roles and teams it is hard to solve, but we need clarity on who should contributors ask to reviewing and approve those changes. - The difficulty to review UI code without context. Even for a simple change of colour or padding, the person reviewing the change needs to answers many questions (how dis it look before? how does it look now?, is it affecting the look of any other component anywhere else in the system?) which require a lot of work to answer. Make it easy to view the UI components would facilitate this process (which leads to the next point).
- *Make it easy to check the current status.* If the current state of
the style is embedded into a specific project, or a local installation of Mediawiki is needed, we are putting too much barriers for most of our users (think on the steps that a volunteer designer at a Hackathon should do to view the Agora buttons and suggest a different tone of blue). Ideally we should be able to provide a single source of truth that can be easily viewed, shared, and contributed to. The more replication and barriers, the hardest it will be to put a quick iterative process to work.
Don't take the above as a complaint. Making a process that involves many teams and roles work fluently is really hard. I just wanted to share some of the issues I found when tried to go through this process in previous attempts so that we can learn from previous experiences.
Pau
On Thu, Nov 7, 2013 at 10:52 AM, Jared Zimmerman <jzimmerman@wikimedia.org
wrote:
Great conversation everyone, looking forward to seeing everyone weigh in, I don't want to get too far down into the weeds of form design though. Let's leave that for the designers of individual features. My hope is that we'd have some general principals and a system that is flexible enough to implement them. Designing theoretical UI libraries and coming up with possible issues with them is something we could probably do until the end of time.
I propose we try this proposal in code, on real process flows that actually exists and inform our decisions of what to change and how to change it on actual user feedback and testing.
The subtleties of color and arrangement will change, I have no doubt, but let's not get so caught up in the what ifs that we don't actually make things.
Sent while mobile
On Nov 7, 2013, at 12:00 AM, Steven Walling swalling@wikimedia.org wrote:
On Wed, Nov 6, 2013 at 11:40 PM, Daniel Friesen < daniel@nadir-seen-fire.com> wrote:
Neutral = Grey Destructive = Red Constructive = Green Primary = Blue
Should we start a new thread about this, and keep the conversation on the topic of button semantics and the according CSS? :)
For reference: https://www.mediawiki.org/wiki/File:Agoraswatch.png is the current palette.
-- Steven Walling, Product Manager https://wikimediafoundation.org/ _______________________________________________ Design mailing list Design@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/design
Design mailing list Design@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/design
-- Pau Giner Interaction Designer Wikimedia Foundation
Design mailing list Design@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/design
On 11/07/2013 11:59 AM, Pau Giner wrote:
"Make it easier to contribute from projects. With previous incarnations of Agora I tried to contribute changes: a loading indicator control (GitHub pull request that I later converted into Gerrit patchset when the GitHub repo was deprecated) and a spacing fix. Nothing got merged nor requests for improvement were made.
If this is still open, please add me as a reviewer, then ping me if needed.
I think this is due to: The fact that this involves merging into core, so it makes it hard to accept a component that works for a specific project and will become more generic in the future by iterating.
Stuff that goes in core should generally be usable by more than one project (meaning e.g. no excessive hard-coding), but that doesn't mean there already needs to be more than one user. Once it's in core, naturally other users may need certain changes/generalizations made, and we can iterate.
The lack of a clear discussion process: Since this involved different
roles and teams it is hard to solve, but we need clarity on who should contributors ask to reviewing and approve those changes.
In general, just select a few people who are familiar with the area/type of code, and/or might be interested.
If you're not sure, there is a JavaScript group (just put JavaScript in the "Add Reviewer" box) that can be used when JS is involved.
We can easily make a similar CSS or Design one if desired. Don't use this for every change, since it is a bit spammy.
You still might need to ping people by email or IRC if a change has stalled out.
The difficulty to review UI code without context. Even for a simple change of colour or padding, the person reviewing the change needs to answers many questions (how dis it look before? how does it look now?, is it affecting the look of any other component anywhere else in the system?) which require a lot of work to answer. Make it easy to view the UI components would facilitate this process (which leads to the next
point).
A solution to this is to make an example usage, which depends on the change. For example, say you were adding the loader control in change A, but there were no uses in core yet (not even in A). You can make a simple change B that is based on (Gerrit shows this as Dependencies) it.
B doesn't need to be actually mergable. It can be marked Example or such. It will still be easy to check out for visual testing.
Make it easy to check the current status. If the current state of the style is embedded into a specific project, or a local installation of Mediawiki is needed, we are putting too much barriers for most of our users (think on the steps that a volunteer designer at a Hackathon should do to view the Agora buttons and suggest a different tone of blue).
Prototypes are essential, but eventually there is really no substitute for environments to actually run the code. These can be:
1. MediaWiki-Vagrant (really quite easy to set up, though it is true download time takes a while initially). 2. Labs - We should reduce obstacles to setting up a wiki on Labs, but in the meantime every time should have wikis to test. Does UX? 3. Any other local or other MW environment.
Ideally we should be able to provide a single source of truth that can be easily viewed, shared, and contributed to.
That single source of truth is the code in Gerrit. Everything else is a prototype. It may be a great prototype, or a great spec, but it's still a prototype.
The more replication and barriers, the hardest it will be to put a
quick iterative process to work.
Agreed, I hope the above is a starting point to reducing barriers.
Matt Flaschen
On 13-11-06 09:28 PM, S Page wrote:
On Tue, Nov 5, 2013 at 8:49 PM, Jared Zimmerman <jared.zimmerman@wikimedia.org mailto:jared.zimmerman@wikimedia.org> wrote:
I'm beginning to catalog behaviors here https://www.mediawiki.org/wiki/Wikimedia_Foundation_Design/Agora_Control_Library/BehaviorIt sounds like you're going to write a new https://www.mediawiki.org/wiki/Wikimedia_Foundation_Design/Patterns_and_components , but two levels down. If you can't adapt that, please Be Bold and move it to /Old and move yours up.
I'm using the format of questions to capture behaviors, that won't be the final state of this, but its helpful to capture some of the places that will need clarity, like the control UI style guide itself this will grow and change over time, as people interact with it.Explaining behaviors is good, but the biggest boost to clarity will come when designers add consistent text and names to the excellent specs and mockups you've already built.
I love this graphic. https://www.wikidata.org/wiki/Help:Statements#Glossary_of_terms It makes sooooo much more sense of Wikidata's contents. (eg https://www.wikidata.org/wiki/Q42 )
It might help to do diagrams like that for various aspects of many products (such as Flow). Consistent naming of features (whether we're talking to each other, or writing documentation), is helped immensely by a diagram, at least for some people. Image is worth 1000 words.
Or you chop the specs up to fit these wiki pages, which seems a lot of work. Maybe there's wiki markup to, e.g. show a portion of page 3 of Agora_specs.pdf within a wiki page; I couldn't figure it out and so took a cropped screenshot for https://www.mediawiki.org/wiki/Wikimedia_Foundation_Design/Patterns_and_components#Buttons.2FActions , which sucks when you revise the original.
Clarity will also come when the LESS files use the same names and reference wiki pages in their comments.
For example, the names in https://www.mediawiki.org/wiki/Wikimedia_Foundation_Design/Agora_Control_Library like "Neutral, Progressive, Destructive, and Constructive" are very helpful, but they're not in the mockups. I love your "Quiet action"[1], but what does it look like? Is it a secondary action that doesn't have a button outline?
I'm done for the night, so if you have questions to add, please do so,The highest priority are the grid of buttons in Agora specs.pdf page 3 "Buttons" , we need good class names for their LESS implementation, and decide what to do with the current mw-ui- classes. Let's nail 'em down tomorrow.
The Behaviors terminology is different from its parent page https://www.mediawiki.org/wiki/Wikimedia_Foundation_Design/Agora_Control_Library. Terms that appear in one and not the other include:
Behaviors: primary, secondary, CTA, action buttons action bar
ACL: Quiet action, neutral null state. action rail
[1] subtle Human League ♩♫ reference :-) Cheers, -- =S Page Features engineer
Design mailing list Design@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/design
yes.
*Jared Zimmerman * \ Director of User Experience \ Wikimedia Foundation
M : +1 415 609 4043 | : @JaredZimmermanhttps://twitter.com/JaredZimmerman
On Tue, Nov 5, 2013 at 7:22 PM, Steven Walling swalling@wikimedia.orgwrote:
On Tue, Nov 5, 2013 at 7:01 PM, Jared Zimmerman < jared.zimmerman@wikimedia.org> wrote:
Thanks for this summary S, the "living style guide" mentioned in https://www.mediawiki.org/wiki/UX_standardization will include not only the visual styling of agora controls but best practices for using them. e.g. things like order of buttons (primary CTA rightmost) and what types of buttons should be disabled when invalid input is detected (places where a post would result in an error) as well as when to use different styles of buttons.
Can the UX team please write the copy for these best practices now, rather than later? We could really use the text accompaniment now, as we begin to build and test the revisions to mediawiki.ui.
For developers, having simple explanation of the intended patterns will ease the transition to a new mediawiki.ui look. For product managers, we'll be able to help make sure that our individual products conform to the general style guide.
Flow is not the only new product that is starting to conform to parts of the new mediawiki.ui spec. For Growth team projects like anonymous editor acquisition, onboarding, and article creation, Pau is already producing mockups that incorporate elements of the new design. If you can produce a single page guide with these best practices you describe, they can be used now and incorporated in to the more interactive living style guide later.
Steven
-- Steven Walling, Product Manager https://wikimediafoundation.org/
Design mailing list Design@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/design
On Monday I began writing a couple of Special pages. The purpose of this was to develop a proof of concept that could generate a style guide from our CSS files.
Would love to get this production ready and use this going forward to ensure we always have a live reference we can refer to...
https://github.com/jdlrobson/MediaWiki-SpecialCssStyleGuide On 5 Nov 2013 19:28, "Jared Zimmerman" jared.zimmerman@wikimedia.org wrote:
yes.
*Jared Zimmerman * \ Director of User Experience \ Wikimedia Foundation M : +1 415 609 4043 | : @JaredZimmermanhttps://twitter.com/JaredZimmerman
On Tue, Nov 5, 2013 at 7:22 PM, Steven Walling swalling@wikimedia.orgwrote:
On Tue, Nov 5, 2013 at 7:01 PM, Jared Zimmerman < jared.zimmerman@wikimedia.org> wrote:
Thanks for this summary S, the "living style guide" mentioned in https://www.mediawiki.org/wiki/UX_standardization will include not only the visual styling of agora controls but best practices for using them. e.g. things like order of buttons (primary CTA rightmost) and what types of buttons should be disabled when invalid input is detected (places where a post would result in an error) as well as when to use different styles of buttons.
Can the UX team please write the copy for these best practices now, rather than later? We could really use the text accompaniment now, as we begin to build and test the revisions to mediawiki.ui.
For developers, having simple explanation of the intended patterns will ease the transition to a new mediawiki.ui look. For product managers, we'll be able to help make sure that our individual products conform to the general style guide.
Flow is not the only new product that is starting to conform to parts of the new mediawiki.ui spec. For Growth team projects like anonymous editor acquisition, onboarding, and article creation, Pau is already producing mockups that incorporate elements of the new design. If you can produce a single page guide with these best practices you describe, they can be used now and incorporated in to the more interactive living style guide later.
Steven
-- Steven Walling, Product Manager https://wikimediafoundation.org/
Design mailing list Design@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/design
Design mailing list Design@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/design
Hi Jon, what do you need from Design to make this happen?
*Jared Zimmerman * \ Director of User Experience \ Wikimedia Foundation
M : +1 415 609 4043 | : @JaredZimmermanhttps://twitter.com/JaredZimmerman
On Wed, Nov 6, 2013 at 5:23 PM, Jon Robson jdlrobson@gmail.com wrote:
On Monday I began writing a couple of Special pages. The purpose of this was to develop a proof of concept that could generate a style guide from our CSS files.
Would love to get this production ready and use this going forward to ensure we always have a live reference we can refer to...
https://github.com/jdlrobson/MediaWiki-SpecialCssStyleGuide On 5 Nov 2013 19:28, "Jared Zimmerman" jared.zimmerman@wikimedia.org wrote:
yes.
*Jared Zimmerman * \ Director of User Experience \ Wikimedia Foundation M : +1 415 609 4043 | : @JaredZimmermanhttps://twitter.com/JaredZimmerman
On Tue, Nov 5, 2013 at 7:22 PM, Steven Walling swalling@wikimedia.orgwrote:
On Tue, Nov 5, 2013 at 7:01 PM, Jared Zimmerman < jared.zimmerman@wikimedia.org> wrote:
Thanks for this summary S, the "living style guide" mentioned in https://www.mediawiki.org/wiki/UX_standardization will include not only the visual styling of agora controls but best practices for using them. e.g. things like order of buttons (primary CTA rightmost) and what types of buttons should be disabled when invalid input is detected (places where a post would result in an error) as well as when to use different styles of buttons.
Can the UX team please write the copy for these best practices now, rather than later? We could really use the text accompaniment now, as we begin to build and test the revisions to mediawiki.ui.
For developers, having simple explanation of the intended patterns will ease the transition to a new mediawiki.ui look. For product managers, we'll be able to help make sure that our individual products conform to the general style guide.
Flow is not the only new product that is starting to conform to parts of the new mediawiki.ui spec. For Growth team projects like anonymous editor acquisition, onboarding, and article creation, Pau is already producing mockups that incorporate elements of the new design. If you can produce a single page guide with these best practices you describe, they can be used now and incorporated in to the more interactive living style guide later.
Steven
-- Steven Walling, Product Manager https://wikimediafoundation.org/
Design mailing list Design@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/design
Design mailing list Design@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/design
Design mailing list Design@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/design
My suggestion...
When working with teams going forward it would be good to get into the habit of making it that team's responsibility to eventually when the design is stabilised to ensure it gets described in core as a LESS file. In the mean time without this tool it would also be good for design to track what teams are working on which components and try to avoid the situation where multiple teams are working on the same thing.
Since so many teams are using buttons I personally believe it would be a good start to codify this and use this work to get the style guide up and running with this example.
Outside the design team, any help in coding this, reviewing it would be most appreciated. Any one who knows Ruby would be useful here since the NodeJS version of KSS is a bit out of date.
On Wed, Nov 6, 2013 at 5:37 PM, Jared Zimmerman < jared.zimmerman@wikimedia.org> wrote:
Hi Jon, what do you need from Design to make this happen?
*Jared Zimmerman * \ Director of User Experience \ Wikimedia Foundation M : +1 415 609 4043 | : @JaredZimmermanhttps://twitter.com/JaredZimmerman
On Wed, Nov 6, 2013 at 5:23 PM, Jon Robson jdlrobson@gmail.com wrote:
On Monday I began writing a couple of Special pages. The purpose of this was to develop a proof of concept that could generate a style guide from our CSS files.
Would love to get this production ready and use this going forward to ensure we always have a live reference we can refer to...
https://github.com/jdlrobson/MediaWiki-SpecialCssStyleGuide On 5 Nov 2013 19:28, "Jared Zimmerman" jared.zimmerman@wikimedia.org wrote:
yes.
*Jared Zimmerman * \ Director of User Experience \ Wikimedia Foundation M : +1 415 609 4043 | : @JaredZimmermanhttps://twitter.com/JaredZimmerman
On Tue, Nov 5, 2013 at 7:22 PM, Steven Walling swalling@wikimedia.orgwrote:
On Tue, Nov 5, 2013 at 7:01 PM, Jared Zimmerman < jared.zimmerman@wikimedia.org> wrote:
Thanks for this summary S, the "living style guide" mentioned in https://www.mediawiki.org/wiki/UX_standardization will include not only the visual styling of agora controls but best practices for using them. e.g. things like order of buttons (primary CTA rightmost) and what types of buttons should be disabled when invalid input is detected (places where a post would result in an error) as well as when to use different styles of buttons.
Can the UX team please write the copy for these best practices now, rather than later? We could really use the text accompaniment now, as we begin to build and test the revisions to mediawiki.ui.
For developers, having simple explanation of the intended patterns will ease the transition to a new mediawiki.ui look. For product managers, we'll be able to help make sure that our individual products conform to the general style guide.
Flow is not the only new product that is starting to conform to parts of the new mediawiki.ui spec. For Growth team projects like anonymous editor acquisition, onboarding, and article creation, Pau is already producing mockups that incorporate elements of the new design. If you can produce a single page guide with these best practices you describe, they can be used now and incorporated in to the more interactive living style guide later.
Steven
-- Steven Walling, Product Manager https://wikimediafoundation.org/
Design mailing list Design@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/design
Design mailing list Design@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/design
Design mailing list Design@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/design
Design mailing list Design@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/design
Sounds good, you might want to change the audience of the email, as i don't know that a huge number of people on the design list will be able to help with that last part.
*Jared Zimmerman * \ Director of User Experience \ Wikimedia Foundation
M : +1 415 609 4043 | : @JaredZimmermanhttps://twitter.com/JaredZimmerman
On Wed, Nov 6, 2013 at 5:58 PM, Jon Robson jrobson@wikimedia.org wrote:
My suggestion...
When working with teams going forward it would be good to get into the habit of making it that team's responsibility to eventually when the design is stabilised to ensure it gets described in core as a LESS file. In the mean time without this tool it would also be good for design to track what teams are working on which components and try to avoid the situation where multiple teams are working on the same thing.
Since so many teams are using buttons I personally believe it would be a good start to codify this and use this work to get the style guide up and running with this example.
Outside the design team, any help in coding this, reviewing it would be most appreciated. Any one who knows Ruby would be useful here since the NodeJS version of KSS is a bit out of date.
On Wed, Nov 6, 2013 at 5:37 PM, Jared Zimmerman < jared.zimmerman@wikimedia.org> wrote:
Hi Jon, what do you need from Design to make this happen?
*Jared Zimmerman * \ Director of User Experience \ Wikimedia Foundation M : +1 415 609 4043 | : @JaredZimmermanhttps://twitter.com/JaredZimmerman
On Wed, Nov 6, 2013 at 5:23 PM, Jon Robson jdlrobson@gmail.com wrote:
On Monday I began writing a couple of Special pages. The purpose of this was to develop a proof of concept that could generate a style guide from our CSS files.
Would love to get this production ready and use this going forward to ensure we always have a live reference we can refer to...
https://github.com/jdlrobson/MediaWiki-SpecialCssStyleGuide On 5 Nov 2013 19:28, "Jared Zimmerman" jared.zimmerman@wikimedia.org wrote:
yes.
*Jared Zimmerman * \ Director of User Experience \ Wikimedia Foundation M : +1 415 609 4043 | : @JaredZimmermanhttps://twitter.com/JaredZimmerman
On Tue, Nov 5, 2013 at 7:22 PM, Steven Walling swalling@wikimedia.orgwrote:
On Tue, Nov 5, 2013 at 7:01 PM, Jared Zimmerman < jared.zimmerman@wikimedia.org> wrote:
Thanks for this summary S, the "living style guide" mentioned in https://www.mediawiki.org/wiki/UX_standardization will include not only the visual styling of agora controls but best practices for using them. e.g. things like order of buttons (primary CTA rightmost) and what types of buttons should be disabled when invalid input is detected (places where a post would result in an error) as well as when to use different styles of buttons.
Can the UX team please write the copy for these best practices now, rather than later? We could really use the text accompaniment now, as we begin to build and test the revisions to mediawiki.ui.
For developers, having simple explanation of the intended patterns will ease the transition to a new mediawiki.ui look. For product managers, we'll be able to help make sure that our individual products conform to the general style guide.
Flow is not the only new product that is starting to conform to parts of the new mediawiki.ui spec. For Growth team projects like anonymous editor acquisition, onboarding, and article creation, Pau is already producing mockups that incorporate elements of the new design. If you can produce a single page guide with these best practices you describe, they can be used now and incorporated in to the more interactive living style guide later.
Steven
-- Steven Walling, Product Manager https://wikimediafoundation.org/
Design mailing list Design@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/design
Design mailing list Design@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/design
Design mailing list Design@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/design
Design mailing list Design@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/design
Design mailing list Design@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/design