Page MenuHomePhabricator

Consider making the new sidebar sticky/fixed
Open, MediumPublic

Description

Description

As part of the Desktop Improvements project we are making the sidebar menu collapsible. This presents the opportunity to think about other possible improvements or modifications to the sidebar's behavior. One idea that seems worth considering is making the sidebar sticky/fixed, such that it remains in-view as you scroll down the page. This behavior can currently be enabled via the FloatSide script (link).

Rationale for sticky/fixed
The sidebar menu is currently only available towards the top of the page. Giving people access to the menu regardless of where they are on the page would increase the utility of the menu.

Rationale against
In cases where the content of the sidebar menu are taller than the height of the screen the sticky/fixed sidebar would need to be able to scroll independently from the page content. This results in an interface that is more complex than the current one (two scrolling panes vs. one) which is not worth the possible additional utility. Additionally, in cases where people need to scroll the sidebar in order to reach menu contents below the fold those contents may be more difficult to access than they currently are.

Current plan

Wait until we 1) release the collapsible sidebar, 2) move the language links out of the sidebar and then revisit this.

Mockups/prototype

Sticky: https://di-collapsible-sidebar-2.firebaseapp.com/Lute
Scrolling: http://patchdemo.wmflabs.org/wikis/197e628bad08d9ea6ab286c6db366fe7/w/index.php/Main_Page (Code: Gerrit - 2 patches)
Scrolling with old layout: https://patchdemo.wmflabs.org/wikis/a880d24935e8a058b27dde56e6066f6b/w/ (Leaner code: Gerrit)

Details

Event Timeline

Restricted Application added a subscriber: Aklapper. · View Herald TranscriptFeb 20 2020, 12:30 PM
ovasileva renamed this task from [EPIC] Deploy collapsible sidebar to all test wikis to [EPIC] Build collapsible sidebar and deploy to all test wikis.Feb 20 2020, 12:32 PM
ovasileva triaged this task as Medium priority.
ovasileva raised the priority of this task from Medium to High.
Demian added a subscriber: Demian.
Demian added a comment.EditedFeb 20 2020, 2:56 PM

@ovasileva wrote:
Sidebar scrolling (nice to have)

For a quickstart to whomever implements scrolling: feel free to adapt the CSS I wrote for WikiZero's to have a neat scrollbar:
https://userstyles.org/styles/179278/wikizero-toc-always-on-screen (click Show CSS code)
Sample screenshot included, that I don't want to take up space here.

There are some intricacies to scrollbars, I hope this helps save some dev time. If it comes to that I'd be happy to adapt it for Vector.

ovasileva updated the task description. (Show Details)Feb 20 2020, 2:58 PM
ovasileva updated the task description. (Show Details)Feb 21 2020, 3:15 PM
ovasileva updated the task description. (Show Details)Feb 21 2020, 3:18 PM
ovasileva updated the task description. (Show Details)Feb 21 2020, 3:35 PM
ovasileva updated the task description. (Show Details)Feb 26 2020, 12:28 PM
ovasileva updated the task description. (Show Details)
nray updated the task description. (Show Details)Feb 26 2020, 5:30 PM
nray updated the task description. (Show Details)Feb 26 2020, 5:35 PM
Niedzielski updated the task description. (Show Details)Feb 26 2020, 5:35 PM
Niedzielski updated the task description. (Show Details)

Instant question on acceptance criteria “sidebar should be sticky” – when the sidebar would be sticky, we'd end up with two vertical scrollbars (in sidebar and main content) when canvas height < sidebar height, which seems relatively common. Are we set on this?

Jdlrobson updated the task description. (Show Details)Feb 26 2020, 6:14 PM

Instant question on acceptance criteria “sidebar should be sticky” – when the sidebar would be sticky, we'd end up with two vertical scrollbars (in sidebar and main content) when canvas height < sidebar height, which seems relatively common. Are we set on this?

Agreed that scrollbars would not be okay. Would there be a way of avoiding this? Maybe have some max length of the sidebar and if it goes above that it's no longer sticky?

ovasileva updated the task description. (Show Details)Feb 27 2020, 1:23 PM
alexhollender added a comment.EditedFeb 27 2020, 3:44 PM

Instant question on acceptance criteria “sidebar should be sticky” – when the sidebar would be sticky, we'd end up with two vertical scrollbars (in sidebar and main content) when canvas height < sidebar height, which seems relatively common. Are we set on this?

In cases where the contents of the sidebar are taller than the screen having a scrollbar on the fixed sidebar is a natural result. Dependent upon user settings the scrollbar will only become visible when someone is interacting with the sidebar element. If we want to we can style the scrollbar (supported by all webkit browsers) to make it more subtle (https://webkit.org/blog/363/styling-scrollbars/) Example from Gmail:

Check out the prototype if you haven't already: https://di-collapsible-sidebar-2.firebaseapp.com/Lute

I feel that we're not fully clear on the added value behind making the sidebar sticky. IMO we need to be clear on why the top items in the crowded sidebar get more importance (sticky) than links further down. Three concerns on sticky:

  • We'd be breaking common user interaction patterns of one-column scrolling, like ctrl+page-up/cmd+arrow-up
  • Making language list easier discoverable comes later in the project and it's probably among most used links section (data?), which is harder to scroll into (you'd need to move your link into smaller area)
  • Sidebar links are a weird per-project collection and it's not clear at all that most important ones are on top, where fixed sidebar would be preferable

