Write your problem statement using layperson’s terminology.
In one sentence, what is the problem or opportunity?
Netflix Problem Statement Example: Going to the video store requires fighting traffic, wandering the aisles, and waiting in long lines just to get a single movie.
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 (ref): “Ensure a quality reading experience for all users by adapting the default experience for X% of pageviews, based on the individual needs and constraints of the user.”
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/fragmenting existing edge 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.
Not simply reading an existing system setting: Though we may consult device system settings (e.g. `prefers-color-scheme`), this mechanism is intended to not simply respond to such settings but to provide a means of overriding them as well.
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
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`. 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:
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
Rank values in order of importance and be explicit about who this benefits and where the value is.
User Value/Organization Value
Objective it supports and How
FY23-24 APP - Web Team + Logged Out Users
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) 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
