Design January 2015

design@lists.wikimedia.org

17 participants
9 discussions

Re: [Design] Living style guide
by Ryan Kaldari 10 Feb '15

10 Feb '15

The whole point of having a living style guide was to prevent the endless proliferation of outdated MediaWiki style guides (as we were creating about 1 a year for a while). Now we're somehow doing the same thing yet again. Is it really impossible for us to stick to a single style guide? On Fri, Jan 30, 2015 at 4:22 PM, MZMcBride <z(a)mzmcbride.com> wrote: > Hi. > > Re: https://www.mediawiki.org/wiki/Design/Living_style_guide > > This page is kind of sad right now. It references > <http://tools.wmflabs.org/styleguide> pretty heavily, but my understanding > from <https://phabricator.wikimedia.org/T88036> is that > <http://living-style-guide.wmflabs.org> is the actual style guide now? I'm > not really sure and I'm worried that if I can't keep up, nobody else > stands a chance! ;-) But really, we want to make sure everyone is > discussing the same project. > > It would be great if someone more knowledgable than me (about the living > style guide!) could update the wiki page and the description of > <https://phabricator.wikimedia.org/tag/living-style-guide/>, at least with > the best URL, if tools.wmflabs.org/styleguide is no longer it. > > MZMcBride > > > > _______________________________________________ > Design mailing list > Design(a)lists.wikimedia.org > https://lists.wikimedia.org/mailman/listinfo/design >

6 12

Wiki Icons
by May Tee-Galloway 10 Feb '15

10 Feb '15

As promised, icons are now done. You may now use them knowing that they're pixel-perfectly composed within 24 x 24px canvas. Icons <https://www.dropbox.com/sh/tn5jctp80x1q8sp/AAC3oZ7TbN26QK89rE6e_XdIa?dl=0> [image: Inline image 1] -- mm

9 10

Re: [Design] is mediawiki.ui deprecated?
by Trevor Parscal 03 Feb '15

03 Feb '15

