We had an interesting discussion in #wikimedia-mobile today. A user
came into the channel and made some comment about "nothing loads on
mobile, afaik it doesnt even allow logging in"
At first I thought he/she was talking about the app but as we talked
some more it became clear he/she hadn't realised the hamburger icon
was clickable and had assumed it was part of the search feature.
May and I tried to probe a bit more to understand whether it's a
cultural thing (e.g. maybe the hamburger icon is only recognisable in
North America/Western Europe). Alas, he/she then got very defensive
and angry and for some reason didn't want to talk about it.
He did however mention she/he wanted a help page but when I asked
where that would be discovered he went into radio silence.
I know the design team have been looking to move away from the
hamburger icon and after talking with May we reckon it might be useful
to run a few A/B tests around it to see if it becomes 'more clickable'
if
* a divider is present
* if we try effects on the icon to make it look more tappable
* If it changes to an icon other than the hamburger
It also suggests we may want to think about how we surface a help
feature to these users... putting it in the hamburger menu itself
might not be a good idea..
Since our current Squid stats [1] don't look very accurate or precise, I
decided to generate something myself based on the logs we have. I
analyzed a week's worth of logs, from 2013-06-10 to 2013-06-16. I
generated three sets of data:
* minor: browsers grouped by their minor version, e.g. all Androids 4.2
go together, all Safaris 5.1, etc.
* major: browsers grouped by their major version, e.g. all Androids 4 go
together, all Safaris 5, etc.
* vendor: browsers grouped by their name only, e.g. all Androids go
together, all Safaris, etc.
Each group has also an additional file with all the unknown user agents
logged (they are logged as "Other" in the main files). Everything is
available here:
https://www.dropbox.com/s/840ftlrfygtou4m/browser-stats-mobile-20130610-201…
Most of it looks like I expected, the market is shared mostly among
mobile Safari and Android. What I hadn't expected is that Android 2.3 is
still the most popular Android at 9.79%. That's a lot. I started
thinking what we could do about this. After some googling I found lots
of Android 2.x users frustrated by the fact that Chrome is not available
for Android older than 4 and they're stuck with a crappy browser.
I tried looking for an alternative and I found it rather quickly:
Firefox. Mobile Firefox is a sad 0.26% of our users, even less than
desktop Firefox (0.29%)! I tried installing it on the first Google Nexus
and hey, maybe it's not superfast, but it's better than the stock
Android 2.3 browser and supports both photo uploading and our new editor
really well (stock Android 2.3 doesn't support uploads and the editor
is... quite wonky). So, my suggestion is: let's show a banner or a call
to action for Android 2.x users telling them about this and encouraging
them to try Firefox. It's free open software and I think it's better
than what stock Android 2.x browser is. What do you think? Wikimedia
Foundation <3 Mozilla Foundation? ;)
Unrecognized browsers are mostly bots with one notable exception,
NativeHost, which is probably the Windows Phone app (I'm guessing [2]).
[1] http://stats.wikimedia.org/wikimedia/squids/SquidReportClients.htm
[2]
http://stackoverflow.com/questions/13306090/how-do-i-change-the-nativehost-…
--
Juliusz
Hello!
Me and May have been experimenting with different ways of finding
articles related to the one the user is currently reading. This is a
feature we are considering for the mobile app - to make it simple to
keep going through to related articles after reading the current one.
Mediawiki doesn't offer any such functionality, so we've to 'cheat'.
I have written a quick userscript to test out the different methods of
finding 'related' articles. You can enable this on your logged in
desktop english wikipedia account by:
1. Going to this page: https://en.wikipedia.org/wiki/Special:MyPage/common.js
2. Add this line to it: importScript("User:Yuvipanda/lost.js");
3. Save the page!
Now, you can go to any wikipedia article and three buttons should show
up under the title. If they don't, do a hard refresh (cmd + shift + r
in OS X), and they then should. The first button does a category based
related/random article, the second one a link based, and a third one
(when it appears) a slightly more involved link based related/random
article one. We're doing this to iterate quickly (the current stuff
took me less than an hour to build) on the various ways to determine
which related article to show.
Do take a look, click around a little and get lost, and tell us which
method you prefer!
Thanks :)
--
Yuvi Panda T
http://yuvi.in/blog
Hey all,
Something you might have more instantaneous insight on than I.
I deployed a fix to CentralNotice today [1] that should have started
serving mobile URLs for CN to mobile clients. It does this by querying
MobileContext::singleton()->shouldDisplayMobileView() inside of the
ResourceLoaderGetConfigVars hook. However, it appears that either... that
function is returning false, or... getMobileUrl is not properly mangling
URLs.
I suspect it's that the function is returning false because:
* I deployed a 'fix' earlier that just used getMobileUrl() which redirected
everyone to the mobile URLs. And...
* There's a blob of code that I added in this patch that will always mangle
URLs and it seems like that's working just fine.
I've tested on my local machine with MF loaded first, and MF loaded last
and can not reproduce the cluster behaviour. So... thoughts?
[1] https://gerrit.wikimedia.org/r/#/c/92806/
~Matt Walker
Wikimedia Foundation
Fundraising Technology Team
Jenkins is now blowing up for reasons unknown to me.
Desktop QUnit tests are failing all the time due to timeout reasons (I
can sometimes replicate this locally - this might have been due to
some core change?)
Mobile tests are sometimes passing and sometimes throwing errors due
to no tests being run. See this commit for an example when the mobile
tests passed but core changes failed:
https://gerrit.wikimedia.org/r/#/c/92000/
and here where both sets of test failed:
https://gerrit.wikimedia.org/r/#/c/92994/
This all started since the seemingly harmless
https://gerrit.wikimedia.org/r/92804 got merged.
any ideas what is going on? This currently stops us merging any code
(since we disabled the verified override)