Design

design@lists.wikimedia.org

602 discussions

Fwd: Welcome May Galloway -- Visual Designer
by Sumana Harihareswara 04 May '13

04 May '13

Welcome, May Galloway! Thanks, Sumana -------- Original Message -------- Subject: [Wmfall] Welcome May Galloway -- Visual Designer Date: Thu, 2 May 2013 11:05:35 -0700 From: Howie Fung <hfung(a)wikimedia.org> Hey all, I'm pleased to welcome May Galloway, a new member of our design team. May is starting today as Visual Designer and will work across our projects to help make our features more engaging, and *gasp* fun to use :) May joins us from The Weather Channel, where she was a User Interface/User Experience Designer. During her time at The Weather Channel, she primarily worked on designing mobile phone and tablet applications specifically on Android, Windows, and iOS platforms.

2 1

Feedback/Suggestions regarding the UI mockups
by Rahul Maliakkal 01 May '13

01 May '13

Hello I am Rahul Maliakkal, 3rd year UG student applying for Google Summer of Code(GSoc). The idea that I plan on implementing is a "PRONUNCIATION RECORDING EXTENSION' .I have made a few UI Mockups in my proposal, I would like the feedback and suggestion from the WMF Design community The link to my proposal: https://www.mediawiki.org/wiki/User:Rahul21/Gsoc Thank You

4 8

Fwd: Re: Left nav/right nav
by Jon Robson 01 May '13

01 May '13

