Design September 2013

design@lists.wikimedia.org

35 participants
18 discussions

"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

Design ideas and help on an edit visualisation tool :-)
by jeph 16 Dec '13

16 Dec '13

Hi, I'm building a tool to make it easier for an editor to go through the edits/revisions in an article. The tool shows the changes in html rather than in wikitext. The content that was removed/deleted in a revision disappears & the new content/ modifications is made to appear. - Please checkout the live demo<https://googledrive.com/host/0B1hJO1N6piYFTTVZdW1mU2c0S28/visualise.html> . - My proposal https://meta.wikimedia.org/wiki/Grants:IEG/Replay_Edits. - Some mock ups. Mock 1<https://docs.google.com/file/d/0B1hJO1N6piYFM2FxVlBtakNlRXM/edit?usp=sharing> ,Mock 2<https://docs.google.com/file/d/0B1hJO1N6piYFMWUzVkpsR2dmUFU/edit?usp=sharing> The demo is bare bones & I'm working on adding the following features . - Pause/Forward/Rewind buttons - Draggable timeline , to select the starting revision and the ending revision. Hoping to hear some ideas or suggestions on the slider to select the start and end revision , especially when the article has thousands of edits over five or six years. Thanks Jeph

6 18

Bugzilla Guided Bug Entry Form
by Andre Klapper 10 Nov '13

10 Nov '13

