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
Whilst in Indonesia I was subjected to some horrifically slow
connections. Although I was only ever on WiFi, connection speeds were
on par with 2G/Edge connection.
Whilst searching the web, I saw various results (including Tripadvisor
and Wikipedia) labelled as being slow to load. When clicked I was
redirected to a product called Google Web Light [1] that had a link to
the original site and used 80% less data.
As a consumer, taking off my Wikimedia hat, I actually appreciated
this experience for Wikipedia. When I clicked view original the
process was so painfully slow I eventually found myself just living
with it as it didn't devoid me of any activities as a reader (at the
time connection was so slow editing just wasn't on my mind). For sites
such as tripadvisor and hotels.com the experience was so bad, to look
things up I ended up always switching to the original. This was more
annoying as I was unable to find some global opt out for the entire
site.
To crudely describe what the weblight experience does:
1) It loads just lead content
2) It strips lots of styles and some JS but not all JavaScript (for
instance main menu works)
3) IT throws away features such as search, editing, talk pages, category
4) It bundles all links into the left menu accessible by the hamburger
I took some screenshots of the experience [2] - you can see the
content is available but not well styled - it's how I'd imagine an AMP
experience of Wikipedia to look like and you can play around with it
yourself [3].
To summarise what this means to us:
Google are making it possible for users with slow connections to get
to our content
... thus various traffic never hits our servers.
... those users cannot edit.
(although on plus side they do see our fundraising banners :-))
We can opt out of this experience via headers but right now I strongly
believe we have to improve the speed of our offering.
I think this is in reach and will be a subject at the dev summit in
various forms.
The reading team has been experimenting in ways to optimise our page
content by using Parsoid [3] specifically to explore how we can
optimise views to HTML heavy pages such as Barack Obama. I'm looking
forward to sharing results.
[1] https://googleweblight.com/?lite_url=https://en.m.wikipedia.org/wiki/Barack
Obama
[2] http://imgur.com/a/dO4wt
[3] https://www.mediawiki.org/w/index.php?title=Reading/Web/Projects/Barack_Oba…
Latest data show that growth in Internet use has slowed down, however,
posting 6.9% global growth in 2015, after 7.4% growth in 2014.
Nonetheless, the number of Internet users in developing countries has
almost doubled in the past five years (2010-2015), with two thirds of
all people online now living in the developing world.
Fastest growth continues to be seen in mobile broadband, with the number
of mobile-broadband subscriptions worldwide having grown more than
four-fold in five years, from 0.8 billion in 2010 to an estimated 3.5
billion in 2015. The number of fixed-broadband subscriptions has risen
much more slowly, to an estimated 0.8 billion today.
http://www.itu.int/net/pressoffice/press_releases/2015/57.aspx
Team:
This schema https://meta.wikimedia.org/wiki/Schema:MobileWebClickTracking has
a lot of data in eventlogging. Tables are getting huge.
Too huge to be queried.
I remember that we agreed to split this schema in several others, can we do
away with this schema now?
Thanks,
Thanks to Sumit's latest change you can now access focus area and
image directly from the API in pageprops [1].
The image comes from editor, if not present Wikidata and soon (if
someone merges it) from PageImages [2].
Currently this is only deployed on WIkivoyage but by deploying the
extension on Wikipedia and disabling article rendering you could use
the API for the app.
Currently updating the origin x and origin y values with the API is
not easy and as nice as it could be but it is potentially doable by
editing the entire page and using some clever regexps.
Something to think about!
[1] http://en.wikipedia.beta.wmflabs.org/wiki/Special:ApiSandbox#action=query&p…
[2] https://gerrit.wikimedia.org/r/#/c/239010/
Please see below if you want to follow test failure messages for some of
the key Reading Web (formerly Mobile web) technologies
-Adam
---------- Forwarded message ----------
From: Bahodir Mansurov <bmansurov(a)wikimedia.org>
Date: Wed, Nov 25, 2015 at 5:53 PM
Hello all,
As you may know, we used to get emails about browser test failures for the
MobileFrontend, Gather, and QuickSurveys to this mailing list (along with
to qa-alerts(a)lists.wikimedia.org). Some people seem to have muted those
(rightly so if they are not interested), other interested people may not
have been getting those emails because they are not subscribed to
reading-wmf. So, in order to reach a broader audience and stop bugging
folks who are not interested in these emails, we will no longer send those
automated emails to this list.
I encourage the reading web team, its product manager, editing team members
who contribute to MobileFrontend, and others who like reading emails that
start with the word "FAILURE:" in bold and red, please subscribe to
qa-alerts(a)lists.wikimedia.org.
I used the following filter to only get the emails I'm interested in:
to:(qa-alerts@lists.wikimedia.org) (MobileFrontend OR QuickSurveys OR
Gather)
Thank you,
Baha
Hey Folks (and Florian in particular),
We created an internal web list to discuss admin stuff, and I failed by
posting the email to the internal list. I wanted to catch you (and the
rest of the team up on the latest link preview data).
[image: Inline image 1]
*Link preview rationale: *
the hypothesis is that if blue-links are more effective overall for users
(benefit/cost is higher on average) with link preview, people will click
them more often.
phab ticket explains the reasoning more:
https://phabricator.wikimedia.org/T111329
*Android results:*
Link preview increased blue-link clicks/user by almost 30% in beta, but in
stable it looks flat to negative. We tried a new version and it was
slightly better, but still no improvement over 'no link-preview' condition.
*Web decision*
One of the reasons we have independent teams on each platform is to allow
us to not make the same mistake on more than one platform. Based on the
above Android results, we made a late-quarter decision not to push link
preview until more analysis could be done. This is what email below kicked
off.
*Update*
It occurred to us yesterday that our current metric is probably
incomplete. We were looking at clicks/user on Android, when we should have
been looking at clicks/pageview. We treated them as equivalent, but what
actually happens is that pageviews drop since not all users continue onto
the article. So clicks/user sees no improvement, but clicks/page looks to
have an increase of ~10%!![?] So this suggests that link preview is
arguably an improvement. I say arguable because, the drop in overall
clicks comes from the fact that before, a user would click on a link, go to
an article and then click on a link from that article (3 articles total).
Now, the user will sometimes decide they have enough information and not
visit the second article. We are giving more targeted information, but are
losing some 'serendipity'.
As Kaity put it, "
*The link preview UX is encouraging people to stay on one article and check
out lots of links but not click through to any of them.*
*Without link preview, a user is more likely to get completely off-topic,
and forget the original article. *
*Which of these behaviors do we want to encourage? We should balance a
focused reading experience with one that encourages the wiki rabbit hole. *
*If a user is encouraged to explore in other ways, like the feed and read
more, than a UX that encourages them to stay focused on 1 article is
justified. *
*Next steps:*
We made the call not to work on link preview on the mobile web (or
hovercards on desktop web [1]) in the remainder of Q2 based on our earlier
analysis. I am tempted to say that this secondary analysis justifies
implementing link preview on the web, but think it is at least worth a
discussion for mobile web, due to the potential trade-off. Do we try again
in Q3? I know Florian is already doing a great deal of the work.
-J
[?] Dmitry on the hook for further analysis
[1] The survey results for hovercards when rolled out as'on-by-default' to
specific wikis were astoundingly positive...I don't have them handy, but if
you're curious, please ping me.
---------- Forwarded message ----------
From: Jon Katz <jkatz(a)wikimedia.org>
Date: Fri, Nov 20, 2015 at 5:05 PM
Subject: Next sprint
To: Joaquin Oltra Hernandez <jhernandez(a)wikimedia.org>, Kristen Lans <
klans(a)wikimedia.org>, Jon Robson <jrobson(a)wikimedia.org>
Hi,
I want to give you a head's up on some recent developments that could
impact next sprint. All of this came in either last night or this
afternoon--we can discuss on Monday at kickoff, but asynch before then will
obviously save meeting time.
*Link Preview:*
Just under the wire, the first couple days of data are in for the new link
preview on Android and they do not show a significant marked increase in
links clicked per user. In other words, it looks like link preview is still
not generating any measurable improvement in user engagement on Android. I
am not a good judge of how much work it would take to push link preview to
mobile beta for further testing (an actual a/b test), but think that is
probably not a great use of your time (unless it is really small). On the
one hand, I believe in the feature and want to give it a chance on web, but
I also believe in staggering development by platform so that we don't make
the same mistakes twice. If anything, the bar is set higher on the mobile
web then on Android, since we are hijacking link clicks.
If we don't launch link preview we could (and should) continue to move
hovercards along as they do not hijack the link and have rave qualitative
reviews. This might still represent enough work to see us through the rest
of the quarter, but I am not sure if you have what you need lined up. How
do you folks feel about it?
*Added to sprint board since planning:*
1. This bug, if it is valid, will prevent us from gathering data from
our surveys until it is fixed: https://phabricator.wikimedia.org/T119152
2. Added another story to account for the 2 surveys that we hope to run
next week before the fundraiser block:
https://phabricator.wikimedia.org/T119267
3. Might not make it:
1. After Toby and I met with community members yesterday, he is
making the executive decision that we should get rid of the special user
profile to appease our contributors:
https://phabricator.wikimedia.org/T85929. I think we have stalled
long enough, but I think we should only remove it if a user
doesn't already
have a page. Otherwise a new user who clicks on their user name
gets taken
to a blank edit screen. If a user doesn't have a page, we should add a
message to specialuserprofile saying --click here to create your own user
profile. A CTA on the link click could also work. Nirzar can
you jump on
this?
-J
Hey Folks,
Based on the thread on this ticket, T119412
<https://phabricator.wikimedia.org/T119412>, it looks like we have
addressed all of the concerns raised and can move forward with scrapping
mobile's special:userprofile (T85929
<https://phabricator.wikimedia.org/T85929>) page in favor of:
- a header that includes a link to the users contributions, and
- if userpage exists: show userpage as is
- if user page doesn't exist: prompts user to create their own (if it is
them) or notifies them of the absence (if it is another user)
If we don't hear any concerns by Friday 6pm GMT, I will ask that the web
team scope the work to see if it can be included in our next sprint.
Best,
J
Forwarding for those who didn't yet see it on other lists. This (US only)
survey
<https://upload.wikimedia.org/wikipedia/commons/2/25/Wikimedia_Reader_Survey…>
contains some general results about readers that are of interest beyond the
fundraising aspects - for example:
- the look and feel of Wikipedia is rated quite favorably
- in the US, there are still more readers using Wikipedia on desktop (=
laptops and desktop PCs) than on mobile (smartphone/tablet) - although the
latter continues to be on the rise even compared to February of this year.
---------- Forwarded message ----------
From: Megan Hernandez <mhernandez(a)wikimedia.org>
Date: Fri, Nov 20, 2015 at 12:06 PM
Subject: [Wikimedia-l] Fundraising Update
To: Wikimedia Mailing List <wikimedia-l(a)lists.wikimedia.org>
Hi all,
We are just a few weeks away from the launch of the December English
fundraiser. The end of the year is the most critical time of the year for
Wikimedia’s fundraising: The goal this year is $25 million. The campaign
will launch in the US, UK, Canada, Australia, New Zealand and Ireland on
Giving
Tuesday <https://en.wikipedia.org/wiki/Giving_Tuesday>, December 1st.
In these past months of preparation, we have relied on feedback from the
volunteer community, readers, and staff through discussion pages, feedback
sessions, phone calls, interviews, user testing, surveys and A/B tests.
Thank you to everyone for participating! It has truly been a helpful
experience and wonderful to hear from so many voices from all different
parts of the movement.
In just the last two weeks, an independent research firm conducted a new
survey of Wikipedia readers. (You may remember that we did a similar survey
last February.) We heard from you last spring that there were some
additional concerns that you would like us to explore with readers. We
tried to look into those concerns in this survey. We have uploaded the
survey
report on Commons
<
https://upload.wikimedia.org/wikipedia/commons/2/25/Wikimedia_Reader_Survey…
>
for anyone who is interested in reading it. We have also setup a section on
the Fundraising Meta page
<
https://meta.wikimedia.org/wiki/Talk:Fundraising#Reader_Survey_November_2015
>
to discuss the survey.
The feedback from readers, the volunteer community and staff has been
critical to shape the campaign. Several improvements have been made so far
as a direct result of this input. We have changed a few specific sentences
of the message that were discussed heavily on meta pages and also tried a
variety of design ideas based on comments.
We also have some fresh banner ideas that came about through a recent
workshop with staff. We will be testing those new banner ideas in small
runs throughout the campaign as well. And we’re still gathering ideas! To
see the latest version of the message and submit your ideas, please visit
the fundraising ideas meta page
<https://meta.wikimedia.org/wiki/Fundraising/2015-16_Fundraising_ideas>.
Since last year, we have made improvements to our banner targeting and
analytics systems with the goal of raising the budget, while limiting the
number of banners and disruption for our readers. We aim to run the
campaign for roughly two weeks at a high traffic level and then at a much
reduced level for the rest of December.
The fundraising team faces a great challenge this year: the highest revenue
target in WMF history along with a decline in page views – particularly in
desktop pageviews where readers are more likely to donate. The team has and
will continue to work hard to make improvements needed to reach this goal.
We cannot do this alone. Thank you to everyone who has offered input,
expertise, time and energy into helping make this fundraiser a success.
We look forward to your ideas and questions. Since the team experiences an
incredibly high volume of seasonal work, we will not be able to respond
immediately to questions or feedback. We will review feedback and bug
reports regularly and we have dedicated time to post an update by
mid-December and again at the end of the campaign. Here’s how to get
involved:
-
To file a bug report or technical issue, please create a phabricator
ticket
<https://phabricator.wikimedia.org/maniphest/task/create/?template=118862
>
or email problemsdonating(a)wikimedia.org
-
To see the latest news from the team, see the fundraising meta page
<https://meta.wikimedia.org/wiki/Fundraising>
-
To suggest a banner idea, visit the test ideas meta page
<https://meta.wikimedia.org/wiki/Fundraising/2015-16_Fundraising_ideas>
-
To read the latest reader survey, see the
<
https://upload.wikimedia.org/wikipedia/commons/2/25/Wikimedia_Reader_Survey…
>full
report on commons
<
https://upload.wikimedia.org/wikipedia/commons/2/25/Wikimedia_Reader_Survey…
>
-
To learn more about the fundraising program and last year’s campaign,
see the 2014-15 fundraising report
<https://wikimediafoundation.org/wiki/2014-2015_Fundraising_Report>
Thank you to everyone who has contributed to the campaign preparations.
More importantly, thank you to the entire Wikimedia community for building
this incredible project that readers love and support with their
donations. None of this would be possible without you.
Megan
--
Megan Hernandez
Director of Online Fundraising
Wikimedia Foundation
_______________________________________________
Wikimedia-l mailing list, guidelines at:
https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
Wikimedia-l(a)lists.wikimedia.org
<https://meta.wikimedia.org/wiki/Mailing_lists/GuidelinesWikimedia-l@lists.w…>
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
<mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe>
--
Tilman Bayer
Senior Analyst
Wikimedia Foundation
IRC (Freenode): HaeB