There is a conversation going on here about consolidating constructive and progressive buttons: https://phabricator.wikimedia.org/T110555
I want to find out if any of you have used these buttons in your interface and have done any testing with your users to see if they understand the difference between the two. Also, if you have used it in other ways that has been helpful to your users, chime in!
Progressive (blue) conveys to the user that they are starting or continuing a multi-step process. Constructive (green) conveys to the user they are completing a single or multi-step process. In most case Constructive color shows the user what will happen. In others it is feedback that the action has completed. For example, thanking a user, adding a page to a watch list.
-- Related discussion about button consolidation: https://phabricator.wikimedia.org/T110565
mm
I would just clarify that constructive buttons are used to indicate an action creates something, rather than just modifying it. Similarly, we use destructive buttons to indicate the inverse, that something is actually being removed. Constructive and destructive don't have anything in particular to do with multi-step processes, only what the process does.
- Trevor
On Tue, Oct 20, 2015 at 6:14 PM, May Tee-Galloway mgalloway@wikimedia.org wrote:
There is a conversation going on here about consolidating constructive and progressive buttons: https://phabricator.wikimedia.org/T110555
I want to find out if any of you have used these buttons in your interface and have done any testing with your users to see if they understand the difference between the two. Also, if you have used it in other ways that has been helpful to your users, chime in!
Progressive (blue) conveys to the user that they are starting or continuing a multi-step process. Constructive (green) conveys to the user they are completing a single or multi-step process. In most case Constructive color shows the user what will happen. In others it is feedback that the action has completed. For example, thanking a user, adding a page to a watch list.
-- Related discussion about button consolidation: https://phabricator.wikimedia.org/T110565
mm
Design mailing list Design@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/design
On Tue, Oct 20, 2015 at 6:31 PM, Trevor Parscal tparscal@wikimedia.org wrote:
I would just clarify that constructive buttons are used to indicate an action creates something, rather than just modifying it. Similarly, we use destructive buttons to indicate the inverse, that something is actually being removed. Constructive and destructive don't have anything in particular to do with multi-step processes, only what the process does.
Hi Trevor,
May was talking about constructive vs. PROGRESSIVE buttons here. Did you misread her email, or are you making a secondary point? It's unclear from your message.
Best, Jonathan
- Trevor
On Tue, Oct 20, 2015 at 6:14 PM, May Tee-Galloway <mgalloway@wikimedia.org
wrote:
There is a conversation going on here about consolidating constructive and progressive buttons: https://phabricator.wikimedia.org/T110555
I want to find out if any of you have used these buttons in your interface and have done any testing with your users to see if they understand the difference between the two. Also, if you have used it in other ways that has been helpful to your users, chime in!
Progressive (blue) conveys to the user that they are starting or continuing a multi-step process. Constructive (green) conveys to the user they are completing a single or multi-step process. In most case Constructive color shows the user what will happen. In others it is feedback that the action has completed. For example, thanking a user, adding a page to a watch list.
-- Related discussion about button consolidation: https://phabricator.wikimedia.org/T110565
mm
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
Sorry if I'm unclear, but yes I fully understand.
I felt that her description somewhat misrepresented the purpose of constructive in relation to progressive.
Essentially, I read her description as saying constructive was simply a final step, when in fact it's designed to provide the user a hint that something will be created - no matter the step.
- Trevor
On Wednesday, October 21, 2015, Jonathan Morgan jmorgan@wikimedia.org wrote:
On Tue, Oct 20, 2015 at 6:31 PM, Trevor Parscal <tparscal@wikimedia.org javascript:_e(%7B%7D,'cvml','tparscal@wikimedia.org');> wrote:
I would just clarify that constructive buttons are used to indicate an action creates something, rather than just modifying it. Similarly, we use destructive buttons to indicate the inverse, that something is actually being removed. Constructive and destructive don't have anything in particular to do with multi-step processes, only what the process does.
Hi Trevor,
May was talking about constructive vs. PROGRESSIVE buttons here. Did you misread her email, or are you making a secondary point? It's unclear from your message.
Best, Jonathan
- Trevor
On Tue, Oct 20, 2015 at 6:14 PM, May Tee-Galloway < mgalloway@wikimedia.org javascript:_e(%7B%7D,'cvml','mgalloway@wikimedia.org');> wrote:
There is a conversation going on here about consolidating constructive and progressive buttons: https://phabricator.wikimedia.org/T110555
I want to find out if any of you have used these buttons in your interface and have done any testing with your users to see if they understand the difference between the two. Also, if you have used it in other ways that has been helpful to your users, chime in!
Progressive (blue) conveys to the user that they are starting or continuing a multi-step process. Constructive (green) conveys to the user they are completing a single or multi-step process. In most case Constructive color shows the user what will happen. In others it is feedback that the action has completed. For example, thanking a user, adding a page to a watch list.
-- Related discussion about button consolidation: https://phabricator.wikimedia.org/T110565
mm
Design mailing list Design@lists.wikimedia.org javascript:_e(%7B%7D,'cvml','Design@lists.wikimedia.org'); https://lists.wikimedia.org/mailman/listinfo/design
Design mailing list Design@lists.wikimedia.org javascript:_e(%7B%7D,'cvml','Design@lists.wikimedia.org'); https://lists.wikimedia.org/mailman/listinfo/design
-- Jonathan T. Morgan Senior Design Researcher Wikimedia Foundation User:Jmorgan (WMF) https://meta.wikimedia.org/wiki/User:Jmorgan_(WMF)
On 2015-10-21 17:03, Trevor Parscal wrote:
Essentially, I read her description as saying constructive was simply a final step, when in fact it's designed to provide the user a hint that something will be created - no matter the step.
What May says does seem to better match how these are used in practice. For example, on https://phabricator.wikimedia.org/T113493 several people requested the green constructive button on the form on Special:MovePage, which doesn't "create" anything.
I think I said it elsewhere a few times, but I believe we have way too many kinds of buttons. We should definitely consolidate "constructive" and "progressive", especially since judging by this email thread, nobody really knows what exactly the difference is supposed to be.
nobody really knows what exactly the difference is supposed to be.
I've had a few conversations on how to use these buttons, people seem abit confused and I started to wonder myself if the intended impact is greater than the confusion caused. The way we described its usage could also be a factor.
However, there may be an alternative use to green buttons that might still warrant its existence. That's what I'd like to learn from everyone. I'll report back if I find something too.
mm
On Wed, Oct 21, 2015 at 10:32 AM, Bartosz Dziewoński matma.rex@gmail.com wrote:
I think I said it elsewhere a few times, but I believe we have way too many kinds of buttons. We should definitely consolidate "constructive" and "progressive", especially since judging by this email thread, nobody really knows what exactly the difference is supposed to be.
-- Bartosz Dziewoński
Design mailing list Design@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/design
One problem I have run into recently is that for a complex form you are not necessarily able to tell which step is the last. E.g. after you submit the login form and MediaWiki verifies your credentials, depending on your user settings you might or might not be presented with a two-factor challenge; so submitting the user name and password might or might not be the last step of the form. (Arguably login should not be constructive in the first place, but it is now. In any case, similar problems could be present with the user registration form, which does create something.)
Personally, I agree with Bartosz that having four button types (five or more if we include silent buttons) just makes the interface confusing.
At some point a couple of years ago, the idea of encoding behavior hints into the colors of the user interface became a major part of MediaWiki UI styling, and OOjs UI had something similar so the two concepts merged. The problem has always been when you start using the buttons in practice, the interface is really loud and confusing because it's blasted with giant bright colored squares on otherwise very light white and gray controls. This has always been a challenge, and in OOjs UI we ended up adding "primary" as an additional designation so only the primary action was a bright color and other buttons were quieter with only colored text and outlines. Which is actually a 4 x 2 matrix of buttons. Owch.
I look forward to May returning with some analysis.
On Wed, Oct 21, 2015 at 11:59 AM, Gergo Tisza gtisza@wikimedia.org wrote:
One problem I have run into recently is that for a complex form you are not necessarily able to tell which step is the last. E.g. after you submit the login form and MediaWiki verifies your credentials, depending on your user settings you might or might not be presented with a two-factor challenge; so submitting the user name and password might or might not be the last step of the form. (Arguably login should not be constructive in the first place, but it is now. In any case, similar problems could be present with the user registration form, which does create something.)
Personally, I agree with Bartosz that having four button types (five or more if we include silent buttons) just makes the interface confusing.
Design mailing list Design@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/design
* There are always gray areas in applying a design guide, that's not a good argument for consolidation. Whether a particular URL should be a link or a button is often tricky, but we still have buttons. * Users not understanding the design is no argument for consolidation, I bet users get an 'D' at best on Material and every other human interest guideline.
I like Trevor's idea that Constructive makes something. Maybe that's why the Special:Search button is progressive, or maybe the argument was it leads to something else. And the way progressive buttons in the middle of a dialog shift to a constructive button at the [Let's Roll!] stage is a great UX thing. And Green for Thanks, because in an unfriendly often toxic "community" it's a nice Constructive thing to do, is a happy byproduct of the naming conventions. That's at least three uses that go away if we consolidate Constructive and Progressive.
Trevor wrote
the interface is really loud and confusing because it's blasted with
giant bright colored squares on otherwise very light white and gray controls
"Confusing" doesn't follow at all from your aesthetic response to the design. As I type this I'm "blasted with a giant bright colored [Send] square", but I think Google knows what it's doing. There are many ways to tamp down the Skittles appearance of the MediaWiki UI and the style guide [1] is clear: "Under no circumstance should an interface display more that one *Primary* button colored with *Intention*." If Quiet and Neutral aren't sufficient Shahyar prototyped at least two more excellent ideas (I can't find the link right now...)
If any clarification comes out of this discussion, the http://livingstyleguide.wmflabs.org [2] should be our one and only guideline. It can acknowledge grey areas without getting bogged down in details. Maybe it can have footnotes or § links to Solomonic appendices on edge cases.
Cheers,
[1] http://livingstyleguide.wmflabs.org/wiki/Buttons#Sets_of_buttons [2] See http://livingstyleguide.wmflabs.org/wiki/Main_Page#Color and livingstyleguide.wmflabs.org/wiki/Buttons#Button_Styles
On Wed, Oct 21, 2015 at 12:05 PM, Trevor Parscal tparscal@wikimedia.org wrote:
At some point a couple of years ago, the idea of encoding behavior hints into the colors of the user interface became a major part of MediaWiki UI styling, and OOjs UI had something similar so the two concepts merged. The problem has always been when you start using the buttons in practice, the interface is really loud and confusing because it's blasted with giant bright colored squares on otherwise very light white and gray controls. This has always been a challenge, and in OOjs UI we ended up adding "primary" as an additional designation so only the primary action was a bright color and other buttons were quieter with only colored text and outlines. Which is actually a 4 x 2 matrix of buttons. Owch.
I look forward to May returning with some analysis.
On Wed, Oct 21, 2015 at 11:59 AM, Gergo Tisza gtisza@wikimedia.org wrote:
One problem I have run into recently is that for a complex form you are not necessarily able to tell which step is the last. E.g. after you submit the login form and MediaWiki verifies your credentials, depending on your user settings you might or might not be presented with a two-factor challenge; so submitting the user name and password might or might not be the last step of the form. (Arguably login should not be constructive in the first place, but it is now. In any case, similar problems could be present with the user registration form, which does create something.)
Personally, I agree with Bartosz that having four button types (five or more if we include silent buttons) just makes the interface confusing.
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
On 21/10/15 19:46, S Page wrote:
Users not understanding the design is no argument for consolidation, I bet users get an 'D' at best on Material and every other human interest guideline.
If users aren't the ones we are designing for, then who is? Wasn't the whole point of the colours is to call the users' attention to them, and the point of differentiating is to tell the users that these are different things?
Otherwise, what is the purpose of any of this?
On Wed, Oct 21, 2015 at 12:46 PM, I wrote:
... every other human interest guideline.
Sorry, "Interface". Human interest guidelines lead to the horror of Daily Mail Online :-)
If Quiet and Neutral aren't sufficient Shahyar prototyped at least two more
excellent ideas (I can't find the link right now...)
http://area51.yar.gs/wmf/flow1/ To repeat, a page would only use a subset of these at any one time, ignore the overstuffed appearance.
On Wed, Oct 21, 2015 at 1:20 PM, Isarra Yos zhorishna@gmail.com wrote:
On 21/10/15 19:46, S Page wrote:
Users not understanding the design is no argument for consolidation, I bet users get an 'D' at best on Material and every other human interest guideline.
If users aren't the ones we are designing for, then who is?
Obviously design is for users. But having a pleasant productive time using a design and understanding its nuances are very different things. "Testing with your users to see if they understand the difference between [two button colors]" seems crazy (unless I misunderstand what designers mean by "understand"). Does Google test to see if users understand the difference between the rounded edge and the shadowed edge in Material? I really doubt it. Different colors and treatments provide different experiences, and there are guidelines when to use them.
Wasn't the whole point of the colours is to call the users' attention to them, and the point of differentiating is to tell the users that these are different things?
Sort of, and yes.
Designers, anything from you guys?
On Fri, Oct 23, 2015 at 11:28 AM, S Page spage@wikimedia.org wrote:
On Wed, Oct 21, 2015 at 12:46 PM, I wrote:
... every other human interest guideline.
Sorry, "Interface". Human interest guidelines lead to the horror of Daily Mail Online :-)
If Quiet and Neutral aren't sufficient Shahyar prototyped at least two more excellent ideas (I can't find the link right now...)
http://area51.yar.gs/wmf/flow1/ To repeat, a page would only use a subset of these at any one time, ignore the overstuffed appearance.
On Wed, Oct 21, 2015 at 1:20 PM, Isarra Yos zhorishna@gmail.com wrote:
On 21/10/15 19:46, S Page wrote:
Users not understanding the design is no argument for consolidation, I bet users get an 'D' at best on Material and every other human interest guideline.
If users aren't the ones we are designing for, then who is?
Obviously design is for users. But having a pleasant productive time using a design and understanding its nuances are very different things. "Testing with your users to see if they understand the difference between [two button colors]" seems crazy (unless I misunderstand what designers mean by "understand"). Does Google test to see if users understand the difference between the rounded edge and the shadowed edge in Material? I really doubt it. Different colors and treatments provide different experiences, and there are guidelines when to use them.
Wasn't the whole point of the colours is to call the users' attention to them, and the point of differentiating is to tell the users that these are different things?
Sort of, and yes.
-- =S Page WMF Tech writer
Design mailing list Design@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/design
On 23/10/15 18:28, S Page wrote:
Obviously design is for users. But having a pleasant productive time using a design and understanding its nuances are very different things. "Testing with your users to see if they understand the difference between [two button colors]" seems crazy (unless I misunderstand what designers mean by "understand"). Does Google test to see if users understand the difference between the rounded edge and the shadowed edge in Material? I really doubt it. Different colors and treatments provide different experiences, and there are guidelines when to use them.
That's nuances, details. Nevermind nuances. The question here is, on whatever level, does the distinction help the user? Have users noticed that there is a difference? Has it meant anything to them? Has anyone looked into this?
If it's shown to help, that's all we need. We have a justification for the maintenance overhead and stuff. And cookies. Always cookies. We should all go get some cookies.
I think one of the underlying aspects here is the idea of side-effects and safe navigation.
We learnt by using the web that buttons and links had generally different expectations. Links have been used for navigation purposes, while buttons are associated with commands which affect the status of the system. These associations make us to click links without having to fear any unexpected change in the system. This allows to navigate more fluently when those assumptions are met, and get into trouble when those are broken (e.g., a delete link in the middle of other navigation links).
I think the purpose of colour buttons is to set similar expectations. We highlight the next logical step and indicate whether some new content will be created (green) or destroyed (red) as an outcome. Creating and deleting content, even if these actions can be undone seems worth some considerations in an environment where content is public and edited collaboratively by many. So I think that setting these expectations is useful on helping the user to determine on which decisions to put more thought and which ones to do more fluently.
I think we can design great experiences with or without this pattern, but this is a pattern that requires to be applied consistently to work. We need to consider also that the resulting effects on the user affect more their intuition than their conscious thoughts. So while I think it can improve the user experience, it is not something easy to test just by asking if the user can figure out why the button is green instead of blue, even less if the user has not been exposed to a consistent application of the pattern for a while.
If the problem is that it is not easy to be applied consistently, we may consider clarifying the guidelines to indicate the cases where each one should use with as unambiguous definitions and clear examples as possible.
Google use of colour buttons has been mentioned. In this talk https://vimeo.com/29965463 (at 26:40) the code colour they used is explained: red for creating something, blue for do/confirm actions such as search, and green fro actions with an audience such as share. The fact Google has been using this approach does not mean that we need to follow, but it illustrates that associating colours to certain types of actions is not an unprecedented idea in the design of user interfaces.
Pau
On Sat, Oct 24, 2015 at 2:02 AM, Isarra Yos zhorishna@gmail.com wrote:
On 23/10/15 18:28, S Page wrote:
Obviously design is for users. But having a pleasant productive time using a design and understanding its nuances are very different things. "Testing with your users to see if they understand the difference between [two button colors]" seems crazy (unless I misunderstand what designers mean by "understand"). Does Google test to see if users understand the difference between the rounded edge and the shadowed edge in Material? I really doubt it. Different colors and treatments provide different experiences, and there are guidelines when to use them.
That's nuances, details. Nevermind nuances. The question here is, on whatever level, does the distinction help the user? Have users noticed that there is a difference? Has it meant anything to them? Has anyone looked into this?
If it's shown to help, that's all we need. We have a justification for the maintenance overhead and stuff. And cookies. Always cookies. We should all go get some cookies.
Design mailing list Design@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/design
See also https://phabricator.wikimedia.org/T116549 ("Provide a color palette and design for buttons that are purely highlighted links, to distinguish them from actual UI buttons") which I think needs designer and developer input.
On Mon, Oct 26, 2015 at 12:43 PM, Pau Giner pginer@wikimedia.org wrote:
I think one of the underlying aspects here is the idea of side-effects and safe navigation.
We learnt by using the web that buttons and links had generally different expectations. Links have been used for navigation purposes, while buttons are associated with commands which affect the status of the system. These associations make us to click links without having to fear any unexpected change in the system. This allows to navigate more fluently when those assumptions are met, and get into trouble when those are broken (e.g., a delete link in the middle of other navigation links).
I think the purpose of colour buttons is to set similar expectations. We highlight the next logical step and indicate whether some new content will be created (green) or destroyed (red) as an outcome. Creating and deleting content, even if these actions can be undone seems worth some considerations in an environment where content is public and edited collaboratively by many. So I think that setting these expectations is useful on helping the user to determine on which decisions to put more thought and which ones to do more fluently.
I think we can design great experiences with or without this pattern, but this is a pattern that requires to be applied consistently to work. We need to consider also that the resulting effects on the user affect more their intuition than their conscious thoughts. So while I think it can improve the user experience, it is not something easy to test just by asking if the user can figure out why the button is green instead of blue, even less if the user has not been exposed to a consistent application of the pattern for a while.
If the problem is that it is not easy to be applied consistently, we may consider clarifying the guidelines to indicate the cases where each one should use with as unambiguous definitions and clear examples as possible.
Google use of colour buttons has been mentioned. In this talk https://vimeo.com/29965463 (at 26:40) the code colour they used is explained: red for creating something, blue for do/confirm actions such as search, and green fro actions with an audience such as share. The fact Google has been using this approach does not mean that we need to follow, but it illustrates that associating colours to certain types of actions is not an unprecedented idea in the design of user interfaces.
Pau
On Sat, Oct 24, 2015 at 2:02 AM, Isarra Yos zhorishna@gmail.com wrote:
On 23/10/15 18:28, S Page wrote:
Obviously design is for users. But having a pleasant productive time using a design and understanding its nuances are very different things. "Testing with your users to see if they understand the difference between [two button colors]" seems crazy (unless I misunderstand what designers mean by "understand"). Does Google test to see if users understand the difference between the rounded edge and the shadowed edge in Material? I really doubt it. Different colors and treatments provide different experiences, and there are guidelines when to use them.
That's nuances, details. Nevermind nuances. The question here is, on whatever level, does the distinction help the user? Have users noticed that there is a difference? Has it meant anything to them? Has anyone looked into this?
If it's shown to help, that's all we need. We have a justification for the maintenance overhead and stuff. And cookies. Always cookies. We should all go get some cookies.
Design mailing list Design@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/design
-- Pau Giner Senior User Experience Designer Wikimedia Foundation
Design mailing list Design@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/design
On Mon, Oct 26, 2015 at 12:43 PM, Pau Giner pginer@wikimedia.org wrote:
I think the purpose of colour buttons is to set similar expectations. We highlight the next logical step and indicate whether some new content will be created (green) or destroyed (red) as an outcome. Creating and deleting content, even if these actions can be undone seems worth some considerations in an environment where content is public and edited collaboratively by many.
The create/destroy/other split doesn't match the "dangerousness" of the actions well, though. The typical way for a non-admin user to make a mess is via page move (which usually cannot be reverted without admin rights) and merge-type actions (wikidata item merge, or adding an interwiki link on Wikipedia that causes different concepts to be merged). The most dangerous actions with admin rights are probably user blocking and page history merge. None of those are constructive or destructive in the sense the UI uses those terms.
We highlight the next logical step and indicate whether some new content will be created (green) or destroyed (red) as an outcome. Creating and deleting content, even if these actions can be undone seems worth some considerations in an environment where content is public and edited collaboratively by many.
Though this is correct, at times, it is very difficult to put an action into the bucket of "creating" and "progressing" there are grey areas here since we are talking about abstracted concepts and it's difficult to make it binary. it is possible, but difficult.
That brings me to the users of these concepts. If i am not wrong, there are three parties involved.
1. Designers 2. Developers 3. Users
For designers, things like progressive and constructive makes sense but a on semantic level. for independent developers without any design help, the distinction between constructive and progressive might make things confusing and complicated. and as far as a I know, users don't perceive their tasks to be progressive or constructive right way.
Of course, the semantics that were thought before implementing it our buttons this way made sense at the time and i think it still can be justified but it seems like there is a fine line between two which makes it difficult to convey.
If the value coming from having these distinctions is less than the confusion that we are causing then maybe it's time not have these different conventions.
On Mon, Oct 26, 2015 at 2:37 PM, Gergo Tisza gtisza@wikimedia.org wrote:
On Mon, Oct 26, 2015 at 12:43 PM, Pau Giner pginer@wikimedia.org wrote:
I think the purpose of colour buttons is to set similar expectations. We highlight the next logical step and indicate whether some new content will be created (green) or destroyed (red) as an outcome. Creating and deleting content, even if these actions can be undone seems worth some considerations in an environment where content is public and edited collaboratively by many.
The create/destroy/other split doesn't match the "dangerousness" of the actions well, though. The typical way for a non-admin user to make a mess is via page move (which usually cannot be reverted without admin rights) and merge-type actions (wikidata item merge, or adding an interwiki link on Wikipedia that causes different concepts to be merged). The most dangerous actions with admin rights are probably user blocking and page history merge. None of those are constructive or destructive in the sense the UI uses those terms.
Design mailing list Design@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/design
I've responded to the related Phabricator https://phabricator.wikimedia.org/T110555#1864571 ticket with my thoughts and summarization from this thread.
Feel free to keep responding here if you're not too much of a Phab person, I've already linked this thread there. Here's a copy of the response:
**About constructive buttons: ** used to indicate an action that creates something rather than modifying provide hint that something will be created, regardless of steps several people have mentioned that green constructive that doesn’t “create” anything
**Constructive vs. progressive buttons**
@isarra mentioned: "If it's shown to help, that's all we need. We have a justification for the maintenance overhead and stuff." Unfortunately we do not have proper resources to help us figure this out. But the current situation is that we've had confusions from developers and community members in understanding when and where to use constructive vs. progressive. For our users to learn the association of constructive button being the last action in a process and progressive being the in-betweens, it "requires [the pattern] to be applied consistently to work" as @pginer-wmf mentioned. Also, in certain complex processes, it's hard to tell which would be the last step. An example given by @tgr was:
"…after you submit the login form and MediaWiki verifies your credentials, depending on your user settings you might or might not be presented with a two-factor challenge; so submitting the user name and password might or might not be the last step of the form."
The idea of constructive vs. progressive sounds like an aid for going through a multi-step process. Its underlying purpose is to keep users informed of where they are within a process. My thoughts are that this progressive/constructive solution sounds like it stemmed from the user need of "knowing where I'm at within a process/workflow."
We can solve this more effectively. @volker_e linked us to a discussion on SO where a user mentioned: "Apple hardly ever uses Wizards for set-up processes, and when they do, the Apple set-up assistants are (in my opinion) always easier to figure out than the Microsoft equivalents. I'd suggest looking at the differences and try to identify the tricks employed by Apple." I can agree with this—a better form /workflow experience.
There is also a good amount of rationale as to why we wouldn't need this sort of variation, which mainly stated complications in applications by the community members and devs and that we have no resources in place to find out if the variation complication outweighs the advantages.
@spage suggested that we use "Green for Thanks, because in an unfriendly often toxic "community" it's a nice Constructive thing to do."
--- -------------
My suggestion after these observations are:
**BLUE**
The main reasons why we use blue button is to (in order of importance):
(1) Help users with clear step to move forward within a page / workflow (if there is only one way to move on) (2) To suggest and highlight (if there are multiple options to move on). If no specific suggestion, they remain uncolored.
Example of (1): Primary actions
Example of (2): Log-in form Others
**GREEN**
There are also a few reasons why we would use green for links or icons
(1) To signal that an action has been taken only when it helps users navigate a page / workflow (2) To highlight a suggested action although not the main action (secondary) on the page or workflow
Examples of (1) & (2): Secondary actions
--- -------------
Because more colors means more confusion than help, we should have restrictions such as
Only one color type of button(s) per page / workflow. Either a blue or red. Never a colored link / icon next to a colored button. Remember, colored buttons are to help users move forward, more colored links / icons dilute the intention. Use green links and icons minimally. Highlight most important only and only when necessary to help users.
Overall, I'm still skeptical that we can make this a binary decision. I think there's only not-so-good and good decisions. Good judgement is the most effective. That is why guides are there to help someone make the best informed decisions while giving space for creativity.
The most immediate example that comes to mind is the log in form. Both are possible ways of moving forward and both are equally primary actions. But say, as a team, we want to drive more sign ups, so instead of highlighting both, we highlight only one. It's possible that both are highlighted, but not recommended because when everything is in focus, nothing is in focus, but this is a less extreme example of that). In the other example of blue, one can use blue buttons repeatedly because there is much content around a call-to-action button that warrants a need for focus.
In conclusion, let's retire the idea of constructive and progressive. Instead, we have primary (blue), secondary (green), and destructive (red).
Help me poke holes in my thoughts with more use cases or perhaps strengthen them with more examples and better guides.
mm
On Mon, Nov 9, 2015 at 5:14 PM, nirzardp@gmail.com nirzardp@gmail.com wrote:
We highlight the next logical step and indicate whether some new content
will be created (green) or destroyed (red) as an outcome. Creating and deleting content, even if these actions can be undone seems worth some considerations in an environment where content is public and edited collaboratively by many.
Though this is correct, at times, it is very difficult to put an action into the bucket of "creating" and "progressing" there are grey areas here since we are talking about abstracted concepts and it's difficult to make it binary. it is possible, but difficult.
That brings me to the users of these concepts. If i am not wrong, there are three parties involved.
- Designers
- Developers
- Users
For designers, things like progressive and constructive makes sense but a on semantic level. for independent developers without any design help, the distinction between constructive and progressive might make things confusing and complicated. and as far as a I know, users don't perceive their tasks to be progressive or constructive right way.
Of course, the semantics that were thought before implementing it our buttons this way made sense at the time and i think it still can be justified but it seems like there is a fine line between two which makes it difficult to convey.
If the value coming from having these distinctions is less than the confusion that we are causing then maybe it's time not have these different conventions.
On Mon, Oct 26, 2015 at 2:37 PM, Gergo Tisza gtisza@wikimedia.org wrote:
On Mon, Oct 26, 2015 at 12:43 PM, Pau Giner pginer@wikimedia.org wrote:
I think the purpose of colour buttons is to set similar expectations. We highlight the next logical step and indicate whether some new content will be created (green) or destroyed (red) as an outcome. Creating and deleting content, even if these actions can be undone seems worth some considerations in an environment where content is public and edited collaboratively by many.
The create/destroy/other split doesn't match the "dangerousness" of the actions well, though. The typical way for a non-admin user to make a mess is via page move (which usually cannot be reverted without admin rights) and merge-type actions (wikidata item merge, or adding an interwiki link on Wikipedia that causes different concepts to be merged). The most dangerous actions with admin rights are probably user blocking and page history merge. None of those are constructive or destructive in the sense the UI uses those terms.
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
On Wed, Oct 21, 2015 at 12:46 PM, S Page spage@wikimedia.org wrote:
... That's at least three uses that go away if we consolidate Constructive and Progressive.
Here's a fourth, the wiki login form. You can [Log in], but you can also create an account (usually phrased as [Join <wikiname>]). They're both significant actions, so neutral for the second button doesn't quite work. So they take different colors, and over time a consistent color choice here and elsewhere should suggest the interaction distinction in the guideline, even though only a tiny fraction of users will ever be able to articulate it. The onus is on anyone who wants to eliminate it to prove it's harmful.
I just noticed the [Join Wikimedia button] is taller than [Log in], a regression. I filed https://phabricator.wikimedia.org/T116427
(I was present when Munaf Assaf and Steven Walling et al. came up with the new login, the first case for Agora, now MediaWiki UI. Good times.)
I want to try to step out of my role for a moment and think about it from a user's perspective: To me the button separation seems rather arbitrary in most current use-cases, that I've seen so far. If it's a multistep dialog/action connected, will the user understand that after using the green button several times and therefore finish his task more easily? If a multi-step action is needed, there's common agreement http://ux.stackexchange.com/questions/9/what-can-be-done-to-make-a-long-multi-step-wizard-more-user-friendly, that
- possibly saving user's inputs at every step to be able to go back and forth, - give feedback of *where they are* in the process and - how many steps are left to accomplish the task.
Providing different button colors between the steps and providing one at the final step doesn't provide much feedback and it's hard to grasp without explaining it upfront and in-detail. As we're already providing primary buttons and secondary ("neutral") buttons, I think we should consolidate the two different primary (progressive & constructive) ones in order to give user's a clearer focus on what's the primary action to get "bigger" tasks done.
On Wed, Oct 21, 2015 at 8:59 PM, Gergo Tisza gtisza@wikimedia.org wrote:
One problem I have run into recently is that for a complex form you are not necessarily able to tell which step is the last. E.g. after you submit the login form and MediaWiki verifies your credentials, depending on your user settings you might or might not be presented with a two-factor challenge; so submitting the user name and password might or might not be the last step of the form. (Arguably login should not be constructive in the first place, but it is now. In any case, similar problems could be present with the user registration form, which does create something.)
Personally, I agree with Bartosz that having four button types (five or more if we include silent buttons) just makes the interface confusing.
Design mailing list Design@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/design