[Please CC me on answers as I'm not subscribed.] Hi, I plan to enable a guided bug entry form on Wikimedia Bugzilla for newbies, to make reporting issues slightly easier. It can be seen on http://boogs.wmflabs.org/enter_bug.cgi?product=Wikimedia&format=guided Login: test(a)test.wmflabs Password: testtest Is this utterly horrible and unusable, or can I deploy it on bugzilla.wikimedia.org without making designers scream and ignore me for the rest of my life? The CSS isn't great (at least it *is* CSS now, sigh), but I needed to start somewhere. Thanks in advance, andre PS: Quick'n'dirty CSS recommendations are also welcome. -- Andre Klapper | Wikimedia Bugwrangler http://blogs.gnome.org/aklapper/

3 7

Re: [Design] Bugzilla Guided Bug Entry Form
by Andre Klapper 30 Sep '13

30 Sep '13

Hi Jared, thanks for the feedback! > -------- Original Message -------- > Subject: Re: [Design] Bugzilla Guided Bug Entry Form > Date: Wed, 25 Sep 2013 13:34:57 -0400 > From: Jared Zimmerman <jared.zimmerman(a)wikimedia.org> > Andre, how much control over this do we have? The upstream code is pretty low quality, and I won't become a great Perl hacker over night, so the answer is "It depends". :-/ There are a bunch of things that bugzilla.mozilla.org have which make the experience for the guided bug entry form way nicer[1], but I have not succeeded yet in convincing Mozilla devs to upstream their changes to Bugzilla. > a few notes: > > Step 1 of 3: Find out if your issue has already been reported, Please > search if your bug or feature request has been already reported by > entering some search words in this box that have to do with your issue, > for example upload error or search empty. Then press the Search button. > The results will appear in the box below. > > This is pretty verbose, and feels very repetitive, can we just say: > > "Search to see if your issue has already been reported." > __________ [ Search Issues ] > > for the search results can we refactor them a bit > > Summary / Product / Component / last updated / Assigned to / [This is my > issue] The displayed columns and their order seem to be based on the user's global preferences on columns displayed in Bugzilla search results, so for a new user they'd pick up the defaults. Question is if we want to change the defaults. > [This is my issue] would prompt the user to add the bug to their watch > bugs list if they have an account, Interesting, bugzilla.mozilla.org has this feature already "Follow bug" button for open tickets next to each search result. I guess that's in their custom "GuidedBug" extension that they use. Upstream ticket is https://bugzilla.mozilla.org/show_bug.cgi?id=616490 > or prompt them to create an account otherwise. You will already need an account to reach this bug entry form. > Can we have the search step on its own page, e.g. force users to search > before you can manually add their own? The option to add your own could > show up after you've done a search. > > [ My issue is new ] > > I assume there will be other components in the list, only one is showing > now, why is it duplicated in the box and to the right of the box? That's only the test instance. The text on the right will show the component description, like on https://bugzilla.wikimedia.org/describecomponents.cgi?product=MediaWiki > Can we swap Summary and Component areas? Yes! Added to my to-do list. > Having images is VERY helpful esp. if it is a design issue, Can we add > an image upload step after summary step, and allow multiple images? I am fine with adding a "Consider adding a screenshot" explanation for the time being (L10N Eng also asked for this). I'm not sure how much work it is to allow adding an attachment directly in this form; I'll investigate. I'll leave support for uploading several attachments at once to upstream developers - https://bugzilla.mozilla.org/show_bug.cgi?id=278469 > is URL usually have helpful information in it, if so perhaps we could > move that field up below results/expected results Will do. > Can we make reproducibility an optional step and just add the control > under the "steps to reproduce" not in a new section just below the text > field? Currently "Reproducibility" is optional and under the "Click here to show four more optional questions" on http://boogs.wmflabs.org/enter_bug.cgi?product=MediaWiki&format=guided > Wrap the remaining questions in a collapsed section called "Advanced", > Additional notes, browser, OS(?), mediawiki version(?), etc. To clarify: By remaining you also mean "Results" and "Expectations"? > Overall this is a great improvement. If you're up for making some > changes and iterating on it later when the design team or I have some > free cycles that would be great. Alright. Again thanks a lot for the very helpful and quick ideas! andre [1] see https://bugzilla.mozilla.org/enter_bug.cgi -- Andre Klapper | Wikimedia Bugwrangler http://blogs.gnome.org/aklapper/

1 0

Re: [Design] FYI: On Mobile, Data URIs are 6x Slower than Source Linking (New Research)
by Jon Robson 26 Sep '13

26 Sep '13

Thanks for this. This is very surprising... cc'in design and mobile list. Maybe we should rethink using css sprites for our icons? On Mon, Sep 23, 2013 at 2:57 PM, Ori Livneh <ori(a)wikimedia.org> wrote: > http://www.mobify.com/blog/data-uris-are-slow-on-mobile/ > > --- > Ori Livneh > ori(a)wikimedia.org

6 5

Agora spec on MediaWiki, Agora interest
by S Page 24 Sep '13

24 Sep '13

I uploaded the Agora spec on dropbox[1] to https://www.mediawiki.org/wiki/File:Agora_specs.pdf . I tried to put in appropriate disclaimers and links, edit away. I filed bug 54360 to implement new Agora spec in the mediawiki.ui CSS module. Now that the LESS CSS preprocessor[2] is in core there's some interest from various engineers. I work on it and a Special:Agora sample page after hours, but it's slow going. [1] https://www.dropbox.com/s/wa9uayq9j09agyh/Agora%20specs.pdf , from August 20. [2] http://lesscss.org/ Cheers, -- =S Page Features engineer

4 4

Design review of MassMessage extension
by legoktm 17 Sep '13

17 Sep '13

Hello! I've been working on the MassMessage extension, and am planning on having it deployed on Wikimedia sites[1]. The extension allows a user to send a message to a list of users across all projects. It is intended to replace the current global message delivery[2] system we have. Any design input you might have would be appreciated. The special page will only be visible to advanced users and administrators who are sending messages. I've set up a test wiki where you can play with it and test it out[3] (it might be a bit slow). You will need to login (username: 'Admin', password: 'test'). I've also uploaded a few screenshots to MediaWiki[4]. Thanks, -- Kunal Mehta (User:Legoktm) [1] https://bugzilla.wikimedia.org/show_bug.cgi?id=52723 [2] https://meta.wikimedia.org/wiki/Global_message_delivery [3] http://legoktm.instance-proxy.wmflabs.org/wiki/Special:MassMessage [4] https://www.mediawiki.org/wiki/Extension:MassMessage/Gallery

1 0

Re: [Design] [WikimediaMobile] Stop collapsing sections by default
by Adam Baso 17 Sep '13

17 Sep '13

Resending now that I'm on the design(a)lists.wikimedia.org list. On Tue, Sep 17, 2013 at 9:55 AM, Adam Baso <abaso(a)wikimedia.org> wrote: > There's been some additional discussion on this, taking search engine and > Find in Page optimization into account. > > https://bugzilla.wikimedia.org/show_bug.cgi?id=45951 > https://bugzilla.wikimedia.org/show_bug.cgi?id=49202 (my duplicate with > some Find in Page-oriented stuff) > > The smart search engine / Find in Page stuff is moderately complex, so I > think the tappable options for section expansion are the place to start. > > It seems to me that the following achieves TOC-like information at a > glance while balancing page load performance, usability, user choice, and > user choice measurement: > > * Don't auto-expand articles by default > * Do have a JavaScript-injected "Expand Sections" / "Collapse Sections" > feature at the top of articles with multiple sections > * Do have a user preference for Auto-Expand Sections on Article Load. > * To gauge love/hate for features, have two preferences as follows > > *Show 'Expand/Collapse Sections' Option at Top of Articles* > On / Off (default = On) > > *Auto-Expand Sections on Article Load* > *Note: this may slow page load time* > On / Off (default = Off) > > > > > > > > > On Mon, Sep 16, 2013 at 4:20 PM, Jared Zimmerman < > jared.zimmerman(a)wikimedia.org> wrote: > >> I like the idea of expanding by default because it fixes my pet peev of >> not being able to do a find on page from my mobile browser without first >> expanding all sections. >> >> * >> * >> * >> * >> *Jared Zimmerman * \\ Director of User Experience \\ Wikimedia >> Foundation >> M : +1 415 609 4043 | : @JaredZimmerman<https://twitter.com/JaredZimmerman> >> >> >> >> On Mon, Sep 16, 2013 at 12:52 PM, Mathieu Stumpf < >> psychoslave(a)culture-libre.org> wrote: >> >>> I didn't followed the thread, but if you try to consult the french >>> wiktionary with the mobile interface it's impossible: section title are >>> links so when you try to uncollapse them, you follow the link. >>> >>> Le lundi 16 septembre 2013 à 11:05 -0700, Brion Vibber a écrit : >>> >>> > On Mon, Sep 16, 2013 at 10:51 AM, Arthur Richards >>> > <arichards(a)wikimedia.org> wrote: >>> > If we still want to explore dynamically loading article >>> > sections (which we all seemed to be in favor of when we did >>> > annual planning back in June), it's hard for me to imagine how >>> > we could realistically pull that off if we display sections >>> > uncollapsed as default. >>> > >>> > >>> > We could rig up an "infinite scroll" type of situation, where we >>> > basically: >>> > >>> > >>> > * load section 0 and section 1 >>> > >>> > * leave placeholder <div>s for sections 2 and beyond >>> > >>> > * when the user scrolls down into section 1, start loading section 2 >>> > in the background >>> > >>> > ** prepare the same thing for the bottom of section 2 load section 3, >>> > etc... >>> > >>> > >>> > Of course a problem with this setup is that if you go offline partway >>> > through reading the article, the later sections might be unavailable >>> > when you scroll down to them. >>> > >>> > >>> > >>> > -- brion >>> > >>> > >>> > >>> > _______________________________________________ >>> > 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 >>> >> >> >> _______________________________________________ >> Mobile-l mailing list >> Mobile-l(a)lists.wikimedia.org >> https://lists.wikimedia.org/mailman/listinfo/mobile-l >> >> >

7 9

Re: [Design] [WikimediaMobile] Stop collapsing sections by default
by Jon Robson 17 Sep '13

17 Sep '13

+ design-l On 17 Sep 2013 12:47, "Jon Robson" <jdlrobson(a)gmail.com> wrote: > It's a very easy change to make - one line of code but it seems like the > majority of people are saying a preference button is a bad idea. > > Personally I think it would be more useful use of time to get event > logging up and running in some form to work out what is the best way of > dealing with this problem and if it is a problem before coding anything... > On 17 Sep 2013 12:25, "Juliusz Gonera" <jgonera(a)wikimedia.org> wrote: > >> On 09/16/2013 11:28 AM, aude wrote: >> >> On Mon, Sep 16, 2013 at 7:34 PM, Jon Robson <jdlrobson(a)gmail.com> wrote: >> >>> The more I think about it, the more I think, in its current state >>> mobile should not collapse sections by default. If you really want to >>> find a lower section, scrolling down the page and being able to >>> collapse a section to see the next one is easy, yet if you just want >>> to read the article in its entirety it is annoying to have to click to >>> expand a section. >>> >> >> I think default collapsed is good but would be nice to have one place >> to click to "expand all" sections, instead of one-by-one. >> >> >> I thought about such a button too. It's on my todo, I'll put something >> together for the experimental mode when I have some time. >> >> -- >> Juliusz >> >> _______________________________________________ >> Mobile-l mailing list >> Mobile-l(a)lists.wikimedia.org >> https://lists.wikimedia.org/mailman/listinfo/mobile-l >> >>

2 1

Re: [Design] [WikimediaMobile] Stop collapsing sections by default
by Brion Vibber 17 Sep '13

17 Sep '13

On Mon, Sep 16, 2013 at 10:51 AM, Arthur Richards <arichards(a)wikimedia.org>wrote: > If we still want to explore dynamically loading article sections (which we > all seemed to be in favor of when we did annual planning back in June), > it's hard for me to imagine how we could realistically pull that off if we > display sections uncollapsed as default. > We could rig up an "infinite scroll" type of situation, where we basically: * load section 0 and section 1 * leave placeholder <div>s for sections 2 and beyond * when the user scrolls down into section 1, start loading section 2 in the background ** prepare the same thing for the bottom of section 2 load section 3, etc... Of course a problem with this setup is that if you go offline partway through reading the article, the later sections might be unavailable when you scroll down to them. -- brion

4 3

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

Design September 2013