Re: [WikimediaMobile] [Apps] Scope of the apps content service

[Bernd Sitzmann]

Max,

For regular page views we split it into two requests: one for lead section
and another for the remaining sections.
As a general rule of thumb we want to put only the information that is
needed to display above the fold (section 0, lead image URL, Wikidata
description, ...), plus maybe some minor metadata fields that help us with
housekeeping.

The gallery data for should go into the second request.

As far as housekeeping goes, I think it would be great to have the revision
ID and some hash for the things outside the pure pagedata (gallery items,
...)
so we could determine after the first request if we could skip the second
request because we already have that as a saved page or in a cache.
Ideally, those would go into an ETag, and the client uses an If-None-Match
header the next time we request it, so that in the case we already have the
data there wouldn't be a payload in the response, just the header.

Bernd

On Thu, Feb 5, 2015 at 9:59 PM, Monte Hurd  wrote:

> Saving pages is not the primary use case for the image meta data portion -
> users tapping on an image and not having to wait for another server round
> trip to determine the high res url and meta data is the primary use case.
>
> Having all this data as part of one request means image taps can be much
> lower latency from the user's perspective. The panel can pop up immediately
> with meta data overlay over the already downloaded low res image and can
> immediately begin lazy loading the high res version. It will seem much more
> responsive, which is really important.
>
> As a side benefit, saving page data for offline access also becomes
> easier, but users tap on images (I think) more than they save pages.
>
>
>
> On Feb 5, 2015, at 1:40 PM, Max Semenik  wrote:
>
> Saving a page for offline is not that speed sensitive, however, serving
> this information as part of normal page views would definitely impact
> overall latency.
>
> On Thu, Feb 5, 2015 at 1:24 PM, Dan Garry  wrote:
>
>> On 5 February 2015 at 13:20, Max Semenik  wrote:
>>>
>>> Wouldn't that bloat the response size?
>>>
>>
>> The rationale for including this is because that way the image viewer
>> will work even if you've not tapped on any of the images. This is pretty
>> important functionality that doesn't work offline right now, even if you
>> save the page for offline reading.
>>
>> That said, we may want to punt this until after the MVP as being possibly
>> outside of scope.
>>
>> Dan
>>
>> --
>> Dan Garry
>> Associate Product Manager, Mobile Apps
>> Wikimedia Foundation
>>
>
>
>
> --
> Best regards,
> Max Semenik ([[User:MaxSem]])
>
> ___
> Mobile-l mailing list
> Mobile-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/mobile-l
>
>
> ___
> Mobile-l mailing list
> Mobile-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/mobile-l
>
>
___
Mobile-l mailing list
Mobile-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mobile-l

Re: [WikimediaMobile] [Apps] Scope of the apps content service

[Monte Hurd]

Saving pages is not the primary use case for the image meta data portion - 
users tapping on an image and not having to wait for another server round trip 
to determine the high res url and meta data is the primary use case. 

Having all this data as part of one request means image taps can be much lower 
latency from the user's perspective. The panel can pop up immediately with meta 
data overlay over the already downloaded low res image and can immediately 
begin lazy loading the high res version. It will seem much more responsive, 
which is really important. 

As a side benefit, saving page data for offline access also becomes easier, but 
users tap on images (I think) more than they save pages.



> On Feb 5, 2015, at 1:40 PM, Max Semenik  wrote:
> 
> Saving a page for offline is not that speed sensitive, however, serving this 
> information as part of normal page views would definitely impact overall 
> latency.
> 
>> On Thu, Feb 5, 2015 at 1:24 PM, Dan Garry  wrote:
>> On 5 February 2015 at 13:20, Max Semenik  wrote:
>>> 
>>> 
>>> Wouldn't that bloat the response size?
>> 
>> 
>> The rationale for including this is because that way the image viewer will 
>> work even if you've not tapped on any of the images. This is pretty 
>> important functionality that doesn't work offline right now, even if you 
>> save the page for offline reading.
>> 
>> That said, we may want to punt this until after the MVP as being possibly 
>> outside of scope.
>> 
>> Dan
>> 
>> -- 
>> Dan Garry
>> Associate Product Manager, Mobile Apps
>> Wikimedia Foundation
> 
> 
> 
> -- 
> Best regards,
> Max Semenik ([[User:MaxSem]])
> ___
> Mobile-l mailing list
> Mobile-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/mobile-l
___
Mobile-l mailing list
Mobile-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mobile-l

