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>:
> 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
>
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
We are now working on the "Cases" page of the draft Code of conduct.
This will become a separate page (for readability of the final CoC), but
is being drafted on the same page with the rest.
This includes both the intro section, and all the sub-sections, which
means everything that starts with "2." in the ToC. Currently this is
"Handling reports", "Responses and resolutions", and "Appealing a
resolution". However, the sections within "Cases" may change:
* Section:
https://www.mediawiki.org/wiki/Code_of_Conduct/Draft#Page:_Code_of_conduct_…
* Talk:
https://www.mediawiki.org/wiki/Talk:Code_of_Conduct/Draft#Finishing_the_Cas…
* Alternatively, you can provide anonymous feedback to
conduct-discussion(a)wikimedia.org .
This is the best time to make any necessary changes to this page (and
explain why, in edit summaries and/or talk) and discuss it on the talk page.
Other updates:
* The text of the "Report a problem" section has been frozen. Thanks to
everyone who helped discuss and edit these sections. Participation
(including both named and anonymous) helped us improve the
confidentiality line.
Thanks,
Matt Flaschen
No public goals yet please. Let's get internal agreement first. Step by
step.
-Toby
On Tuesday, November 10, 2015, Wes Moran <wmoran(a)wikimedia.org> wrote:
>
> https://www.mediawiki.org/wiki/Wikimedia_Engineering/2015-16_Q2_Goals#Readi…
>
> On Tue, Nov 10, 2015 at 11:35 AM, Dan Garry <dgarry(a)wikimedia.org
> <javascript:_e(%7B%7D,'cvml','dgarry(a)wikimedia.org');>> wrote:
>
>> Thanks for the updates!
>>
>> From a process perspective, I'd ask that you post your goals to the public
>> goals page
>> <https://www.mediawiki.org/wiki/Wikimedia_Engineering/2015-16_Q2_Goals>,
>> as it's the centralised place where we keep all goals.
>>
>> Thanks,
>> Dan
>>
>> On 10 November 2015 at 09:43, May Tee-Galloway <mgalloway(a)wikimedia.org
>> <javascript:_e(%7B%7D,'cvml','mgalloway(a)wikimedia.org');>> wrote:
>>
>>> Hello everyone,
>>>
>>> We want to post an update on the progress on UI standardization’s Q2
>>> goals.
>>>
>>> Late last week we were able to collect most of your team priorities so
>>> we, the UI Standardization team, can better sync efforts to
>>> collectively achieve UI consistency with other teams. We’ve started
>>> with Reading, Editing and Search/Discovery. Through learnings from
>>> more conversations, we then reached out to several teams across the
>>> foundation that produce front-end user interfaces. These priorities
>>> are documented here:
>>>
>>> https://docs.google.com/a/wikimedia.org/spreadsheets/d/163SxJchYcDozOwjkzBs…
>>>
>>> We are still in the process of gathering feedback from more community
>>> members, Community Resources, and Design Research teams. The timing
>>> hasn’t been ideal, but I am very happy to see this many participation
>>> from relevant parties as a start from the *entire* foundation. We are
>>> learning to better join forces and we are learning fast. Hence, going
>>> forward in the next quarters to come, we want to make it a point to
>>> better integrate teams and community members that do similar work and
>>> care about this matter.
>>>
>>> It's well into mid Q2 now, our scope for Q2 will be smaller, but
>>> nonetheless productive and impactful. For the remaining quarter, we
>>> will be prioritizing on these efforts:
>>> 1- Basic styles implemented with CSS and accompanying HTML
>>> 2- Style Guide - Guide on how and when to use UI components
>>> 3- Improve accessibility of our interface (Vector, OOjs UI, MediaWiki UI)
>>>
>>> There will be list of FAQ on our MediaWiki page
>>> (https://www.mediawiki.org/wiki/Wikimedia_User_Interface) in the next
>>> couple of days on how we came to prioritize these requests with your
>>> help. We will also be sharing the estimated timelines for these said
>>> top priorities within this week.
>>>
>>> We will be posting more on the public design list so our community can
>>> be in the loop and have weight even at goal settings. I hope to see
>>> further design-related topics be brought up in the same channel as
>>> well.
>>>
>>> So, stay tuned! More updates to come.
>>>
>>> May & Volker
>>>
>>
>>
>>
>> --
>> Dan Garry
>> Lead Product Manager, Discovery
>> Wikimedia Foundation
>>
>
>
* Does some user interface have small design issues?
* Do you have some tasks that welcome some design research?
* Do your old bugs welcome some testing?
* Does your documentation need improvements?
* Do you have small, self-contained, "easy" bugs you'd love to get fixed?
(Also see https://www.mediawiki.org/wiki/Annoying_little_bugs )
Google Code-In (GCI) will take place again in Dec+Jan: a contest for
13-17 year old students to provide small contributions to free software
projects.
Wikimedia will apply again to take part in GCI. The more tasks we can
offer the likelier the changes Wikimedia will get accepted.
Unsure about quality of contributions and effort?
Read about tgr's post about Multimedia achievements in GCI 2014:
https://lists.wikimedia.org/pipermail/multimedia/2015-January/001009.html
In short:
* Add the project "GCI2015" + a comment to Phabricator tasks you'd mentor.
* Tasks are welcome in five areas: Code; Outreach/Research;
Documentation/Training; Quality Assurance; User Interface.
* Make sure the task description provides pointers to help the student.
* Add yourself to the table of mentors on the wikipage.
* "Beginner tasks" (<30 min for an experienced contributor) also welcome.
* "Generic" tasks also welcome (e.g. "Fix two user interface messages from
the "Blocked By" list in https://phabricator.wikimedia.org/T40638 ").
For all information, check
https://www.mediawiki.org/wiki/Google_Code-in_2015#Mentors.27_corner
27 "easy" Design tasks (are they still valid? are there more?):
https://phabricator.wikimedia.org/maniphest/query/ePvtv_ahPMrx/#R
Can you imagine providing a helping hand to someone fixing tasks?
Please ask if you have questions!
Thank you!
andre
--
Andre Klapper | Wikimedia Bugwrangler
http://blogs.gnome.org/aklapper/
From time to time I see references to the 'design team' on lists and on
phabricator. But what does this really mean now? As I understood it, the
previous monolithic Design Team was essentially disbanded toward the
beginning of the year, with the designers themselves distributed amongst
the other WMF teams in order to more directly integrate their services
into the development workflow (which sounds like a pretty good idea to
me, at least, since design is such an integral part of most
development). Did this happen? According to
https://wikimediafoundation.org/wiki/Staff_and_contractors, there seem
to still be two teams now with the word 'design' in their names, Reading
Design and Design Research, though these both seem to have somewhat more
specialised functions than just general design, namely Reading (sounds
like front-end non-interactive mw stuff, the visuals perhaps?) and Research.
So what is the 'design team'? Is it one of these, though the teams only
have 5 and 4 people on them, respectively? Is it just WMF designers in
general?
As much as this is also just a plea to please be more specific, if you
have an actual answer, or if you have been saying this, please, speak
up, share your experience and where you're coming from. As confusing as
it is, I suspect a discussion of what and why this has been going on
could also clear up quite a bit.
Thanks.
-I
Hello everyone,
We want to post an update on the progress on UI standardization’s Q2 goals.
Late last week we were able to collect most of your team priorities so
we, the UI Standardization team, can better sync efforts to
collectively achieve UI consistency with other teams. We’ve started
with Reading, Editing and Search/Discovery. Through learnings from
more conversations, we then reached out to several teams across the
foundation that produce front-end user interfaces. These priorities
are documented here:
https://docs.google.com/a/wikimedia.org/spreadsheets/d/163SxJchYcDozOwjkzBs…
We are still in the process of gathering feedback from more community
members, Community Resources, and Design Research teams. The timing
hasn’t been ideal, but I am very happy to see this many participation
from relevant parties as a start from the *entire* foundation. We are
learning to better join forces and we are learning fast. Hence, going
forward in the next quarters to come, we want to make it a point to
better integrate teams and community members that do similar work and
care about this matter.
It's well into mid Q2 now, our scope for Q2 will be smaller, but
nonetheless productive and impactful. For the remaining quarter, we
will be prioritizing on these efforts:
1- Basic styles implemented with CSS and accompanying HTML
2- Style Guide - Guide on how and when to use UI components
3- Improve accessibility of our interface (Vector, OOjs UI, MediaWiki UI)
There will be list of FAQ on our MediaWiki page
(https://www.mediawiki.org/wiki/Wikimedia_User_Interface) in the next
couple of days on how we came to prioritize these requests with your
help. We will also be sharing the estimated timelines for these said
top priorities within this week.
We will be posting more on the public design list so our community can
be in the loop and have weight even at goal settings. I hope to see
further design-related topics be brought up in the same channel as
well.
So, stay tuned! More updates to come.
May & Volker
Hi folks,
@cscott <https://phabricator.wikimedia.org/p/cscott/> pointed out that in
our next RfC meeting on IRC (happening later today) it would be great to
have some design/UX input.
The specific task we're talking through is T90914: Provide semantic
wiki-configurable styles for media display
<https://phabricator.wikimedia.org/T90914>
The IRC meeting we're talking about is E68: RFC Meeting on
#wikimedia-office IRC channel (2015-09-30 UTC)
<https://phabricator.wikimedia.org/E68>(today at 2pm PDT). We already
doubt that any final decisions will be made at this, but getting your input
on this today should be extremely helpful for moving things along.
>From a Phab perspective, I would like to generally tag RfCs that need
design input, but I don't know what the best way of doing that. What tag
should we use to make you aware of RfCs that should have design/UX input?
If there isn't a tag that's a good fit, could we figure out a tag we should
create for this purpose?
Rob
---------- Forwarded message ----------
From: cscott <no-reply(a)phabricator.wikimedia.org>
Date: Wed, Sep 30, 2015 at 8:16 AM
Subject: [Calendar] E68: RFC Meeting on #wikimedia-office IRC channel
(2015-09-30 UTC)
To: robla(a)wikimedia.org
cscott added a subscriber: cscott.
cscott added a comment.
@RobLa-WMF <https://phabricator.wikimedia.org/p/RobLa-WMF/>: I'd like to
get some designers' input on T90914
<https://phabricator.wikimedia.org/T90914>, I don't know if they're in the
habit of attending rfc meetings in general. So I'd prefer to have good
advance notice, and publicize the meeting via email involving the design
team, etc.
*EVENT DESCRIPTION*
Location: #wikimedia-office IRC channel
Time: 2015-09-30, Wednesday 21:00 UTC
* {T112553}
* @GWicke is eager to move this one forward, and doesn't //seem// too
controversial
* {T90914}
* We hope to give @cscott some time to move this one forward, but we may
not have time to make much progress on this one.
We've also tentatively set up {E74} for a few hours after this meeting.
*EVENT DETAIL*
https://phabricator.wikimedia.org/E68
*EMAIL PREFERENCES*
https://phabricator.wikimedia.org/settings/panel/emailpreferences/
*To: *RobLa-WMF, cscott, ArchCom
*Cc: *cscott, tstarling, GWicke, devunt, daniel, Jay8g, bd808, Legoktm