Page MenuHomePhabricator

Audit iOS, Android and Mobile Web HTML, CSS, and JS
Closed, ResolvedPublic

Description

Each mobile platform maintains a set of custom HTML/CSS/JS that is used to render articles specifically for each platform.

This ticket is focused on auditing these separate implementations and seeing which code can be shared and how.

As a matter of timing, the Web Team is working on prototyping a new ServiceWorker powered implementation of the Mobile Web while at the same time using the MCS for content. Because of this, it seems like an appropriate time to look into this topic.

Questions / Ideas:

  1. Can CSS / JS be written in a way that can work across various form factors / platforms but not fragment the cache? Is cache fragmentation only an issue for saved pages on Android and iOS?
    • @TheDJ recommends reviewing .client-js vs .client-nojs that is already two platforms. Just adding classes to the body for various platform bugs, features etc. You just have to make very sparingly use of them. But it's easy to have a system where you have potential body classes like: 'ios android android3 svg-support' etc. Any code which relies on this is then shipped as 'specific' as possible.
  2. Can we use media queries to move some custom JS into CSS?
  3. Identify differences between apps and web (CSS / JS) to allow the above
  4. What will live in the MCS? (Just the Mobile Sections API?)
  5. What about cross site hosting concerns?
  6. When will Service Worker Proxy be completed? (Server side ServiceWorker)
  7. How much can we change the look of all platforms to ensure they have a consistent look to make the above easier? How much would actually change from platform to platform? (verify with design and PMs)
  8. Will the mobile web use API calls to populate the HTML?
  9. Will mobile web degrade to non service worker w/js and then to non js clients? Or will it be all or nothing?
  10. Will streaming HTML to the apps improve rendering time? WebView is optimized to load pages itself but apps aren't that different from a web SPA.
  11. How can we decrease rendering time? What are the current times to render?
  12. Where will the JavaScript blob live?
    • Square recommends that the blob be provided by the server. This allows the server to control both the data and logic in one place without re-releasing the app and greatly minimizing versioning concerns; @TheDJ recommends this approach as well but 1) adds that it's essential to perform consistency checks on the delivered resources, so that you don't break your app with an incomplete request and 2) to pre-ship a copy whenever possible (enhances first start, even when first start is offline) and keep it up to date
    • Regardless of where the blob lives, we should publish it as an NPM package
  13. What does testing look like?
    • For presentation logic such as dates (today, yesterday, 3p, etc), this could be string assertions
    • For DOM transforms (such as making tables collapsible), this could be apply then transform then trigger it and observe the result
    • In general, apps should depend on the library, not the other way around. If possible, usage of the library shouldn’t require Vagrant and shouldn’t require an app
  14. Are there any special considerations for versioning needed between the library and the Content Service? Native bridge platforms?
  15. Can we eliminate page rewriting for offline mode on Android and iOS? Maybe base href with a local server can be useful?
  16. What version of JavaScript are we compiling to?
    • Android is currently API 16. Android System WebView isn't available until 21 so we have to support whatever is baked into 16.
  17. Can we simplify the process of generating stylesheets? Currently they exit in a separate repo, have common and platform overide files, and generated infrequently
  18. Do we need to support both MediaWiki and the Content Service? If only the Content Service, should we migrate iOS to the Content Service before we touch the JavaScript?

Localization and customization:

  • Localization and customization of content. Is this performed by the app with placeholders or handled entirely by the JS lib? Content received the JS lib should appear like “the ideal endpoint.” If you request content from the Hebrew endpoint, everything that could be translated would be?
  • Anything in the page should be in the article language? Should be customizable?
  • What does personalization / customization come in? This seems like it should be handled by the JS lib since presumably all platforms would like the ability to theme a page, for example
  • Content translations should be stored in lib? For example, “Table of contents” chrome could be a single set of translations in the JS lib instead of all clients
  • Themes, timestamps, location (you’re 380 miles from the subject of this article), show images, locale, ...

Android and iOS hybrid native components that integrate with HTML:

  • Scrolling
  • Find in page (iOS only)
  • Edit here (Android only?)
  • Read more
  • Page toolbar
  • References, disambiguations / similar pages, content issues
  • Page header (lead image, title, subtitle / Wikidata description)
  • Page preview -- where should stuff like this live? content service or js lib?

References:

Event Timeline

Restricted Application added a subscriber: Aklapper. · View Herald TranscriptDec 12 2016, 6:56 PM
Fjalapeno updated the task description. (Show Details)Jan 17 2017, 8:04 PM
Mhurd added a subscriber: Mhurd.Jan 18 2017, 7:39 PM
Niedzielski updated the task description. (Show Details)Jan 19 2017, 5:13 AM
Niedzielski updated the task description. (Show Details)Jan 19 2017, 6:41 AM
Fjalapeno claimed this task.
Fjalapeno updated the task description. (Show Details)Jan 20 2017, 6:35 PM
Niedzielski updated the task description. (Show Details)Jan 22 2017, 1:32 AM
TheDJ added a subscriber: TheDJ.Jan 31 2017, 10:22 AM

Can CSS / JS be written in a way that can work across various form factors / platforms but not fragment the cache? Is cache fragmentation only an issue for saved pages on Android and iOS?

I'd say, look at how we do .client-js vs .client-nojs that is already two platforms. I have been solving platform variance in a similar way for ionic mobile apps for a few years now. Just adding classes to the body for various platform bugs, features etc. You just have to make very sparingly use of them. But it's easy to have a system where you have potential body classes like: 'ios android android3 svg-support' etc. Any code which relies on this is then shipped as 'specific' as possible.

Square recommends that the blob be provided by the server.

I advise that as well, BUT

  • essential: do consistency checks on the delivered resources, so that you don't break your app with an incomplete request.
  • advisable: pre-ship a copy whenever possible (enhances first start, even when first start is offline) and keep it up to date.

This can be done with serviceworkers, but all of it can already be done inside apps right now (there are even some SDKs, though I've never had to use them).

Niedzielski updated the task description. (Show Details)Feb 1 2017, 3:06 PM

@TheDJ, thanks for the tips! I've updated the task with your notes :]

bearND added a subscriber: bearND.Feb 14 2017, 3:05 AM
Niedzielski updated the task description. (Show Details)Feb 16 2017, 2:01 PM

This task became a catch-all for the entire wikimedia-page-library project for a time but its about to run its course and I will be closing it out, as well as T155695 and T155693, with @Mhurd towards the end of this week. In it's place, I've opened up many new tasks, all are tagged wikimedia-page-library and most are children of T163839. MobileFrontend lazy load tasking and general task review are still pending and will be completed prior to closing this task. I believe I've captured everything else that's relevant that we want to act upon in the foreseeable future but please feel free to add anything I've missed (and consider tagging it with wikimedia-page-library!).

If you object, speak soon!

Niedzielski closed this task as Resolved.

After discussion with Monte, we're closing T152991, T155695, T155693. Everything presently actionable is tasked in wikimedia-page-library / wikimedia-page-library-tshirt except T164313 which is still being reviewed.