User Story
As an editor, I would like to have a persistent state for my sidebar, so that I don't have to change the state every time I start a new session
Implementation
T255727: Make collapsible sidebar persistent for logged-in users
T257169: Proposal: Make collapsible sidebar persistent for logged-out users
Task implemented
For logged-out/unregistered AND logged-in users (by @Demian):
DEMO with all header improvements, including drop-down usermenu (patch 589808 + patch 606436)
DEMO with limited content width (patch 607188)
Acceptance criteria
- Make collapsible sidebar persistent across multiple sessions for logged-in users (while they're still logged-in)
- Make collapsible sidebar persistent during a single session for logged-out users (while they switch pages)
- (nice to have) make sidebar globally persistent for logged-in users (across devices, across logging-in/logging-out)
- the user preference is marked as hidden so it doesn't show up on Special:UserPreferences
Note on default states
INITIAL STATE: sidebar is default on for all users
EVENTUAL STATE: sidebar is default off for anons, default on for all other users
Developer notes
For persistent state we have several options - localStorage, cookies and user preferences. Given we do not want reflows for users user preferences seems like the correct and only choice here. (EDIT: reflows do not affect proper implementations)
Risk 1 - user preference may not save.
owever there is a change on slow connections that an update to state is not completed before the user navigates to a different page. In that situation e.g. hamburger is clicked and then menu item is quickly clicked the menu may appear collapsed.
Risk 2 - multiple saves? (only server-side solution)
We'll likely want to update the hidden user preference on every click to the hamburger click. If some users keep clicking it in the same session this will result in multiple HTTP requests. We likely want to debounce the saving for at least a second, but that will increase the risks of 1.
Risk 3- future anonymous support?
Note if we ever need to make this work for anonymous user's we'll likely to have to rethink this whole idea. It won't work in that situation.
EDIT: The client-side implementation for logged-out users can be integrated with the server-side implementation for logged-in users.
Alternative?
Some editors might prefer an explicit "Always show menu expanded" as this avoids all the risk above.
Questions
- What does "globally persistent for logged-in users" mean? Across all wikis (e.g., GlobalPreferences), simply persistent across all sessions, or something else?
- Do we need per device awareness? E.g., on a tablet, maybe an editor's preference is to hide the menu by default but on a large monitor to show it by default. On the Android native app, we built a similar feature that would sync user options across devices (like GlobalPreferences) that some considered an anti-feature since they wanted different preferences on different devices.
- What are the tradeoffs? The risks (cons) are identified above but what are the pros of each? Some further discussion may be useful if it hasn't been had already. Slack notes.
- (Covered by risk 3 but framed a little differently) If latest mode is enabled on a wiki by default for anonymous users, is it considered a nice-to-have feature to support this collapse state option for anons or would it be unused?
- How is this setting changed? The AC says "the user preference is marked as hidden so it doesn't show up on Special:UserPreferences" so is this toggled by interactions with the sidebar? Is that a good idea or should we consider a default preference state and a session (across pages) state distinctly?
Spike outcome
Jan shared the following presentation:
After considering all the implications we decided to limit this to T255727 for now.