Change Details

== 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 == Task implemented For logged-out/unregistered AND logged-in users (by @Demian): [[ http://patchdemo.wmflabs.org/wikis/a8e7b5a942abf19e07768dc3024b1fde/w/?useskinversion=2 | DEMO with all header improvements, including drop-down usermenu ]] ([[https://gerrit.wikimedia.org/r/c/mediawiki/skins/Vector/+/589808/31|patch 589808]] + [[https://gerrit.wikimedia.org/r/c/mediawiki/skins/Vector/+/606436/4|patch 606436]]) [[ http://patchdemo.wmflabs.org/wikis/4e1771475b4b2a3d0d84eacd0442e185/w/?useskinversion=2 | DEMO with current state of DI development ]] ([[https://gerrit.wikimedia.org/r/c/mediawiki/skins/Vector/+/606307/4|patch 606307]]) == 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. # 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? 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. ## 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. [[ https://wikimedia.slack.com/archives/G8QAPHCTT/p1582920620169000 | 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?

== 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 == Task implemented For logged-out/unregistered AND logged-in users (by @Demian): [[ http://patchdemo.wmflabs.org/wikis/77898108d535dd96fdeff4c5f13b3d1e/w/?useskinversion=2 | DEMO with all header improvements, including drop-down usermenu ]] ([[https://gerrit.wikimedia.org/r/c/mediawiki/skins/Vector/+/589808/31|patch 589808]] + [[https://gerrit.wikimedia.org/r/c/mediawiki/skins/Vector/+/606436/4|patch 606436]]) [[ http://patchdemo.wmflabs.org/wikis/fb5516c4e28d89ef5cd28e657ff49171/w/?useskinversion=2 | DEMO with current state of DI development ]] ([[https://gerrit.wikimedia.org/r/c/mediawiki/skins/Vector/+/606307/4|patch 606307]]) == 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. # 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? 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. ## 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. [[ https://wikimedia.slack.com/archives/G8QAPHCTT/p1582920620169000 | 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?

== 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 == Task implemented For logged-out/unregistered AND logged-in users (by @Demian): [[ http://patchdemo.wmflabs.org/wikis/a8e7b5a942abf19e07768dc3024b1fd77898108d535dd96fdeff4c5f13b3d1e/w/?useskinversion=2 | DEMO with all header improvements, including drop-down usermenu ]] ([[https://gerrit.wikimedia.org/r/c/mediawiki/skins/Vector/+/589808/31|patch 589808]] + [[https://gerrit.wikimedia.org/r/c/mediawiki/skins/Vector/+/606436/4|patch 606436]]) [[ http://patchdemo.wmflabs.org/wikis/4e1771475b4b2a3d0d84eacd0442e185/w/fb5516c4e28d89ef5cd28e657ff49171/w/?useskinversion=2 | DEMO with current state of DI development ]] ([[https://gerrit.wikimedia.org/r/c/mediawiki/skins/Vector/+/606307/4|patch 606307]]) == 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. # 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? 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. ## 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. [[ https://wikimedia.slack.com/archives/G8QAPHCTT/p1582920620169000 | 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?