Design

design@lists.wikimedia.org

604 discussions

Agora button semantics and CSS naming
by S Page 08 Nov '13

08 Nov '13

Agora specs[1] introduce expanded button semantics, but the "Buttons" visuals on p. 3 don't name or explain them. I added that image and some explication to the existing page "Patterns and components"[2] <mildflame on>Don't ignore existing specs just because you didn't work on them! Update pages when designs change, don't leave them to rot and mislead.</mildflame> Because the semantics are changed, some current styles in mediawiki.ui don't cleanly map: * mw-ui-primary (the main button, e.g. [Login]) * mw-ui-constructive (an alternative, e.g. "Don't have an account? [Join Wikipedia]" button) The new specs distinguish continue and completion actions for the primary button, and a constructive alternative is just a plain button. mw-ui-primary can either remain the style for the complete form action (changing from blue to green!) or be a deprecated synonym for a new mw-ui-completion style, since I don't think any multi-step forms use Agora yet. I think mw-ui-constructive becomes a deprecated no-op. Flow's CSS uses "mw-ui-button mw-ui-text" for actions that don't appear as a button (the two top rows). [1] https://www.mediawiki.org/wiki/File:Agora_specs.pdf [2] https://www.mediawiki.org/wiki/Wikimedia_Foundation_Design/Patterns_and_com… -- =S Page Features engineer

12 23

Are external link icons useful
by Jon Robson 31 Oct '13

31 Oct '13

Changed subject to reflect this change in topic. Also cc'ing design mailing list. In terms of external links to me I don't care about whether I'm leaving the site or not. If I clicked on something and it wasn't what I expected that's a badly labeled link. A link saying there is more information on the [white house official website] and a link to the word [house] should be enough information to tell which I'd external and which isn't. I actually think the only place an icon next to a link really makes sense is for downloads. Clicking something that downloads a PDF when I thought it was a web page is a little confusing (on mobile at least). That said if all the external links are in the external links / references section wouldn't encouraging that organisation of links be better....? Also I agree with Juliusz that we shouldn't force behaviour of where links open. It should be up to the user if they want the same tab or new one and it should be configurable within the browser preferences. On 24 Oct 2013 16:07, "Juliusz Gonera" <jgonera(a)wikimedia.org> wrote: > No, we should definitely not warn people, that's just weird ;) It's not > like something bad is about to happen. > I'm also not saying that users have the expectation that links point to > local URLs, I'm only saying that it might be a useful piece of information > to some. > > > On 10/24/2013 02:48 PM, Jared Zimmerman wrote: > > Its definitely a less heavy handed way of doing the thing many > (annoying) sites do when they warn you that you're leaving their site. I > just wonder is the signal to noise it worth it. I don't know that modern > web users have any expectations that link within a site always point to > local site urls. > > * > * > * > * > *Jared Zimmerman * \\ Director of User Experience \\ Wikimedia > Foundation > M : +1 415 609 4043 | : @JaredZimmerman<https://twitter.com/JaredZimmerman> > > > >

9 14

Design Team Promotion
by Jared Zimmerman 31 Oct '13

31 Oct '13

Hello All, It is my great pleasure to announce the promotion of Vibha Bamba to Senior User Experience Designer. Vibha is recognized for her leadership in mobile design at the foundation as well as her recent efforts to “Humanize Wikipedia.” It should come as no surprise that she is one of the pillars of our design group. Her efforts to further Design internally at the Foundation as well as the Foundations standing in the tech and non-profit Design community have helped us attract new talent to the group as well as interest from community members wanting to volunteer their time to improve the appearance and usability of the projects. Please join me in congratulating Vibha on this exciting news, Jared Zimmerman * * * * *Jared Zimmerman * \\ Director of User Experience \\ Wikimedia Foundation M : +1 415 609 4043 | : @JaredZimmerman<https://twitter.com/JaredZimmerman>

1 0

Success, warning, and error boxes
by Matthew Flaschen 30 Oct '13

30 Oct '13

