Hi everyone,
*tl;dr: We'll be stripping all content contained inside brackets from the
first sentence of articles in the Wikipedia app.*
The Mobile Apps Team is focussed on making the app a beautiful and engaging
reader experience, and trying to support use cases like wanting to look
something up quickly to find what it is. Unfortunately, there are several
aspects of Wikipedia at present that are actively detrimental to that goal.
One example of this are the lead sentences.
As mentioned in the other thread on this matter
<https://lists.wikimedia.org/pipermail/mobile-l/2015-March/008715.html>,
lead sentences are poorly formatted and contain information that is
detrimental to quickly looking up a topic. The team did a quick audit
<https://docs.google.com/a/wikimedia.org/spreadsheets/d/1BJ7uDgzO8IJT0M3UM2q…>
of
the information available inside brackets in the first sentences, and
typically it is pronunciation information which is probably better placed
in the infobox rather than breaking up the first sentence. The other
problem is that this information was typically inserted and previewed on a
platform where space is not at a premium, and that calculation is different
on mobile devices.
In order to better serve the quick lookup use case, the team has reached
the decision to strip anything inside brackets in the first sentence of
articles in the Wikipedia app.
Stripping content is not a decision to be made lightly. People took the
time to write it, and that should be respected. We realise this is
controversial. That said, it's the opinion of the team that the problem is
pretty clear: this content is not optimised for users quickly looking
things up on mobile devices at all, and will take a long time to solve
through alternative means. A quicker solution is required.
The screenshots below are mockups of the before and after of the change.
These are not final, I just put them together quickly to illustrate what
I'm talking about.
- Before: http://i.imgur.com/VwKerbv.jpg
- After: http://i.imgur.com/2A5PLmy.jpg
If you have any questions, let me know.
Thanks,
Dan
--
Dan Garry
Associate Product Manager, Mobile Apps
Wikimedia Foundation
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…
There are currently plans on deploying skin Blueprint on mediawiki.org
<https://phabricator.wikimedia.org/T93613>. Besides my work on UI
Standardization I'll also continue to work on the skin. I think Blueprint
should be on that list.
Best,
Volker
On Thu, Jul 23, 2015 at 6:25 PM, Adam Baso <abaso(a)wikimedia.org> wrote:
> Would you please share this on the list?
>
> On Thursday, July 23, 2015, Volker Eckl <veckl(a)wikimedia.org> wrote:
>
>> Hi Adam,
>> there are currently plans on deploying skin Blueprint on mediawiki.org
>> <https://phabricator.wikimedia.org/T93613>. Besides my work on UI
>> Standardization I'll also continue to work on Blueprint. Although UI
>> Standardization is a "special case", formally we belong to Reading and
>> therefore I think Blueprint should be on that list.
>>
>>
>> Best,
>> Volker
>>
>> On Mon, Jul 20, 2015 at 10:58 PM, Adam Baso <abaso(a)wikimedia.org> wrote:
>>
>>> Hi all -
>>>
>>> I've been reviewing a list of extensions with Reading Engineering and
>>> Reading Infrastructure leads - props to James Forrester for promoting this
>>> discussion. Here's a list of extensions we believe currently falls under
>>> Reading for triage (n.b., not all extensions will get active development
>>> support).
>>>
>>> https://www.mediawiki.org/wiki/User:ABaso_(WMF)/Extension_Responsibility
>>>
>>> Presuming no major issues with this, I think we should move the page to
>>> mw:Reading/Extension_Responsibility.
>>>
>>> One important outstanding question:
>>>
>>> Is MultimediaViewer appropriate for Reading given its
>>> consumption-oriented nature? Or is this actually better suited to Editing
>>> (where there exists a team named Multimedia)?
>>>
>>> Some other notes:
>>>
>>> * For skins with low utilization, we in time probably should coordinate
>>> handover to interested community members (or discuss with community members
>>> practical approaches for EOL).
>>>
>>> * Regarding the Nostalgia skin, we believe it's only used on
>>> https://nostalgia.wikipedia.org/wiki/HomePage, so maintenance would be
>>> updating for breaking skin changes or security issues only.
>>>
>>> * JsonConfig, ZeroBanner, ZeroPortal - we'll need to examine this more
>>> closely. Yuri (who has deepest PHP knowledge on extensions) is now over in
>>> Discovery, Jeff (JS & Lua) is in Reading, and now I'm managing instead of
>>> writing lots of code.
>>>
>>> * Collection probably belongs in Services
>>>
>>>
>>>
>>> _______________________________________________
>>> Mobile-l mailing list
>>> Mobile-l(a)lists.wikimedia.org
>>> https://lists.wikimedia.org/mailman/listinfo/mobile-l
>>>
>>>
>>
Forward to mobile-l (I answered Andre, only :/)
-----Original-Nachricht-----
Betreff: AW: [WikimediaMobile] Password alternative for mobile
Datum: Thu, 29 Oct 2015 13:48:55 +0100
Von: "Florian Schmidt" <florian.schmidt.welzow(a)t-online.de>
An: "Andre Klapper" <aklapper(a)wikimedia.org>
As far as I understand you don't need to type in your password. So the login would have the following workflow:
Type in the username on the Yahoo login page and click "login" (without entering a password). You'll get a notification on your smartphone with details about the computer/device where the account access request was made from. If you accept this request, you'll get access to the account on the pc where you want to login.
No need to know a password or type in a one time code. Only a username and the (registered) smartphone is enough.
Sounds very interesting.
-----Original-Nachricht-----
Betreff: Re: [WikimediaMobile] Password alternative for mobile
Datum: Thu, 29 Oct 2015 12:33:50 +0100
Von: Andre Klapper <aklapper(a)wikimedia.org>
An: mobile-l(a)lists.wikimedia.org
On Thu, 2015-10-29 at 00:17 -0700, Pine W wrote:> Maybe worth considering as an option for mobile Web and mobile apps?> http://www.komonews.com/news/tech/Yahoos-updated-email-app-aims-to-ki> ll-the-password-333096981.html
What is the actual difference to Two-Factor Authentication?
andre
--
Andre Klapper | Wikimedia Bugwrangler
http://blogs.gnome.org/aklapper/
_______________________________________________
Mobile-l mailing list
Mobile-l(a)lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mobile-l
Hi all,
here is the weekly look at our most important readership metrics. As laid
out earlier, the main purpose is to raise awareness about how these are
developing, call out the impact of any unusual events in the preceding
week, and facilitate thinking about core metrics in general. We are still
iterating on the presentation and eventually want to create dashboards for
those which are not already available in that form already. Feedback on the
format has continued to come in and remains welcome.
Besides going over the usual metrics, I’d like to highlight another piece
of data this time: The app session metrics which we started to record in
May and report in our quarterly review
<https://commons.wikimedia.org/w/index.php?title=File:WMF_Reading_Quarterly_…>,
but haven’t yet tracked systematically. (A session is defined as a sequence
of pageviews by the same app user that are no longer than 30 minutes
apart.)
The median number of sessions per user has remained constant during this
time, between 3 and 4 sessions in a 30-day period, as has the median number
of pageviews per session (between 2 and 3). However, the median duration of
a session has risen considerably:
Anyone have thoughts about possible reasons? Also, I think this is a good
opportunity to ponder what we would be maximizing if we were to maximize
session length/time spent.
(The data is for both Android and iOS, but - cf. the DAU numbers below -
can be assumed to be dominated by Android. We’re going to see if we can
obtain it separately by platform as well.)
Now to the usual data. (All numbers below are averages for October 19-25,
2015 unless otherwise noted.)
Pageviews
Total: 533 million/day (+1.0% from the previous week)
Context (April 2015-October 2015):
(see also the Vital Signs dashboard
<https://vital-signs.wmflabs.org/#projects=all/metrics=Pageviews>)
Obviously this month is quieter than September (where we had a peak
followed by drop).
Desktop: 57.7%
Mobile web: 41.1%
Apps: 1.2%
Global North ratio: 76.9% of total pageviews (previous week: 77.0%)
Context (April 2015-October 2015):
Out of curiosity whether there are more relevant small-scale changes
happening beneath the surface of this tranquil weekly ebb and flow, I ran
queries for the countries with the largest changes from the previous week
(restricted to those with more than 1 million views per day).
Largest increases from the previous week:
-
Romania +60.5%
-
Denmark +16.3%
-
Israel +13.4%
-
Brazil +12.2%
-
Vietnam +11.5%
Largest decreases from the previous week:
-
Philippines -12.4%
-
unknown country (code “--”) -4.9%
-
Italy -4.9%
-
South Africa -4.9%
-
Austra -4.0%
Something must have happened in Romania, which increased from 1.8 to 2.9
million pageviews per day last week.
Unique app users
Android: 1.161 million /day (+0.1% from the previous week)
Context (July-October 2015):
iOS: 280k / day (-0.2% from the previous week)
Context (July-October 2015):
New app installations
Android: 37.6k/day (-0.8% from the previous week)
(Daily installs per device, from Google Play)
Context (July-October 2015):
A small bump in the last few days.
iOS: 6.09k/day (-9.0% from the previous week)
(download numbers from App Annie)
Context (July-October 2015):
The app stopped being featured in the “Learn Your Fact” section of the App
store as of last Thursday.
----
For reference, the queries and source links used are listed below (access
is needed for each). Most of the above charts are available on Commons, too
<https://commons.wikimedia.org/w/index.php?title=Special:ListFiles&offset=20…>
.
hive (wmf)> SELECT SUM(view_count)/7000000 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-10-19"
AND "2015-10-25";
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)/7 FROM
wmf.projectview_hourly WHERE agent_type = 'user' AND
CONCAT(year,"-",LPAD(month,2,"0"),"-",LPAD(day,2,"0")) BETWEEN "2015-10-19"
AND "2015-10-25" 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-10-19"
AND "2015-10-25";
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, increaseratio, viewsthisweek FROM
(SELECT country_code, ROUND(SUM(IF(day>18 AND day<26, view_count,
null))/SUM(IF(day>11 AND day<19, view_count, null))-1,3) AS increaseratio,
SUM(IF(day>18 AND day<26, view_count, null)) AS viewsthisweek
FROM wmf.projectview_hourly
WHERE
year = 2015
AND month = 10
AND agent_type = "user"
GROUP BY country_code)
AS countrylist
WHERE viewsthisweek > 7*1000000 GROUP BY country_code, increaseratio,
viewsthisweek ORDER BY increaseratio DESC LIMIT 5;
(and analogously for decreases)
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 20151019 AND
20151025;
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';
https://play.google.com/apps/publish/?dev_acc=02812522755211381933#StatsPla…https://www.appannie.com/dashboard/252257/item/324715238/downloads/?breakdo…
(select “Total”)
--
Tilman Bayer
Senior Analyst
Wikimedia Foundation
IRC (Freenode): HaeB
Hi
The Kiwix dev team is happy to announce a new release of Kiwix (1.2) for
iOS:
* Faster search (especially when having a lot of large ZIM files)
* Better iPad multitasking experience
* Bug fixes and other improvements
If you have a device with iOS8+, give a try to Kiwix for iOS! It's free
and probably already one of the best Wikipedia offline apps on iTunes.
http://ios.kiwix.org/
Enjoy
Kelson
--
Kiwix - Wikipedia Offline & more
* Web: http://www.kiwix.org
* Twitter: https://twitter.com/KiwixOffline
* more: http://www.kiwix.org/wiki/Communication
Hi,
I'm building the ToC entries from Parsoid HTML content. Another part which
caused some struggle is building the correct anchors for the section
headings.
First I thought I could just use the id attributes in the heading tags
Parsoid provides[2].
Example from [1]:
<h2 id="mwCA">Template truncation</h2>
But then I thought about links to specific sections. Those would not use
the same ids Parsoid generates.[3] They would use the anchorencoded tocline
strings.[4]
Since I have not found an npm module which does anchorencoding in
JavaScript I wrote a small library function to do the same. It uses the
phpjs npm module to take into account the PHP specific way URLencoding is
done. Would you mind checking the anchorencode.js
file and the associate test file anchorencode-test.js in my patch[5]?
If there is a JS implementation of this I'd be happy to hear about that, of
course.
Thanks,
Bernd
[1] https://test.wikipedia.org/wiki/Section_edit_links_bug2
[2] view-source:
https://test.wikipedia.org/api/rest_v1/page/html/Section_edit_links_bug2
[3] https://test.wikipedia.org/api/rest_v1/page/html/Section_links
[4]
https://www.mediawiki.org/wiki/Manual:PAGENAMEE_encoding#Encodings_compared
[5] https://gerrit.wikimedia.org/r/#/c/246100/7