whoops. sending fail... ---------- Forwarded message ---------- From: <design-owner(a)lists.wikimedia.org> Date: 26 Apr 2013 08:46 Subject: Re: [Design] Left nav/right nav To: <jdlrobson(a)gmail.com> Cc: You are not allowed to post to this mailing list, and your message has been automatically rejected. If you think that your messages are being rejected in error, contact the mailing list owner at design-owner(a)lists.wikimedia.org. ---------- Forwarded message ---------- From: Jon Robson <jdlrobson(a)gmail.com> To: "A list for the design team." <design(a)lists.wikimedia.org> Cc: Date: Fri, 26 Apr 2013 08:46:08 +0100 Subject: Re: [Design] Left nav/right nav Raging hatred is for having 2 places for menus. History has shown us (user testing) that secondary menus are not discoverable. People always look in the hamburger first (or don't even find that!!) That said a user button makes sense if it takes a user to a profile page. I'm mostly worried about moving things from the left menu to another menu and having a second menu. Somehow even though login, watch list and uploads belong to a user they are a site activity in some ways and I'd still prefer to see them in the left menu. To me a profile would best serve access to user page, stats and user talk page but not incorporate the other things. Having 2 menus also makes the user have to think is that in x menu or y menu? "I don't understand. When I press our current hamburger, the page moves to the right and my finger is over the Home button..." That's what 24 hrs without sleep does to you. :) I can't articulate what it is about the Facebook app and wiki right menu prototype I don't like but this is not in. Just something feels unnatural about it. In terms of fb it could be the inconsistency...on private messages hitting info hides the button and leaves hamburger in place but doesn't do this for news feed. It may however be the fact the right user menu is just not how I use Facebook and contains features I see as useless. The search on the left menu in Facebook serves the exact same purpose. I'd really push us to leave the left menu as it is (with some visual separation) and think of the user button as more of a profile page then a place to find features. Where watch star goes is another question. In terms of fixed positioning the only way to do this reliably and nicely (and then only if JavaScript is enabled) is to use something like iscroll and reimplement native browser scrolling. On 25 Apr 2013 20:30, "Juliusz Gonera" <jgonera(a)wikimedia.org> wrote: > That's more like it ;) > Also, I'd squeeze in a few most recent notifications in there when we have > Echo. > > > On 04/25/2013 12:11 PM, Maryana Pinchuk wrote: > > You're right, Vibha; a picture is worth a thousand words :) > > Jon, ignoring the specific elements of what's in the "me" menu (all just > placeholders at this point), does my scribbling below make more sense > conceptually? Despite the "nav" in the title, the story card actually > leaves implementation pretty open: > https://mingle.corp.wikimedia.org/projects/mobile/cards/579. I can > clarify in the title of the card and the A.C. that this should be an > overlay, not a nav. Does that address some of your concerns? > > > [image: Inline image 1] > > > On Thu, Apr 25, 2013 at 11:32 AM, Vibha Bamba <vbamba(a)wikimedia.org>wrote: > >> At this point we should be doing this at a whiteboard. >> There are some legitimate concerns but text is hardly a medium to improve >> ideas =] >> >> >> On Thu, Apr 25, 2013 at 11:21 AM, Maryana Pinchuk < >> mpinchuk(a)wikimedia.org> wrote: >> >>> On Thu, Apr 25, 2013 at 10:39 AM, Jon Robson <jrobson(a)wikimedia.org>wrote: >>> >>>> I'm beginning to exhibit raging hatred of the right nav concept... >>>> >>>> Firstly.. Ergg. two settings is confusing (site and user) - they >>>> should be the same page and there is no reason why they can't be. It >>>> would be great if when logged in the settings page morphed from device >>>> specific to user specific. Would be great to be able to activate alpha >>>> on all my devices. >>>> >>>> In terms of a right nav, the more I think about it and having played >>>> with a prototype I knocked up, the more I think a right nav is bad. >>>> Although it seems to be becoming an established pattern it seems like >>>> an easy option that in my opinion is badly implemented. We can do >>>> better and should lead by example. For one I never touch the Facebook >>>> one... it just doesn't come natural. I also don't like the idea of 2 >>>> menus. I wonder if we could envision 2 stacked menus that can be >>>> toggled between and persist when selected. >>>> >>>> To quote >>>> http://www.upassoc.org/upa_publications/jus/2011august/faulkner2.html >>>> "... Kingsburg and Andre carried out two studies with 16 users and >>>> found in both of their studies that selection from a left-hand menu >>>> was faster than from a right-hand menu (2004). However, their research >>>> also showed that selections were best done from the same panel, >>>> whether that was on the right or left. Thus it is better to have a >>>> single design, either on the left or the right, rather than a mixed >>>> navigational method that requires the user to select from both left >>>> and right panels (Kingsburg & Andre, 2004). This is hardly surprising >>>> and is both predicted and supported by Fitts’ Law. (1954)." >>>> >>>> The thing that bugs me most is that when you move your finger over the >>>> left hamburger button and press it the page moves to the left. Your >>>> finger is still above the button. This doesn't apply to the right >>>> menu. Your finger is now above something else. This to me is very >>>> jarry and always feels icky. >>> >>> >>>> It still leaves the question of where things such as watch star, talk >>>> page link, edit, move and delete buttons go. >>>> The bottom would make sense for an app, but position fixed is buggy in >>>> the majority of current mobile browsers and we will need a fallback of >>>> some sort. >>>> >>> >>> Is it just the "nav" part that bothers you, and not so much the >>> "right" and "my stuff" part? What if we had a little person icon to the >>> right of the search bar, and tapping that opened an overlay with pretty >>> visualizations of your recent editing and uploading activity, as well as >>> links to your watchlist and talk page? *That's* what I ultimately want >>> to work toward; in my mind, the nav part was always just a stepping stone, >>> but maybe we don't actually need that stepping stone and can just go >>> directly to (sneakily) beginning work on a totally new, totally rad mobile >>> userspace :) >>> >>> -- >>> Maryana Pinchuk >>> Associate Product Manager, Wikimedia Foundation >>> wikimediafoundation.org >>> >>> _______________________________________________ >>> Design mailing list >>> Design(a)lists.wikimedia.org >>> https://lists.wikimedia.org/mailman/listinfo/design >>> >>> >> >> _______________________________________________ >> Design mailing list >> Design(a)lists.wikimedia.org >> https://lists.wikimedia.org/mailman/listinfo/design >> >> > > > -- > Maryana Pinchuk > Associate Product Manager, Wikimedia Foundation > wikimediafoundation.org > > > _______________________________________________ > Design mailing listDesign@lists.wikimedia.orghttps://lists.wikimedia.org/mailman/listinfo/design > > > > _______________________________________________ > Design mailing list > Design(a)lists.wikimedia.org > https://lists.wikimedia.org/mailman/listinfo/design > >

5 6

Underline on a.mw-ui-button
by Matthew Flaschen 30 Apr '13

30 Apr '13

commonElements (one of the screen stylesheets for both Monobook and Vector) has: a:hover, a:focus { text-decoration: underline; } Do you think it makes sense to turn this underline off for all a.mw-ui-buttons (Agora buttons using an a element)? We're doing this for GuidedTour buttons (e.g. https://commons.wikimedia.org/wiki/File:Guiders-Agorastyle.png), but I thought it might be of broader use. Thanks, Matt Flaschen

4 4

Re: [Design] Left nav/right nav
by Jon Robson 25 Apr '13

25 Apr '13

I'm beginning to exhibit raging hatred of the right nav concept... Firstly.. Ergg. two settings is confusing (site and user) - they should be the same page and there is no reason why they can't be. It would be great if when logged in the settings page morphed from device specific to user specific. Would be great to be able to activate alpha on all my devices. In terms of a right nav, the more I think about it and having played with a prototype I knocked up, the more I think a right nav is bad. Although it seems to be becoming an established pattern it seems like an easy option that in my opinion is badly implemented. We can do better and should lead by example. For one I never touch the Facebook one... it just doesn't come natural. I also don't like the idea of 2 menus. I wonder if we could envision 2 stacked menus that can be toggled between and persist when selected. To quote http://www.upassoc.org/upa_publications/jus/2011august/faulkner2.html "... Kingsburg and Andre carried out two studies with 16 users and found in both of their studies that selection from a left-hand menu was faster than from a right-hand menu (2004). However, their research also showed that selections were best done from the same panel, whether that was on the right or left. Thus it is better to have a single design, either on the left or the right, rather than a mixed navigational method that requires the user to select from both left and right panels (Kingsburg & Andre, 2004). This is hardly surprising and is both predicted and supported by Fitts’ Law. (1954)." The thing that bugs me most is that when you move your finger over the left hamburger button and press it the page moves to the left. Your finger is still above the button. This doesn't apply to the right menu. Your finger is now above something else. This to me is very jarry and always feels icky. It still leaves the question of where things such as watch star, talk page link, edit, move and delete buttons go. The bottom would make sense for an app, but position fixed is buggy in the majority of current mobile browsers and we will need a fallback of some sort. On Thu, Apr 25, 2013 at 5:57 PM, Maryana Pinchuk <mpinchuk(a)wikimedia.org> wrote: > On Apr 24, 2013, at 2:37 PM, Juliusz Gonera <jgonera(a)wikimedia.org> wrote: > >> My only concern about the right nav is that we might be moving too many things there. I think that people might be confused by not seeing e.g. Settings after tapping the hamburger (the mingle card mentions it in the right nav). Also, settings are currently tied to the device, not the user. > > I had the same hesitation with settings, actually. I think you're right that the way we use settings currently is more like "site-wide settings" than "my personal preferences" and thus belongs in the left nav. But at some future date, we could also add personal user preferences to the right nav :)

5 7

Making Interproject links more prominent
by Yuvi Panda 25 Apr '13

25 Apr '13

There's a discussion / RFC on meta about making interproject links more prominent. It has a bunch of designs being discussed, and I think there'll be more added before consensus can be reached: https://meta.wikimedia.org/wiki/Requests_for_comment/Interproject_links_int… -- Yuvi Panda T http://yuvi.in/blog

1 0

Re: [Design] [Wikitech-l] Making inter-language links shorter
by Sumana Harihareswara 24 Apr '13

24 Apr '13

https://www.mediawiki.org/wiki/Accessibility has a list of "People and organizations working on MediaWiki accessibility" including Sami Mubarak, who works on the accessibility of MediaWiki for the blind (in Arabic). I've cc'd Sami. Hope this helps! -- Sumana Harihareswara Engineering Community Manager Wikimedia Foundation On 04/24/2013 03:17 PM, Brion Vibber wrote: > Please note that "screen readers" and "readers without JavaScript" aren't > in any way the same thing -- modern screen readers hook into "real > browsers" like IE, Safari, Chrome, and Firefox and JavaScript runs just > great in them. > > Serious accessibility concerns should really be referred to someone who's > an expert... do we have anybody on staff or volunteer who has real, direct, > current experience with vision-impaired users and their needs? > > -- brion > > > On Wed, Apr 24, 2013 at 11:51 AM, Pau Giner <pginer(a)wikimedia.org> wrote: > >>> >>> Also, did you think of the accessibility issues in your solution? >> >> >> First, I want to clarify that the prototype was made just to communicate >> the idea in terms of interaction. The The implementation is just a quick >> hack to simulate this interaction. >> >> For a production implementation I can image the whole list of languages to >> be sent to the client, and then, the list being shortened by Javascript. >> For those users without Javascript (from screen-readers, to Search engine >> crawlers) the same list of links they receive now will be available for >> them. >> >> In any case, developers could provide even better strategies to solve that. >> As an interaction designer I just wanted to share the idea to collect >> possible concerns with the interaction proposed, to be fixed in next >> iterations of the designs before development effort is made. >> >> >> >> >> On Sat, Apr 20, 2013 at 2:04 AM, Mathieu Stumpf < >> psychoslave(a)culture-libre.org> wrote: >> >>> Also, did you think of the accessibility issues in your solution? Here I >>> especialy think of people with view disabilities, for who js often mean >>> no way to get the content, while a long list of hyperlinks is >>> manageable. >>> >> > _______________________________________________ > Wikitech-l mailing list > Wikitech-l(a)lists.wikimedia.org > https://lists.wikimedia.org/mailman/listinfo/wikitech-l >

1 0

Re: [Design] [Wikitech-l] Making inter-language links shorter
by Jon Robson 19 Apr '13

19 Apr '13

---------- Forwarded message ---------- From: "Jon Robson" <jdlrobson(a)gmail.com> Date: 19 Apr 2013 00:41 Subject: Re: [Design] [Wikitech-l] Making inter-language links shorter To: "A list for the design team." <design(a)lists.wikimedia.org> Cc: The alpha version (here be dragons more) of the mobile site exposes talk pages in an overlay. Currently working on allowing contribution to this page. Try it out by going to settings opting into beta then going back again and opting into the dragons mode... feedback welcomed! On 19 Apr 2013 00:38, "Mathieu Stumpf" <psychoslave(a)culture-libre.org> wrote: > Le 2013-04-19 00:12, Brion Vibber a écrit : > >> On Thu, Apr 18, 2013 at 3:08 PM, Mathieu Stumpf >> <psychoslave(a)culture-libre.org**> wrote: >> >> Oh by the way, is there an access to discussion pages on the mobile >>> version now? Last time I checked it wasn't accessible directly, but at >>> the begining it wasn't possible to access other languages if I'm not >>> mistaken, so I thought that may also come with an update. >>> >> >> I believe Jon may be working on something to expose talk pages, but >> it's not quite ready yet. We were kind of hoping to wait for a more >> structured discussion system to come into place, but we're still >> waiting on that. >> >> In the meantime, you should be able to jump to them via the search >> box, it just won't be very pretty. :) >> > > My personal work around is: going to the desktop version>going to the talk > page>going to the mobile version > > On mobile following links is, in my experience, easier to do than typing > words. ;) > > -- > Association Culture-Libre > http://www.culture-libre.org/ > > ______________________________**_________________ > Design mailing list > Design(a)lists.wikimedia.org > https://lists.wikimedia.org/**mailman/listinfo/design<https://lists.wikimedia.org/mailman/listinfo/design> >