Re: [WikimediaMobile] [Apps] Scope of the apps content service

[Monte Hurd]

I think it will be more than offset by the reduction in response size gained by 
the "Exclude unused HTML" bullet point. Also, gzip encoding is pretty good at 
text compression. 


> On Feb 5, 2015, at 1:20 PM, Max Semenik  wrote:
> 
>> On Thu, Feb 5, 2015 at 12:00 PM, Dan Garry  wrote:
>> Image meta data for all images in the page
>> License
>> Description
>> Includes the URL for the high resolution version used for the lead image
> Wouldn't that bloat the response size?
> 
> -- 
> Best regards,
> Max Semenik ([[User:MaxSem]])
> ___
> Mobile-l mailing list
> Mobile-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/mobile-l
___
Mobile-l mailing list
Mobile-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mobile-l

Re: [WikimediaMobile] Site banners on Mobile

[Pine W]

Hi Dan,

OK. By the way, I have a couple of questions about the mobile apps team:

* What is the thinking behind having mobile apps instead of focusing
resources 100% on mobile web?
* I believe that Damon said something about needing more mobile devs
shortly after he was first hired. Is that still planned?

Thanks,

Pine

*This is an Encyclopedia* 






*One gateway to the wide garden of knowledge, where lies The deep rock of
our past, in which we must delve The well of our future,The clear water we
must leave untainted for those who come after us,The fertile earth, in
which truth may grow in bright places, tended by many hands,And the broad
fall of sunshine, warming our first steps toward knowing how much we do not
know.*

*—Catherine Munro*

On Thu, Feb 5, 2015 at 5:14 PM, Dan Garry  wrote:

> Hey Pine,
>
> The mobile apps do not display CentralNotice banners. The reason for this
> is because that the apps are not based on the MediaWiki technology stack at
> all so we don't get the integration for free, and there is no convenient
> API for CentralNotice which means it'd be a lot of work for us to integrate
> with it. And since we're still a very small team, building this API and
> hooking the apps into it isn't a priority right now.
>
> Thanks,
> Dan
>
> On 5 February 2015 at 13:48, Pine W  wrote:
>
>> Do site banners appear on mobile apps and mobile web? I can't recall
>> seeing one. With the growth in mobile, I hope that mobile apps and mobile
>> web will support site banners for important notifications such as Wiki
>> Loves Monuments.
>>
>> Thanks,
>>
>> Pine
>>
>> *This is an Encyclopedia* 
>>
>>
>>
>>
>>
>>
>> *One gateway to the wide garden of knowledge, where lies The deep rock of
>> our past, in which we must delve The well of our future,The clear water we
>> must leave untainted for those who come after us,The fertile earth, in
>> which truth may grow in bright places, tended by many hands,And the broad
>> fall of sunshine, warming our first steps toward knowing how much we do not
>> know.*
>>
>> *—Catherine Munro*
>>
>> ___
>> Mobile-l mailing list
>> Mobile-l@lists.wikimedia.org
>> https://lists.wikimedia.org/mailman/listinfo/mobile-l
>>
>>
>
>
> --
> Dan Garry
> Associate Product Manager, Mobile Apps
> Wikimedia Foundation
>
___
Mobile-l mailing list
Mobile-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mobile-l

Re: [WikimediaMobile] Site banners on Mobile

[Dan Garry]

Hey Pine,

The mobile apps do not display CentralNotice banners. The reason for this
is because that the apps are not based on the MediaWiki technology stack at
all so we don't get the integration for free, and there is no convenient
API for CentralNotice which means it'd be a lot of work for us to integrate
with it. And since we're still a very small team, building this API and
hooking the apps into it isn't a priority right now.

Thanks,
Dan

On 5 February 2015 at 13:48, Pine W  wrote:

> Do site banners appear on mobile apps and mobile web? I can't recall
> seeing one. With the growth in mobile, I hope that mobile apps and mobile
> web will support site banners for important notifications such as Wiki
> Loves Monuments.
>
> Thanks,
>
> Pine
>
> *This is an Encyclopedia* 
>
>
>
>
>
>
> *One gateway to the wide garden of knowledge, where lies The deep rock of
> our past, in which we must delve The well of our future,The clear water we
> must leave untainted for those who come after us,The fertile earth, in
> which truth may grow in bright places, tended by many hands,And the broad
> fall of sunshine, warming our first steps toward knowing how much we do not
> know.*
>
> *—Catherine Munro*
>
> ___
> Mobile-l mailing list
> Mobile-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/mobile-l
>
>


