Page MenuHomePhabricator

Proposal: Make collapsible sidebar persistent for logged-out users
Open, Stalled, LowestPublic

Description

NOTE: this is a placeholder for what is likely to be a recurring user request for something the web team has previously judged as a technically unfeasible solution. It should be documented at the end of the Desktop improvements project.

User Story

As a reader, I would like to have a persistent state for my sidebar, so that I don't have to change the state every time I navigate to a new article.

Background

In T246427 we discussed making the sidebar persist for logged out users. The only feasible solutions were 1) inline JavaScript with localStorage (see implementation notes in this task) 2) revisiting Wikimedia cache infrastructure and 3) rebuilding Vector as a single page app.

Generally, we advise against any sort of inline JS in Wikimedia products, as JS is executed on all browsers (even incompatible unsupported browsers), JS errors there can break site functionality and due to our caching infrastructure are difficult to rectify.

We instead decided to make this logged in only as part of T255727.

Inline JS solution (for prosperity)

The following patch demonstrates the localStorage and inline JS approach:
https://gerrit.wikimedia.org/r/c/mediawiki/skins/Vector/+/606436/19/includes/VectorTemplate.php

Technical approach

Prerequisite: T257075: Simplify the checkboxHack API

  • The setting is stored client-side in the browser's LocalStorage service.
  • The setting is loaded right before the sidebar is rendered, thus avoiding an initial flicker if the sidebar would be shown and then immediately hidden.
  • The sidebar is rendered and the setting loaded after the content is loaded, therefore the initial render of the above-the-fold content (first page) is not delayed by initializing the sidebar. That delay is barely measurable anyway.
  • The state saving JavaScript is loaded asynchronously, typically after the sidebar is rendered. The sidebar can be toggled before that logic loads, but saving the state will be delayed until loading is done. This has no noticeable effect on the user experience unless the user very quickly (faster than the full load time) toggles the sidebar and reloads the page. This could be noticeable only on very slow connections and does not represent a beneficial use-case, therefore an accepted trade-off.

Event Timeline

Demian changed the task status from Open to Stalled.Jul 6 2020, 1:41 AM
Demian triaged this task as Lowest priority.
Demian created this task.
Restricted Application added a subscriber: Aklapper. · View Herald Transcript
Demian changed the subtype of this task from "Spike" to "Task".Jul 6 2020, 1:41 AM

Change 608756 had a related patch set uploaded (by Aron Manning; owner: Aron Manning):
[mediawiki/core@master] checkboxHack: Call onChange() callback when checkbox state changes

https://gerrit.wikimedia.org/r/608756

Inb4 @Aklapper: no need for project tags, this would be "in the way" on workboards. It can be explored from the task tree when the need will arise.

Change 607188 had a related patch set uploaded (by Aron Manning; owner: Aron Manning):
[mediawiki/skins/Vector@master] [POC] [modern] checkboxHack: Persist sidebar collapsed state client-side

https://gerrit.wikimedia.org/r/607188

Inb4 @Aklapper: no need for project tags, this would be "in the way" on workboards. It can be explored from the task tree when the need will arise.

If this is about the Vector codebase then it has to have a Vector project tag so it can be found under that project tag.

That's reasonable. Thank you for helping out with exact tag suggestion this time! Please keep that up in the future ;-)

Jdlrobson renamed this task from Make collapsible sidebar persistent for logged-out users to Proposal: Make collapsible sidebar persistent for logged-out users.Jul 6 2020, 9:49 PM
Jdlrobson removed the point value for this task.
Jdlrobson updated the task description. (Show Details)

"State: stalled on decision to not implement this. To be reopened when the bug reports / complaints from readers start piling up." comments like that are not helpful. We've outlined in great detail the challenges with this and making promises about reopening that you can't keep are not in the spirit of collaboration. Point to old tasks if necessary, but be neutral.

We've outlined in great detail the challenges with this

The only person, who outlined a detailed solution with all the challenges addressed was myself. There's no other "outline" on phab, just a few misconceptions without practical basis, which turned out to be false assumptions.
That sentence is a blatantly false summary of what has happened.

I reckon a decision was made without proper research, while ignoring well-thought-through input from a different perspective. My efforts to alleviate the misconceptions were in vain.
The fact is, implementing the server-side persistence has more issues than client-side and for this price only serves a minority of the users.
As the client-side solution would serve logged-in users as well, the more complicated server-side solution is unnecessary. How donor money is spent is not my concern though.
My focus is giving the users what they need / expect, which is outlined and implemented in this task. The two approaches fortunately would be able to co-exists, this one only handling logged-out users.

and making promises about reopening that you can't keep are not in the spirit of collaboration

I think you fundamentally misunderstood my comment.

  1. I didn't make such promise. It's not up to me to decide to include this functionality. Hopefully, that decision will be made by the person responsible.
  2. If I were to make such promise, I would have no problem keeping it: I've already completed this task.

About collaboration: In the 50-100 hours/month work I've been doing since Feb-March I've given plenty of examples about how to productively collaborate.
In return 1) most of my questions go unanswered 2) after I complete all the requests on my patches, most of those are simply forgotten and never merged 3) I've received criticism - usually as unfounded as this one - whenever I've asked that mistakes be reconsidered.

I'd be happy to see some examples of the "spirit of collaboration". I've worked hard for months, patiently, to get to see it. I find this accusation of not being collaborative very disrespectful.
Note that "making promises about reopening that you can't keep are not in the spirit of collaboration" is not just negative and incorrect, but a violation of the etiquette: "Criticize ideas, not people."
This is a repeated case of criticism when bad decision was in the background. I believe an apology would be appropriate.

[Resetting assignee due to inactive user account]