Preference Persistence For Anonymous Users
edit
Problem Statement Artifact
Project Owner
|
Mohd Abualruz
|
Email
|
mabualruz@wikimedia.org
|
Submission Date
|
Mar 22, 2023
|
Phab Link
|
https://phabricator.wikimedia.org/T333867
|
Deadline for Decision (Date or Date Range)
|
May-June 2023
|
Problem Statement Review Meeting
|
30th March, 2023
|
Problem Statement Sent to TDF Reps for Feedback
|
5th April, 2023
|
Problem Statement Feedback Review
|
|
- Define the problem or opportunity (WHAT).
- Outline the importance of addressing the problem or opportunity (WHY).
- Technical Forum Chair Review.
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
|
What happens if we do nothing?
edit
- 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:
- 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
|
Identify the value(s) this problem/opportunity provides. Add links to relevant OKRs.
edit
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:
|
- 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?
edit
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
|
Technical Forum Chair Review
edit
This is to be filled out by theTechnical Forum Chairs.
|
Yes
|
No
|
Is the problem statement clear?
|
X X
|
|
Should this decision go through the Technical Decision Making Process?
|
X x
|
|