As I said. I can see both sides of the argument.
I'll say it again:
___Data.___
I can imagine some useful metrics might be as follows:
For a given page that we decide to run an A/B test on...
* Given a page has all sections expanded by default how many sections are closed
* Given a page has all sections collapsed by default how many sections
are opened
* Given a page has all sections expanded when the reader leaves the
page what is the furthest open section they view in the visible
viewport area of the screen - calculate average
* Given a page has all sections collapsed when the reader leaves the
page what is the furthest open section that they reach - calculate
average
I would say we should be optimising for:
* the lower amount of clicks (better experience for the user all round)
* for the furthest down the page (measures engagement of article)
In terms of results if the results highly favour one situation we
should use that situation
If the results show a 50/50 split / are inconclusive this suggests a
preference/button would be the way to go.
We may also want to record referrer as certain behaviours might be
favoured when coming from a google search result over coming from a
wikipedia mobile link/search result.
If this sounds like a good starting point we can start developing a
schema on the wiki?
On Tue, Sep 17, 2013 at 12:49 PM, James Alexander
<jalexander(a)wikimedia.org> wrote:
> [that said a 'collapse all' certainly helps my concerns, since I can just
> click that]
>
> James Alexander
> Legal and Community Advocacy
> Wikimedia Foundation
> (415) 839-6885 x6716 @jamesofur
>
>
> On Tue, Sep 17, 2013 at 12:48 PM, James Alexander <jalexander(a)wikimedia.org>
> wrote:
>>
>> On Tue, Sep 17, 2013 at 12:38 PM, Steven Walling <swalling(a)wikimedia.org>
>> wrote:
>>>
>>>
>>>> I'm not sure I agree with Steven's assessment that this will make
>>>> navigating between sections difficult - behaviour gets reverted - you close
>>>> the section to see the next section. This is akin to flicking through a book
>>>> and flicking to the next page (closing the section) if the heading at the
>>>> top of the page doesn't interest you. It just means you don't see all the
>>>> headings in one go which could be a good or bad thing.
>>
>>
>>
>> Right... but if you don't actually see the other sections you have to
>> start closing them all to find out what is actually available. I know, at
>> least in my case, that will likely mean I just navigate away (or switch to
>> desktop view). In general I've found that what you 'see' at the start is
>> very important. Honestly I'm surprised it's even a question.. I can see
>> arguments for it being uncollapsed by default (find on page etc, even if I
>> don't agree with them) but there is little doubt in my mind that it hurts
>> the easy navigation. This is especially true without a table of contents
>> (which the compressed sections basically acted as), in a book you don't just
>> flick to the next page, you look at the TOC and know where to go.
>>
>
>
> _______________________________________________
> Mobile-l mailing list
> Mobile-l(a)lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/mobile-l
>
+ design-l
On Mon, Sep 16, 2013 at 10:34 AM, 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.
>
> Since we currently load all the HTML for the content of a page it
> seems silly to hide it (although we should certainly rethink this if
> we ever begin to lazy load sections)
>
> We ran event logging on toggling a while back [1] and the data showed
> as you got down the page, it was less likely a section would be
> toggled opened and read.
>
> I would propose we keep toggling enabled but change the default of all
> sections to be open rather than closed.
>
> This also removes the existing risk of a flash of unstyled content and
> enables the ability for users to do find on this page.
>
> We should at least run some kind of A/B test that rethinks this.
>
> Thoughts?
>
> [1] https://www.mediawiki.org/wiki/Event_logging/Mobile#Section_toggles
Hi,
I am going to start a project named ''Colours of Bangladesh''.[1] Here we
will entourage the existing photography community to contribute to the
Wikimedia Commons (first phase will target for the historical places) and
at the same time we will create and update the articles on Bengali and
English WIkipedia and we may go for the Wikivoyage too.
A big part of this project will be offline activities like workshop,
photowalk, photo donation and other photo related event. I have a plan to
give a badge (as a banstar on talk page, as a sticker and badge ) to all of
them who will join this project. They will show it to their friends and may
be it will encourage the others.
So could you please help me to get a design for this badge. The tagline
will be something 'I contribute photos to wikipedia', or ' I am a wiki
photographer' or something similar.
[1] - http://en.wikipedia.org/wiki/WP:WikiProject_Colours_of_Bangladesh
*--
**Nasir Khan Saikat* <http://profiles.google.com/nasir8891>
user:nasir8891
www.nasirkhn.com
https://www.wikidata.org/wiki/Wikidata:Paper_cuts includes some ideas
for small design improvements, in case anyone wants to try their hand at
implementing them or suggesting better ways to address the problems.
-Sumana
-------- Original Message --------
Subject: Re: [Wikitech-l] paper cuts
Date: Wed, 11 Sep 2013 15:15:57 +0200
From: Lydia Pintscher <lydia.pintscher(a)wikimedia.de>
Reply-To: Wikimedia developers <wikitech-l(a)lists.wikimedia.org>
To: wikitech-l <wikitech-l(a)lists.wikimedia.org>
On Wed, Aug 21, 2013 at 2:48 PM, Lydia Pintscher
<lydia.pintscher(a)wikimedia.de> wrote:
> Heya folks :)
>
> Quite a while ago Ubuntu did a paper cuts initiative
> (https://wiki.ubuntu.com/OneHundredPaperCuts). Basically it was about
> collecting and fixing small bugs/annoyances that were easy to fix but
> had a large impact on how pleasant it is to use the product. We're
> going to do something similar for Wikidata now.
>
> I'd like to get a bugzilla keyword for this so we can easily tag those
> bugs. For that I need at least one other team however who'd like to
> join such an initiative. Is there anyone who's interested in this?
Sumana asked me for an update about how this is going so here it is:
I think it is going very very well so far. We've had a lot of
high-quality, structured and useful input on
https://www.wikidata.org/wiki/Wikidata:Paper_cuts and people seem to
love the idea. Now it's up to the development team and the rest of the
community to start working on fixes for the issues we've collected.
IMHO definitely something to try for other new projects that could use
some polish.
Cheers
Lydia
--
Lydia Pintscher - http://about.me/lydia.pintscher
Community Communications for Technical Projects
Wikimedia Deutschland e.V.
Obentrautstr. 72
10963 Berlin
www.wikimedia.de
Wikimedia Deutschland - Gesellschaft zur Förderung Freien Wissens e. V.
Eingetragen im Vereinsregister des Amtsgerichts Berlin-Charlottenburg
unter der Nummer 23855 Nz. Als gemeinnützig anerkannt durch das
Finanzamt für Körperschaften I Berlin, Steuernummer 27/681/51985.
_______________________________________________
Wikitech-l mailing list
Wikitech-l(a)lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
As multilingual content grows, interlanguage links become longer on
Wikipedia articles. Articles such as "Barak Obama" or "Sun" have more than
200 links, and that becomes a problem for users that often switch among
several languages.
As part of the future plans for the Universal Language Selector, we were
considering to:
- Show only a short list of the relevant languages for the user based on
geo-IP, previous choices and browser settings of the current user. The
language the users are looking for will be there most of the times.
- Include a "more" option to access the rest of the languages for which
the content exists with an indicator of the number of languages.
- Provide a list of the rest of the languages that users can easily scan
(grouped by script and region ao that alphabetical ordering is possible),
and search (allowing users to search a language name in another language,
using ISO codes or even making typos).
I have created a prototype <http://pauginer.github.io/prototype-uls/#lisa> to
illustrate the idea. Since this is not connected to the MediaWiki backend,
it lacks the advanced capabilities commented above but you can get the idea.
If you are interested in the missing parts, you can check the flexible
search and the list of likely languages ("common languages" section) on the
language selector used at http://translatewiki.net/ which is connected to
MediaWiki backend.
As part of the testing process for the ULS language settings, I included a
task to test also the compact interlanguage designs. Users seem to
understand their use (view
recording<https://www.usertesting.com/highlight_reels/qPYxPW1aRi1UazTMFreR>),
but I wanted to get some feedback for changes affecting such an important
element.
Please let me know if you see any possible concern with this approach.
Thanks
--
Pau Giner
Interaction Designer
Wikimedia Foundation
Everyone,
It is my great pleasure to welcome Kaity Hammerstein to the User Experience
team. Kaity joins us as a recent graduate of the University of Cincinnati
School of Design, Architecture, Art and Planning with a degree in Graphic
Communication Design.
Kaity joins our Wikimedia Foundation as an Associate UX Designer, and will
be working with the team on everything from mobile, to content translation,
Flow, Wikipedia Zero, multimedia initiatives, and upcoming theme changes
and onboarding and learning. Kaity’s focus for her senior thesis was how
interaction design can improve the relationship of a user to journalistic
content and media. Her experience in both Interaction Design and Visual
Design will be a great addition to the group.
Kaity has worked with Cooper and Apple (twice) as an intern and has
experience working with a range of platforms. She enjoys working with
people from many different disciplines, such as engineers, artists and
writers. She is thrilled to be part of the Wikimedia Foundation’s mission
and looks forward to becoming more involved in volunteer opportunities. She
enjoys exploring the beautiful Bay Area and baking pastries.
Photo of Kaity — http://cl.ly/RAll
Kaity will be sitting with my team in our new space in the Northwest corner
of the 3rd floor, please come and introduce yourself.
*Jared Zimmerman * \\ Director of User Experience \\ Wikimedia
Foundation
M : +1 415 609 4043 | : @JaredZimmerman<https://twitter.com/JaredZimmerman>
