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:

• Shared App Functionality via JavaScript (Square)