Jump to content

Reading/Web/Projects/OCCAM/ArchCom-03-15-2017

From mediawiki.org

Copied from https://docs.google.com/document/d/1jlBl_qAIrGPF7zqOmK77Db8y4InO1j3qX1qqipzJNmc/edit#

High level mobile frontend requirements & plans

[edit]

Agenda

[edit]
  • Agenda bashing
  • Quick overview of product & technical goals (Joaquin) (5 min)
  • Q&A

Background reading

[edit]

Discussion

[edit]
  • Joaquin giving an introduction on technical objectives and product requirements
  • Brion: Thanks for presenting. Sounds very interesting. One question comes up repeatedly is editing tools, especially on mobile. How can we integrate mobile editing?
  • Joaquin: Editing team is working on edit tools for mobile. Technically, there should not be an issue with integrating our current edit tools like VE into a new experience too.
  • Daniel: Mobile editing always struck me as a secondary concern, as editing prose is hard. Curation and patrolling on the other hand seems more suitable. What would we need technically to support this kind of feature?
  • Joaquin: We have definitely thought about this, and would like to do something about it. Currently editing is more of an owner for this kind of product.
  • Gabriel: Technically the requirements don't seem to be that specific.
  • Daniel: Don't know of overly specific ones either, just need to keep it in mind. For example, important to integrate with existing workflows like talk pages.
  • Corey: Discussion of editing triage workflows (i.e. reverts) currently going on in product. Not much of a technical impact.
  • Timo: VE isn't really a done deal for static/standalone mobile yet. VE has a standalone experience, but that’s without MW support (Cite, Template, Parsoid etc.), which would be a requirement here. To clarify, this new frontend would be provided as a stand-alone distribution / infrastructure. What are we trying to achieve with that, and how can we avoid previous issues?
  • Joaquin: A key differentiator is the offline experience. Need to be able to load from a local cache. We still don't know if this is absolutely a priority, but it would be hard to do with the existing architecture.
  • Timo: So far my view has been that we shouldn't have a stand-alone front-end. But the offline use case is compelling, and it has opportunities for other performance optimizations as well. Need to think about it.
  • Timo: In the performance team we are thinking about improving the no-JS experience. Also affects network failures of individual modules.
  • Gabriel: First load is a major use case (~80% of sessions on mobile are a single page only). Need to make this fast, can't load a lot of JS before showing content.
  • Timo: +1, we have been moving in the pure HTML direction in the perf team for a while, putting focus on the no-JS experience being ‘good enough’. All scripts load async so the HTML & CSS only page needs to work
  • Gabriel: Code duplication is something we really need to avoid. Fall-back should use the same architecture.
  • Brion: Have some questions about technical debt & implementation. How can we support high-end devices vs. low-end ones? Are we constrained by lowest common denominator? Progressive enhancement?
  • Volker: Screen size / form factors is another big concern as well.
  • Corey: Could ServiceWorker help here?
  • Gabriel: Yes. supported by ~60% of browsers now.
  • Joaquin: Our current fall-back provides a fairly different experience. Basic browsers need to support all the basic functionality.
  • Gabriel: Can offer several support levels, still run JS in a page even if SW is not supported.
  • Corey: Does running JS on the server eliminate the need to make different code for constrained browsers
  • Gabriel: Not automatically, depends on what the SW-composed page expects.
  • Adam: Even Opera Mini is improving a lot, lowest common denominator is shifting.
  • Joaquin: For example: Currently, in a modern client you get an interactive search experience, while on opera mini you get a basic form. So it depends on the feature.
  • Timo: Does the search results page look the same?
  • Joaquin: It's very similar.
  • Gabriel: How does the module / tooling parts affect/relate to ResourceLoader?
  • Timo: The frontend tooling part that is being discussed may be better as a separate topic. There’s an RFC about it. For ServiceWorker code it would be a prerequesite. The current RFC for multifile common.js modules is on its way to be approved. Details left to be fleshed out. That seems fine. Seems like an orthogonal thing, but it depends on the requirements being set. Things like source maps are very important for development.
  • Joaquin: We see it that way, current patch to develop with those technologies until we get a general technology
  • Gabriel: Opinions on using services for content consumption and separating the data layer and the UI layer.
  • Daniel: Looks fine but lack data about the approach to have a solid opinion on it.
  • Volker: What are your ideas for i18n?
  • Adam: Is this about content, or UI?
  • Volker: UI. How much will we need to duplicate efforts?
  • Timo: Share concern about duplication. Should aim for data-driven approach, where the client renders a data blob using a template. Business logic would sit behind the API.
  • Joaquin: That's the approach we had in mind. Having the business logic behind the API also lets us share this logic across experiences.
  • Timo: This is essentially a reimplementation of the skin layer. I proposed something like this before, even at the PHP layer (T140664). The important part is the clear interface between frontend & backend.
  • Joaquin: I'd like to note that once we have more information from the product side / clearer requirements we'd like to update you / discuss again.
  • Gabriel: What are your thoughts on using a hangout this time?
  • Brion: I liked it, but Tim didn't have audio & we need to get recording / streaming working.
  • Gabriel: Agreed. Thanks everyone!

IRC transcript: https://tools.wmflabs.org/meetbot/wikimedia-office/2017/wikimedia-office.2017-03-15-21.10.html

Retrieved from "https://www.mediawiki.org/w/index.php?title=Reading/Web/Projects/OCCAM/ArchCom-03-15-2017&oldid=3045302"