Design

design@lists.wikimedia.org

602 discussions

PS 1.0 - 25 years old
by Nick Wilson (Quiddity) 14 Mar '15

14 Mar '15

https://www.youtube.com/watch?v=TtA46JT2q_0 Some good weekend amusement. :) [But also, complexity! I look eagerly forward to our ever more powerful interfaces, and also to better mappings of our existing expert-tools (there is so much buried treasure in our wikiverse!).]

2 1

Wikiwand iOS app released
by Steven Walling 13 Mar '15

13 Mar '15

The CEO announced on Quora ;-) http://qr.ae/jFd21

2 1

Wikitable padding
by Andre Klapper 09 Mar '15

09 Mar '15

Is there any design input to provide in reply to https://phabricator.wikimedia.org/T91890#1098647 ? Cheers, andre -- Andre Klapper | Wikimedia Bugwrangler http://blogs.gnome.org/aklapper/

1 0

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

04 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 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

← Newer
1
...
14
15
16
17
18
19
20
...
61
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

Design