Felipe Dário
2015-12-11 21:04:23 UTC
UNSUBSCRIBE
*Felipe Dário*
+55 11 95351 1569
http://felipedario.com/
*Felipe Dário*
+55 11 95351 1569
http://felipedario.com/
Send Design mailing list submissions to
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
You can reach the person managing the list at
When replying, please edit your Subject line so it is more specific
than "Re: Contents of Design digest..."
1. Re: Constructive vs. progressive buttons (May Tee-Galloway)
2. Loading indicators (May Tee-Galloway)
----------------------------------------------------------------------
Message: 1
Date: Thu, 10 Dec 2015 12:46:05 -0800
Subject: Re: [Design] Constructive vs. progressive buttons
<CAN4BDz50RgGgQrmJQHbBYRA=
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,
**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
"âŠ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."
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."
---
-------------
**BLUE**
(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.
Primary actions
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
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
will
deleting
actions well, though. The typical way for a non-admin user to make a
mess
link on
dangerous
Design mailing list
https://lists.wikimedia.org/mailman/listinfo/design
--
mm
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <
https://lists.wikimedia.org/pipermail/design/attachments/20151210/750a3363/attachment-0001.html
------------------------------
Message: 2
Date: Thu, 10 Dec 2015 22:16:12 -0800
Subject: [Design] Loading indicators
<CAN4BDz5yG=
Content-Type: text/plain; charset="utf-8"
There is a discussion going on loading indicators on Phabricator
<https://phabricator.wikimedia.org/T75972>.
âBasically there are two kinds of indicators, indeterminateâ and
determinate. Here is a documentation
<
https://www.mediawiki.org/wiki/Wikimedia_User_Interface/Use_cases/Loading_Indicators
of what we have currently.
Do you know any other loading indicators out there? Any other kinds of use
cases or purposes where loading indicators are used and needed? â
Discuss at Phabricator <https://phabricator.wikimedia.org/T75972> or on
this mailing list.
And if you find more loading indicators, let us know here
<https://www.mediawiki.org/wiki/Wikimedia_User_Interface>.
âThank ya,
mm
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <
https://lists.wikimedia.org/pipermail/design/attachments/20151210/e41260ab/attachment-0001.html
------------------------------
Message: 3
Date: Fri, 11 Dec 2015 12:03:13 +0530
Subject: Re: [Design] Loading indicators
<CAKufZiERw4Tjjk8x2_=
Content-Type: text/plain; charset="utf-8"
Hey May,
- There's a determinant progress bar in MediaViewer while the image is
loading[1] I will add it on the MediaWiki page.
- There are two progress indicators in OO-JS-UI here
https://doc.wikimedia.org/oojs-ui/master/demos/#widgets-mediawiki-mixed-ltr
Scroll down to "progress" section. I am not sure where they are used, but
they do exist. The first one is used in VE (with progressive tint) if i am
not wrong.
- On Mobile web, we use iOS style activity indicator (indeterminate). It's
part of MW-UI [2] and used in various places. You can see it on Mobile VE
loading right now.
[1] Loading Image...
[2] mw-ui-icon mw-ui-icon-spinner mw-ui-icon-element spinner loading
- Nirzar
On Fri, Dec 11, 2015 at 11:46 AM, May Tee-Galloway <
An HTML attachment was scrubbed...
URL: <
https://lists.wikimedia.org/pipermail/design/attachments/20151211/3aca8cf9/attachment.html
------------------------------
Subject: Digest Footer
_______________________________________________
Design mailing list
https://lists.wikimedia.org/mailman/listinfo/design
------------------------------
End of Design Digest, Vol 45, Issue 1
*************************************
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
You can reach the person managing the list at
When replying, please edit your Subject line so it is more specific
than "Re: Contents of Design digest..."
1. Re: Constructive vs. progressive buttons (May Tee-Galloway)
2. Loading indicators (May Tee-Galloway)
----------------------------------------------------------------------
Message: 1
Date: Thu, 10 Dec 2015 12:46:05 -0800
Subject: Re: [Design] Constructive vs. progressive buttons
<CAN4BDz50RgGgQrmJQHbBYRA=
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,
**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
"âŠ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."
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."
---
-------------
**BLUE**
(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.
Primary actions
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
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
We highlight the next logical step and indicate whether some new content
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,
thewill 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 actiondeleting content, even if these actions can be undone seems worth some
considerations in an environment where content is public and edited
collaboratively by many.
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,
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
itconfusing 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
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
differentIf the value coming from having these distinctions is less than the
confusion that we are causing then maybe it's time not have these
conventions.
WeI think the purpose of colour buttons is to set similar expectations.
highlight the next logical step and indicate whether some new content
be created (green) or destroyed (red) as an outcome. Creating and
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 theconsiderations in an environment where content is public and edited
collaboratively by many.
actions well, though. The typical way for a non-admin user to make a
is via page move (which usually cannot be reverted without admin rights)
and merge-type actions (wikidata item merge, or adding an interwiki
and merge-type actions (wikidata item merge, or adding an interwiki
Wikipedia that causes different concepts to be merged). The most
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
https://lists.wikimedia.org/mailman/listinfo/design
_______________________________________________merge. None of those are constructive or destructive in the sense the UI
uses those terms.
_______________________________________________
Design mailing list
https://lists.wikimedia.org/mailman/listinfo/design
Design mailing list
https://lists.wikimedia.org/mailman/listinfo/design
mm
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <
https://lists.wikimedia.org/pipermail/design/attachments/20151210/750a3363/attachment-0001.html
------------------------------
Message: 2
Date: Thu, 10 Dec 2015 22:16:12 -0800
Subject: [Design] Loading indicators
<CAN4BDz5yG=
Content-Type: text/plain; charset="utf-8"
There is a discussion going on loading indicators on Phabricator
<https://phabricator.wikimedia.org/T75972>.
âBasically there are two kinds of indicators, indeterminateâ and
determinate. Here is a documentation
<
https://www.mediawiki.org/wiki/Wikimedia_User_Interface/Use_cases/Loading_Indicators
of what we have currently.
Do you know any other loading indicators out there? Any other kinds of use
cases or purposes where loading indicators are used and needed? â
Discuss at Phabricator <https://phabricator.wikimedia.org/T75972> or on
this mailing list.
And if you find more loading indicators, let us know here
<https://www.mediawiki.org/wiki/Wikimedia_User_Interface>.
âThank ya,
mm
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <
https://lists.wikimedia.org/pipermail/design/attachments/20151210/e41260ab/attachment-0001.html
------------------------------
Message: 3
Date: Fri, 11 Dec 2015 12:03:13 +0530
Subject: Re: [Design] Loading indicators
<CAKufZiERw4Tjjk8x2_=
Content-Type: text/plain; charset="utf-8"
Hey May,
- There's a determinant progress bar in MediaViewer while the image is
loading[1] I will add it on the MediaWiki page.
- There are two progress indicators in OO-JS-UI here
https://doc.wikimedia.org/oojs-ui/master/demos/#widgets-mediawiki-mixed-ltr
Scroll down to "progress" section. I am not sure where they are used, but
they do exist. The first one is used in VE (with progressive tint) if i am
not wrong.
- On Mobile web, we use iOS style activity indicator (indeterminate). It's
part of MW-UI [2] and used in various places. You can see it on Mobile VE
loading right now.
[1] Loading Image...
[2] mw-ui-icon mw-ui-icon-spinner mw-ui-icon-element spinner loading
- Nirzar
On Fri, Dec 11, 2015 at 11:46 AM, May Tee-Galloway <
There is a discussion going on loading indicators on Phabricator
<https://phabricator.wikimedia.org/T75972>.
âBasically there are two kinds of indicators, indeterminateâ and
determinate. Here is a documentation
<
https://www.mediawiki.org/wiki/Wikimedia_User_Interface/Use_cases/Loading_Indicators<https://phabricator.wikimedia.org/T75972>.
âBasically there are two kinds of indicators, indeterminateâ and
determinate. Here is a documentation
<
of what we have currently.
Do you know any other loading indicators out there? Any other kinds of
useDo you know any other loading indicators out there? Any other kinds of
cases or purposes where loading indicators are used and needed? â
Discuss at Phabricator <https://phabricator.wikimedia.org/T75972> or on
this mailing list.
And if you find more loading indicators, let us know here
<https://www.mediawiki.org/wiki/Wikimedia_User_Interface>.
âThank ya,
mm
_______________________________________________
Design mailing list
https://lists.wikimedia.org/mailman/listinfo/design
-------------- next part --------------Discuss at Phabricator <https://phabricator.wikimedia.org/T75972> or on
this mailing list.
And if you find more loading indicators, let us know here
<https://www.mediawiki.org/wiki/Wikimedia_User_Interface>.
âThank ya,
mm
_______________________________________________
Design mailing list
https://lists.wikimedia.org/mailman/listinfo/design
An HTML attachment was scrubbed...
URL: <
https://lists.wikimedia.org/pipermail/design/attachments/20151211/3aca8cf9/attachment.html
------------------------------
Subject: Digest Footer
_______________________________________________
Design mailing list
https://lists.wikimedia.org/mailman/listinfo/design
------------------------------
End of Design Digest, Vol 45, Issue 1
*************************************