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
Hi,
So today I worked with Kaldari (thanks for the help!!) and committed a very
simple module to enable webfonts support in MobileFrontend:
https://gerrit.wikimedia.org/r/#/c/86340/https://gerrit.wikimedia.org/r/#/c/86337/
Review and any comments are very welcome, of course.
The current implementation is very simple. It doesn't allow any
configuration or choice of fonts - if there is a default font for the
language, it is used wherever there's a lang attribute or a style or a
class the sets a font explicitly. (Some languages, like Tamil and Hebrew
have fonts, but they are not default, so none are used). It may be worth
optimizing it, for example:
* Only loading the font of the content language to save time and bandwidth.
(Loading additional fonts can be an option.)
* Only loading fonts on devices that are known to have bad font support. On
iPhone and it's pretty for many languages. On the latest Windows Mobile
version it's very good. On Android below 4.0, however, it's very bad: most
languages of India are completely unreadable, which is the main reason to
do this (the same goes for languages of Ethiopia, South-East Asia and some
others). Android 4 and above is not always perfect either.
I'd love to hear more considerations about bandwidth, performance, testing
etc.
Thanks!
--
Amir Elisha Aharoni · אָמִיר אֱלִישָׁע אַהֲרוֹנִי
http://aharoni.wordpress.com
“We're living in pieces,
I want to live in peace.” – T. Moore
Thanks Amir for kicking this off!
A general point I wanted to make off the back of this... when adding
things to the mobile site, no matter how minimal a module is we should
get in the discipline habit of thinking "Does everyone need this
module?" We should be extremely careful what JavaScript and CSS
modules we add to mobile users, especially when modules are not useful
to certain users.
In this case I would recommend checking if the language needs WebFonts
before adding the module to the page. Another key thing we are doing
on mobile now is making use of mw.loader.using to conditionally load
JavaScript - this is another useful trick :-).
On Fri, Sep 27, 2013 at 10:49 PM, Yuvi Panda <yuvipanda(a)gmail.com> wrote:
> Forwarded to wikitech-l
>
>
> ---------- Forwarded message ----------
> From: Amir E. Aharoni <amir.aharoni(a)mail.huji.ac.il>
> Date: Sat, Sep 28, 2013 at 10:38 AM
> Subject: [WikimediaMobile] webfonts in mobile frontend
> To: "mobile-l(a)lists.wikimedia.org" <mobile-l(a)lists.wikimedia.org>
>
>
> Hi,
>
> So today I worked with Kaldari (thanks for the help!!) and committed a
> very simple module to enable webfonts support in MobileFrontend:
> https://gerrit.wikimedia.org/r/#/c/86340/
> https://gerrit.wikimedia.org/r/#/c/86337/
>
> Review and any comments are very welcome, of course.
>
> The current implementation is very simple. It doesn't allow any
> configuration or choice of fonts - if there is a default font for the
> language, it is used wherever there's a lang attribute or a style or a
> class the sets a font explicitly. (Some languages, like Tamil and
> Hebrew have fonts, but they are not default, so none are used). It may
> be worth optimizing it, for example:
>
> * Only loading the font of the content language to save time and
> bandwidth. (Loading additional fonts can be an option.)
> * Only loading fonts on devices that are known to have bad font
> support. On iPhone and it's pretty for many languages. On the latest
> Windows Mobile version it's very good. On Android below 4.0, however,
> it's very bad: most languages of India are completely unreadable,
> which is the main reason to do this (the same goes for languages of
> Ethiopia, South-East Asia and some others). Android 4 and above is not
> always perfect either.
>
> I'd love to hear more considerations about bandwidth, performance, testing etc.
>
> Thanks!
>
> --
> Amir Elisha Aharoni · אָמִיר אֱלִישָׁע אַהֲרוֹנִי
> http://aharoni.wordpress.com
> “We're living in pieces,
> I want to live in peace.” – T. Moore
>
> _______________________________________________
> Mobile-l mailing list
> Mobile-l(a)lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/mobile-l
>
>
>
> --
> Yuvi Panda T
> http://yuvi.in/blog
>
> _______________________________________________
> Wikitech-l mailing list
> Wikitech-l(a)lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
--
Jon Robson
http://jonrobson.me.uk
@rakugojon
Is there a way to have the general mobile web automation tests run
continuously, alerting #wikimedia-mobile and select individuals in the case
there are failing tests?
Sorry if this has been asked and answered, or is already the case and I
missed it somehow.
A bug introduced to ZeroRatedMobileAccess interfered with MobileFrontend
yesterday. It was spotted manually. It would be cool to increase the odds
of automatically being notified of failing tests from the general mobile
web (the Wikipedia Zero automation tests do positive/negative tests for
in-scope Wikipedia Zero, and only a couple of negative tests for the
general mobile web). To be fair, tests won't always catch errant behavior,
but they improve the odds!
Props to Arthur, Jon, Juliusz, and Max spotting the issue last night and
Yuri and Yuvi (Yuri !== Yuvi) getting the fix in shortly thereafter (
https://bugzilla.wikimedia.org/show_bug.cgi?id=54209).
Thanks.
-Adam
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
Hi mobile developers. I am attaching a report that an Israeli bidi expert
wrote about RTL support in iOS 7. You may find this interesting.
I am not an iOS user or developer, but I understand what this document
says, and if anybody is curious, I'll be glad to explain more.
A one-line summary is that the text is presented mostly fine, which is the
most important thing, but the placement of the elements is not adjusted in
many apps, and this, though not critical, is somewhat ugly and confusing.