UNSUBSCRIBE
*Felipe Dário* +55 11 95351 1569 http://felipedario.com/
2015-12-11 4:33 GMT-02:00 design-request@lists.wikimedia.org:
Send Design mailing list submissions to design@lists.wikimedia.org
To subscribe or unsubscribe via the World Wide Web, visit https://lists.wikimedia.org/mailman/listinfo/design or, via email, send a message with subject or body 'help' to design-request@lists.wikimedia.org
You can reach the person managing the list at design-owner@lists.wikimedia.org
When replying, please edit your Subject line so it is more specific than "Re: Contents of Design digest..."
Today's Topics:
- Re: Constructive vs. progressive buttons (May Tee-Galloway)
- Loading indicators (May Tee-Galloway)
- Re: Loading indicators (nirzardp@gmail.com)
Message: 1 Date: Thu, 10 Dec 2015 12:46:05 -0800 From: May Tee-Galloway mgalloway@wikimedia.org To: "Design.Public" design@lists.wikimedia.org Subject: Re: [Design] Constructive vs. progressive buttons Message-ID: <CAN4BDz50RgGgQrmJQHbBYRA= P58FtNQTLH0Li6F-caR1Hd6f1w@mail.gmail.com> Content-Type: text/plain; charset="utf-8"
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
-- mm
Felipe, to unsubscribe:
1. Visit https://lists.wikimedia.org/mailman/listinfo/design 2. In the section labeled "Change your settings or unsubscribe", enter your email address and follow the steps to unsubscribe
-Adam
On Fri, Dec 11, 2015 at 1:04 PM, Felipe Dário fala@felipedario.com wrote:
UNSUBSCRIBE
*Felipe Dário* +55 11 95351 1569 http://felipedario.com/
2015-12-11 4:33 GMT-02:00 design-request@lists.wikimedia.org:
Send Design mailing list submissions to design@lists.wikimedia.org
To subscribe or unsubscribe via the World Wide Web, visit https://lists.wikimedia.org/mailman/listinfo/design or, via email, send a message with subject or body 'help' to design-request@lists.wikimedia.org
You can reach the person managing the list at design-owner@lists.wikimedia.org
When replying, please edit your Subject line so it is more specific than "Re: Contents of Design digest..."
Today's Topics:
- Re: Constructive vs. progressive buttons (May Tee-Galloway)
- Loading indicators (May Tee-Galloway)
- Re: Loading indicators (nirzardp@gmail.com)
Message: 1 Date: Thu, 10 Dec 2015 12:46:05 -0800 From: May Tee-Galloway mgalloway@wikimedia.org To: "Design.Public" design@lists.wikimedia.org Subject: Re: [Design] Constructive vs. progressive buttons Message-ID: <CAN4BDz50RgGgQrmJQHbBYRA= P58FtNQTLH0Li6F-caR1Hd6f1w@mail.gmail.com> Content-Type: text/plain; charset="utf-8"
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
-- mm