Design February 2015

design@lists.wikimedia.org

11 participants
5 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 09 Feb '15

09 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] Wiki Icons
by May Tee-Galloway 03 Feb '15

03 Feb '15

That was an embarrassing overlook, fixed! On Tue, Feb 3, 2015 at 5:41 PM, Rob Moen <rmoen(a)wikimedia.org> wrote: > On Tue, Feb 3, 2015 at 4:29 PM, May Tee-Galloway <mgalloway(a)wikimedia.org> > wrote: > >> displayed > > > Great job May! > > Is the white stripe in the unflag_icon un-intentional? (see what I did > there?) Seems it should be a transparent line going through like the other > Un_icons > > > -- > Rob Moen > Wikimedia Foundation > rmoen(a)wikimedia.org > -- mm

1 0

Re: [Design] Living style guide
by Federico Leva (Nemo) 03 Feb '15

03 Feb '15

The possibly-living (or not) style guide. Nemo

2 1

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

02 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

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

Design February 2015