Page MenuHomePhabricator

Wikimedia Technical Conference 2018 Session - Determining use cases and requirements for the APIs that we build
Open, Needs TriagePublic

Description

Session Themes and Topics

  • Theme: Increasing our technical capabilities to achieve our strategy
  • Topic: APIs (+asset delivery)

Session Leaders

Facilitator

  • Greg Grossmeier (@greg)

Description

In order to define the future APIs of the platform, we must first understand how the APIs will be used and what behaviors they must support. This session will primarily be concerned with APIs supporting client user interfaces.

Questions to answer during this session

QuestionSignificance: Why is this question important? What is blocked by it remaining unanswered?
Which client “UIs” do we support with our APIs? How can we support apps, mobile and desktop use cases? What about upcoming platforms (watch, voice-enabled devices, VR, etc.)? Any others?We want to identify as many potential use cases for our APIs as possible, new or upcoming. These varying use cases constrain possible solutions.
What data should be decomposed and exposed through APIs? How will data be composed into rendered HTML or other UIs? Any considerations regarding: Where does localization of data (e.g. dates) occur? What about authenticated vs unauthenticated users? What about low bandwidth/intermittent network environments? Are there any exceptions to decomposing data in this way?A decision on this workflow is required in order to make decisions on implementation and supporting technologies. Example pages that can’t be decomposed cleanly: maybe some special pages
To support existing clients, what technologies do we need given the API first and data first architecture?The level of support required for existing clients must be decided so that a solution can be architected. Trade-offs will need to be made in order to support existing clients while still providing support for advanced modern use cases.

Facilitator and Scribe notes

https://docs.google.com/document/d/1pFQvlcFZ4AdJjvnxH5YPOFqloOpB_rORfgrmiNRZX1w

Session type: Evaluating Use Cases
This type of session is examining at a set of use cases that have the potential to generate requirements which significantly impact the architecture. The questions are designed to remove ambiguity about the use cases and identify key features that will result in us being able to unblock architecture decisions.

Session structure

  1. Intro
    • Format: Presentation
    • Time: 5 minutes
    • Session format and facilitation instructions
  2. Get all platforms/clients we want to support with APIs
    • Format: Small Group Discussion - Reconvene into post-its on walls
    • Time: 10 minutes + 2 minutes for context switch
  3. List considerations/constraints (e.g. network characteristics, size of display, whether there’s a display at all, browser available, etc.)
    • Format: Working Groups - Group by platform expertise, and write considerations
    • Time: 10 minutes + 2 minutes for context switch
  4. Data needs for the different platforms
    • Format: Station rotation (group by data expertise who visit different platform stations) or working groups?
    • Time: 15 minutes + 2 minutes for context switch
  5. Lead into follow-up session about API tech (optional)
    • Format: Presentation
    • Time: 5 minutes
    • Summarize information collected
    • Explain the next session and what will be discussed
    • Ask for participants to attend followup

Post-event Summary

Action items generated from the transcription

  • The Foundation should invest in researching upcoming and future technologies to better understand the constraints and considerations before building for them or supporting them officially.
  • Prompt the Foundation to publish a list of currently supported platforms/clients.
  • Publish the notes from this session to a wiki so that they can be discussed, refined, and added to over time.

Event Timeline

debt created this task.Oct 2 2018, 10:56 PM
Restricted Application added a subscriber: Aklapper. · View Herald TranscriptOct 2 2018, 10:56 PM
kchapman renamed this task from Wikimedia Technical Conference 2018 Session - What are the requirements for the APIs that we build? (Clients / Bots) to Wikimedia Technical Conference 2018 Session - Determining use cases and requirements for the APIs that we build.Oct 3 2018, 2:31 AM
debt updated the task description. (Show Details)Oct 4 2018, 11:39 PM
debt added a subscriber: phuedx.
phuedx updated the task description. (Show Details)Oct 5 2018, 12:37 PM
debt updated the task description. (Show Details)Oct 10 2018, 1:48 PM
debt updated the task description. (Show Details)Oct 17 2018, 10:00 PM
debt added a subscriber: greg.
Jhernandez updated the task description. (Show Details)Oct 19 2018, 2:49 PM
Jhernandez added a subscriber: Tgr.Oct 19 2018, 2:57 PM

@Tgr I think the task is mostly final with the session structure in case you want to have a look.

As we talked, if you need something specific for the final part to lead into your session, let us know.

We will try to keep big postits on the walls with the content in case it can be useful for your session.

Quiddity updated the task description. (Show Details)Oct 20 2018, 12:35 AM

We have transcribed everything to the google doc, will be publishing here soon and summarizing to answer the questions

