Hi all!
I've been writing the phabricator practices of the Reading Web team.
We're trying hard to use phab to the best of it's ability so we've moved to
having multiple backlogs and relying on priorities heavily.
I've written down our current processes, boards and dashboard we use for
triaging here:
https://www.mediawiki.org/wiki/Reading/Web/Phabricator
Would appreciate any feedback or questions, I may have forgotten something
or not clearly explained what we're doing.
We are also in the process of assigning priorities to a big backlog of
un-triaged tasks, so we'll slowly get there.
Cheers!
The Android team[0] is 100% delighted to announce a new Wikipedia Android
app
beta release, v2.0.109-beta-2015-08-21[1]. In 491 characters[2], this
revision
contains the following enhancements:
* New and redesigned Link Preview style: now includes image thumbnail
gallery! (Note: only half of Beta users will see previews, as an A/B
test)
* More great improvements to app visual design
* Reduced load times when changing screen orientation
* Simplify page link share option to share only the URL
* More options when pressing-and-holding links: Save, Share, and Copy
* Bug fixes for saved pages and history entries
* Improve reliability of saving tabs
* Better backgrounds in night mode
Make it better! Read our getting started guide[3]. We cannot wait for
your contributions!
-The Wikimedia Android team
[0] https://www.mediawiki.org/wiki/Wikimedia_Apps/Team#Android_App
[1] Rolling out at
https://play.google.com/store/apps/details?id=org.wikipedia.beta
[2] A complete list of changes is available at
http://git.wikimedia.org/commits/apps%2Fandroid%2Fwikipedia/beta%2F2.0.108-…
[3]
https://www.mediawiki.org/wiki/Wikimedia_Apps/Team/Wikipedia_Android_app_ha…
Very interesting and fun talk for those of you interested on progressive
enhancement on the web, fast web experiences, service worker, etc.
https://www.youtube.com/watch?v=RQQNNP8tFro
Good food for thought for the future of the experience, it features
Wikipedia and Jake's offline wikipedia around minute 22, but it is
recommended to watch the whole talk for context.
Cheers.
Forwarding to the public list too.
---------- Forwarded message ----------
From: Tilman Bayer <tbayer(a)wikimedia.org>
Date: Sun, Aug 16, 2015 at 9:40 PM
Subject: Interesting WSJ article: "The Rise of Phone Reading"
To: Internal communication for WMF Reading team
<reading-wmf(a)lists.wikimedia.org>
Some food for thought - it's probably not entirely surprising in 2015,
but this article collects a lot of information showing that the
assumption "few people want to read long texts on a phone" is too
simplistic: http://www.wsj.com/articles/the-rise-of-phone-reading-1439398395
TLDR from our perspective: Smartphones are becoming a major venue for
reading ebooks, ie. really long-form texts, more than was predicted a
few years ago. ("In a Nielsen survey of 2,000 people this past
December, about 54% of e-book buyers said they used smartphones to
read their books at least some of the time. That’s up from 24% in
2012.") One reason is convenience - “The best device to read on is the
one you have with you"/"Most people who read on their phones toggle
back and forth between devices, using whichever is closest at hand
when opportunity strikes". Another is that screen sizes are getting
bigger.
Also has some bits about how book publishers react to this, which may
of course be less applicable to us.
[...]
--
Tilman Bayer
Senior Analyst
Wikimedia Foundation
IRC (Freenode): HaeB
Hi,
Because of https://phabricator.wikimedia.org/T76732 if you try and find the
#reading-web project when doing a phabricator advanced search the project
won't show up.
https://i.imgur.com/RK64P8f.png
In order to have it show up there's a workaround right now which is
executing JX.TypeaheadSource.prototype.setMaximumResultCount(100) to make
phabricator show more results when autocompleting.
There's extensions for all browsers to run scripts per domain when a page
loads, for example Tampermonkey for Chrome.
Hope this helps if anybody else has the same problem.
Cheers.
Hi Folks,
TLDR:
Results from analysis of new beta header
- Mobile beta still does not have sufficient volume or stability for
meaningful time-comparison experiments.
- Rough numbers I was able to get (highly suspect), *suggest* that
- the new header did not have a meaningful impact on either search or
main menu clicks
- There was a rise in opt-outs, but it started almost a week before
the change (http://mobile-reportcard.wmflabs.org/, use table view)
- Data and tables used here
<https://docs.google.com/spreadsheets/d/1oyTdP04IoYztG7ZNsJQ_0R9wjG8NOGU8tcq…>
I ran the data from the new beta header, which was designed to promote main
menu discovery by showing the menu anytime someone clicked in the header.
We knew it was a confusing experience and made it harder to search, but
since it was almost built before I joined the team, I asked the team to
promote it to beta anyway so that we could see what, if any, the impact was.
Context:
Current:
[image: Inline image 2]
Behaviors:
- click search, begin typing immediately
- click hamburger menu, see main menu
Test. Clicking anywhere on the header, including search, will now surface
the main menu:
[image: Inline image 1]
Behaviors:
- click anywhere in the heading and see both search and main menu.
Click search again to begin typing
[image: Inline image 1]
Hypothesis:
- Main menu item clicks will increase
- Search clicks will decrease
I was personally curious to see how much we could drive main menu
clicks--would increased exposure improve visitation? How much would an
extra click hurt search? These answers would help us as we made decisions
for a new navigation. For all of the below, I looked at English Wikipedia
only.
Complications/caveats:
- beta traffic is low (~500 search clicks a day, ~80 settings clicks
before the change,) and fluctuates, so impacts measured should be taken
with a grain of salt
- pageview traffic is hard to derive, so I looked at an hour each day
and used that as the index against which to measure actions, for stable pvs
I also sampled 1/1000
- there is a period of missing main-menu click data whose impact is
fully over by 7/11, so I could only measure the 4 days before the change.
PV data seems limited to a 90 day window (at least the method I am using to
query)
- after the change, there was no measurement of overall 'header' clicks.
Results TLDR:
- when indexed against pageviews, search results did not decreaes!
- surprisingly, main menu clicks did not have consistent
improvements--largely
- Home: +12%
- Nearby: -6% (anomalous spike just before)
- Random: +101% (there is clearly 1 day here with a major spike--just
an outlier)
- Collections: - 20%
- Settings: + 27% (to change out of beta?)
- pageviews decreased significantly over this period, however (25% over
the two comparison windows). So overall actions did decrease. How to
interpret the results, one has to know why pageviews decreased--
- Certainly one component is looking at partial weeks and different
days of the week. Weekends see mobile spikes and the first portion is a
weekend and the second was not.
- Did they decrease because of a natural population decay from our
pushing more people into beta? Maybe.
- Did they decrease because people did not like the header.
Unlikely--we see an opt out of beta jump that starts a few days
before the
change was promoted.
[image: Inline image 13]
(the 3 digit numbers below are dates:
Here is an example of the total number of actions during this time--a
comparison to all traffic (which I dub 'stable') helps identify when a
spike is or is not a beta artifact, but ultimately I ended up using
pageviews as that is more relevant:
[image: Inline image 7]
[image: Inline image 10]
Here are clicks on "Home" in the main menu:
[image: Inline image 11]
Here is search:
[image: Inline image 12]
The jumps you see in early May are from a banner campaign we ran to
increase beta users so that we could run meaningful quantitative analysis.
Conclusion:
- We need to either increase beta users, a/b test, or test in stable
more (which would also mean a/b testing on a small % of the population)
- Increased exposure to the main menu in it's current state does not
appear to have a strong positive impact on engagement. One might argue
that this has a great deal to do with an awkward transition, but it is hard
to tell with the noise.
- Search was seemingly not impacted by a trivial extra step--people are
possibly more resilient than we think.
Hello Android Wikipedia alpha users!
We recently implemented a change in our signing process affecting alpha
builds. While a long term improvement, in the short term this will
require an uninstall and reinstall of the _alpha_ app. This can be done
at any time but app upgrades will fail in the interim.
Please note that this change has no effect on beta nor prod installs.
This change is only applicable to the app titled "Wikipedia Alpha" that
has an orange starburst icon[0].
If you don't have the alpha app installed, today is a good day to
download[1]!
-The Wikimedia Android team
[0]
https://git.wikimedia.org/blob/apps%2Fandroid%2Fwikipedia/7662379c6dce08827…
[1]https://android-builds.wmflabs.org/
For the apps folks, I just found this:
https://phabricator.wikimedia.org/T100262
Seems like it is possible to cache api requests by adding:
- maxage (tells client to cache for a period in seconds)
- smaxage (tells varnish to cache for a period in seconds)
I thought you may benefit from adding some of these on the apps api queries
if you are not already doing it.
Cheers
