= Session Themes and Topics=
* Theme: Increasing our technical capabilities to achieve our strategy
* Topic: APIs (+asset delivery)
=Session Leaders=
* Sam Smith (@phuedx) & Joaquin Hernandez (@Jhernandez)
=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=
|**Question**|**Significance: 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.
=Scribe Instructions=
Please make a copy of the notes worksheet located here to take notes: https://docs.google.com/document/d/1J-wTeelHFGeXw6dO1ywkGr0NfnzG-cUykowc6aSKoWE/edit?usp=sharing
=Facilitator Instructions=
Reference: 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
1. 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
1. 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
1. 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
1. 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:
* `TODO`...
Action items:
* `TODO`...