Awesome, thanks for publishing the notes!
On Thu, Jun 30, 2016 at 1:24 AM, Jon Robson <jrobson(a)wikimedia.org> wrote:
On Tue, Jun 28, 2016 at 10:01 AM, Stephen Niedzielski
<sniedzielski(a)wikimedia.org> wrote:
Action items:
Audit any assumptions apps make about contents of HTML returned by API
and
make tickets for tests [Jon Robson]
Make sure all edge cases are covered e.g. What if srcset is not present?
What if there are no img and the figure tag is being used?
Rely less on HTML wherever possible - explore if it would make more
sense to
pull out metadata in API responses
Capture in a task for Reading Web team to write a MobileFrontend test to
protect app requirements
Write new tests for MobileFrontend (wherever they make most sense) to
make
sure they cover what is needed by iOS and Android
and they need to be
triggered by MobileFrontend commits
Done:
https://phabricator.wikimedia.org/T139004 (see also parent)
Could add some MCS tests for HTML content
Look into hooking up Jenkins Android / iOS to the mobile front end tests
so
that MobileFrontend merges are blocked when they
break things in apps
[Corey
Floyd + Michael Holloway]
Explore if TemplateData could be used by Apps for replacing editor
created
template constructs e.g. infobox
Look at testing apps against beta cluster [Monte Hurd]
Android / iOS should try to get CSS / JavaScript into MobileFrontend more
rather than changing it on the client [T137992]
Copy and paste of Etherpad for posterity:
Agenda
9:00-9.15: What happened. Let's get a shared understanding of the problem
hit. Demo would be useful here if this can be arranged.
9:15-9.40: How could this have been avoided? What APIs would have made it
better?
9:40-10:00: Actions/story writing.
From Google invite:
"I think this is something we should probably discus more next week -
probably as a separate meeting. It would be good to talk about the
strategies we use in the apps to get the content and what we can do to
improve them. This is also very relevant for the content service."
I've marked some as mandatory and some as optional, but I don't think it
would hurt to join and even just listen passively even if you're
optional,
especially if you have an interest.
The removal of srcset led to some breakage in the iOS app's galleries.
Notes:
App clients have two different calls:
Meta data: search, something powering the feed
Content: HTML <-- This is where the issue is.
HTML content:
HTML is valid but... We extract somethings (with selector queries)
to do
things natively. This is kind of hacky generally
because content is tough
and variable. For example, table of contents (the sections themselves are
parsed out server side...? it's pulled down and seperated). Any changes
to
the structure of this HTML can break things.
Content Service does this kind of thing too but at least the output is
from
Parsoid.
Web does very little with HTML content. The stuff we do is very minimal.
Somethings get stripped out but generally considered small.
More tests would be nice for content specifically. For instance, if you
clients are expected a src set, then write a test for that.
iOS added a test for srcset. Content Service has lots of content tests.
It's tricky for native apps since the tests are written in a different
environment than the other app tests? Just need to make sure the HTML
isn't
messed up.
MobileFrontend has some Jenkins automated tests. Probably could use some
fleshing out to make sure they cover whatever the apps need. This won't
be
super simple.
Can we move some of the Android screenshot tests to Mobile Frontend
somehow?
testwiki gets code drops on tuesdays
beta cluster (
en[.m].wikipedia.beta.wmflabs.org) gets whatever's merged
to
master like within 30 minutes of merge
Action items:
Audit any assumptions apps makes about contents of HTML returned by
API
and make tickets for tests [JR]
Make sure all edge cases are covered e.g. What if srcset is not
present?
What if there are no img and the figure tag is
being used?
Rely less on HTML wherever possible - explore if it would make more
sense to
pull out metadata in API responses
Capture in a task for Reading Web team to write a MobileFrontend test to
protect app requirements
Write new tests for MobileFrontend (wherever they make most sense) to
make sure they cover what is needed by iOS and Android and they need to
be
triggered by MobileFrontend commits
Content Service is used by Android and already has a lot of tests,
remaining tests are integration level screenshot tests
Could add some MCS test for HTML content
Look into hooking up Jenkins Android / iOS to the mobile front end tests
so
that MobileFrontend merges are blocked when they
break things in apps
[CF +
MHolloway]
Explore if TemplateData could be used by Apps for replacing editor
created
template constructs e.g. infobox
Look at testing apps against beta [MHurd]
Android / iOS should try to get CSS / JavaScript into MobileFrontend more
rather than changing it on the client
[
https://phabricator.wikimedia.org/T137992]
_______________________________________________
Mobile-l mailing list
Mobile-l(a)lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mobile-l
_______________________________________________
Mobile-l mailing list
Mobile-l(a)lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mobile-l