This article [1] is also very interesting.

I agree sticky menus are quicker to navigate but my worry about the research is how often do you need those functions? To run a similar test imagine us running the following experiment.

1) Go to the Washington Monument page 2) Find out how tall the washington monument is. 3) You discover there is an issue with the page contact Wikipedia to let them know. 4) Find out when the Washington Monument was erected 5) You are now at the White House, search for the Wikipedia article 6) Find out how many snipers are typically on the roof of the white house 7) Find other articles near your current location

In this sort of workflow the user needs to access the menu throughout the article, so is going to be biased towards an interface that makes this workflow quicker however my question is how often does this happen? We are telling the user how to behave but my question is does the user behave that way? For instance if the user uses their browser address bar to search for Wikipedia articles then do they need quick access to a sticky navigation bar? In such a test would they be more biased to using Wikipedia's search function as they feel like that is there expected behaviour? Also how commonly are they going to contact Wikipedia? How commonly will they use a nearby function?

To take Facebook mobile website as a concrete example (which has no fixed nav at least on my Android), when viewing my news feed I don't actually want the fixed navigation - consuming my friend's latest activity is the most important thing. In a Wikipedia article I think the same goes - but I could imagine that it might be useful to have quicker access to certain features - potentially search for example.

Can someone send me the research that says that users use Wikipedia's search tool? I really don't believe this to be the case for the average user and would be interested to know what percentage of our total audience does use it and whether we've done research to show they use it more if fixed.

I'd be keen at some point to do more goal driven experiments with fixed positioned navigation on a wider audience to see if this encourages more searching. For example we could imagine enabling a fixed navigation menu on all iPhone 5 users for a day and see if the search traffic goes up.

[1] http://www.alistapart.com/articles/organizing-mobile/

I tend to agree that reading articles in all their gory detail is a primary usage of Wikipedia.

Here are the links to two significant research reports about mobile conducted by the Foundation in the past two years:

http://meta.wikimedia.org/wiki/Research:Wikipedia_Mobile_User_Research http://meta.wikimedia.org/wiki/Research:Wikipedia_Mobile_Readers_Survey_2011

Note in the Mobile Readers Survey the following:

*Attitudes & Preference for Wikipedia User Experience*

1. Mobile readers want improvements to their navigation experience when reading Wikipedia on their mobile phones. In particular, they want to more easily find and review information on a desired topic. Forty-two percent (Top 2 box) wanted to have an easy-to-find search box on each page. Thirty-five percent wanted the ability to more easily expand or collapse sections, while 31% wanted a glossary/list of sections listed at the top of each article. 2. Expanding and collapsing information is not only one of the most desired improvements; it is also one of the most desired formats for reading the articles themselves (41%). 3. Scrolling up and down for additional information was also a preferred reading method, with 45% identifying it as their top choice.

*UI Improvements and New Features*

1. In terms of new features most likely to be used, the majority (51% Top 2 box) are looking forward to a feature that allows them to save articles to read or edit offline. Accordingly, the most likely to be used new mechanisms include the ability to download (44%), print (33%) and share (24%) articles. Moreover, 41% (Top 2 box) want to be able to rate articles. Referencing articles by the strength of their rating also works well to improve search functionality. 2. Mobile readers want to see a main page of the mobile Wikipedia website that highlights the search bar (62%), as well as news of the day (48%) and featured articles (37%). Improving search via a clear search bar solution will both improve navigation and curb discouraging attitudes about search.

There are also some findings about search accuracy but I believe the underlying issues have been addressed since this survey was done.

Finally, we have had some bugs with search in the apps recently and the fact that people complain about that is some indication of how commonly people use our search.

I have captured some of the prior discussion around search on this page:

https://www.mediawiki.org/wiki/Mobile_design/Wikipedia_navigation/Search

Phil

On Tue, Sep 18, 2012 at 12:45 PM, Platonides platonides@gmail.com wrote:

On 18/09/12 03:55, Brandon Harris wrote:

...

No surprises here, but nice research.

http://uxdesign.smashingmagazine.com/2012/09/11/sticky-menus-are-quicker-to-...

I kind of agree with that, but I don't like the idea of a navigation bar sticky at the top if you can't hide it. Sure, it makes navigation easier, but if what you're caring about is the page content, it gets annoying by taking up useful content space.

See for instance the given example of http://www.rodolphecelestin.com/ There we have a long page with a ribbon at the top. It'd be ok if it could "hide" at the right. But that way it looks "intruding". If I'm reading the page, I want to have as much content as possible in one screen. Currently two designs could fit per screen if the ribbon wasn't there (I see how it ends behind the bar), or if I manually do a fine tuning with the scroll bar to only miss a little bit, but that's annoying to the users. Of course better.png and skills.png do not fit together, probably not even without the navbar without manual tuning, but seeing that the developer added me an unneeded piece of duct tape gives me bad feelings.

OTOH I find that the sticky bar of http://ryanscherf.net/ is lovely (the only flaw is that not all of those icons are descriptive enough).

Jon Robson wrote:

...

Can someone send me the research that says that users use Wikipedia's search tool? (...)

Note that the research was done on navigation alone, without including text reading [1]. I usually build the urls in the address bar by hand, by the way. :)

[1]

http://uxdesign.smashingmagazine.com/2012/09/11/sticky-menus-are-quicker-to-...

---

Mobile-l mailing list Mobile-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mobile-l