# 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 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_proprerties 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, font size, and menu persistence.
* **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 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
* Menu state persistence
* **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