-- 
Dan Garry
Associate Product Manager, Mobile Apps
Wikimedia Foundation
___
Mobile-l mailing list
Mobile-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mobile-l

Re: [WikimediaMobile] Developer tools and workflows

[Tomasz Finc]

Let's make sure to announce these a week or so before as i'm sure
we'll have other teams who want to attend.

--tomasz

On Tue, Feb 3, 2015 at 1:34 PM, Jon Robson  wrote:
> In future it would be great to include other team members/volunteers
> outside the mobile web team in these discussions. It was really
> interesting seeing how different people work and I already feel more
> productive with some of my learnings.
>
> Please let us know if that interests you. We are planning to get
> together once a month.
>
> Thanks Joaquin for getting this documented!
> Jon
>
>
> On Tue, Feb 3, 2015 at 6:53 AM, Sam Smith  wrote:
>> Nice job Joaquin!
>>
>> I've already started tweaking my workflow with all of the tips and tricks
>> from last time.
>>
>> –Sam
>>
>> On Tue, Feb 3, 2015 at 11:32 AM, Joaquin Oltra Hernandez
>>  wrote:
>>>
>>> Hi!
>>>
>>> The mobile web team and contributors met while in San Francisco and had a
>>> session on tools, workflows, and useful things to know when developing that
>>> was pretty awesome.
>>>
>>> We took notes, and I've structured and published them in the Dev sessions
>>> page (https://www.mediawiki.org/wiki/Mobile_web/Team/Dev_sessions)
>>>
>>> I've probably missed something we talked about, so if I missed something,
>>> please complete it.
>>>
>>> We plan on having this session monthly, so hopefully we'll keep on filling
>>> that list.
>>>
>>> If you try any of the items and have any doubts do not hesitate and ask on
>>> the talk page or via email to mobile-l.
>>>
>>> Cheers!
>>>
>>> ___
>>> Mobile-l mailing list
>>> Mobile-l@lists.wikimedia.org
>>> https://lists.wikimedia.org/mailman/listinfo/mobile-l
>>>
>>
>>
>> ___
>> Mobile-l mailing list
>> Mobile-l@lists.wikimedia.org
>> https://lists.wikimedia.org/mailman/listinfo/mobile-l
>>
>
> ___
> Mobile-l mailing list
> Mobile-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/mobile-l

___
Mobile-l mailing list
Mobile-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mobile-l

Re: [WikimediaMobile] Site banners on Mobile

[Jeremy Baron]

On Thu, Feb 5, 2015 at 9:50 PM, James Alexander
 wrote:
> They can be (it's a non default but available checkbox on the CN interface)
> but they have to be very very carefully tested. Normal CentralNotice banners
> tend to end up being so large on the mobile system that they can be highly
> intrusive and it is difficult to do things like close the banner.

+1.

even desktop banners are often not tested on enough screen resolutions.

Search for iphone or android at
https://meta.wikimedia.org/wiki/Special:BannerAllocation?project=wikipedia&language=he&country=IL

(just used he_IL because I saw it on
https://meta.wikimedia.org/wiki/Special:GlobalAllocation)

-Jeremy

___
Mobile-l mailing list
Mobile-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mobile-l

Re: [WikimediaMobile] Site banners on Mobile

[James Alexander]

They can be (it's a non default but available checkbox on the CN interface)
but they have to be very very carefully tested. Normal CentralNotice
banners tend to end up being so large on the mobile system that they can be
highly intrusive and it is difficult to do things like close the banner.

James Alexander
Legal and Community Advocacy
Wikimedia Foundation
(415) 839-6885 x6716 @jamesofur

On Thu, Feb 5, 2015 at 1:48 PM, Pine W  wrote:

> Do site banners appear on mobile apps and mobile web? I can't recall
> seeing one. With the growth in mobile, I hope that mobile apps and mobile
> web will support site banners for important notifications such as Wiki
> Loves Monuments.
>
> Thanks,
>
> Pine
>
> *This is an Encyclopedia* 
>
>
>
>
>
>
> *One gateway to the wide garden of knowledge, where lies The deep rock of
> our past, in which we must delve The well of our future,The clear water we
> must leave untainted for those who come after us,The fertile earth, in
> which truth may grow in bright places, tended by many hands,And the broad
> fall of sunshine, warming our first steps toward knowing how much we do not
> know.*
>
> *—Catherine Munro*
>
> ___
> Mobile-l mailing list
> Mobile-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/mobile-l
>
>
___
Mobile-l mailing list
Mobile-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mobile-l

[WikimediaMobile] Site banners on Mobile

[Pine W]

Do site banners appear on mobile apps and mobile web? I can't recall seeing
one. With the growth in mobile, I hope that mobile apps and mobile web will
support site banners for important notifications such as Wiki Loves
Monuments.

Thanks,

Pine

*This is an Encyclopedia* 






*One gateway to the wide garden of knowledge, where lies The deep rock of
our past, in which we must delve The well of our future,The clear water we
must leave untainted for those who come after us,The fertile earth, in
which truth may grow in bright places, tended by many hands,And the broad
fall of sunshine, warming our first steps toward knowing how much we do not
know.*

*—Catherine Munro*
___
Mobile-l mailing list
Mobile-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mobile-l

Re: [WikimediaMobile] [Apps] Scope of the apps content service

[Max Semenik]

Saving a page for offline is not that speed sensitive, however, serving
this information as part of normal page views would definitely impact
overall latency.

On Thu, Feb 5, 2015 at 1:24 PM, Dan Garry  wrote:

> On 5 February 2015 at 13:20, Max Semenik  wrote:
>>
>> Wouldn't that bloat the response size?
>>
>
> The rationale for including this is because that way the image viewer will
> work even if you've not tapped on any of the images. This is pretty
> important functionality that doesn't work offline right now, even if you
> save the page for offline reading.
>
> That said, we may want to punt this until after the MVP as being possibly
> outside of scope.
>
> Dan
>
> --
> Dan Garry
> Associate Product Manager, Mobile Apps
> Wikimedia Foundation
>



-- 
Best regards,
Max Semenik ([[User:MaxSem]])
___
Mobile-l mailing list
Mobile-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mobile-l

Re: [WikimediaMobile] [Apps] Scope of the apps content service

[Dan Garry]

On 5 February 2015 at 13:20, Max Semenik  wrote:
>
> Wouldn't that bloat the response size?
>

The rationale for including this is because that way the image viewer will
work even if you've not tapped on any of the images. This is pretty
important functionality that doesn't work offline right now, even if you
save the page for offline reading.

That said, we may want to punt this until after the MVP as being possibly
outside of scope.

Dan

-- 
Dan Garry
Associate Product Manager, Mobile Apps
Wikimedia Foundation
___
Mobile-l mailing list
Mobile-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mobile-l

Re: [WikimediaMobile] [Apps] Scope of the apps content service

[Max Semenik]

On Thu, Feb 5, 2015 at 12:00 PM, Dan Garry  wrote:

>
>- Image meta data for all images in the page
>- License
>   - Description
>   - Includes the URL for the high resolution version used for the
>   lead image
>
> Wouldn't that bloat the response size?

-- 
Best regards,
Max Semenik ([[User:MaxSem]])
___
Mobile-l mailing list
Mobile-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mobile-l

Re: [WikimediaMobile] [Apps] Scope of the apps content service

[Brian Gerstle]

I forgot to fill in my "*" next to "app services."  The name is not a great
one, and I'm open to suggestions that are more specific or intuitive.

On Thu, Feb 5, 2015 at 4:04 PM, Brian Gerstle 
wrote:

> In an effort to avoid yet another mega thread, I went ahead and created a
> Wiki page under the apps space which holds the problems & requirements for app
> services *.
> There's even a discussion page
>  where
> I've cherry-picked Brion & Gabriel's comments, organized by topic.  I hope
> this proves useful and will give us something to go on in the future.  I've
> put my comments so far on the talk page.
>
> On Thu, Feb 5, 2015 at 3:15 PM, Gabriel Wicke 
> wrote:
>
>> On Thu, Feb 5, 2015 at 12:04 PM, Brion Vibber 
>> wrote:
>>>
>>>
- Versioning? What if we add or remove a field from the response?
   We should version this. Can we do this easily?


>> In RESTBase we generally use mime type versioning like this:
>>
>> application/json; profile=mediawiki.org/specs/app_page_bundle/1.0.0
>>
>> This is specced in the Swagger spec & enforced by RESTBase. On version
>> mismatch from stored content, the backend service is called to re-generate
>> or upgrade the content, which is then saved back. It can be passed the
>> stored content to make re-generation more efficient.
>>
>> If needed, clients could also signal the content-type they expect with an
>> accept header. The details of how things would then be upgraded /
>> downgraded would need to be worked out in case you really need this. In
>> general, you can go a long way by only adding properties while remaining
>> backwards-compatible with the old properties.
>>
>> We also distinguish stability per end point:
>>
>>
>>- *experimental *end points can change at any time (effectively
>>private, use at your own risk)
>>- *unstable *end points can change, but we make an effort to avoid
>>breakage and notify users
>>- any change to *stable* end points will increment the major API
>>version (/v1/) following semver
>>
>> The mobile API should probably be marked as experimental, as it is
>> primarily intended as an API for apps we control.
>>
>> Gabriel
>>
>> ___
>> Mobile-l mailing list
>> Mobile-l@lists.wikimedia.org
>> https://lists.wikimedia.org/mailman/listinfo/mobile-l
>>
>>
>
>
> --
> EN Wikipedia user page: https://en.wikipedia.org/wiki/User:Brian.gerstle
> IRC: bgerstle
>



-- 
EN Wikipedia user page: https://en.wikipedia.org/wiki/User:Brian.gerstle
IRC: bgerstle
___
Mobile-l mailing list
Mobile-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mobile-l

Re: [WikimediaMobile] [Apps] Scope of the apps content service

[Brian Gerstle]

In an effort to avoid yet another mega thread, I went ahead and created a
Wiki page under the apps space which holds the problems & requirements for app
services *.
There's even a discussion page
 where
I've cherry-picked Brion & Gabriel's comments, organized by topic.  I hope
this proves useful and will give us something to go on in the future.  I've
put my comments so far on the talk page.

On Thu, Feb 5, 2015 at 3:15 PM, Gabriel Wicke  wrote:

> On Thu, Feb 5, 2015 at 12:04 PM, Brion Vibber 
> wrote:
>>
>>
>>>- Versioning? What if we add or remove a field from the response? We
>>>   should version this. Can we do this easily?
>>>
>>>
> In RESTBase we generally use mime type versioning like this:
>
> application/json; profile=mediawiki.org/specs/app_page_bundle/1.0.0
>
> This is specced in the Swagger spec & enforced by RESTBase. On version
> mismatch from stored content, the backend service is called to re-generate
> or upgrade the content, which is then saved back. It can be passed the
> stored content to make re-generation more efficient.
>
> If needed, clients could also signal the content-type they expect with an
> accept header. The details of how things would then be upgraded /
> downgraded would need to be worked out in case you really need this. In
> general, you can go a long way by only adding properties while remaining
> backwards-compatible with the old properties.
>
> We also distinguish stability per end point:
>
>
>- *experimental *end points can change at any time (effectively
>private, use at your own risk)
>- *unstable *end points can change, but we make an effort to avoid
>breakage and notify users
>- any change to *stable* end points will increment the major API
>version (/v1/) following semver
>
> The mobile API should probably be marked as experimental, as it is
> primarily intended as an API for apps we control.
>
> Gabriel
>
> ___
> Mobile-l mailing list
> Mobile-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/mobile-l
>
>


-- 
EN Wikipedia user page: https://en.wikipedia.org/wiki/User:Brian.gerstle
IRC: bgerstle
___
Mobile-l mailing list
Mobile-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mobile-l

Re: [WikimediaMobile] [Apps] Scope of the apps content service

[Gabriel Wicke]

On Thu, Feb 5, 2015 at 12:04 PM, Brion Vibber  wrote:
>
>
>>- Versioning? What if we add or remove a field from the response? We
>>   should version this. Can we do this easily?
>>
>>
In RESTBase we generally use mime type versioning like this:

application/json; profile=mediawiki.org/specs/app_page_bundle/1.0.0

This is specced in the Swagger spec & enforced by RESTBase. On version
mismatch from stored content, the backend service is called to re-generate
or upgrade the content, which is then saved back. It can be passed the
stored content to make re-generation more efficient.

If needed, clients could also signal the content-type they expect with an
accept header. The details of how things would then be upgraded /
downgraded would need to be worked out in case you really need this. In
general, you can go a long way by only adding properties while remaining
backwards-compatible with the old properties.

We also distinguish stability per end point:


   - *experimental *end points can change at any time (effectively private,
   use at your own risk)
   - *unstable *end points can change, but we make an effort to avoid
   breakage and notify users
   - any change to *stable* end points will increment the major API version
   (/v1/) following semver

The mobile API should probably be marked as experimental, as it is
primarily intended as an API for apps we control.

Gabriel
___
Mobile-l mailing list
Mobile-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mobile-l

Re: [WikimediaMobile] [Apps] Scope of the apps content service

[Brion Vibber]

There are two main approaches to versioning y'all can take:

One is the method used by most MediaWiki API modules where if you want a
new bit of info that wasn't in the default before, you have to ask for
it... and you never remove anything from defaults for fear of breaking
things.

The other is to use a nice linear versioning scheme, where you go to
"/api/v1/" or "/api/v2/" etc and the version number controls the business
logic of which elements get fetched and inserted into the response.

I tend to favor the latter as it's conceptually simpler and fits with the
concept of versioning up the apps along with their associated service. (The
former is more flexible but also means your requests get longer and longer
as you add features.)

-- brion

On Thu, Feb 5, 2015 at 12:00 PM, Dan Garry  wrote:

> Some of the Mobile Apps Team engineers met to discuss the scope of the MVP
> for a mobile apps content service.
>
> Firstly, we enumerated our goals for this content service:
>
>- Minimise number of requests the app has to make to generate a page
>- Reduce payload size of requests
>- Abstract away from of the API logic contained in the client into the
>server instead
>- Do some of the transforms that are currently done on the client on
>the server instead, where appropriate
>
> We decided that the scope of the service should be feature parity; the
> service should be a drop-in replacement for our current API calls. More
> concretely, this means it should give us:
>
>- Data from mobileview
>   - Wikidata description
>   - Revision ID of page
>   - Wikibase ID
>- Image meta data for all images in the page
>- License
>   - Description
>   - Includes the URL for the high resolution version used for the
>   lead image
>- Exclude unused HTML
>- Navboxes, etc.
>- Exclude hidden elements
>   - CSS: display: none; unless if we display later
>- Related articles suggestions from full text search API
>
> Things which we want to add, but are out of scope for the first iteration:
>
>- Arbitrary Wikidata properties
>- Disambiguation (already "transcluded", following the chain of
>disambiguation pages and returning a JSON array of those links)
>- Page issues
>- Interwiki links
>- Table of contents (as a JSON array)
>
> Open questions:
>
>- Versioning? What if we add or remove a field from the response? We
>should version this. Can we do this easily?
>
> Thanks,
> Dan
>
> --
> Dan Garry
> Associate Product Manager, Mobile Apps
> Wikimedia Foundation
>
> ___
> Mobile-l mailing list
> Mobile-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/mobile-l
>
>
___
Mobile-l mailing list
Mobile-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mobile-l

[WikimediaMobile] [Apps] Scope of the apps content service

[Dan Garry]

Some of the Mobile Apps Team engineers met to discuss the scope of the MVP
for a mobile apps content service.

Firstly, we enumerated our goals for this content service:

   - Minimise number of requests the app has to make to generate a page
   - Reduce payload size of requests
   - Abstract away from of the API logic contained in the client into the
   server instead
   - Do some of the transforms that are currently done on the client on the
   server instead, where appropriate

We decided that the scope of the service should be feature parity; the
service should be a drop-in replacement for our current API calls. More
concretely, this means it should give us:

   - Data from mobileview
  - Wikidata description
  - Revision ID of page
  - Wikibase ID
   - Image meta data for all images in the page
   - License
  - Description
  - Includes the URL for the high resolution version used for the lead
  image
   - Exclude unused HTML
   - Navboxes, etc.
   - Exclude hidden elements
  - CSS: display: none; unless if we display later
   - Related articles suggestions from full text search API

Things which we want to add, but are out of scope for the first iteration:

   - Arbitrary Wikidata properties
   - Disambiguation (already "transcluded", following the chain of
   disambiguation pages and returning a JSON array of those links)
   - Page issues
   - Interwiki links
   - Table of contents (as a JSON array)

Open questions:

   - Versioning? What if we add or remove a field from the response? We
   should version this. Can we do this easily?

Thanks,
Dan

-- 
Dan Garry
Associate Product Manager, Mobile Apps
Wikimedia Foundation
___
Mobile-l mailing list
Mobile-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mobile-l