Additionally on a technical level, scrollbar appearance is on many GUI systems still underwhelming and customizations are hard and non-standard. Means, they might look terrible in small space additionally to all user-experience concerns.

Demian added a comment.EditedFeb 27 2020, 9:31 PM

Agreed that scrollbars would not be okay.

Scrollbars are commonly used for sidebars and better than having to scroll the whole article when looking for a specific link on the scrollbar. If done well it's subtle and convenient. Please see Discord for a great example, or try the userstyle for WikiZero I've posted in the first comment to see the difference with or without scrollbar on a page with long sidebar content and try WikiWand to see scrolling is usable even without a scrollbar, though it's up to the user to recognize there's more...

I feel that we're not fully clear on the added value behind making the sidebar sticky. IMO we need to be clear on why the top items in the crowded sidebar get more importance (sticky) than links further down.

Tl;dr: the reason for not seeing added value is that the site-navigation sidebar has in itself very little added value. Editors and readers are often asking for solutions to hide it.
What has added value is the TOC, the best solution would be to show the TOC on the sidebar and optionally - when the user clicks the navmenu icon -, show the site navigation (current sidebar) instead of the TOC. This is a requested feature on the DIP page, it seems this is the last time that can be effectively discussed.

Three concerns on sticky:

  • We'd be breaking common user interaction patterns of one-column scrolling, like ctrl+page-up/cmd+arrow-up

FYI Ctrl+PGUP in Chrome and most browsers will go to the tab to the left. Do you mean simple PGUP?

  • The scrolling behaviour won't be broken. As long as the main (content) column is focused, PGUP will have its effect there.
  • If the user clicks inside the sidebar, it's expected that PGUP will affect that area.
  • If the user clicks a link inside the sidebar (assuming site navigation is in the sidebar) a new page will load and focus returns to the main content.
  • If the user clicks a link inside the sidebar TOC, then it is unexpected (not breaking tho) that focus (and PGUP scrolling) stays there, but easily fixed with an onclick handler that returns focus to main.
  • Making language list easier discoverable comes later in the project and it's probably among most used links section (data?), which is harder to scroll into (you'd need to move your link into smaller area)

The DIP page suggests me with numerous examples that the language list is moved to a drop-down in the top-right corner. Is this concerning the special case of no-js runtime?

  • Sidebar links are a weird per-project collection and it's not clear at all that most important ones are on top, where fixed sidebar would be preferable
  • If projects put their important links not to the top, that's their own problem. Why would they?
  • The bottom links are obscured in Vector, anyway. By the time a reader scrolls down, their focus is on reading the content, not the sidebar. These "concerns" also apply to the status quo.

Additionally on a technical level, scrollbar appearance is on many GUI systems still underwhelming and customizations are hard and non-standard. Means, they might look terrible in small space additionally to all user-experience concerns.

Don't even consider defaulting to the default (system) scroll-bar, that would be terrible indeed. That's why I posted a ready-made solution above.

Change 576170 had a related patch set uploaded (by Aron Manning; owner: Aron Manning):
[mediawiki/skins/Vector@master] [POC] Make sidebar scrolled

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

alexhollender renamed this task from [EPIC] Build collapsible sidebar and deploy to all test wikis to Consider making the new sidebar sticky/fixed.Mar 5 2020, 9:00 PM
alexhollender lowered the priority of this task from High to Medium.
alexhollender updated the task description. (Show Details)

@Volker_E @ovasileva @Demian apologies for the phab spam and potential confusion. I have renamed and rescoped this task to specifically be about whether or not the sidebar should be sticky/fixed. The epic is now T247032.

@Volker_E thank you for your comments in T245734#5924285; these are great points. I do agree that two scrolling columns is more complex than one, even if two columns is a fairly common pattern. I also agree that we don't want to make the language links more difficult to access. I think we can defer this decision until after we've moved the language links, at which point the sidebar contents will be shorter, and will probably fit entirely into an average screen (with no additional scrolling needed).

@Demian thank you for all of your comments, reference links, and the prototype. These are all quite helpful. I do think there is a bit of a catch 22 situation here where the sidebar links currently are not very valuable, therefore fixing the sidebar doesn't seem very useful. However there's also the possibility that if we did make the sidebar fixed/sticky then communities would reconsider which elements are in there, potentially leading to better maintained lists of sidebar links across various wikis.

