Hi Folks,
TLDR: want to introduce the idea of surfacing simple english version of
wikipedia in a more prominent way to test if this appeals to our readers.
no timeline, no action items, just an intro to the concept and a request
for feedback/suggestions.
*Bakground:*
As a refresher/summary, as part of the reading team's strategic process
<https://www.mediawiki.org/wiki/Reading/Strategy>, we identified 4 reading
strategies that we are exploring and want to test hypothesis that will help
us determine which strategies are more impactful.
I am reviewing our strategy tests (i.e. tests that can help us determine if
a particular strategy is one we should focus on) and came across some notes
I made with Abbey (copied) around the potential strategy "Guided
Educational Experiences" that I wanted to surface and run by you. This
potential strategy is one where the reading team focuses on enhancing
learning (comprehension and/or retention) of content. Ideas in this theme
include identifying prerequisite articles, a suggested order to reading
articles (curricula), simple or practical versions of articles, quizzes or
even games. To be clear, this is a potential strategy that we are
evaluating along with others, as described here
<https://www.mediawiki.org/wiki/Reading/Strategy/Strategy_Process/Testing#Ab…>.
I also want to acknowledge that there have likely been other experiments in
this area--if you have specific examples you would like to share, please do
so. The test proposed below came about from one such awareness.
*The test:*
One idea for this strategy was "simplified versions of articles"--versions
of articles for readers who were unfamiliar with the topic or lacked a
basic educational foundation. That wikipedia articles are sometimes to
advanced is not a novel observation, but it's a tough nut to crack.
We had originally framed the test as "will editors want to create
simplified versions of articles" and we planned on asking them. However
the work that James Helman is doing with editors translating medical
documents into more practical guides in Swahili [link?] seems to show there
is interest here. However, we felt that SimpleEnglish was, in itself, a
remarkable test of what is being proposed, even though its focus is on
simple wording rather than concept simplicity. The most often-cited problem
(anecdote) with SimpleEnglish is that very few readers can find it. This
makes sense: someone confused by sophisticated vocabulary or looking for a
summary of an article is not likely to check the language list to see if a
simple version of the article sits there.
So the proposed test would be to surface simple english in a more prominent
way and to test if this led to higher comprehension using either quick
surveys or a proxy, like pageviews. I added the broad outlines of the test
to our strategy test document, here
<https://www.mediawiki.org/wiki/Reading/Strategy/Strategy_Process/Testing#Cr…>
.
*The ask:*
This is not part of our proposed Q3 plans or even our Q4 plans, but I would
like to hear feedback and ideas around how we could effectively integrate
it into our plans. One idea would be to implement it on one of the apps,
first, since we can move things around there without disturbing as many
people. We are open to suggestions.
Best,
J
Hi all,
here is the usual look at our most important readership metrics. This time
examining, among other things, pageview changes in various countries, such
as the effect of a brief block in China and of the sudden popularity of a
Greek expression derived from Latin. The Android has been seeing a
prolonged decrease in downloads, which fortunately were offset recently by
a more positive development.
With this issue we are changing the scope of this report from a timespan of
one week to two weeks (a fortnight
<https://en.wikipedia.org/wiki/FFF_system>) or four weeks, see further
remarks below. Most of the metrics here are now being updated weekly on the new
Product page <https://www.mediawiki.org/wiki/Wikimedia_Product#Reading>.
Before we go to the usual data, a note (for those who haven’t seen it yet)
that Wikistats <https://stats.wikimedia.org/> has now been upgraded to the
new pageview definition, see the announcement
<http://infodisiac.com/blog/2015/12/wikistats-upgraded-to-new-page-view-defi…>
by Erik Zachte.
(All numbers below are averages for November 23-December 6, 2015 unless
otherwise noted.)
Pageviews
Total: 527 million/day (-2.4% from the previous fortnight)
Context (April 2015-December 2015):
(see also the Vital Signs dashboard
<https://vital-signs.wmflabs.org/#projects=all/metrics=Pageviews>)
A notable weekly drop of -2.2% in the week until November 29, followed by
another -0.2% in the week until December 6.
Desktop: 56.6% (week until Nov 22: 57.2%)
Mobile web: 42.2% (week until Nov 22: 41.6%)
Apps: 1.2% (week until Nov 22: 1.2%)
Context (April 2015-December 2015):
<https://commons.wikimedia.org/wiki/File:Wikimedia_daily_pageviews,_mobile_p…>
Global North ratio: 77.6% of total pageviews (week until Nov 22: 77.3%)
Context (April 2015-December 2015):
<https://commons.wikimedia.org/wiki/File:Percentage_of_Wikimedia_pageviews_f…>
Out of curiosity about the -2.2% drop, I ran a query for the week until
November 29 to find the countries with the largest changes from the
previous week (as in some
<https://lists.wikimedia.org/pipermail/mobile-l/2015-November/009919.html>
previous reports; restricted to those with >1 millions views/day in the
week until Nov 29):
Greece +21.6% 2.3 m/day
South Africa -21.6% 1.2 m/day
Ireland -20.6% 2.3 m/day
Colombia -15.7% 3.3 m/day
Venezuela -10.9% 2.3 m/day
Argentina -8.3% 4.9 m/day
Philippines -8.3% 3.5 m/day
New Zealand -7.3% 1.3 m/day
Vietnam -7.1% 2.1 m/day
Taiwan -6.9% 6.2 m/day
For the top three, I looked at how pageviews developed on a daily basis
during the last three month including the week after this large change
(until Dec 6):
In Greece, the +21.6% rise was the result of an isolated spike from
November 23-25. This can be traced to a single page on the Greek Wiktionary
which on most days before and after only saw a single-digit number of
pageviews, but on these three days received more than 2.8 million: τάλε
κουάλε
<https://el.wiktionary.org/wiki/%CF%84%CE%AC%CE%BB%CE%B5_%CE%BA%CE%BF%CF%85%…>.
It’s about an expression that apparently comes from Latin via Italian
(“tale quale”) <https://en.wiktionary.org/wiki/tale_e_quale> and means
something like “exactly the same” or “spitting image”. From the form of the
spike, it was likely not the result of actual human interest, rather an
undetected bot trying to learn exactly the same about exactly the same.
In Ireland, the -20.6% drop marked the end of a plateau whose start had
actually shown up in the report for the week until November 1
<https://lists.wikimedia.org/pipermail/mobile-l/2015-November/009919.html>
already, where the country was the top changer with a 40.2% rise.
For South Africa, the -20.6% drop does not form part of a clear pattern.
Turning to the week until December 6, there were user reports
<https://zh.wikipedia.org/wiki/Wikipedia:%E4%BA%92%E5%8A%A9%E5%AE%A2%E6%A0%8…>
starting around December 4 that Wikimedia projects were being blocked in
China on desktop more widely than before (the Chinese Wikipedia has been
blocked since May 2015). However, as can be seen in the chart below, the
block appears to have been short-lived. It has also been mentioned in
various media reports (English-language examples: China Digital Times
<http://chinadigitaltimes.net/2015/12/minitrue-weekend-block-of-wikipedia/>,
TIME
<http://time.com/4142305/xi-jinping-china-censorship-world-internet-conferen…>).
New app installations
Android: 30.6k/day (-28.9% from the previous fortnight)
Daily installs per device, from Google Play
Context (last two months):
Instead of recovering to the level from before the App Store feature from
Nov 5-12, installation numbers dropped further until early December. It now
appears that this is connected to a sharp decrease in Google search
referrals to the app’s store page. We’re looking further into it. The good
news though is that the app is currently featured among the Best Apps of
2015
<https://lists.wikimedia.org/pipermail/mobile-l/2015-December/009995.html>
in various countries, with a clear effect on download numbers from December
3 on. (We’ll do a full assessment of the impact of this promotion in early
January after it ends.)
iOS: 4.44k/day (-4.6% from the previous fortnight)
Download numbers from App Annie
Context (last three months):
[image:
Wikipedia_iOS_app_daily_downloads%2C_Sep_8%2C_2015_~_Dec_6%2C_2015_(App_Annie).png]
<https://commons.wikimedia.org/wiki/File:Day-7_retention_of_Wikipedia_iOS_ap…>
There was a 5.4% drop between the week until November 22 and the week until
November 29. But this is still higher than in the first week of November,
say.
App user retention
Android: 14.8% (previous fortnight: 15.0%)
(Ratio of app installs opened again 7 days after installation, average of
daily percentages for installs from the previous week. 1:100 sample)
Context (last three months):
(NB: In order to have the chart show any potential causal connections more
clearly, I’ve changed the x-axis to the installation date instead of the
date on which the survival is measured, and added annotations.)
iOS: N/A
(Ratio of app installs opened again 7 days after installation, average of
daily ratios for installs from the previous week. From iTunes Connect,
opt-in only = ca. 20-30% of all users)
Unfortunately I encountered data quality issues with this metric (again
<https://lists.wikimedia.org/pipermail/mobile-l/2015-November/009942.html>).
We are in contact with Apple about this. I will leave the metric out of
these reports until this is resolved or we have a suitable substitute (we
could conceivably track this ourselves via EventLogging, like on
Android).Unique
app users
Android: 1.158 million / day (-3.8% from the previous week)
Context (last two months):
By now it looks like the App Store feature from Nov 5-12 indeed raised
active users numbers a bit, although they have since been steadily
decreasing, possibly for other reasons (see above).
iOS: 284k / day (+1.0% from the previous fortnight)
Context (last two months):
The week until November 29 saw an increase of 3.5% compared to the previous
week. And in the chart, a little bump can be discerned from November 26 on,
which could be related to Thanksgiving in the US (as we know, mobile use
tends to be higher on weekends and presumably also holidays).
Schedule of this report
As mentioned last time
<https://lists.wikimedia.org/pipermail/mobile-l/2015-November/009942.html>,
we have been rethinking the schedule of this report. New issues will now
cover either two weeks or four weeks each (keeping it to a multiple of
seven days, considering that most of these metrics show a strong weekly
seasonality and comparisons are hence best taking that period into
account). The main purpose remains the same as laid out earlier
<https://lists.wikimedia.org/pipermail/mobile-l/2015-September/009773.html>:
to raise awareness about how these metrics are developing, call out the
impact of any unusual events in the preceding week, and facilitate thinking
about core metrics in general. Having iterated the selection and
presentation of these metrics on a weekly basis since launching this report
in September, they have now stabilized a bit. Also, it now appears that the
newsworthy items uncovered by examining the development of these metrics
can also be covered on a less frequent than weekly schedule. On the other
hand, most of these metrics are now also updated weekly as part of the
Reading team’s section on the new Wikimedia Product page on mediawiki.org
<https://www.mediawiki.org/wiki/Wikimedia_Product>. Feedback and discussion
continue to be welcome.
----
For reference, the queries and source links used are listed below (access
is needed for each). Unless otherwise noted, all content of this report is
authored on behalf of the Wikimedia Foundation and released under the CC
BY-SA 3.0 <https://creativecommons.org/licenses/by-sa/3.0/> license. Most
of the above charts are available on Commons
<https://commons.wikimedia.org/w/index.php?title=Special:ListFiles&offset=20…>,
where I’m also uploading PDF versions of previous issues of this report.
hive (wmf)> SELECT SUM(view_count)/14000000 AS avg_daily_views_millions
FROM wmf.projectview_hourly WHERE agent_type = 'user' AND
CONCAT(year,"-",LPAD(month,2,"0"),"-",LPAD(day,2,"0")) BETWEEN "2015-11-23"
AND "2015-12-06";
hive (wmf)> SELECT year, month, day,
CONCAT(year,"-",LPAD(month,2,"0"),"-",LPAD(day,2,"0")) as date,
sum(IF(access_method <> 'desktop', view_count, null)) AS mobileviews,
SUM(view_count) AS allviews FROM wmf.projectview_hourly WHERE year=2015 AND
agent_type = 'user' GROUP BY year, month, day ORDER BY year, month, day
LIMIT 1000;
hive (wmf)> SELECT access_method, SUM(view_count)/14 FROM
wmf.projectview_hourly WHERE agent_type = 'user' AND
CONCAT(year,"-",LPAD(month,2,"0"),"-",LPAD(day,2,"0")) BETWEEN "2015-11-23"
AND "2015-12-06" GROUP BY access_method;
hive (wmf)> SELECT SUM(IF (FIND_IN_SET(country_code,
'AD,AL,AT,AX,BA,BE,BG,CH,CY,CZ,DE,DK,EE,ES,FI,FO,FR,FX,GB,GG,GI,GL,GR,HR,HU,IE,IL,IM,IS,IT,JE,LI,LU,LV,MC,MD,ME,MK,MT,NL,NO,PL,PT,RO,RS,RU,SE,SI,SJ,SK,SM,TR,VA,AU,CA,HK,MO,NZ,JP,SG,KR,TW,US')
> 0, view_count, 0))/SUM(view_count) FROM wmf.projectview_hourly WHERE
agent_type = 'user' AND
CONCAT(year,"-",LPAD(month,2,"0"),"-",LPAD(day,2,"0")) BETWEEN "2015-11-23"
AND "2015-12-06";
hive (wmf)> SELECT year, month, day,
CONCAT(year,"-",LPAD(month,2,"0"),"-",LPAD(day,2,"0")), SUM(view_count) AS
all, SUM(IF (FIND_IN_SET(country_code,
'AD,AL,AT,AX,BA,BE,BG,CH,CY,CZ,DE,DK,EE,ES,FI,FO,FR,FX,GB,GG,GI,GL,GR,HR,HU,IE,IL,IM,IS,IT,JE,LI,LU,LV,MC,MD,ME,MK,MT,NL,NO,PL,PT,RO,RS,RU,SE,SI,SJ,SK,SM,TR,VA,AU,CA,HK,MO,NZ,JP,SG,KR,TW,US')
> 0, view_count, 0)) AS Global_North_views FROM wmf.projectview_hourly
WHERE year = 2015 AND agent_type='user' GROUP BY year, month, day ORDER BY
year, month, day LIMIT 1000;
SELECT country_code, changeratio, ROUND(milliondailyviewsthisweek,1) AS
milliondailyviewsthisweek FROM
(SELECT country_code, ROUND(100*SUM(IF(day>22 AND day<30, view_count,
null))/SUM(IF(day>15 AND day < 23, view_count, null))-100,1) AS
changeratio, SUM(IF(day>22 AND day<30, view_count, null))/7000000 AS
milliondailyviewsthisweek
FROM wmf.projectview_hourly
WHERE
year = 2015
AND month = 11
AND agent_type = "user"
GROUP BY country_code)
AS countrylist
WHERE milliondailyviewsthisweek > 1 GROUP BY country_code, changeratio,
milliondailyviewsthisweek ORDER BY ABS(changeratio) DESC LIMIT 10;
https://console.developers.google.com/storage/browser/pubsite_prod_rev_0281…
(“overview”)
https://www.appannie.com/dashboard/252257/item/324715238/downloads/?breakdo…
(select “Total”)
SELECT LEFT(timestamp, 8) AS date, SUM(IF(event_appInstallAgeDays = 0, 1,
0)) AS day0_active, SUM(IF(event_appInstallAgeDays = 7, 1, 0)) AS
day7_active FROM log.MobileWikiAppDailyStats_12637385 WHERE userAgent LIKE
'%-r-%' AND userAgent NOT LIKE '%Googlebot%' GROUP BY date ORDER BY DATE;
(with the retention rate calculated as day7_active seven days later divided
by day0_active from the install date)
https://analytics.itunes.apple.com/#/retention?app=324715238
hive (wmf)> SELECT SUM(IF(platform = 'Android',unique_count,0))/7 AS
avg_Android_DAU_last_week, SUM(IF(platform = 'iOS',unique_count,0))/7 AS
avg_iOS_DAU_last_week FROM wmf.mobile_apps_uniques_daily WHERE
CONCAT(year,LPAD(month,2,"0"),LPAD(day,2,"0")) BETWEEN 20151123 AND
20151206;
hive (wmf)> SELECT CONCAT(year,"-",LPAD(month,2,"0"),"-",LPAD(day,2,"0"))
as date, unique_count AS Android_DAU FROM wmf.mobile_apps_uniques_daily
WHERE platform = 'Android';
hive (wmf)> SELECT CONCAT(year,"-",LPAD(month,2,"0"),"-",LPAD(day,2,"0"))
as date, unique_count AS iOS_DAU FROM wmf.mobile_apps_uniques_daily WHERE
platform = 'iOS';
--
Tilman Bayer
Senior Analyst
Wikimedia Foundation
IRC (Freenode): HaeB
Hi all,
We're pleased to announce our latest update to the Wikipedia Android
app[1][2], rolling out as we speak to the Google Play store! Here are the
highlights from this update:
* Nearby with Maps! Tap the Nearby option in the navigation menu to see an
interactive map with Wikipedia articles about points of interest near you.
You can also pan/zoom/rotate the map and go to any other part of the world,
and see Wikipedia articles for those locations.
* In Android 6.0, highlighting a word in any other app gives the option to
search for it in Wikipedia.
* Deleting your browsing history will now also clear your open tabs.
* Updated link preview design.
* A metric ton of bug- and crash fixes.[3]
Thanks to the following brave volunteers for their excellent contributions:
* Ondřej Kroupa (Sealskej / @kroupao)
* Daniel Rey (@DanReyLop)
* Dan Garry (Deskana / @danjgarry)
* Katie Filbert (Aude / @filbertkm)
* You?[4]
Cheers,
--
Dmitry Brant
Product Owner (Android), Mobile Apps Team
Wikimedia Foundation
https://www.mediawiki.org/wiki/Wikimedia_mobile_engineering
[1] https://play.google.com/store/apps/details?id=org.wikipedia&hl=en
[2]
https://releases.wikimedia.org/mobile/android/wikipedia/stable/wikipedia-2.…
[3] https://phabricator.wikimedia.org/T121236
[4]
https://www.mediawiki.org/wiki/Wikimedia_Apps/Team/Wikipedia_Android_app_ha…
Hello Everyone,
Hope you are enjoying the approach of the end of the year. In the last 3
months the reading team has worked on a process for open strategy planning
[0], in order to define priorities, and align tests and products that the
team works on, with broader movement goals.
Given the strategy work, planning for Q3 (the next quarter: Jan - March) is
different; the team is sharing its roadmap for Q3 and Q4 [1], as well as
the actions planned for Q3 [2] early on. Despite of the strategy work and
planning, these documents are still work in progress; adaptations and
changes are likely to take place, given the time frame and tests included.
However, the team is sharing early in order to accommodate feedback. You
can also add suggestions for Q4 (Apr - Jun), as long as they align with the
roadmap.
This is the first team the team shares its plans early and openly, and
allows room for feedack and suggestions in future planning. We trust that
the open process will help with better engagement and more lessons to learn
on best practices.
Enjoy December!
All the best,
M
[0] https://www.mediawiki.org/wiki/Reading/Strategy/Strategy_Process/Testing
[1] https://www.mediawiki.org/wiki/Reading/Roadmap
[2] https://www.mediawiki.org/wiki/Reading/Quarterly_Planning/Q3
[3] https://www.mediawiki.org/wiki/Reading/Quarterly_planning/Q4
That would be interesting. I'm not sure who to ask about this. Oliver,
perhaps you know, is it possible for WMF to publicize article pageviews by
country on a weekly basis?
I believe that there's also work happening on getting an approximate number
of unique users per country. Will there be per-country stats on unique
visitors from mobile web, mobile app, Zero, and desktop? Approximate
numbers are fine so that we work around privacy concerns.
Thanks,
Pine
On Wed, Dec 9, 2015 at 5:09 AM, James Heilman <jmh649(a)gmail.com> wrote:
> Yes we at WPMED would be interested in developing more content for
> disasters. One useful bit of data is what sort of topics are people looking
> for? If we had country level data for readership of our articles that would
> be powerful.
>
> James
>
> On Wed, Dec 9, 2015 at 1:53 AM, Pine W <wiki.pine(a)gmail.com> wrote:
>
>> News article: http://www.bbc.com/news/business-34715962
>>
>> I hear about Humanitarian OSM with some frequency. And when the ebola
>> scare was in full swing, Wikipedians (including those in WikiProject
>> Medicine) were working to get accurate information published about the
>> disease in multiple languages. I wonder if the Wikipedia mobile web, mobile
>> apps, and/or Wikipedia Zero could be further leveraged in disaster response
>> scenarios, perhaps in partnership with OSM or agencies like Doctors Without
>> Borders and UNICEF. Any thoughts?
>>
>> Pine
>>
>
>
>
> --
> James Heilman
> MD, CCFP-EM, Wikipedian
>
> The Wikipedia Open Textbook of Medicine
> www.opentextbookofmedicine.com
>
> As of July 2015 I am a board member of the Wikimedia Foundation
> My emails; however, do not represent the official position of the WMF
>
Hi,
I'm currently developing, with some friends, an application called
WikiJourney to promote « free » (as in a speech) tourism. For now, it
can locate an android user on a map, display points of interests
extracted from wikidata and show the user the associated wikipedia
articles.
The application will shortly be able to create touristic « tours », but
currently, we need some feedback from people, and not just user-related
feedback...
We feel our code (https://github.com/WikiJourney/wikijourney_app/) is a
bit messy, but don't know if there's a precise « coding convention »
here at Wikimedia.
What do you think of it?
Thanks by advance for your feedback,
The WikiJourney Team
FYI. Google just announced an open source project to create a speedier
framework for mobile browsing. It might be worth looking at what they're
doing:
From:
http://tech.slashdot.org/story/15/10/08/035200/googles-effort-to-speed-up-t…
Google has officially taken the wraps off its AMP project — Accelerated
Mobile Pages <https://www.ampproject.org/> — which aims to speed up the
delivery of web content to mobile devices
<https://www.ampproject.org/how-it-works/>. They say, "We began to
experiment with an idea: could we develop a restricted subset of the things
we'd use from HTML, that's both fast and expressive, so that documents
would always load and render with reliable performance?" That subset is now
encapsulated in AMP, their proof-of-concept. They've posted the code to
GitHub <https://github.com/ampproject/amphtml> and they're asking for help
from the open source community to flesh it out. Their conclusions are
familiar to the Slashdot crowd: "One thing we realized early on is that
many performance issues are caused by the integration of multiple
JavaScript libraries, tools, embeds, etc. into a page. This isn't saying
that JavaScript immediately leads to bad performance, but once arbitrary
JavaScript is in play, most bets are off because anything could happen at
any time and it is hard to make any type of performance guarantee. With
this in mind we made the tough decision that AMP HTML documents would not
include any author-written JavaScript, nor any third-party scripts."
They're seeing speed boosts anywhere from 15-85%, but they're also looking
at pre-rendering options to make some content capable of loading
instantaneously. Their FAQ <https://www.ampproject.org/faq/> has a few more
details.
Google blog announcement:
https://googleblog.blogspot.com/2015/10/introducing-accelerated-mobile-page…
.png){kind=link}
.png){kind=link}
.png){kind=link}