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
Hi everyone,
We're thrilled to bring you our latest update to the Wikipedia Android
app[1][2], available now on the Google Play Store. Here are the highlights
from this release:
* Tabbed browsing! Pressing-and-holding a link now lets you open it in a
new tab, allowing you to keep reading the current article without losing
your place, and switch to the new tab when you're ready. This can also be
done directly from Search results, Nearby results, "Similar Pages" links,
and "Read More" links. To view and manage your current list of open tabs,
press the Tabs button near the top-right corner, which will allow you to
switch to any tab in the list, create a new tab, or close a tab.
* Language selection from the Search bar! When searching from within the
app, you can now select the language of Wikipedia to be searched. By
default, the Wiki language in the app is set to the system language of your
Android device. But now, for our multilingual friends, you can quickly
change your preferred language by pressing the button next to the Search
field while searching.
* A slightly redesigned table-of-contents button: the button now appears at
the bottom right of the screen, and disappears a short time after you
scroll away from the top of the article. The button reappears if you start
scrolling quickly, or if you reach the top of the article again. (The table
of contents is also still accessible by swiping from the right edge of the
screen)
Additional minor enhancements include:
* Added and updated some more Material Design components in the app.
* Improved error handling and presentation of error messages throughout the
app.
* Improved relevance of "read more" suggestions at the bottom of articles.
* Added option to view the current page in an external browser (at the
bottom of the article).
* Many more bug fixes and localization updates.[3]
Until next time, happy reading!
Best,
Dmitry Brant
Mobile Apps Team (Android)
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/T107344
Hi folks,
Back in January, the size of MobileWebClickTracking had gotten to be over
200 gb, making it so slow as to be unusable. As a result, we split up the
into 3 separate tables.
However, it seems that >90% of the clicks are coming from the article
table (or adding search created bloat) and
MobileWebUIClickTracking_10742159 is now approaching 300gb. Mostly this is
due to search. I would encourage further sampling, but that would mean that
beta data would be lost. Perhaps we can split it into separate beta/stable
tables and then sample stable? Any other ideas?
Phab ticket here:
https://phabricator.wikimedia.org/T108723
-J
I just want to say thank you to all you who help to develop the mobile apps. I really admire your dedication. I just help test because I don't know code, but thank you to those who do.
Best
Philip
Hey Mobile Apps crew,
there are 58 open tasks in archived Wikipedia-App-* Phabricator
projects which do not have any active projects associated either:
https://phabricator.wikimedia.org/maniphest/query/s4y9prrcTSnQ/#R
What should happen to these tasks and what feedback should be given to
the folks who spent time to report those issues?
We can mass-{add comments, change statuses, change priorities} but I
don't know which message you'd like to send out here.
Thanks in advance!,
andre
--
Andre Klapper | Wikimedia Bugwrangler
http://blogs.gnome.org/aklapper/
Hi,
Did anybody try to count how long are mobile edits?
How many characters do people actually type when they edit wiki pages
through mobile web and mobile apps?
Or, more precisely, how many meaningful keystrokes?
A simplistic way would be to measure the number of added characters, but
that's not quite correct, because deleting a wrong letter and typing a
correct one looks like zero added characters, but actually it's at least
two meaningful keystrokes.
Is there any measurement like that?
--
Amir Elisha Aharoni · אָמִיר אֱלִישָׁע אַהֲרוֹנִי
http://aharoni.wordpress.com
“We're living in pieces,
I want to live in peace.” – T. Moore
