Page MenuHomePhabricator

Design spec for collapsible sidebar
Closed, ResolvedPublic

Authored By
alexhollender_WMF
Mar 5 2020, 9:49 PM
Referenced Files
F31744400: image.png
Apr 8 2020, 9:36 PM
F31744388: image.png
Apr 8 2020, 9:36 PM
F31744396: image.png
Apr 8 2020, 9:36 PM
F31744386: image.png
Apr 8 2020, 9:36 PM
F31744398: image.png
Apr 8 2020, 9:36 PM
F31744390: image.png
Apr 8 2020, 9:36 PM
F31736953: closed history.png
Apr 6 2020, 4:04 PM
F31736961: Article-SpecialPage.gif
Apr 6 2020, 4:04 PM

Description

Description

Finalize design details for collapsible sidebar

Design details

Latest prototype: https://di-collapsible-sidebar-5.firebaseapp.com/Hathor

Wide screen (1780px)

sidebar closedsidebar opensidebar open on special page
image.png (800×1 px, 82 KB)
image.png (800×1 px, 107 KB)
image.png (800×1 px, 83 KB)

Narrow screen (1280px)

sidebar closedsidebar opensidebar open on special page
image.png (800×1 px, 42 KB)
image.png (800×1 px, 41 KB)
image.png (800×1 px, 40 KB)
Persistence of of open/closed sidebar state
  • For all users sidebar state should persist across pageviews (i.e. if I go from one article/page to another, in the same browser tab)
  • For logged-in users sidebar state should also persist across sessions (i.e. if I close the browser tab, and then open a new one)
  • For logged-out users every session should start with the sidebar closed
Sticky/fixed sidebar

To begin with the sidebar will not be fixed/sticky alongside the content, because doing so creates a slightly more complicated two column interface and we don’t want to make access to language links more difficult. Once we’ve moved language links we can revisit this behavior.

Sidebar animation

In order to avoid weird content reflow issues:
If there is enough room for the sidebar to open without the article content having to move, the sidebar will have an animation. This should be at or above 1420px (the magic number at which the sidebar can open without the content having to move).
If there is not enough room, the sidebar will not have an animation.

Sidebar background