Timo is spot on, as usual. Everything he said, I am being completely. Additionally, the lack of public communication is not an oversight. It's planned, and we are on schedule. Give it a week. Documentation is already being moved to the wiki over the next few work days[1], the finishing touches are waiting to be merged for the PHP implementation[2], the first interfaces are being converted[3] the template stuff is stalled on the Flow team conforming their code to upstream light-n-candy[4]. Also, high-level notes about our activities were discussed October's monthly engineering report[5]. - Trevor [1] http://www.mediawiki.org/wiki/OOjs_UI/Documentation [2] https://gerrit.wikimedia.org/r/#/c/182875/ [3] https://gerrit.wikimedia.org/r/#/c/183390/ [4] https://phabricator.wikimedia.org/T75440 [5] https://www.mediawiki.org/wiki/Wikimedia_Engineering/Report/2014/October#Fr… On Thu, Jan 8, 2015 at 2:33 AM, Timo Tijhof <ttijhof(a)wikimedia.org> wrote: > A few quick thoughts: > > * One could argue the mediawiki.ui implementation was never destined to > become a standard/default implementation to begin with. The design is > staying (or that direction at least), but not the implementation. However > that didn't prevent people from using those classes outside the intended > usage area (e.g. selected areas in core and certain extensions that need > the look and feel now, while OOjs UI was being worked on). I warned against > this when it was added to the default page modules, but alas. I guess > people either didn't realise what it meant or are okay with having to > migrate twice (once to mw.ui.less and now to oojs-ui). > > * The factor of how easy a class is for a human to grok is mostly > irrelevant. OOjs UI's API isn't single classes. The HTML isn't meant to be > written by hand on a page.[2] To achieve the features we need and, more > importantly, browser support; a single element with some classes doesn't > suffice. The browser's themselves have a lot more than one element, too. > They just hide it via ShadowDOM.[1] Until we can either reliably use CSS3 > and CSS4 features or HTML5 Web Components across browsers, we'll need most > widgets to be two or three elements in the public DOM. Another reason for > not maintaining such HTML by hand is because it can change and you'll want > to keep maintenance central and minimal for when that happens. We'll keep > breaking changes to a minimum (especially those requiring html changes), > but expect them to happen (especially in the first year). > > * Perhaps we should freeze mediawiki-ui. Then keep around until we're > comfortable removing it. No new features, design syncs or other changes. > Focus efforts on OOjs UI, and slowly migrate towards that. Including OOjs > UI "no-js" entry point where a lighter html footprint is required. > > — Timo > > [1] Here's an example of Chrome rendering a simple input field with > placeholder and a number input field, exposing the internal elements the > browser utilises to render it: http://i.imgur.com/CWQ2Htj.png > [2] This is easy for JS and PHP, but for wiki pages the community should > use an abstraction for that html. Templates or Lua modules are the > appropriate venue for that. > > > On 8 Jan 2015, at 04:18, S Page <spage(a)wikimedia.org> wrote: > > (I couldn't find a list for "Frontend standards group" and I'm not sure if > all its engineers are on the design list.) > > I congratulated James_F on IRC for VisualEditor/ OOjs UI adopting the > mediawiki.ui style, but then it went topsy-turvy: > > *spagewmf* I missed that VisualEditor is now using the mediawiki.ui > style formerly known as "Agora" > *James_F* No, we are not. > Agora and MediaWiki.ui are both previous designs. This one is different, > apparently. > Don't ask me how. :-) It's mostly similar, at least. > It's the MediaWiki Theme for OOjs UI. > > *spagewmf* How is WMF keeping the "simple" mw-ui-button > mw-ui-constructive and OOjs UI's more elaborate oo-ui-widget > > oo-ui-buttonElement oo-ui-flaggedElement-constructive CSS in sync? Are > we able to share LESS rules? > *James_F* MW UI isn't being kept in sync with the new design, I believe. > I don't think it's credible to try to marry the technologies together with > shared files – it'd be a huge amount of work for a short-term hack. > > *spagewmf* The mw-ui- classes are a lot easier for humans to grok/reuse, > e.g. https://en.wikipedia.org/wiki/Template:Clickable_button It could be > very cool for pages to have OOjs UI gadgets someday. > *James_F* Well, tough. :-) MW-UI won't be around for much longer. > > > How soon is "short-term" and "not much longer"? It's less than a year > since mediawiki.ui.button made it into the default set of page modules and > the Living Style Guide > <http://tools.wmflabs.org/styleguide/desktop/section-2.html> appeared. > Are devs going to continue working on $wgUseMediaWikiUIEverywhere to > deliver UX consistency? > > I understand the approach espoused by the Frontend standards group > <https://www.mediawiki.org/wiki/Frontend_standards_group> is "use OOjs UI > <https://www.mediawiki.org/wiki/OOjs_UI> components" and I'm excited to > see Bartosz prototyping the UserLogin form in oojs-ui/php. But it'll be a > long time before the 15 extensions using mediawiki.ui have all transitioned > to OOjs UI. > > I look forward to the "Frontend standards" session at the developer > summit. “The future has arrived — it’s just not evenly distributed yet.” > > Cheers, > -- > =S Page WMF Tech writer > > >

2 5

SOFTWARE
by martin anderson 31 Jan '15

31 Jan '15

Hi my name is Marty Anderson and I subscribed to your Design program some time ago thinking I could learn how to design my own software, what was I thinking. I’m currently working on a project and I was wondering wether you would like to be involved. Regards Marty Anderson

2 1

Living style guide
by MZMcBride 31 Jan '15

31 Jan '15

Hi. Re: https://www.mediawiki.org/wiki/Design/Living_style_guide This page is kind of sad right now. It references <http://tools.wmflabs.org/styleguide> pretty heavily, but my understanding from <https://phabricator.wikimedia.org/T88036> is that <http://living-style-guide.wmflabs.org> is the actual style guide now? I'm not really sure and I'm worried that if I can't keep up, nobody else stands a chance! ;-) But really, we want to make sure everyone is discussing the same project. It would be great if someone more knowledgable than me (about the living style guide!) could update the wiki page and the description of <https://phabricator.wikimedia.org/tag/living-style-guide/>, at least with the best URL, if tools.wmflabs.org/styleguide is no longer it. MZMcBride

1 0

