Felipe, to unsubscribe:
1. Visit
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(a)felipedario.com> wrote:
UNSUBSCRIBE
*Felipe Dário*
+55 11 95351 1569
http://felipedario.com/
2015-12-11 4:33 GMT-02:00 <design-request(a)lists.wikimedia.org>rg>:
> Send Design mailing list submissions to
> design(a)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(a)lists.wikimedia.org
>
> You can reach the person managing the list at
> design-owner(a)lists.wikimedia.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Design digest..."
>
>
> Today's Topics:
>
> 1. Re: Constructive vs. progressive buttons (May Tee-Galloway)
> 2. Loading indicators (May Tee-Galloway)
> 3. Re: Loading indicators (nirzardp(a)gmail.com)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Thu, 10 Dec 2015 12:46:05 -0800
> From: May Tee-Galloway <mgalloway(a)wikimedia.org>
> To: "Design.Public" <design(a)lists.wikimedia.org>
> Subject: Re: [Design] Constructive vs. progressive buttons
> Message-ID:
> <CAN4BDz50RgGgQrmJQHbBYRA=
> P58FtNQTLH0Li6F-caR1Hd6f1w(a)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(a)gmail.com <nirzardp(a)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.
> >
> > 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(a)wikimedia.org>
> wrote:
> >
> >> On Mon, Oct 26, 2015 at 12:43 PM, Pau Giner <pginer(a)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(a)lists.wikimedia.org
> >>
https://lists.wikimedia.org/mailman/listinfo/design
> >>
> >>
> >
> > _______________________________________________
> > Design mailing list
> > Design(a)lists.wikimedia.org
> >
https://lists.wikimedia.org/mailman/listinfo/design
> >
> >
>
>
> --
> mm
>