I've merged Bartosz's patch (https://gerrit.wikimedia.org/r/#/c/82828/) for rolling out the boxes to all forms, not just vforms. He used the same colors as the vform styles. It seems to me that the success and error boxes might be better with a little more color contrast. You can test on Beta (http://en.wikipedia.beta.wmflabs.org/) by editing your preferences (success), going to Special:UserLogin while logged in (warning), and entering the wrong password for login (error). Matt Flaschen

3 3

Re: [Design] [Wikitech-l] Should MediaWiki CSS prefer non-free fonts?
by Matthew Flaschen 30 Oct '13

30 Oct '13

On 10/27/2013 03:37 PM, Steven Walling wrote: > Many FOSS communities have dealt with the trade off between great-looking > fonts and freedom by commissioning foundries to get their own free fonts. > See also: Ubuntu, Android, and more. I've talked to the design team about > this idea, including perhaps getting a foundry to donate a unique font > stack in exchange for the publicity they'd get. Do we really need our own, or are there already quality free fonts we can list? Has the design team taken a good look at the existing free fonts? My general position is that it is not a violation of our principles to list a proprietary font in the stack. However, we should never *distribute* such a font. I would prefer that free fonts appear first, and that is more workable if we can find good free fonts that suit our design needs. We should also ensure that the interface does not look worse in the future than it does today, when using free fonts. Also, remember that font-matchers may substitute a free font when they are given a proprietary font name. Matt Flaschen CCing design

8 15

Re: [Design] conflicting uses of smiley face UI component
by Jon Robson 25 Oct '13

25 Oct '13

On Mon, Oct 21, 2013 at 7:11 PM, Ryan Kaldari <rkaldari(a)wikimedia.org> wrote: > Recently on mobile we switched our iconography used to represent a user from > being a simplified head and shoulders to being a square smiley face. > Unfortunately, the square smiley face is already being used to represent the > thank action (via the Thanks extension). You can see an example of these two > UI elements being used on the same page in this design mock-up for the > mobile media viewer: > https://commons.wikimedia.org/wiki/File:Media-viewer-tools-mobile-design-pa… > > As you can see, it's a bit confusing having 2 square smiley faces in the > same interface representing separate things (not to mention the square > frowny face for the flag action). > > I would suggest that we change one or the other. Since the thank iconography > has already been through much debate and revision (originally being a red > heart, then a green heart, then a smiley face), I would favor changing the > user iconography back to a head and shoulders. Thoughts? > > Ryan Kaldari

10 21

Re: [Design] [Wikitech-l] Visualising CSS debt - cleaning up our messy codebase
by Matthew Flaschen 25 Oct '13

25 Oct '13

On 10/24/2013 08:27 PM, Steven Walling wrote: > Thanks for doing this Jon. > > When I used the Vector version, at first I got an all black screen, which > made me think it was broken. I guess that was just a CSS rule to click and > delete? :) Yes. > Yeah, if we don't have a bug about settling on one overlay style, we > should. This is pretty bad. Maybe the work being done to split out > ve.ui/oo.js/whatever we're calling it might help us settle on a standard? It's part of https://bugzilla.wikimedia.org/show_bug.cgi?id=55534 >> * .guider_button >> > > Extension:GuidedTour. Matt will explain more I'm sure. Right. As noted, it's not actually being used. To complicate it further, I think the UX team actually now wants to go in a totally different direction with no blue buttons at all (https://www.mediawiki.org/wiki/File:WMF_DESIGN_Password_Reset.png). So we should try to finalize that if possible. That might avoid people having to go back and change their HTML twice (once to use mw-ui, another to e.g. add another layer). In some cases CSS can be changed alone, but sometimes they have to be changed in tandem, which is more code to touch. CCing the design list. Matt

2 2

wikiHow launches redesign
by Steven Walling 24 Oct '13

24 Oct '13

Few other popular sites use MediaWiki as their primary CMS. Basically it's just us, Wikia, and wikiHow AFAIK. I'd definitely go to wikihow.com and check out what they've done in their just-launched redesign. Here's a screenshot of their previous homepage, for comparison: https://upload.wikimedia.org/wikipedia/en/archive/9/9a/20131019173222%21Wik… -- Steven Walling, Product Manager https://wikimediafoundation.org/

11 15

Fwd: Google Code-in: are you in?
by Quim Gil 22 Oct '13

22 Oct '13

Google Code-in is open to tasks related with user interface. Are you in? -------- Original Message -------- Subject: Google Code-in: are you in? Date: Thu, 10 Oct 2013 10:51:21 -0700 From: Quim Gil <qgil(a)wikimedia.org> To: Wikimedia developers <wikitech-l(a)lists.wikimedia.org> Google Code-in has been announced: http://www.google-melange.com/gci/homepage/google/gci2013 This is about 13-17 year old students performing tasks that can be isolated and a skilled contributor would complete in a couple of hours. The tasks mjust have a mentor and can be related to code, documentation, outreach, QA or UX. Participants get one point for each task completed and they can complete as many as they can between 18 November and 6 January. Wikimedia can apply thanks to our participation on GSoC 2013. The deadline is 28 October. Only 10 organizations will be accepted. I think we should apply. Main reasons: * The definition of a Code-in task fits very well with our ideal definition of an annoying little bug: https://www.mediawiki.org/wiki/Annoying_little_bugs * The typical Code-in participant needs what most potential new contributor also need from us: an insightful landing page, straight connections to first tasks and friendly community support. * Just like GSoC / OPW, it is a good chance for non-primetime projects to raise their hands, get some help and hopefully some new contributors. * Good exercise for first-time mentors, practicing for more co plex internship projects. * Good exercise for any open source project, meaning just any MediaWiki / Wikimedia tech project. But of course this will only work if many projects want to step in with a task and a mentor for it. So what do you think? -- Quim Gil Technical Contributor Coordinator @ Wikimedia Foundation http://www.mediawiki.org/wiki/User:Qgil

1 1

Return of the annoying post account creation screen
by Jon Robson 21 Oct '13

21 Oct '13

When I sign up on beta labs for a new account instead of getting thrown back to the article I was on I get this instead: http://imgur.com/zFA7Nql Has this always been the case or did something change? I thought we made a decision to move away from this horrible intermediate screen? http://en.m.wikipedia.beta.wmflabs.org/w/index.php?title=Special:UserLogin&…

4 4

← Newer
1
...
33
34
35
36
37
38
39
...
61
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

Design