Re: [Design] [Wikitech-l] A new extension of content tree about Wikipedia
by quiddity 09 Jan '15

09 Jan '15

(I've CC'd the design-list, for all of these ideas. Design: please see the earlier part of this thread (7 msgs) for more context, at https://lists.wikimedia.org/pipermail/wikitech-l/2014-December/079793.html) On Fri, Dec 19, 2014 at 8:15 PM, Krinkle <krinklemail(a)gmail.com> wrote: > I'm not sure we should implement collapsible sections for desktop. > > If built and instrumented, one may find that users use it a fair bit and > it may be better-than-nothing as solution for certain use cases. But I > don't think collapsible sections would be an adequate feature for those use > cases. > > Our table of contents is in desperate need of improvement. Having that be > more accessible throughout the reading experience would be a big step > forward[1] (much like the Wikipedia iOS app). Having a proper TOC means > users don't have to collapse/expand anything. > > This would allow users to have a birds eye view of the document at all > times, jump to any section at any time, whilst still being able to scroll > through the document top to bottom as one would expect. > > From a performance viewpoint (as opposed to usability) we can still do > optimisations such as not loading images until a section is accessed > (lazy-load). > > -- Krinkle > > [1] Different ideas around an "aside"-accessible table of contents: > * http://underscorejs.org/ > * Wikipedia iOS App: http://i.imgur.com/Sg0pqsg.jpg > * User manual: http://asciidoctor.org/docs/user-manual/ > > Re: Collapsible - I strongly agree that collapsing content is potentially harmful, and should be avoided as much as possible. It increases the effort required to see content, and thereby reduces the likelihood of any given section being seen. This is bad for readers (harder to access knowledge), and bad for editors/potential-editors (harder to spot errors/vandalism during casual reading). It goes for article content as well as navigational elements and metadata. Footer-navboxes are frequently collapsed, and I think this has established a harmful precedent. (See also [[Linus's Law]], "given enough eyeballs, all bugs are shallow". We need more eyeballs, not less.) Re: ToC improvements - Agreed. As always, the difficulty is with fitting it in somewhere, given the diversity of screen/browser-window sizes that each user has or prefers. It would be especially useful on long articles, but it would also take up the most space there. I'm not sure where the most recent brainstorming and notes are, regarding the standard mediawiki sidebar? I know it's been discussed a *lot* over the years... Re: "birds eye view" - I really like this idea, taken to the 'completism' level... A number of text/code editors, have a "minimap" attached to the side. http://did2memo.net/wp-content/uploads/2013/01/minimap-in-sublime-text-2.png http://i.imgur.com/OIhkpfA.png http://notepad-plus-plus.org/assets/images/docMap.png It works as an enhanced-scrollbar, and as an overview, and it shows text-selections from ctrl-F. I think something similar to this would potentially help us: * To better understand the scope of an article/section/entry, upon first loading the page. * As editors, to find & refine wall-of-text paragraphs. * Encourage light-readers to scroll more, particularly if they see thumbnails of images - in the same way that good textbooks can use images as content-hooks. * more? It would need Increased font size for headings, to enable ToC-like functionality. And some sort of minimal-version, for users who find animated-aspects too distracting. What else? It might be too complicated to be a global default (UX-wise, and/or Performance-wise), but I'd love to see something like this as an option (toggle or preference or gadget). HTH. --Quiddity

4 4

is mediawiki.ui deprecated?
by S Page 08 Jan '15

08 Jan '15

(I couldn't find a list for "Frontend standards group" and I'm not sure if all its engineers are on the design list.) I congratulated James_F on IRC for VisualEditor/ OOjs UI adopting the mediawiki.ui style, but then it went topsy-turvy: *spagewmf* I missed that VisualEditor is now using the mediawiki.ui style formerly known as "Agora" *James_F* No, we are not. Agora and MediaWiki.ui are both previous designs. This one is different, apparently. Don't ask me how. :-) It's mostly similar, at least. It's the MediaWiki Theme for OOjs UI. *spagewmf* How is WMF keeping the "simple" mw-ui-button mw-ui-constructive and OOjs UI's more elaborate oo-ui-widget > oo-ui-buttonElement oo-ui-flaggedElement-constructive CSS in sync? Are we able to share LESS rules? *James_F* MW UI isn't being kept in sync with the new design, I believe. I don't think it's credible to try to marry the technologies together with shared files – it'd be a huge amount of work for a short-term hack. *spagewmf* The mw-ui- classes are a lot easier for humans to grok/reuse, e.g. https://en.wikipedia.org/wiki/Template:Clickable_button It could be very cool for pages to have OOjs UI gadgets someday. *James_F* Well, tough. :-) MW-UI won't be around for much longer. How soon is "short-term" and "not much longer"? It's less than a year since mediawiki.ui.button made it into the default set of page modules and the Living Style Guide <http://tools.wmflabs.org/styleguide/desktop/section-2.html> appeared. Are devs going to continue working on $wgUseMediaWikiUIEverywhere to deliver UX consistency? I understand the approach espoused by the Frontend standards group <https://www.mediawiki.org/wiki/Frontend_standards_group> is "use OOjs UI <https://www.mediawiki.org/wiki/OOjs_UI> components" and I'm excited to see Bartosz prototyping the UserLogin form in oojs-ui/php. But it'll be a long time before the 15 extensions using mediawiki.ui have all transitioned to OOjs UI. I look forward to the "Frontend standards" session at the developer summit. “The future has arrived — it’s just not evenly distributed yet.” Cheers, -- =S Page WMF Tech writer

2 1

Welcome Michelle Nguyen, Visual Design Fellow
by Jared Zimmerman 06 Jan '15

06 Jan '15

Hello Everyone, It's my great pleasure to welcome Michelle Nguyen to the User Experience team. Michelle joins us from Tenderloin Economic Development Project[1], where she was a Marketing Communications Specialist and a Graphic Designer. At TEDP, Michelle redesigned their website and was responsible in maintaining their social media networks and online presence. She also served as a community advocate with Mid-Market tech companies and Tenderloin business owners, and in turn successfully developed Tasting the Tenderloin - a series of lunches held at restaurants within the neighborhood. Attendees and sponsors came from One Kings Lane, PeerSpace, Spotify, Square, WeWork, and Zendesk. Michelle joins the Wikimedia Foundation as a Visual Design Fellow, and will be working on projects related to the User Interface standardization and providing visual design support for other team projects. Michelle graduated from San Francisco State University with a Bachelor of Science in Visual Communication Design in 2012. Since graduation, she has been working as a freelance designer in the realm of branding, animation, and signage[2]. She is excited to be part of the Wikimedia Foundation’s mission. When she is not at work, Michelle practices hand lettering styles, bike and skateboard around the city, and nerd out on vegan recipes (even though she eats everything including pork blood and duck embryos). [image: Inline image 1] Michelle will start today, Jan 6 working from the SF office, and will be seated next to May on the 3rd floor. She will be working here with us through July. Please come say Hi! [1] www.tedpsf.org [2] michellemeng.com *Jared Zimmerman * \\ Director of User Experience \\ Wikimedia Foundation M +1 415 609 4043 \\ @jaredzimmerman <http://loo.ms/g0>

2 1

User Research - sign-up to help out
by Nick Wilson (Quiddity) 06 Jan '15

06 Jan '15

Hi all, The Wikimedia Foundation's Design Research team,[1] Abbey Ripstra and Daisy Chen, are looking for people to participate in research about editing. They want to talk with both experienced editors and new editors to better understand what you do, how you do it, what is difficult and what works well with editing tools. Currently, they're doing some hour-long research interviews over Google Hangouts. In the future, there will be other types of research programs, probably including a card sorting task to determine how editing tools and tasks could be organized to suit you best. If you would like to hear about opportunities to participate in user-based research, please sign up here: https://wikimedia.qualtrics.com/SE/?SID=SV_6R04ammTX8uoJFP This is a small survey to fill out so the research team knows a little bit about your experience level and how to contact you to invite you to research. You can always opt out again, and signing up does not obligate you to participate. Thank you! [1] https://www.mediawiki.org/wiki/Design/Research -- Nick Wilson (Quiddity) Community Liaison Wikimedia Foundation

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

Design January 2015