Thanks. 7-9% of responses on Wikipedia Zero being WAP is pretty substantial.
On Tue, Sep 10, 2013 at 2:01 PM, Andrew Otto <otto(a)wikimedia.org> wrote:
> > These
> > zero.tsv.log*
> > files to which I refer seem to be, basically Varnish log lines that
> > correspond to Wikipedia Zero-targeted traffic.
> Yup! Correct. zero.tsv.log* files are captured unsampled and based on
> the presence of a "zero=" tag in the X-Analytics header:
>
>
> http://git.wikimedia.org/blob/operations%2Fpuppet.git/37ffb0ccc1cd7d3f5612d…
>
> > Do I understand correctly that field as Content-Type?
> Yup again! The varnishncsa format string that is currently being beamed
> at udp2log is here:
>
>
> http://git.wikimedia.org/blob/operations%2Fpuppet.git/37ffb0ccc1cd7d3f5612d…
>
>
>
>
>
> On Sep 10, 2013, at 4:25 PM, Adam Baso <abaso(a)wikimedia.org> wrote:
>
> > Somewhere in between, I think.
> >
> > Wikipedia Zero's main extension, ZeroRatedMobileAccess, relies upon the
> > mobile web's main extension, MobileFrontend. Wikipedia Zero access is
> > served across [lang.].zero.wikipedia.org and [lang.].m.wikipedia.org.
> >
> > As I understand, the general Varnish logs capture both the Wikipedia
> > Zero-based and the non-Wikipedia Zero-based mobile web access. These
> > zero.tsv.log*
> > files to which I refer seem to be, basically Varnish log lines that
> > correspond to Wikipedia Zero-targeted traffic.
> >
> > Wikipedia Zero for the mobile web will in all likelihood have a higher
> rate
> > of WAP device usage and WAP content served when compared to the general
> > Wikipedia for the mobile web stats. It's likely that, to at least some
> > extent, that higher WAP usage in participating Wikipedia Zero markets,
> > would be washed out by the relatively higher adoption of smartphones in
> > wealthier markets.
> >
> > Please do let me know in case of a need for further clarification!
> >
> > -Adam
> >
> >
> > On Tue, Sep 10, 2013 at 4:04 AM, Gerard Meijssen
> > <gerard.meijssen(a)gmail.com>wrote:
> >
> >> Hoi,
> >> Is the Wikipedia-Zero traffic information part of the mobile statistics
> or
> >> is it something completely separate thing?
> >> Thanks,
> >> GerardM
> >>
> >>
> >> On 10 September 2013 03:26, Adam Baso <abaso(a)wikimedia.org> wrote:
> >>
> >>> Wikipedia Zero traffic (IP address and MCC/MNC matching as expected)
> >> shows
> >>> in one day of requests (zero.tsv.log-20130907) roughly 7-9% of page
> >>> responses having a Content-Type response of "text/vnd.wap.wml",
> presuming
> >>> field #11 (or index 10 if you're indexing from 0) in
> zero.tsv.log-<date>
> >> is
> >>> the Content-Type. Do I understand correctly that field as Content-Type?
> >>>
> >>> Thanks.
> >>> -Adam
> >>>
> >>>
> >>> On Thu, Sep 5, 2013 at 9:27 AM, Arthur Richards <
> arichards(a)wikimedia.org
> >>>> wrote:
> >>>
> >>>> Would adding the accept header to the x-analytics header be worthwhile
> >>> for
> >>>> this?
> >>>> On Sep 5, 2013 4:16 AM, "Erik Zachte" <ezachte(a)wikimedia.org> wrote:
> >>>>
> >>>>> For a breakdown per country, the higher the sampling rate the better,
> >> as
> >>>>> the data will become reliable even for smaller countries with a not
> so
> >>>>> great adoption rate of Wikipedia.
> >>>>>
> >>>>> -----Original Message-----
> >>>>> From: analytics-bounces(a)lists.wikimedia.org [mailto:
> >>>>> analytics-bounces(a)lists.wikimedia.org] On Behalf Of Max Semenik
> >>>>> Sent: Thursday, September 05, 2013 12:28 PM
> >>>>> To: Diederik van Liere
> >>>>> Cc: A mailing list for the Analytics Team at WMF and everybody who
> has
> >>> an
> >>>>> interest in Wikipedia and analytics.; mobile-l; Wikimedia developers
> >>>>> Subject: Re: [Analytics] [WikimediaMobile] Mobile stats
> >>>>>
> >>>>> On 05.09.2013, 4:04 Diederik wrote:
> >>>>>
> >>>>>> Heya,
> >>>>>> I would suggest to at least run it for a 7 day period so you capture
> >>>>>> at least the weekly time-trends, increasing the sample size should
> >>>>>> also be recommendable. We can help setup a udp-filter for this
> >> purpose
> >>>>>> as long as the data can be extracted from the user-agent string.
> >>>>>
> >>>>> Unfortunately, accept is no less important here.
> >>>>> So, to enumerate our requirements as a result of this thread:
> >>>>> * Sampling rate the same as wikistats (1/1000).
> >>>>> * No less than a week worth of data.
> >>>>> * User-agent:
> >>>>> * Accept:
> >>>>> * Country from GeoIP to determine the share of developing countries.
> >>>>> * Wiki to determine if some wikis are more dependant on WAP than
> other
> >>>>> ones.
> >>>>>
> >>>>> Anything else?
> >>>>>
> >>>>> --
> >>>>> Best regards,
> >>>>> Max Semenik ([[User:MaxSem]])
> >>>>>
> >>>>>
> >>>>> _______________________________________________
> >>>>> Analytics mailing list
> >>>>> Analytics(a)lists.wikimedia.org
> >>>>> https://lists.wikimedia.org/mailman/listinfo/analytics
> >>>>>
> >>>>>
> >>>>> _______________________________________________
> >>>>> Mobile-l mailing list
> >>>>> Mobile-l(a)lists.wikimedia.org
> >>>>> https://lists.wikimedia.org/mailman/listinfo/mobile-l
> >>>>>
> >>>>
> >>>> _______________________________________________
> >>>> Mobile-l mailing list
> >>>> Mobile-l(a)lists.wikimedia.org
> >>>> https://lists.wikimedia.org/mailman/listinfo/mobile-l
> >>>>
> >>>>
> >>> _______________________________________________
> >>> Wikitech-l mailing list
> >>> Wikitech-l(a)lists.wikimedia.org
> >>> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
> >>>
> >> _______________________________________________
> >> Wikitech-l mailing list
> >> Wikitech-l(a)lists.wikimedia.org
> >> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
> >>
> > _______________________________________________
> > Wikitech-l mailing list
> > Wikitech-l(a)lists.wikimedia.org
> > https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>
>
> _______________________________________________
> Wikitech-l mailing list
> Wikitech-l(a)lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>
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
>
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 have a few questions regarding mobile stats.
I need to determine a real percentage of WAP browsers. At first glance,
[1] looks interesting: ratio of text/html to text/vnd.wap.wml
is 92M / 3987M = 2.3% on m.wikipedia.org. However, this contradicts
the stats at [2] which have different numbers and a different ratio.
I did my own research: because during browser detection in Varnish
WAPness is detected mostly by looking at accept header and because our
current analytics infrastructure doesn't log it, I quickly whipped up
a code that recorded user-agent and accept of every 10,000th request
for mobile page views hitting apaches.
According to several days worth of data, out of 14917 logged requests
1445 contained vnd.wap.wml in Accept: headers in any form. That's more
than what is logged for frontend responses, however it is expected as
WAP should have worse cache hit rate and thus should hit apaches more
often.
Next, our WAP detection code is very simple: user-agent is
checked against a few major browser IDs (all of them are HTML-capable
and this check is not actually needed anymore and will go away soon)
and if still not known, we consider every device that sends Accept:
header "vnd.wap.wml" (but not "application/vnd.wap.xhtml+xml"), to be
WAP-only. If we apply these rules, we get only 68 entries that qualify
as WAP which is 0.05% of all mobile requests.
The question is, what's wrong: my research or stats.wikimedia.org?
And if it's indeed just 0.05%, we should probably^W definitely kill
WAP support on our mobile site as it's virtually unmaintained.
-----
[1] http://stats.wikimedia.org/wikimedia/squids/SquidReportRequests.htm
[2] http://stats.wikimedia.org/wikimedia/squids/SquidReportClients.htm
--
Best regards,
Max Semenik ([[User:MaxSem]])
