Design

design@lists.wikimedia.org

602 discussions

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

Cancel button
by Matthew Flaschen 07 Mar '14

07 Mar '14

The current proposed change to use mw-ui-button for save/preview/show changes/cancel (on the edit screen) uses mw-ui-destructive (with quiet) for the cancel button. This directly contradicts the style guide, which says, "This should not be used for cancel buttons.". As noted at https://gerrit.wikimedia.org/r/#/c/116725/ , my understanding of destructive is that you are deleting something that was already publicly visible, or at least has an impact beyond your own personal session. The cancel button doesn't seem to fit that. Cancel is a common concept, and semantically clear, so perhaps we should simply add mw-ui-cancel. Matt Flaschen

7 13

mediawiki.ui test instance on Labs
by Matthew Flaschen 07 Mar '14

07 Mar '14

I set up a mediawiki.ui test instance on Labs. For now, it is dedicated to showing the in-progress patch which is rolling out mw-ui to all buttons (https://gerrit.wikimedia.org/r/#/c/52169/). You can see what's implemented so far in the commit message in the top right. The URL is http://mwui.wmflabs.org/wiki/Main_Page . Feel free to check out those pages, create accounts, make test edits, etc. However, it's not a wiki for actual documentation or design mockups, etc. After that patch is done, the instance can be used for testing other mw.ui work. Matt Flaschen

2 2

Fwd: Re: Font stack
by bawolff 05 Mar '14

05 Mar '14

> > > > > > > Why would this be the best experience? > > In our case, a good experience means being able to *read stuff* and understand the content as easy as possible. Therefore, a typographic setup that makes reading as easy as possible makes for a good experience. Thats interesting. Some people have made arguments that the change would actually make it more difficult for some groups. My impression until now was that the change was being proposed because its pretty. > > > Why did the generic 'serif' and 'sans-serif' become insufficient? > > They were in fact never sufficient. But for quite some time, web technology didn't allow us to do it better. Now that it does (with webfonts and finer typographic control), why shouldn't we go ahead and improve our user experience? > > > > I'm sorry, but you are proposing using a technology that was introduced ~1996. It predates Wikipedia by 5 years. How is the web letting us do better now (webfonts dont count as this proposal isnt using them) -bawolff

1 0

← Newer
1
...
25
26
27
28
29
30
31
...
61
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

Design