Design

design@lists.wikimedia.org

602 discussions

Position open for a User Interface Engineer
by Quim Gil 22 Jan '16

22 Jan '16

You or someone you know might be interested in this new position of User Interface Engineer at the Wikimedia Foundation: https://boards.greenhouse.io/wikimedia/jobs/151523?t=0dbamu#.VqHkenUrLQp PS: Usually I don't send job announcements, but this position really looked like a good match for this specialized list. -- Quim Gil Engineering Community Manager @ Wikimedia Foundation http://www.mediawiki.org/wiki/User:Qgil

1 0

Design resources on wiki
by May Tee-Galloway 20 Jan '16

20 Jan '16

The standardization team is currently working on the Wikimedia User Interface style guide, where it will be a one-stop shop for all design resources and specs in the future. But for now, you can obtain these updated resources from the Design Resources section of our team's wiki. It includes: UI elements for use by designers / others (Sketch • how to use gif) and specs for developers (WMFLabs • LESS file); Three ways of using our icon library -- SVG, SVG sprite, and Icon font. We will keep updating this thread as more resources become available and updated. -- mm

3 5

Willingness to work as a design Intern during May-July 2016
by Vikram Aditya 15 Jan '16

15 Jan '16

Hello, My name is Vikram Aditya, and I am currently a Pre-Final year Bachelors of Design student at IIT Guwahati. I wish to apply for the position of a Design Internship at the Wikimedia Foundation during the summer of 2016. If I have reached the wrong place, it would be very kind of you to guide me in the right direction. Having interned at Interface Sense <http://interfacesense.com/> as a UX Designer and at Cobalt.io <http://cobalt.io/> as a remote graphic design intern along with having worked on several design projects, I am well versed with the User Experience, Typography, Visual Communication, User Study, Heuristic Evaluation and Front-End Development. I also have been passionate about Interaction Design and Human Computer Interaction and have carried out several projects from this domain as a part of my course. Recently I have taken up a project on organic interfaces at the Embedded Interaction Lab <http://embeddedinteractions.com/> where I am apart of a team trying to visualise new interactions with shape changing displays in collaboration with Nokia. Please find my curriculum vitae at http://vikramadityadesign.com/Vikram_Aditya_Resume.pdf My portfolio link is: http://vikramadityadesign.com/ Please let me know if my work and interests match with the profile that you might be looking for. Regards, | *Vikram Aditya* *| *Pre-Final Year Student (B.Des) *|* Department of Design *|* Indian Institute of Technology Guwahati | Portfolio: http://vikramadityadesign.com/ *| *+91 8011035410 | Alternate Email : *vikramaditya(a)iitg.ernet.in <vikramaditya(a)iitg.ernet.in>* Sent with MailTrack <https://mailtrack.io/install?source=signature&lang=en&referral=vikramaditya…>

1 0

Re: [Design] UI Library for prototyping
by May Tee-Galloway 11 Jan '16

11 Jan '16

We wouldn't want to use web components for the reasons you mentioned and polymer because it uses shadow DOM, where you cannot share css styles. What would be great is webcomponent-like custom elements that share css, that's why webcomponents.js <http://webcomponents.org/polyfills/> is used in this library <http://wikimedia-ui.wmflabs.org/>. It will be much more accessible for a lot more users if we managed to do similar things to OOjs UI components with a more approachable language for uses in and out of wiki like <wiki-icon icon="star" color="green"></wiki-icon> mm On Sun, Jan 10, 2016 at 2:54 PM, Prateek Saxena <psaxena(a)wikimedia.org> wrote: > On Wed, Nov 11, 2015 at 1:59 PM, S Page <spage(a)wikimedia.org> wrote: > > Sure, but how cool would it be if OOjs UI were expressible as > > WebComponent-ish things… > > I have been considering the WebComponent approach since before we > decided OOjs UI to be our go to UI library, but it obviously isn't > ready to be our main UI technology. Iteratively adding a WebComponent > layer to OOjs UI shouldn't be hard but I have mixed feelings about it > [1]: > * Lack of support [2]. We'll still need parser tags to consistently > support these tags. > * Maintainability. > * Choice of polyfill and/or library, brick/polymer. > > It does solve the UI prototyping problem, but I wonder if its worth the > effort. > > —prtksxna > > [1] I am super excited about WebComponents but want to hold myself back. > [2] http://caniuse.com/#search=web%20components > > _______________________________________________ > Design mailing list > Design(a)lists.wikimedia.org > https://lists.wikimedia.org/mailman/listinfo/design > -- mm

1 0

Find code for graphics
by Moushira Elamrawy 10 Jan '16

10 Jan '16

Hello folks, Did you see this before? http://wikimedia-ui.wmflabs.org ..a simple way to get the code for the graphics you want. Very neat. Helps us all build a clean and visiually unified look of pages. I spotted it in the In the recent discovery and reading showcae [0]. Bravo and thanks to May Tee-Galloway :) Best, Moushira [0] https://www.youtube.com/watch?v=LNAQD4RCeWM

5 6

Code of Conduct session at Wikimedia Developer Summit 2016
by Matthew Flaschen 29 Dec '15

29 Dec '15

The Wikimedia Developer Summit starts this Monday, Jan. 4! There will be an information and discussion session about the in-progress Code of Conduct for technical spaces (https://www.mediawiki.org/wiki/Code_of_Conduct/Draft) on Monday. Thanks, Matt Flaschen

1 0

[UI Standardization] Team goals Jan-March 2016
by Volker Eckl 21 Dec '15

21 Dec '15

Hi everyone, We have published our goals for upcoming Q3, Jan-Mar 2016 ( https://www.mediawiki.org/wiki/Wikimedia_Engineering/2015-16_Q3_Goals#UI_St…) largely based on our work started this quarter, aligning to feedback from community and front-end user interfaces producing teams across foundation. Please feel free to contact us on IRC (#wikimedia-design, users Volker_E & violetto), by email or talk page on our MediaWiki page ( https://phabricator.wikimedia.org/tag/ui-standardization/). We're welcoming your feedback. Best regards, Volker

1 0

Loading indicators
by May Tee-Galloway 14 Dec '15

14 Dec '15

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_I…> 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

5 5

Re: [Design] Design Digest, Vol 45, Issue 1
by Felipe Dário 11 Dec '15

11 Dec '15

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 >

2 1

Constructive vs. progressive buttons
by May Tee-Galloway 10 Dec '15

10 Dec '15

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

11 20

← Newer
1
...
10
11
12
13
14
15
16
...
61
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

Design