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
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
>>>
>>>
>>
Hi
This was a long standing feature request and not the easiest one to
implement, that's why the Kiwix development team is pretty proud to
announce the release of Kiwix for iOS v1.0.
With Kiwix for iOS you can easily download/read recent snapshots (with
or without pictures) of all Wikimedia projects with your iPhone/iPad.
This first version of the app provides basic functionalities like:
* ZIM reader
* Navigation through articles
* Search based on article title
* Content library/downloader
* Bookmarks
* Browse history
* iTunes sync (already in beta testing for v1.1)
The app has been developed for the last 18 months by Chris, a New-York
based developer. He was (a bit) mentored by an older member of the Kiwix
dev team and the project was supported by WikimediaCH for the
administrative work with Apple and the coverage of mandatory hardware costs.
With this last stone, Kiwix which is already available for Windows, OSX,
Linux and Android, has reached a milestone. 10 years after the project
creation, Kiwix is a a cutting-edge solution to access Wikipedia (and a
lot more) offline - with most of the computers - whatever the platform.
Download Kiwix for iOS on Itunes:
https://itunes.apple.com/us/app/kiwix/id997079563
Have a look to the source code:
https://github.com/kiwix/iOS
Regards
Emmanuel
--
Kiwix - Wikipedia Offline & more
* Web: http://www.kiwix.org
* Twitter: https://twitter.com/KiwixOffline
* more: http://www.kiwix.org/wiki/Communication
The WMF Android App team will be ceasing active support for older
devices soon, namely devices that run Android 4.0 (Ice Cream Sandwich)
or older. Our final legacy device release is expected in mid to late
September[0]. This release will remain available on the Google Play
Store for devices running Android 2.3 (Gingerbread) through 4.0 (Ice
Cream Sandwich). However, future releases will only target devices
running Android 4.0.3 (Ice Cream Sandwich MR1) and higher. [1]
* Why this is happening
Devices running Android versions older than 4.0.3 make up less than
8%[2] of the Wikipedia for Android install base, and supporting older
devices requires disproportionate developer time and effort. Focusing
our efforts on the most recent and widely used versions will allow us
to provide a faster, more stable, and more delightful Wikipedia
experience.
* What this means for older devices
Enjoy a stable and beautiful legacy release for as long as you wish.
When you're ready for a new device, a sleek and modern app awaits you.
* What this means for all other devices
Reap the benefits of a Wikipedia for Android experience built to take
advantage of the latest and greatest Android technology available.
-The Wikimedia Android team
[0] This will be the final planned legacy device release. Allowances
will be made to enable back support patches of critical issues.
[1] https://source.android.com/source/build-numbers.html
[2] Google Play Developer Console, Current Installs by Device on August
20, 2015.
.. well, that would be a bit too simplified, but there's food for
thought in these two reports:
http://qz.com/466089/the-fastest-growing-mobile-phone-markets-barely-use-ap…
("In Asia and Africa, websites made up 90% and 96% of mobile
impressions, respectively, in the second quarter.
Their habits are a sharp contrast to the US, where apps accounted for
91% of impressions. Globally, there’s a more even distribution, with
apps making up 56% of mobile impressions and websites comprising the
remainder.")
http://thenextweb.com/insider/2015/08/26/how-we-use-our-phones-is-changing-…
("According to Yahoo’s data, the use of the browser on smartphones is
quickly declining [in the US]. From 2013 to 2015, the company saw the
usage time of the mobile browser drop by over 50 percent as they moved
to native apps instead.")
--
Tilman Bayer
Senior Analyst
Wikimedia Foundation
IRC (Freenode): HaeB
Hello Folks,
Many apologies for cross-posting. We have got a page with reading team
updates for August [0]. The brief for those is:
[1]. The team is doing more efforts in order better understand user
behaviors and patterns, and has a survey tool in place
[2] There are discussions around possible alternatives for article layout
on mobile
On a side note: If you are interested in helping the apps team understand
what users want, get in touch with me, please. We need more OTRS
volunteers to help with handling users and community questions
As usual, comments and questions feel more at home on the talk page of
their relevant topic than they are on this email thread. :)
Happy Weekend!
Moushira
[0] https://www.mediawiki.org/wiki/Reading/Reading_team_updates_August,_2015
[1]https://www.mediawiki.org/wiki/Extension:QuickSurveys/Documentation
[2] https://www.mediawiki.org/wiki/Talk:Reading/Features/Article_lead_image
Good news for F-Droid users. We're finally getting updates of our app on F-
Droid again. [1][2]
This apk is similar to the production apk on Google Play Store, and has the
same application ID. The flip side of that is that you can have only either
the F-Droid or the Google Play production apk installed at the same time.
The certificates used for building are different from ours, so to update
the apk you have to stick with the same line of apks, either from F-Droid or
from Google Play.
The only difference to the Google Play versions are channel name ("fdroid"),
version name (2.y.z-fdroid), and timing of releases. Other than that they
behave the same.
[1]
https://f-droid.org/repository/browse/?fdfilter=wikipedia&fdid=org.wikipedia
[2] https://phabricator.wikimedia.org/T67460
Cheers,
--Bernd
+ mobile-l
Here's a rough summary of the discussion based on my understanding:
*Problem and background:*
While most parameters we pass to the PHP API action=mobileview endpoint are
constant, there are a couple of parameters which depend either on device
dimensions or on user preferences.
The questions revolve around trading off caching of requests/trying to
avoid too much variance of requests vs. processing on clients when we move
to RESTBase services for page content. We want to be able to take advantage
of caching on both the edge cache side (Varnish) and also on the
server-side (RESTBase stores the results of each page revision) as well.
In the first phase of using RESTBase it won't pre-generate the results when
a new page revision gets created. Instead, it would generate and save the
results on-demand. In a later phase we aim to get pre-generation enabled.
*1) leadImageWidth*: The Android app provides the desired lead image width
and passes that to the mobileview action API as "thumbsize".[1] The Android
app provides only one of three possible values: 640, 800, 1024.[3]. It only
uses the the URL for the lead image, not the dimensions since it gets them
when the actual image finished downloading. The iOS app currently uses
"thumbwidth"
which is somewhat similar to "thumbsize" but has its own pros and cons.[4]
*2) noimages*: In the Android app settings, the user can chose to not show
any images. (The iOS app doesn't have this setting.) When this is the case
we add a noimages=true query parameter to the PHP mobileview request.[1]
Then the payload replaces the <img> tags with <span> tags. BTW, if the
client specified noimages=true then the value of leadImageWidth does not
matter; in fact, then we could omit the whole lead image info from the
result as well.
It's unclear to me which percentage of users actually use this setting.
*Possible solution alternatives:*
*1) leadImageWidth: *
*1A)* If the clients uses a constant value, let's say 800px for thumbsize
action=mobileview parameter then the client could replace the /800px-
portion in the resulting URL with the desired width, as long as the URL
structure stays predictable[2]. If the string replacement fails we could
still use the 800px URL.
*1B)* The new RESTBase API could provide an array of leadImage URL values
to the client (instead of the thumb JSON object).
*2) noimages: *
*2A)* The clients could replace the <img> tags with <span> tags, to emulate
what the nomiages flag of mobileview does. This would help caching by
reducing variability. OTOH this puts more burden on clients since DOM
transformations is something clients want to avoid. In this case in
particular since this is usually set because there are bandwidth or CPU
issues on the client side.
*2B)* We could provide a noimages=true query parameter also with RESTBase. We
could keep this uncached or implement this as a transform on the cached
base version (ideally in the service).
Thoughts, comments?
Cheers,
Bernd
[1]
https://en.m.wikipedia.org/w/api.php?action=mobileview&format=json&page=CER…
[2] Example:
"//
upload.wikimedia.org/wikipedia/commons/thumb/6/6e/Cernfounders.png/800px-Ce…"
would become "//
upload.wikimedia.org/wikipedia/commons/thumb/6/6e/Cernfounders.png/1024px-C…
".
[3] We don't want to add arbitrary values and follow certain bucket sizes
to enhance chances of cache hits and reduce burden on servers.
Width buckets: *https://git.wikimedia.org/blob/mediawiki%2Fextensions%2FMultimediaViewer.git/f9e7bae91a8032fa13fc68114a0d57d190ea77f9/resources%2Fmmv%2Fmmv.ThumbnailWidthCalculator.js#L69
<https://git.wikimedia.org/blob/mediawiki%2Fextensions%2FMultimediaViewer.gi…>*
[4] The Android app wanted to move to thumbwidth as well but iOS
encountered issues with svg files: https://phabricator.wikimedia.org/T91144
+ https://phabricator.wikimedia.org/T98528
On Sun, Jul 26, 2015 at 11:01 PM, Bernd Sitzmann <bernd(a)wikimedia.org>
> wrote:
>
>>
>> Correct me if I'm wrong, but the actual JPEG / PNG of the (lead) image
>>> will not be sent together with the first response, right? If so, simply
>>> adding the JSON with the three sizes adds an overhead of 100 or so bytes,
>>> while allowing us to cache/store the response correctly.
>>
>>
>> Yes, you are correct. The actual image is downloaded in a separate
>> request. This is just to get the URL of the lead image. Earlier I thought
>> we would also use the dimensions provided in the JSON output, but looking
>> at the Android code I don't see this used.
>> I'm now thinking that we could just provide one standard value (e.g.
>> 800px) for the mobileview request, and then the client could just adjust
>> the lead image URL
>> Example:
>> "//upload.wikimedia.org/wikipedia/commons/thumb/6/6e/Cernfounders.png/
>> *800px*-Cernfounders.png" would become "//
>> upload.wikimedia.org/wikipedia/commons/thumb/6/6e/Cernfounders.png/
>> *1024px*-Cernfounders.png".
>> While this seems a bit hacky by not following hypermedia principles it
>> would also avoid the issue thumbwidth issues.[1][2]
>>
>> Bernd
>>
>> [1] https://phabricator.wikimedia.org/T91144
>> [2] https://phabricator.wikimedia.org/T98528
>>
>>
>> On Sat, Jul 25, 2015 at 4:37 PM, Gabriel Wicke <gwicke(a)wikimedia.org>
>> wrote:
>>
>>>
>>>
>>> On Sat, Jul 25, 2015 at 5:50 AM, Marko Obrovac <mobrovac(a)wikimedia.org>
>>> wrote:
>>>
>>>> Correct me if I'm wrong, but the actual JPEG / PNG of the (lead) image
>>>> will not be sent together with the first response, right? If so, simply
>>>> adding the JSON with the three sizes adds an overhead of 100 or so bytes,
>>>> while allowing us to cache/store the response correctly.
>>>>
>>>> As for the options, I'd go with (1) as well. Mostly because external
>>>> requests will not be POSTs, but GETs, so we would still need some magic
>>>> translation in RESTBase hashing the query parameters and deducing the exact
>>>> storage request. I might be wrong here as well, though.
>>>>
>>>> Perhaps we should consider option (1a): RESTBase sends the request
>>>> together with the HTML to mangle right away. Hm, that looks more closely to
>>>> option (2) though and still needs a specialised RESTBase module.
>>>>
>>>
>>> 2) should work without a special module once the post_request_storage
>>> stanza is implemented. We can point that to the main content storage
>>> bucket, and get the implicit data fetching that way.
>>>
>>>
>>>>
>>>> Cheers,
>>>> Marko
>>>>
>>>> On 24 July 2015 at 23:53, Gabriel Wicke <gwicke(a)wikimedia.org> wrote:
>>>>
>>>>>
>>>>>
>>>>> On Fri, Jul 24, 2015 at 2:39 PM, Bernd Sitzmann <bernd(a)wikimedia.org>
>>>>> wrote:
>>>>>
>>>>>> Option 1 sounds interesting to me.
>>>>>> Not sure I fully understand option 2. (Sounds like pre-generation to
>>>>>> me.)
>>>>>>
>>>>>
>>>>> Yes, it would normally use the pre-generated content, but generate &
>>>>> save it on demand if needed. That's the case in both variants, though. Only
>>>>> difference is recursive GET back to RESTBase vs. RB POSTing the needed
>>>>> content directly.
>>>>>
>>>>>
>>>>>>
>>>>>> Thanks,
>>>>>> Bernd
>>>>>>
>>>>>> On Fri, Jul 24, 2015 at 3:22 PM, Gabriel Wicke <gwicke(a)wikimedia.org>
>>>>>> wrote:
>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Fri, Jul 24, 2015 at 2:05 PM, Bernd Sitzmann <bernd(a)wikimedia.org
>>>>>>> > wrote:
>>>>>>>
>>>>>>>> Transforms on the cached base version sounds interesting for both
>>>>>>>> cases. How does that work?
>>>>>>>>
>>>>>>>
>>>>>>> I see three main options:
>>>>>>>
>>>>>>> 1) the app service provides a GET end point and, when called with
>>>>>>> the custom parameters, fetches the base version from RESTBase & returns a
>>>>>>> patched version corresponding to the custom settings. RESTBase just proxies
>>>>>>> the custom entry point.
>>>>>>>
>>>>>>> 2) is basically the same, except that RESTBase POSTs the base
>>>>>>> version to the service. We are just starting work on T105975 which might
>>>>>>> give us a way to do this without writing a custom module.
>>>>>>>
>>>>>>> 3) is to do the post-processing in a custom RESTBase module. I'm not
>>>>>>> in favor of this unless absolutely needed, which I don't think is the case
>>>>>>> here.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>
>>>>>>>> Bernd
>>>>>>>>
>>>>>>>> On Fri, Jul 24, 2015 at 2:48 PM, Gabriel Wicke <
>>>>>>>> gwicke(a)wikimedia.org> wrote:
>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Fri, Jul 24, 2015 at 1:28 PM, Bernd Sitzmann <
>>>>>>>>> bernd(a)wikimedia.org> wrote:
>>>>>>>>>
>>>>>>>>>> I tend to agree and I think we should try to take advantage of
>>>>>>>>>> the storage & caching capabilities as much as possible. Not just
>>>>>>>>>> on our servers but also on the edge-caches.
>>>>>>>>>>
>>>>>>>>>> I'd venture a guess that the *noimages* flag is rarely used
>>>>>>>>>> (<5%). Dmitry, do we have any data about the use of "Show images"
>>>>>>>>>> preference being turned off? If not then that would be another good one for
>>>>>>>>>> EL. I'm going out on a limb here saying that if my guess is correct then we
>>>>>>>>>> could potentially replace the <img> tags with the respective <span> tags to
>>>>>>>>>> emulate the noimages flag on the clients. It's not ideal since the <img>
>>>>>>>>>> tags have a bigger payload and post-processing the payload on the clients
>>>>>>>>>> is something we would like to avoid. It's really a tradeoff between caching
>>>>>>>>>> and pure payload size.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> We could keep this uncached or implement this as a transform on
>>>>>>>>> the cached base version (ideally in the service).
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> The *leadImageWidth* has currently three possible values:
>>>>>>>>>> * 640px for phones,
>>>>>>>>>> * 800px for 7" tablets/phablets,
>>>>>>>>>> * 1024px for 10" tablets.
>>>>>>>>>> So, it's not completely variable. We try to take the image size
>>>>>>>>>> buckets[1] into account to help the servers with caching. Here the
>>>>>>>>>> distribution is not so clear-cut. I'm not sure if there is a reasonable
>>>>>>>>>> default value. But the difference in the payload would be very minor. This
>>>>>>>>>> only affects the thumb JSON object at the top level of the JSON payload.
>>>>>>>>>>
>>>>>>>>>> Examples:
>>>>>>>>>> 640[2]:
>>>>>>>>>> "thumb": {
>>>>>>>>>> "url": "//
>>>>>>>>>> upload.wikimedia.org/wikipedia/commons/thumb/6/6e/Cernfounders.png/635px-Ce…
>>>>>>>>>> ","width": 635,"height": 640},
>>>>>>>>>> 800:
>>>>>>>>>> "thumb": {"url": "//
>>>>>>>>>> upload.wikimedia.org/wikipedia/commons/thumb/6/6e/Cernfounders.png/794px-Ce…
>>>>>>>>>> ","width": 794,"height": 800},
>>>>>>>>>> 1024:
>>>>>>>>>> "thumb": {"url": "//
>>>>>>>>>> upload.wikimedia.org/wikipedia/commons/thumb/6/6e/Cernfounders.png/1017px-C…
>>>>>>>>>> ","width": 1017,"height": 1024},
>>>>>>>>>>
>>>>>>>>>> So, I'm thinking before we enable to pre-generation we could drop
>>>>>>>>>> the parameters and do something else instead, like:
>>>>>>>>>> Make "thumb" an (associative?) array so we have all three values
>>>>>>>>>> always included. I'm not a big fan of it since this mean we need to deviate
>>>>>>>>>> the parsing code between action=mobileview and RESTBase further and we have
>>>>>>>>>> again more data in the payload than the client is actually using.
>>>>>>>>>>
>>>>>>>>>> To summarize, I think we have some alternatives we could consider
>>>>>>>>>> but they come with a price.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> You could also both the old & new dimensions in the PHP response
>>>>>>>>> for a transition period. That way you could eventually phase out the
>>>>>>>>> top-level width & height. Since the urls are all the same apart from the
>>>>>>>>> size, you could perhaps also use something more compact like
>>>>>>>>>
>>>>>>>>> thumb: {
>>>>>>>>> baseURL: "//
>>>>>>>>> upload.wikimedia.org/wikipedia/commons/thumb/6/6e/Cernfounders.png/
>>>>>>>>> <http://upload.wikimedia.org/wikipedia/commons/thumb/6/6e/Cernfounders.png/6…>
>>>>>>>>> ",
>>>>>>>>> 640: {
>>>>>>>>> w: 635,
>>>>>>>>> h: 640,
>>>>>>>>> url: "635px-Cernfounders.png
>>>>>>>>> <http://upload.wikimedia.org/wikipedia/commons/thumb/6/6e/Cernfounders.png/6…>
>>>>>>>>> "
>>>>>>>>> },
>>>>>>>>> 800: {
>>>>>>>>> w: 794,
>>>>>>>>> h: 800,
>>>>>>>>> url: "794px-Cernfounders.png
>>>>>>>>> <http://upload.wikimedia.org/wikipedia/commons/thumb/6/6e/Cernfounders.png/6…>
>>>>>>>>> "
>>>>>>>>> },
>>>>>>>>> 1024: {
>>>>>>>>> w: 1017,
>>>>>>>>> h: 1024,
>>>>>>>>> url: "1017px-Cernfounders.png
>>>>>>>>> <http://upload.wikimedia.org/wikipedia/commons/thumb/6/6e/Cernfounders.png/6…>
>>>>>>>>> "
>>>>>>>>> }
>>>>>>>>> }
>>>>>>>>>
>>>>>>>>> or, if you really wanted to go super compact at the cost of
>>>>>>>>> readability:
>>>>>>>>>
>>>>>>>>> ["//
>>>>>>>>> upload.wikimedia.org/wikipedia/commons/thumb/6/6e/Cernfounders.png/
>>>>>>>>> <http://upload.wikimedia.org/wikipedia/commons/thumb/6/6e/Cernfounders.png/6…>
>>>>>>>>> {size}px-Cernfounders.png
>>>>>>>>> <http://upload.wikimedia.org/wikipedia/commons/thumb/6/6e/Cernfounders.png/6…>
>>>>>>>>> ",
>>>>>>>>> [640,635,640,635],
>>>>>>>>> [800,794,800,794],
>>>>>>>>> [1024,1017,1024,1017]
>>>>>>>>> ]
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Thanks,
>>>>>>>>>> Bernd
>>>>>>>>>>
>>>>>>>>>> [1]
>>>>>>>>>> https://git.wikimedia.org/blob/mediawiki%2Fextensions%2FMultimediaViewer.gi…
>>>>>>>>>> [2]
>>>>>>>>>> https://en.m.wikipedia.org/w/api.php?action=mobileview&format=json&page=CER…
>>>>>>>>>> *size*=640
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On Fri, Jul 24, 2015 at 11:13 AM, Gabriel Wicke <
>>>>>>>>>> gwicke(a)wikimedia.org> wrote:
>>>>>>>>>>
>>>>>>>>>>> This does complicate the storage & caching story. We likely
>>>>>>>>>>> won't want to pre-generate all permutations for each revision, which means
>>>>>>>>>>> that request performance will be worse than stored content.
>>>>>>>>>>>
>>>>>>>>>>> In the short term we can deploy this without storage and
>>>>>>>>>>> caching, but for the longer term we should really figure out a way to make
>>>>>>>>>>> this efficient. Could some of this processing be done on the client,
>>>>>>>>>>> perhaps by running a string replacement on HTML?
>>>>>>>>>>>
>>>>>>>>>>> On Fri, Jul 24, 2015 at 7:27 AM, Marko Obrovac <
>>>>>>>>>>> mobrovac(a)wikimedia.org> wrote:
>>>>>>>>>>>
>>>>>>>>>>>> Hi Bernd,
>>>>>>>>>>>>
>>>>>>>>>>>> On 24 July 2015 at 08:07, Bernd Sitzmann <bernd(a)wikimedia.org>
>>>>>>>>>>>> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>> Hi Marko,
>>>>>>>>>>>>>
>>>>>>>>>>>>> There are a couple of parameters we pass to the mobileview
>>>>>>>>>>>>> action which depend either on device dimensions or on user preferences.
>>>>>>>>>>>>> * leadImageWidth: We calculate the desired lead image width to
>>>>>>>>>>>>> download on the client and pass that to the mobileview action API as
>>>>>>>>>>>>> "thumbsize".[1]
>>>>>>>>>>>>> * noimages: The user can chose to not download any images.
>>>>>>>>>>>>> When this is the case we add a "noimages": true flag to the PHP.[1] Then
>>>>>>>>>>>>> the payload returns no <img> tags.
>>>>>>>>>>>>>
>>>>>>>>>>>>> In the future there might be a few more. I could also see
>>>>>>>>>>>>> something similar to leadImageWidth, where we calculate the best size of
>>>>>>>>>>>>> images or videos to display.
>>>>>>>>>>>>>
>>>>>>>>>>>>> What do you recommend to accomplish the equivalent for
>>>>>>>>>>>>> RESTBase endpoints?
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> What you are describing seems like complimentary information,
>>>>>>>>>>>> so I would recommend providing them as query parameters, with the
>>>>>>>>>>>> MobileApps service having some (sane) defaults in case these are missing.
>>>>>>>>>>>> The public API call would then be something like: https://
>>>>>>>>>>>> (en|m).
>>>>>>>>>>>> wikipedia.org/api/rest_v1/page/mobile-html-full/Foobar?thumbsize=200&noimag…
>>>>>>>>>>>> .
>>>>>>>>>>>>
>>>>>>>>>>>> Note that RESTBase needs the explicit list of query params and
>>>>>>>>>>>> headers that can be forwarded to back-end services, so if/when you do
>>>>>>>>>>>> implement this in the apps service, please notify us (phab, mail, irc, etc)
>>>>>>>>>>>> or try to include them in the RESTBase config concerning MobileApps~[1]
>>>>>>>>>>>> yourselves.
>>>>>>>>>>>>
>>>>>>>>>>>> Cheers,
>>>>>>>>>>>> Marko
>>>>>>>>>>>>
>>>>>>>>>>>> [1]
>>>>>>>>>>>> https://github.com/wikimedia/restbase/blob/master/specs/mediawiki/v1/mobile…
>>>>>>>>>>>>
>>>>>>>>>>>> P.S. We are making really good progress on the deployment! Hope
>>>>>>>>>>>> to see it live soon :)
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>> Bernd
>>>>>>>>>>>>>
>>>>>>>>>>>>> [1]
>>>>>>>>>>>>> https://en.m.wikipedia.org/w/api.php?action=mobileview&format=json&page=CER…
>>>>>>>>>>>>> *noimages=true&thumbsize=640*
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> --
>>>>>>>>>>>> Marko Obrovac, PhD
>>>>>>>>>>>> Senior Services Engineer
>>>>>>>>>>>> Wikimedia Foundation
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> --
>>>>>>>>>>> Gabriel Wicke
>>>>>>>>>>> Principal Engineer, Wikimedia Foundation
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> Gabriel Wicke
>>>>>>>>> Principal Engineer, Wikimedia Foundation
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> Gabriel Wicke
>>>>>>> Principal Engineer, Wikimedia Foundation
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Gabriel Wicke
>>>>> Principal Engineer, Wikimedia Foundation
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Marko Obrovac, PhD
>>>> Senior Services Engineer
>>>> Wikimedia Foundation
>>>>
>>>
>>>
>>>
>>> --
>>> Gabriel Wicke
>>> Principal Engineer, Wikimedia Foundation
>>>
>>
>>
>
+mobile-l
On Tue, Aug 25, 2015 at 11:02 AM, Jon Robson <jrobson(a)wikimedia.org> wrote:
> Note web has similar measurements and the findings here seem relatively
> consistent with apps.
>
> http://mobile-reportcard.wmflabs.org/
> On 25 Aug 2015 7:54 am, "Dmitry Brant" <dbrant(a)wikimedia.org> wrote:
>
>> Brian--
>> This data is just for the action of pulling out the nav menu and
>> selecting an item or canceling. We are indeed logging taps on the Search
>> button (in Android; not sure about iOS), but it's a separate action from
>> the nav menu, so I'm not sure how meaningful it would be to graph those
>> taps vs. the nav menu taps...
>>
>> Stephen--
>> Yes, good point; we had a rough idea that the usage of Random was quite
>> high, but this really proves it. In order for us to log when the user
>> *doesn't* tap on something, we would need a true "session" funnel where
>> we note these kinds of details. I think we have the beginnings of this in
>> Android, and I think we should flesh it out more and deploy it soon.
>>
>>
>>
>> On Tue, Aug 25, 2015 at 10:42 AM, Brian Gerstle <bgerstle(a)wikimedia.org>
>> wrote:
>>
>>> +1 great question stephen. seeing all of this correlated with user
>>> sessions would be great so we can start to hone in on specific scenarios or
>>> use cases.
>>>
>>> On Tue, Aug 25, 2015 at 10:28 AM, Stephen Niedzielski <
>>> sniedzielski(a)wikimedia.org> wrote:
>>>
>>>> Wow! I was most surprised by random! Surfacing interesting aggregated
>>>> content sounds better and better. Any idea on what proportion of users who
>>>> didn't engage the menu at all is?
>>>>
>>>> --stephen
>>>> On Aug 25, 2015 8:23 AM, "Dmitry Brant" <dbrant(a)wikimedia.org> wrote:
>>>>
>>>>> Ever wonder which Navigation menu items in our apps receive more taps
>>>>> than others? Well, wonder no more. Here's the breakdown, based on the
>>>>> numbers from the last ~3 weeks:
>>>>>
>>>>> For Android:
>>>>>
>>>>> [image: Inline image 1]
>>>>>
>>>>> And for iOS:
>>>>>
>>>>> [image: Inline image 2]
>>>>>
>>>>> Some takeaways from these data:
>>>>> - The rate of canceling the navigation menu is roughly the same on
>>>>> both platforms.
>>>>> - On iOS, the "Today" item is used nearly *three times* as much as it
>>>>> is on Android.
>>>>> - On Android, users care about Saved Pages twice as much as on iOS.
>>>>> - On both platforms, engagement with Nearby isn't nearly as high as I
>>>>> thought.
>>>>>
>>>>>
>>>>>
>>>>> https://docs.google.com/a/wikimedia.org/spreadsheets/d/1z0lzjAieNfx0OEHj-wT…
>>>>>
>>>>>
>>>>> --
>>>>> Dmitry Brant
>>>>> Mobile Apps Team (Android)
>>>>> Wikimedia Foundation
>>>>> https://www.mediawiki.org/wiki/Wikimedia_mobile_engineering
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> reading-wmf mailing list
>>>>> reading-wmf(a)lists.wikimedia.org
>>>>> https://lists.wikimedia.org/mailman/listinfo/reading-wmf
>>>>>
>>>>>
>>>> _______________________________________________
>>>> reading-wmf mailing list
>>>> reading-wmf(a)lists.wikimedia.org
>>>> https://lists.wikimedia.org/mailman/listinfo/reading-wmf
>>>>
>>>>
>>>
>>>
>>> --
>>> EN Wikipedia user page: https://en.wikipedia.org/wiki/User:Brian.gerstle
>>> IRC: bgerstle
>>>
>>> _______________________________________________
>>> reading-wmf mailing list
>>> reading-wmf(a)lists.wikimedia.org
>>> https://lists.wikimedia.org/mailman/listinfo/reading-wmf
>>>
>>>
>>
>>
>> --
>> Dmitry Brant
>> Mobile Apps Team (Android)
>> Wikimedia Foundation
>> https://www.mediawiki.org/wiki/Wikimedia_mobile_engineering
>>
>>
>> _______________________________________________
>> reading-wmf mailing list
>> reading-wmf(a)lists.wikimedia.org
>> https://lists.wikimedia.org/mailman/listinfo/reading-wmf
>>
>>
> _______________________________________________
> reading-wmf mailing list
> reading-wmf(a)lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/reading-wmf
>
>
--
Dmitry Brant
Mobile Apps Team (Android)
Wikimedia Foundation
https://www.mediawiki.org/wiki/Wikimedia_mobile_engineering