1 0

Re: [Design] [Wikitech-l] Making inter-language links shorter
by Mathieu Stumpf 19 Apr '13

19 Apr '13

Le jeudi 18 avril 2013 à 12:57 -0700, Brion Vibber a écrit : > On the mobile site we've collapsed the whole thing to an "Other languages" > section or button (depending on if you're in beta mode) at the bottom of > the article, and this seems to have gotten good usability responses from > mobile users. Oh by the way, is there an access to discussion pages on the mobile version now? Last time I checked it wasn't accessible directly, but at the begining it wasn't possible to access other languages if I'm not mistaken, so I thought that may also come with an update.

2 2

how to improve visual & interaction design skills
by Sumana Harihareswara 18 Apr '13

18 Apr '13

For those of you who haven't obsessively followed Brandon Harris's answers on Quora http://www.quora.com/Brandon-Harris-1/answers -- check out his suggestions on how to improve your skills at interaction design and visual design: http://www.quora.com/Communication-Design/How-can-I-get-good-at-visual-and-… A few key tips from Brandon's answer: design is about understanding problems. Look at problems and try to re-solve the problems you run across every day, both simple and complex. Research why people created existing solutions and made certain decisions, and think about what you'd do differently. Learn to communicate your designs, and practice a lot. Brandon, thanks for the writeup. -- Sumana Harihareswara Engineering Community Manager Wikimedia Foundation

2 1

← Newer
1
...
42
43
44
45
46
47
48
...
61
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

Design