I also wanted to introduce another pattern I've seen recently on the updated Twitter desktop site (you need to be logged in). It's an interesting combination of a sticky sidebar but a single scrolling column. The sidebar scrolls with the page, until it reaches the point where the bottom-most contents are visible at which point it sticks. As soon as you start scrolling back up the sidebar un-sticks and scrolls with the page again. I can't figure out how this would be possible without js. I haven't had the time to prototype it yet, however here is a GIF that describes the behavior:

@Demian thank you for all of your comments, reference links, and the prototype. These are all quite helpful.

Parts of the proto can be turned into patches for the decided-upon functionality with some renames and refactoring.
I've updated the patch with the scrollbars refactored to mixins, that's written with the final product in mind (reuse demonstrated on the main scrollbar).
Tell me if you need any part in some form.

I do think there is a bit of a catch 22 situation here where the sidebar links currently are not very valuable, therefore fixing the sidebar doesn't seem very useful.

There have been many requests to completely remove the sidebar or replace it with TOC. I don't see these being discussed, which I think we should do. A TOC for ex. changes the use-case significantly, a wider sidebar is required in that case and TOCs can also get pretty long, see https://www.wikiwand.com/en/Wikipedia where the benefit of a sticky sidebar is more clear.

Personally I would show SiteNav (current sidebar) only on the Main_Page and TOC on all others. Thinking:

  • Reader opening ??.wikipedia.org is most likely to navigate to a specific page, thus use SiteNav. TOC on Main_Page would be short and unnecessary.
  • Reader opening a specific page is most likely to want to read that page and navigate inside the page, thus require the TOC.

Alternatively, I would make the sidebar tabbed with TOC primary, SiteNav secondary. In this case, tabs would have different widths. I'll submit a demo for this.

This would make space to develop such gadgets / extensions like:

  1. Editing tools tab
  2. Bookmarks tab
  3. Advanced gadget tab
  4. Admin tools tab, etc.

@Demian my apologies for forgetting to address your comments about the TOC — I meant to respond to that.

Yes, we definitely agree that experimenting with a persistent TOC, and/or a TOC that is accessible as a menu from anywhere on the page, is worthwhile and will be part of this project. I don't think we need to discuss it further as part of this task (though I totally understand why you brought it up here). Please lookout for discussions specifically regarding the TOC in the upcoming months, or I will try to remember to ping you once those tasks/explorations get created.

[The TOC] I don't think we need to discuss it further as part of this task (though I totally understand why you brought it up here). Please lookout for discussions specifically regarding the TOC in the upcoming months, or I will try to remember to ping you once those tasks/explorations get created.

Thank you! It seemed reasonable to discuss the TOC before the sidebar where I believe it would be best placed. I'll follow up on further discussions. Note: the information circulating between developers about these plans (timeline, what will be done) is not available to us volunteers, so I'm sorry in advance for starting misplaced / mistimed discussions ;-)

[The TOC] I don't think we need to discuss it further as part of this task (though I totally understand why you brought it up here). Please lookout for discussions specifically regarding the TOC in the upcoming months, or I will try to remember to ping you once those tasks/explorations get created.

Thank you! It seemed reasonable to discuss the TOC before the sidebar where I believe it would be best placed. I'll follow up on further discussions. Note: the information circulating between developers about these plans (timeline, what will be done) is not available to us volunteers, so I'm sorry in advance for starting misplaced / mistimed discussions ;-)

@Demian - fyi - the sequence in which we plan on building the features is published here. Of course, there might be some changes as we go along, but this reflects the plan as it stands currently. We'll be updating that page as we go along as well as publishing more detailed info on each feature once initial feedback rounds are complete. Hope this is helpful!

Demian updated the task description. (Show Details)Thu, Mar 12, 9:02 PM

In cases where the contents of the sidebar are taller than the screen having a scrollbar on the fixed sidebar is a natural result. Dependent upon user settings the scrollbar will only become visible when someone is interacting with the sidebar element. If we want to we can style the scrollbar (supported by all webkit browsers) to make it more subtle (https://webkit.org/blog/363/styling-scrollbars/)

Since November 2019 there is a standard way, already supported by Firfox and Edge (WebKit coming soon): https://css-tricks.com/almanac/properties/s/scrollbar-width/

I've made a demo: http://patchdemo.wmflabs.org/wikis/197e628bad08d9ea6ab286c6db366fe7/w/index.php/Main_Page (Code: Gerrit - 2 patches)
And a patch to include the mixins in core/../mediawiki.less: https://gerrit.wikimedia.org/r/c/mediawiki/core/+/579414
Please see if that patch can be merged.

Change 579414 had a related patch set uploaded (by Aron Manning; owner: Aron Manning):
[mediawiki/core@master] Add scrollbar Less mixins in common include path

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

Change 579620 had a related patch set uploaded (by Aron Manning; owner: Aron Manning):
[mediawiki/skins/Vector@master] Add scrollbar Less mixins

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

Demian updated the task description. (Show Details)Sat, Mar 14, 10:08 AM
Demian updated the task description. (Show Details)