Design March 2014

design@lists.wikimedia.org

39 participants
37 discussions

Winter User Tests, Round Two (and Two: Electric Boogaloo)
by Brandon Harris 16 Mar '14

16 Mar '14

I have run two sets of user tests with Winter to determine the usability of in-header page action icons and whether or not users can easily recognize their personal tools menu and the search box, especially after scrolling in the page. The results are not encouraging for the in-header icons. Two tests were run because the first test had some possible errors and confusions. The second test (Winter Harness Two Electric Boogaloo) had some modifications to the flow to avoid people getting lost on user talk pages (this was the result of the first version of Harness Two telling them to click on the Speech Bubble icon in the top right if they were lost - but they had scrolled to the top already). H2:EB corrected this by directing them to the context action ribbon. * https://www.mediawiki.org/wiki/Winter#Harness_Two:_Winter * https://www.mediawiki.org/wiki/Winter#Harness_Two:_Electric_Boogaloo * Only *one* user out of ten correctly used the in-header page action icons. Further, his language indicated that he had some icon confusion: he thought that only a few icons were added, and that existing ones were moved (e.g., history and edit were new, but the watch list icon was still the same). * Most users were unable to recognize the personal tools section as being "my stuff" unless their username was ''also'' included. Once the username was gone, it was invisible to them (with rare exceptions, and mostly by accident then). * No users had trouble with the search box. At all. * Most users ended up using the context action ribbon and ignored other navigation hints. * The in-header TOC might as well be invisible. * At this point, with 10 testers and a 10% success rate, I'd say that the benefits of putting page icons in the header are outweighed by the negatives of losing the username for discoverability. Discussion here: https://www.mediawiki.org/w/index.php?title=Talk:Winter&workflow=rr0ke21yl3… --- Brandon Harris, Senior Designer, Wikimedia Foundation Support Free Knowledge: http://wikimediafoundation.org/wiki/Donate

4 6

Requesting feedback on Project- UploadWizard: Openstreetmap embedding
by Anu George Enchackal 14 Mar '14

14 Mar '14

Hi Everyone, I would like to invite your feedback on [1] prototype of Project-'UploadWizard:OSM embedding' [ user/password is mediawiki/mw ]. This project is about enhancing the image upload process for Wikimedia Commons.The main goal of the OSM embedding project is to provide map interface to the UploadWizard. We can not expect each and every uploader to know exact location where image being uploaded was taken, or to use location enabled camera/phone to take the image. With introduction of map interface, uploader can easily choose location coordinates for uploaded images. Detailed project description can be found at [2]. Functioning of embedded map : - On valid coordinates/location inputs widget first loads a static map which on 'click' will initialize leaflet powered dynamic map - Address search - ' type' or 'importance' specific zoom for various kinds of locations on address search - .Dynamic updation of coordinate fields and location field on leaflet map interaction and vice versa Kindly give your suggestions for map widget- design as it needs to be improved, also propose features and/or improvements in current features. Please share your insights at [3]. [1]http://uploadwizard-osm.bitnamiapp.com/mediawiki/Special:UploadWizard [2] https://www.mediawiki.org/wiki/UploadWizard_OSM_map_embedding [3] https://www.mediawiki.org/wiki/Talk:UploadWizard_OSM_map_embedding Best regards Anu G Enchackal

6 7

English Wikipedia Main Page Redesign 2014
by Gabriel Chi Hong Lee 14 Mar '14

14 Mar '14

Dear all, I have noticed a page called Wikipedia:2014 main page redesign proposal in Wikipedia, I want to confirm that the community really wants to have the main page design changed. If the community really wants to change, I suggest to use User:Gabrielchihonglee/Main_Page as the new design. How do you guys think about that? _______________________________________________ Gabriel Lee Admin at beta and wy/zh #PRAYFORMH370

2 1

Winter User Test Results, Part 1
by Brandon Harris 13 Mar '14

13 Mar '14