Literal transcription from the posters of the session

Platform: Offline wiki experiences
Constraints: Freshness, storage (choose a subset of content), read-only (?)
Data requirements: Related media, images (rescaled and/or bundles), batch updating, keyword filtering, article HTML, edit conflict-resolution

Platform: Social media embeds
Constraints: Attribution, fragmented, limited information, link to specific area inside the content
Data requirements: Metadata and/or OpenGraph, abstracts, page images, sentence ID, embedded media

Platform: Mobile browsers/reader mode browsers
Constraints: Spotty internet, screen size
Data requirements: Article HTML

Platform: Google Knowledge Graph
Constraints: Scalability
Data requirements: Structured data (RDF or JSON+LD), dumps

Platform: Voice assistants (Google Home, Siri, Alexa)
Constraints: Sentence splitting, limit bandwidth, no browser engine, limited transparent, no screen
Data requirements: Text, JSON, HTML (?), audio, simplified text, device sends search queries

Platform: Discovery, curation, and analytics tools
Constraints: Large volume and/or concurrency, wikitext, sends search queries
Data requirements: JSON, images, audio, text

Platform: Wearables, smartwatches
Constraints: Small screen, no keyboard, no JS, limited bandwidth, high latency, location awareness
Data requirements: Images, JSON

Platform: UC Mini, Opera Mini
Constraints: No JS, small screen, limited connectivity
Data requirements: HTML

Platform: VR and AR
Constraints: Location-aware, more dimensions
Data requirements: Plaintext?

Platform: NaNoGenMo
Constraints: ?
Data requirements: JSON-structured data

Platform: Desktop (native?) applications
Constraints: Custom UI, screen size varies
Data requirements: HTML + text all together, structured links/tables, images, styling

Platform: Mobile apps
Constraints: See above, HTML is good for content but bad for UX, bandwidth varies, small screen, data price
Data requirements: See above, structured data, mixed media, JS/CSS, JSON, events

Platform: Assistive tech
Constraints: Needs assistive markup for semantic info, UX, no styling, layout and content
Data requirements: Short text summary, discoverability, semantic markup alt-text, navigation links

Platform: Wikiwho and other analytics data crunching services, WDQS
Constraints: Special endpoints/data?, RDF stream of updates, specific data needs
Data requirements: Styling, text, HTML, media, events, pageviews, dumps, RDF stream of updates (?)

Platform: cURL
Constraints:
Data requirements: JSON-structured data, HTML, text, dumps

Platform: Mobile web
Constraints: Bandwidth varies
Data requirements: HTML, JSON structured data/Wikidata, short text summaries, images

Platform: Desktop web
Constraints: HTML browsers, bandwidth varies, screen varies
Data requirements: Styling, images, JSON structured data/Wikidata

Platform: WAP
Constraints: Is it dead? Very low bandwidth, no styles, small screen
Data requirements: Light markup, small pages

Platform: Map apps/mashups
Constraints: No JS, limited bandwidth, high latency, small screen
Data requirements: JSON, coords/address, images

Platform: Third-party web interfaces (Wikiwand)
Constraints: Consumes DOM
Data requirements: HTML, mixed media, structured data

Platform: Consoles
Constraints: Low resolution (?)
Data requirements: HTML, JSON

Platform: Crawlers, spiders, bots, Archive.org
Constraints:
Data requirements: (Batch-) events, site index, structured data, sitemaps, HTML, JS

Platform: PDF/print
Constraints:
Data requirements: HTML, wikitext, medata, Latex, CSS, images

Platform: Editing + program organising tools
Constraints:
Data requirements: Everything, analytics data

Platform: WebTV
Constraints: JS?
Data requirements: JSON, streaming video/audio

Platform: Gadgets
Constraints:
Data requirements: JSON

Platform: Research
Constraints:
Data requirements: Everything

Platform: Our autocomplete/search results
Constraints:
Data requirements: JSON, images

Platform: ToolLabs vizualisations
Constraints:
Data requirements: JSON

Action items generated from the transcription

  • The Foundation should invest in researching upcoming and future technologies to better understand the constraints and considerations before building for them or supporting them officially.
  • Prompt the Foundation to publish a list of currently supported platforms/clients.
  • Publish the notes from this session to a wiki so that they can be discussed, refined, and added to over time.
Jhernandez updated the task description. (Show Details)Oct 25 2018, 8:43 PM
Jhernandez updated the task description. (Show Details)Oct 25 2018, 8:45 PM

☝️ I forgot to upload this image on the day.

Hello! We are starting to ramp up on session creation for the 2019 Wikimedia Technical Conference. If there is no longer anything remaining to do here please close this task to avoid confusion.