# What?
## Problem Statement
//Write your problem statement using layperson's terminology. In one sentence, what is the problem or opportunity?//
* To support **WE2.1** and **other similar use cases,** we need a **clearly-defined **(but limited)**, performant, **mechanism to provide **configurable user experiences **for **anonymous** users that** require changes to the way the page is rendered. **
* **WE2.1: **FY23-24 Annual Planning (draft) objective 2, Key Result 1: “X% of unique devices read Wikipedia through a customized experience, in order to fit their own needs.”
* **Other similar use cases**: We would like to identify a class of related problems, and solve for these together, going beyond simply the preferences explicitly called out in the KR.
* **Clearly-defined (but limited): **As part of our discussion, we should spell out the scope of this mechanism: what it is and is not intended to cover.
* **Performant: **Falling within explicitly-defined acceptable performance budgets
* **Configurable user experiences **- allow for different user experience presentations depending on the user
* **Anonymous:** this does not affect logged-in users, who have the user_properties table
* **Affect the way the page is rendered**: These should be changes that need to happen before the page is loaded
* Scope:
* **No caching changes: **Currently we serve the same (usually cached) HTML to all anonymous users - any proposed solution should avoid impacting existing Varnish caching
* **No A/B tests: **We should consider A/B tests to be out of scope for this solution. There may be other out of scope options/changes as well which we should discuss
* **No cross-device storage: **These preferences should be specific to the device they’re stored on – cross-device preference storage is out of scope for this solution.
* **On-Wiki Storage: **Though they may interact with device system settings (e.g. `prefers-color-scheme`), these settings will be explicitly stored on the site itself
* To be determined:
* **What class of changes?: **What is the class of change this should and shouldn’t cover?
* E.g. binary changes only, Scalar values etc.
## What does the future look like if this is achieved?
* **Impact to Movement: **We have a mechanism that will enable us to deliver successfully on the FY23-24 Annual Planning OKR WE2.1 to enable customization of user experiences for anonymous users.
* **Extensibility: **We have a clear, documented, constrained go-to solution for storing future client-side preferences that teams doing development on the frontend can use for a defined subset of use cases
* **Scope: **We have documented and made clearly understood the circumstances under which a team would and would not use this mechanism
* **Performance Parameters: **We have documented and made clearly understood the performance impact of this mechanism and how a given team would evaluate the performance risk of a given proposal
## What happens if we do nothing?
* **Anonymous User Customizability: **Anonymous users, who make up the bulk of users of our sites, would miss out on certain customizable user experience benefits such as page density, dark mode, and font size
* **System-level Overrides: **Note that the key detail here is **customizability**. For dark mode specifically, and likely several other of these preferences, there are device & system-specific defaults which one can query by means of media queries such as [`prefers-color-scheme`](https://developer.mozilla.org/en-US/docs/Web/CSS/@media/prefers-color-scheme). If we do nothing, we defer automatically to these system-wide settings. That said, as currently defined, WE2.1 is about the ability to **customize** and override such systems-specific settings on a per-site basis - if, for example, a user wished to have system-wide dark mode but to opt out of this on-wiki, there would be no means of doing so without this kind of anonymous preference storage.
* **Reinventing the Wheel: **The Web Team, or other teams looking to persist similar features, would not benefit from a unified solution in this space, and may need to individually work through any number of the following issues:
* **[Flash of Unstyled Content](https://en.wikipedia.org/wiki/Flash_of_unstyled_content)** - content appearing before styled according to the settings specified
* **Other layout shifts** - applying settings after page-render may result in user-visible shifts in page layout
* **Performance impact** - it is possible that teams would store preferences in a non-performant way at the wrong juncture of the critical rendering path, potentially resulting in rendering slowdowns or hits to SEO
* **Lack of unified solution** - teams would otherwise need to solve the question of how to store certain preferences for anonymous users on a case-by-case basis, potentially re-inventing the wheel for every preference that needs to be stored
* **Missing go-to solution - **Other teams looking to persist similar features might hesitate to implement features with this need at all, fearing that they might encounter the above consequences
* **Missing guidance - **Existing, temporary measures for storing various user settings may be expanded to use cases that they are not suited for, e.g. making DOM changes in a critical render path
# Why?
## User Value/Organization Value AND Objective it supports and How
* **FY23-24 APP - Web Team**
* The FY23-24 OKR WE2.1 (draft) currently states: “X% of unique devices read Wikipedia through a customized experience, in order to fit their own needs.” The ability to store at very least the following preferences for anonymous users to be critical to making these possible:
* Page density (page width)
* Accessibility settings:
* Dark Mode
* Font size
* **Community Responsiveness/Wishlist**
* Dark mode was the top-voted item in the community wishlist survey, and implementing a dark-mode preference for anonymous users in a persistent way will be an important part of this
* **APP - Other Feature Teams**
* Other teams are working now through the APP process, and it would be helpful to them to know when and how they could store certain settings for affected anonymous users.
* The Web team has been approached by several teams that would be interested in potentially storing preferences in some way
## Why are you bringing this decision to the Technical Forum?
//What about the scope of this problem led you and your team to seek input across departments/organizations?//
- **Impact - **This is intended to be a general-purpose mechanism that could be used by any team at the Foundation (provided their use case fits within our defined criteria) - thus the scope goes beyond the Web Team
* **Clarity - **An initial mechanism that the Web team implemented for storing page width (see [here](https://phabricator.wikimedia.org/T321498)) was made in render-blocking code, and concerns were raised about when and how this was accomplished. Providing clarity about when/how we should and should not use this mechanism – wherever possible tied to specific metrics of concern and interest – for Web and for other teams, is critical.
* **Expertise and Alternatives **- It is important to solicit input from those who either need to store similar preferences or who have relevant subject-matter/domain expertise to understand what options and alternatives exist for this kind of storage
# Stakeholders
* Web Team - will likely (pending APP approval) need to use this or similar mechanisms for work beginning FY 2023-24
* Performance Team - will need to weigh in as to the performance implications
* Other teams doing FE feature work - will need to weigh in as to whether and how this mechanism could be used for other frontend use cases.
## Non-Stakeholders
* SRE - it is our assumption that this solution, being client-side only, will not necessitate involvement of the SRE team
* Related Designs *
https://www.figma.com/file/84uThsPg9ayvZmnbshyP7e/Vector-2022-updates?type=design&node-id=161-9748&mode=design
https://www.figma.com/file/84uThsPg9ayvZmnbshyP7e/Vector-2022-updates?type=design&node-id=212-13880&mode=design