The first battery of user tests have completed against the Winter prototype. I have included links to all of them at the main Winter page: https://www.mediawiki.org/wiki/Winter#Harness_One:_Winter All tests are annotated, but highlights are included in-line. The primary take-aways are: * No tester had difficulty recognizing the search bar. * All testers quickly grasped the in-page context action ribbon. * Several testers expressed surprise that Wikipedia had discussions, which lends even more credence to the idea that Vector tabs are effectively invisible. * The "Cancel" button from the editor may need work. * All testers found their way to the contributions page, even when faced with bugs/difficulties. They just did it in other routes. I am very pleased with the results. I’ve created a Flow discussion about this here: https://www.mediawiki.org/w/index.php?title=Talk:Winter&topic_postId=rqjdm7… --- Brandon Harris, Senior Designer, Wikimedia Foundation Support Free Knowledge: http://wikimediafoundation.org/wiki/Donate

6 9

Re: [Design] [Wikitech-l] Requesting feedback on Project- UploadWizard: Openstreetmap embedding
by Ryan Kaldari 12 Mar '14

12 Mar '14

Glad to hear you were aware of the earlier work. I agree it is often easier to reimplement something from scratch than finishing someone else work. Regarding the static maps on initial load, I found this feature to be unintuitive when I tried it. IMO, it would be better to just show a spinner while the map is loading, rather than requiring an extra click to get to the actual map. The rest of the functionality seemed quite smooth and intuitive. Nice work! Ryan Kaldari On Wed, Mar 12, 2014 at 3:50 PM, Gergo Tisza <gtisza(a)wikimedia.org> wrote: > On Wed, Mar 12, 2014 at 2:42 PM, Ryan Kaldari <rkaldari(a)wikimedia.org > >wrote: > > > Ack, I wish I had known about this earlier. Most of these features had > > already been implemented for UploadWizard, but the patches were never > > polished enough to be merged: > > https://gerrit.wikimedia.org/r/#/c/12352/ > > https://gerrit.wikimedia.org/r/#/c/12353/ > > > > I would be good to at least compare against your implementation and see > if > > there are any ideas that would be useful to incorporate. > > > > I looked at those some time ago, but reusing them didn't seem much less > effort than reimplementing (also the OPW project had more ambitious goals > like Nominatim integration and using static maps initially to speed up page > load). > I didn't compare visually (you used CloudMade tiles, Anu uses MapQuest), > that would be worth doing. > > There is also a third OSM integration attempt, > https://github.com/lukaszkostrzewa/wiki which has some additional > server-side features which look interesting although probably overlap with > MobileFrontend's Nearby. > _______________________________________________ > Wikitech-l mailing list > Wikitech-l(a)lists.wikimedia.org > https://lists.wikimedia.org/mailman/listinfo/wikitech-l

1 0

Font stack
by Isarra Yos 11 Mar '14

11 Mar '14

Has it ever been specified why mw needs a font stack in the first place? Sure, when specifying only the generic type of font, the fonts different systems chose do look a bit different, but why is this a bad thing? From what I understand, these fonts are usually the most readable ones for the systems in question, hence why they are the defaults. So why do we want to override this? -I

15 44

Keep going mobile experiment badly thought out
by Jon Robson 11 Mar '14

11 Mar '14

Mobile is experimenting with showing a small banner at the top of the main page that prompts logged in editors to help a page in need of new links: https://en.m.wikipedia.org/wiki/Main_Page?mobileaction=beta I think this is _great_ and started playing with it on the train with nothing to do. Two improvements need to be made though: 1) It's difficult to know what to link to. I wrap words which I feel should be existing wiki pages but I pretty much have to guess or open a new window to check those. Some kind of search interface or link validation tool/corrector would be useful. 2) Since red links are turned off in the editor preview it can be tricky to know whether I caused a typo or linked correctly if new to wiki text. This is a bad first time user experience. Some kind of validation step or feedback when I create red links in the editor itself would be useful. We should at very least enable red links in the editor preview. On a side note: I really think we should give more priority to enabling new page creation on enwiki to help those sort of experiences before continuing down this path of encouraging new editors. People could start drafts, start pages with photos. This seems like a really useful focus of time.

3 5

Re: [Design] [WikimediaMobile] Musing about canned edit summaries
by Jon Robson 11 Mar '14

11 Mar '14

