Awesome, thanks for publishing the notes! On Thu, Jun 30, 2016 at 1:24 AM, Jon Robson <jrob...@wikimedia.org> wrote:
> On Tue, Jun 28, 2016 at 10:01 AM, Stephen Niedzielski > <sniedziel...@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@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