The sidebar background changes based on the width of the page.
Below 1500px: background: linear-gradient(to bottom, #ffffff 0%,#f6f6f6 5%,#f6f6f6 50%,#f6f6f6 90%,#ffffff 100%);
At or above 1500px: white background w/ left border that mimics the gradient above
(I wasn't able to figure out how to get the gradient border to work the way I wanted so for the prototype I ended up putting a gradient background on the parent element, and then making the parent element 1px wider than the sidebar container.)

Open/close trigger/icon

TBD based on closer review of feedback, however considering something like

sidebar closed (hamburger icon)sidebar open (<< icon)
Screen Shot 2020-04-03 at 7.34.00 PM.png (642×829 px, 141 KB)
Screen Shot 2020-04-03 at 7.34.11 PM.png (641×833 px, 184 KB)
Container width & breakpoints

There are three containers. All three containers usually remain horizontally centered within the browser window. The case where they don't is when the browser is less than 1500px wide and the sidebar is open, in which case the content container gets offset to the right.

  • Page container
    • this is the outer-most container, ensuring that on extra wide screens the header contents don't drift too far from the content. The only thing that lives at this level is the site header.
    • max-width: 1650px, padding: 0 30px
  • Workspace container
    • this is in place to ensure that the sidebar doesn't drift too far from the content on wide screens. It also acts as a container for Special page contents that are not limited to the content container
    • max-width: 1440px, padding: 0
  • Content container
    • this is the inner-most container, which contains the article toolbar and article contents
    • max-width: 960px, padding 0

We've discussed whether or not below a certain screen width the sidebar should slide over the content (like how the mobile menu does). At this point I think we can hold off on that functionality. The website will be usable, with the sidebar open, until the screen width gets below ~700px, at which point a horizontal scrollbar will appear.

Page footer

Page footer should be within the workspace container (red dotted line in screenshot below)

Screen Shot 2020-04-03 at 7.49.21 PM.png (441×1 px, 128 KB)

Special pages

certain special pages will not have a fixed-width on the contents container.

Here is an extreme example of how this will look:

Sidebar closed

normal pagespecial pagegif
closed article.png (897×1 px, 365 KB)
closed history.png (897×1 px, 457 KB)
Article-SpecialPage.gif (897×1 px, 306 KB)

Sidebar open

normal pagespecial pagegif
open article.png (897×1 px, 426 KB)
open history.png (897×1 px, 482 KB)
closed Sidebar-Article-SpecialPage.gif (897×1 px, 314 KB)

Event Timeline

👏🏼 for prototype!
If we gonna consider to get rid of gradient – I think that is worthwhile considering, we also need to think about the sectioning design of the sidebar. Otherwise it feels visually a bit lost IMHO.
The animation or not animation could be a per user-setting option. Not a preference, but relying on an operating sys option via [[ https://developer.mozilla.org/en-US/docs/Web/CSS/@media/prefers-reduced-motion | prefers-reduced-motion ]] media query.
With that we would both add animation/transition CSS and also opt-out media feature code.

alexhollender_WMF added a subscriber: Jdrewniak.

@Volker_E regarding animation, @Jdrewniak has come up with a great solution as you can see in the prototype — above 1360px screen width there is an animation, and below 1360px screen width there is no animation. This avoids the weird content reflowing issue associated with animation.

@alexhollender My comment on reduced motion support was targeted at two things:

  • The on/off state by just show/hide seems disruptive to me for majority of our users (we should test this assumption). In all our components and recent products we've follow basic transitions for all cases of showing/hiding elements on page.
  • When such transitions/animations are added by default, at the same time we should add extra code for catering to prefers-reduced-motion

@Jdrewniak I've added details to the description here. Your prototype — https://wikipedia-vue-protoype.netlify.com/p3.html#/en/wiki/Hawaiian_Islands — is getting pretty close. A few things to point out that need to be updated (please reference the task description for details):

  • padding around the content
  • sidebar will not be fixed/sticky to begin with
  • for now we can drop the overlapping sidebar behavior on smaller screens
  • the article toolbar should be contained within the page content area, e.g. this shouldn't be able to happen
    image.png (209×637 px, 67 KB)

@ovasileva @Jdrewniak @Jdlrobson I wanted to call our attention to how the article bar will look with a fixed content width. Below is German Wikipedia with the max-width at 960px. Thankfully there seems to be decent responsive support here, so even if folks have gadgets that result in extra tabs we should be fine. Eventually this situation will be resolved by us moving the search bar out of the toolbar. For now I think we should be mindful of this and keep an eye on it.

fixed-width german.png (371×1 px, 174 KB)

image.png (282×805 px, 54 KB)

@alexhollender yeah, we'll certainly revisit that "more" functionality as we move things around.
Regarding the prototype, I've made the revisions in the comment above and uploaded it to the following URL

https://people.wikimedia.org/~jdrewniak/dip/p3.html

I did also include an idea for the extra-large monitor use-case, where if the screen-width is larger than 1440px, the content is constrained to 66.7% instead of 960px. The math there is 960/1440=66.6667 so it makes a smooth transition from fixed to flexible. That's really just a proof-of-concept at this point though.

@Jdrewniak nice. There are still a few minor issues with the prototype, though I'm not sure if it makes sense to continue refining it, or just wait until we start building the thing for real? Would additional work here further benefit the production effort?

Regarding the width, after thinking a bit more about it I think there's something potentially to be gained by having a consistent width for all readers & editors (of course provided their screen is larger than the fixed-width). I think the percentage-based width looks nice, but to start with I think we should just fix it, regardless of how large the screen gets. I've started writing about this here: https://www.mediawiki.org/wiki/Reading/Web/Desktop_Improvements/First_Prototype_Feedback_Report#2._Establishing_a_common_reading_experience

@Jdrewniak @Volker_E documenting the conversation we had in slack regarding adding a max-width to the outer page container as well, resulting in something like:

1920px browser width (sidebar closed)1920px browser width (sidebar open)
image.png (897×1 px, 382 KB)
image.png (896×1 px, 437 KB)

we could also consider some kind of subtle outline or background to help establish the boundary, e.g.

image.png (944×1 px, 899 KB)

alexhollender_WMF added a subscriber: olga.

@olga @Niedzielski the spec is all set. I'm not sure if we want to copy some parts of the description into T246419, or just include a link to this task.

@ovasileva I've copied the relevant info into the two tasks (T246419 & T246420)