I had a chat with paper scrunching Moiz in person. To reiterate what I said there - as stated in my first email "I wanted to discuss whether this is a good idea?" To be clear I was never saying it was a bad idea. My original mail was just curious to the motivating factors to why we are doing it and what we are achieving and most specifically for me whether mobile web should be experimenting with it too. We should definitely try this out and see what happens. Max has identified that this happens already on Russian Wikipedia and Amir that this happens on Hebrew and Polish and I didn't know that. There is also a widely used gadget. Those are interesting data points. Steven has identified a problem you have with what summaries get canned. This is now a shared problem. This is why we discuss these things to understand them and end up building the right and the best thing. Please keep us up to date with designs. Maybe a volunteer might be interested in knocking this up for mobile web..? I'd love to see any other findings you've made. To wrap this conversation up can you share the link to the relevant trello card (I couldnt find it) or wherever is the best place to find your most up to date designs for this so if a volunteer/future me wants to work on this they can do so? On 11 Mar 2014 06:43, "Amir E. Aharoni" <amir.aharoni(a)mail.huji.ac.il> wrote: 2014-03-11 1:00 GMT+02:00 Max Semenik <maxsem.wiki(a)gmail.com>: > On 11.03.2014, 1:32 Jon wrote: > > The interface showed various buttons that when clicked would populate > > the edit summary input. e.g. "Fixed typos/grammar" or "Added links") > > > > I wanted to discuss whether this is a good idea? > Russian Wikipedia was doing that for ages to everyone's satisfaction. > The only problem is where to cram them in, but that's solvable. Hebrew and Polish Wikipedias are doing it for ages, too, and probably some other languages. In fact, numerous people complained that VisualEditor breaks this feature. Editors don't care whether it's a local custom gadget or something else - for all they care, it's a feature and VE breaks it. Anyway, it would be a lovely feature to productize and make available for all languages, for both mobile and desktop interfaces. The code is basically there - just take the gadget from one of the Wikipedias that currently use it and package it as an extension. -- Amir Elisha Aharoni · אָמִיר אֱלִישָׁע אַהֲרוֹנִי http://aharoni.wordpress.com ‪“We're living in pieces, I want to live in peace.” – T. Moore‬

1 0

Re: [Design] [WikimediaMobile] Musing about canned edit summaries
by Amir E. Aharoni 11 Mar '14

11 Mar '14

2014-03-11 1:00 GMT+02:00 Max Semenik <maxsem.wiki(a)gmail.com>: > On 11.03.2014, 1:32 Jon wrote: > > The interface showed various buttons that when clicked would populate > > the edit summary input. e.g. "Fixed typos/grammar" or "Added links") > > > > I wanted to discuss whether this is a good idea? > Russian Wikipedia was doing that for ages to everyone's satisfaction. > The only problem is where to cram them in, but that's solvable. Hebrew and Polish Wikipedias are doing it for ages, too, and probably some other languages. In fact, numerous people complained that VisualEditor breaks this feature. Editors don't care whether it's a local custom gadget or something else - for all they care, it's a feature and VE breaks it. Anyway, it would be a lovely feature to productize and make available for all languages, for both mobile and desktop interfaces. The code is basically there - just take the gadget from one of the Wikipedias that currently use it and package it as an extension. -- Amir Elisha Aharoni · אָמִיר אֱלִישָׁע אַהֲרוֹנִי http://aharoni.wordpress.com ‪“We're living in pieces, I want to live in peace.” – T. Moore‬

1 0

"Thoughts on humanizing Wikipedia for the mobile web" post
by Sumana Harihareswara 08 Mar '14

08 Mar '14

http://designatwikipedia.tumblr.com/post/62048718932/thoughts-on-humanizing… "With humanizing articles, we have two objectives: -Creating awareness about the editors and their interests on Wikipedia. -Promoting connections within the community using shared interests." The post shares some ideas and mockups and notes, "While the details are being refined, comments on the general direction towards contributions or alternate ideas would be super appreciated." (By the way, after this email, I'm unsubscribing from the design list as I prep for my sabbatical - more info at http://lists.wikimedia.org/pipermail/wikitech-l/2013-August/071542.html . If you need to talk about Wikimedia technical community stuff or communication before January, please consult Quim Gil, qgil at wikimedia dot org, or Guillaume Paumier, gpaumier at wikimedia dot org. Thanks! Looking forward to coming back in January.) -- Sumana Harihareswara Engineering Community Manager Wikimedia Foundation

5 4

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

Design March 2014