Design

design@lists.wikimedia.org

602 discussions

First meeting of the front end standards group
by Tomasz Finc 22 Sep '14

22 Sep '14

Several of the engineers and advisors developing components for front end standardization met Friday to check status, set direction, and identify upcoming obstacles Big take aways: = MediaWiki theme for OOjs UI = * Should be finalized this week by Trevor and Bartosz * Server side to follow in the next couple of weeks = Icon system = * Bartosz has done the early work for a Grunt task that takes SVGs and a JSON config to generate colored SVG and PNG renderings and the corresponding LESS markup for them Notes and additional items from the discussion can be found on mw.org [1] Follow up items: * Generate prospective roadmap [Trevor] * Raise Template RFC w/ arch committee and make a decision [Brion] * Find out if Derk-Jan (cc'd) can join us next time * Discuss Server-side OOUI at next meeting Please update as necessary if you attended and I've forgotten or misrepresented anything. thanks all --tomasz [1] - https://www.mediawiki.org/wiki/FrontEndStandardsGroup/Weekly-Sept_19_2014

1 0

red links and color blindness
by Amir E. Aharoni 19 Sep '14

19 Sep '14

Hi, Disclaimer: Though I worked in an accessibility software company for three years, I know almost nothing about color blindness, so this question may be silly. A participant in a recent workshop for new Wikipedia editors workshop in Israel complained that he cannot tell red links from blue links because he is color-blind. Has this issue ever been noticed or addressed by anybody? The only related thing I can think of is the option to show links to nonexistent pages with a question mark, which was disabled on Wikimedia sites a year or two ago. Is there anything else? Thanks. -- Amir Elisha Aharoni · אָמִיר אֱלִישָׁע אַהֲרוֹנִי http://aharoni.wordpress.com ‪“We're living in pieces, I want to live in peace.” – T. Moore‬

10 19

we need a better sound icon
by Ryan Kaldari 18 Sep '14

18 Sep '14

If you've ever looked at Wikipedia articles for music, I'm sure you've seen the following icon: https://commons.wikimedia.org/wiki/File:Gnome-mime-sound-openclipart.svg See, for example, https://en.wikipedia.org/wiki/Goldberg_Variations The icon is fairly sloppy and isn't even symmetrical. I tried to clean it up a few months ago, but I've never really been happy with it. While this icon is not technically part of the MediaWiki software, it's use on our projects is ubiquitous. If any designers feel inspired to create a replacement, please let me know! Ryan Kaldari

3 4

Update: Standardizing icons across projects
by Tomasz Finc 17 Sep '14

17 Sep '14

Several front end engineers, designers, and others got together again to update on their progress to standardize icons across projects today. This was a follow to the previous conversation on 8/27 [1]. Big take aways: * Monte iterating and almost completing his SVG->Font python scripts * Trevor & Bartosz finalizing an npm module for customizing SVG generation * Jon needing additional support from Sam to move forward on mw ui icon markup Notes from the discussion can be found on etherpad [2] Follow up items: * Finish up SVG2FONT2SVG script (hopefully done in a week) (Monte) ** Create manifest for padding and other small options (Trevor) * Review Trevor's SVG/PNG generation (Everyone present once its out) * Followup with Sam for standard icon html mark-up (Matt) * Schedule team discussion follow up (Tomasz) Please update as necessary if you attended and I've forgotten or misrepresented anything. thanks all --tomasz [1] - https://lists.wikimedia.org/pipermail/mobile-l/2014-August/007922.html [2] - http://etherpad.wikimedia.org/p/IconStandardization

1 0

Getting $wgUseMediaWikiUIEverywhere = true to be the default
by Jon Robson 17 Sep '14

17 Sep '14

I'm committed to killing the global variable $wgUseMediaWikiUIEverywhere Prateek asked me today how he could help so in case it is not clear this is how developers/designers can help. Essentially as a first step we need to identify problems with form interfaces across MediaWiki and fix them. 1) Enable MediaWiki UI everywhere Developers: Add $wgUseMediaWikiUIEverywhere=true into your LocalSettings Non-developers: Explore http://mwui.wmflabs.org/wiki/Main_Page or http://en.m.wikipedia.beta.wmflabs.org/ (the mobile site already enables these to be the default) 2) Navigate around the site and make a note of interfaces that look wrong. Please file bugs against them here [1] * Places where buttons are constructive when they should be destructive / progress * Take screenshots of interfaces that look cluttered/cramped. * Identify pages which do not use MediaWiki UI styles at all 3) Let's fix the bugs 4) When this is all done, we will need to engage the community/communicate this change. We might need to run a beta feature. I'm hoping Jared or Steven can oversee this. Alternatively we might just want to turn it on if we do not consider it a massive change. [1] https://bugzilla.wikimedia.org/enter_bug.cgi?product=MediaWiki&component=Me…

7 17

Re: [Design] [Wmfall] Daisy Chen is joining the UX Research team as Associate Design Researcher!
by Jonathan Morgan 15 Sep '14

15 Sep '14

That's totally awesome :) - Jonathan On Mon, Sep 15, 2014 at 11:36 AM, Abbey Ripstra <aripstra(a)wikimedia.org> wrote: > Hello Everyone, > > > It is with great happiness, and excitement that we announce Daisy Chen is > joining the UX Research team as Associate Design Researcher! > > Since April, 2012, Daisy has been working at the Foundation on the Legal > team as a paralegal. With a BA in Sociology providing relevant > facilitation, observation and research design experience, Since April 2014, > she began contributing time and effort to UX research projects and in > support of design iteration with the UX team. > > Along with collaborating through her role in Legal to support setup, and > vetting of UX Research tools, policies and processes, Daisy has recently > contributed to some larger UX research projects. With this work, Daisy > has already been making important contributions to the UX Research team. > > Daisy’s design research capabilities and enthusiasm are a very welcome and > important addition to this growing team. > > > Welcome Daisy!! > > > > > Abbey Ripstra > > Lead Design Research Manager > > Wikimedia Foundation > > > _______________________________________________ > Wmfall mailing list > Wmfall(a)lists.wikimedia.org > https://lists.wikimedia.org/mailman/listinfo/wmfall > > -- Jonathan T. Morgan Learning Strategist Wikimedia Foundation User:Jmorgan (WMF) <https://meta.wikimedia.org/wiki/User:Jmorgan_(WMF)> jmorgan(a)wikimedia.org

1 0

WikiFont and accessibility
by Derk-Jan Hartman 10 Sep '14

10 Sep '14

Something that came up yesterday when I was discussing with User:Rexx about the new WikiFont, is how it will influence accessibility, since it is actually a 'character' that will have effects on screenreader software. I have no idea what the effect will be, so if we start using that, I very much encourage that we should go and find out and then document some of the knowledge we gather into it's style and usage recommendations guidelines. DJ

11 20

Living Styeguide: Questions
by Prateek Saxena 09 Sep '14

09 Sep '14

Hey, I submitted some [1] patches [2] to add the sub-sections links for the current section [3]. It required some JS as handlebars doesn't allow comparison conditions without additional helpers (though, this isn't the approach that I took, should I?). I was about to start work on auto-highlighting links as you scroll but had a few questions— * Does the navigation remain fixed on the side of the page? * If the content overflows do we just hide it like the Bootstrap docs [4]? The trello card mentions auto-expand, but as we have different pages for each section there is no list to expand to. —prtksxna [1] https://gerrit.wikimedia.org/r/158855 [2] https://gerrit.wikimedia.org/r/158856 [3] https://trello.com/c/ZusIHb5G/8-organise-components-under-a-ui-elements-sec… [4] http://getbootstrap.com/components/ [5] https://trello.com/c/tKKWz3fo/7-javascript-auto-expand-table-of-contents

2 2

MediaWiki UI Forms
by Jon Robson 09 Sep '14

09 Sep '14

On bug 65317 [1] it is suggested that the preferences page should have buttons aligned to the right and should be ordered so constructive is the last. I've written a fix for this and I would appreciate some code review. This had me wondering, should this apply to all forms? e.g. the editing form If so I think we probably need to get this into the style guide in some form, detailing how buttons should be ordered. We may want to introduce mw-ui-button-group or mw-ui-form-button-group. [1] https://bugzilla.wikimedia.org/show_bug.cgi?id=65317

6 13

Re: [Design] [WikimediaMobile] SVG to font (WAS: The future of skins_
by Matthew Flaschen 06 Sep '14

06 Sep '14

On 09/04/2014 03:29 AM, Monte Hurd wrote: > The font forge importation workflow was sticky enough (importing svgs > and mapping them, etc) that small visual tweaks (baseline offsets and > such) ended up being made in the font forge project itself as well, > thus diverging from the source svgs. This is why automation and having a clear understanding of what the source code is are both so important. > I think this workflow stickiness was what led the designer to see the > font forge project as canonical. Actually, it was somewhat ambiguous what the source code is. Read https://gerrit.wikimedia.org/r/#/c/137888/ if you want to know what I mean. > One automates creating a font from a folder of svgs. Svgs are > canonical as they should be, but hey, you want a font? You got it. Great. This will be useful for the app, and if we ever decide to revisit the decision about icons on web (I completely agree SVG is better as source code, but we could still use generated fonts on desktop if we decided that approach was suitable). Matt Flaschen

1 0

← Newer
1
...
18
19
20
21
22
23
24
...
61
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

Design