Sidebar behavior

[MCMaurer]

I think it would be nice to have a sticky navigation bar (stays pinned to the side as you scroll down the page) for a few reasons:

1. Makes the outline more usable as learners progress through an episode, rather than having to jump back to the top, then jump to a section.
2. Makes it more obvious that you can collapse the sidebar to get more space for content once you start scrolling through the lesson. As I got down to actual code blocks I was thinking "ah I wish there was more space so the blocks didn't have horizontal scroll bars", and I didn't realize the side bar could collapse.

Sticky navigation bars pose their own issues, as a really long navigation bar will extend the whole length of the screen, and you can't scroll to the bottom of it without scrolling to the bottom of the whole document. However, I think given the auto-collapse of the episode sections, the navigation bar would probably stay small enough to fit on a reasonably sized-screen. It might even be possible to have the sticky behavior toggle based on page size.

If the tradeoffs with the sticky navigation bar don't make sense, I think two other things would solve the problem as well:

1. Have the sidebar auto-collapse once you scroll past it
2. Have a static, non-collapsing sidebar that has a fixed length, such that content lower down on the page can expand to the full width, like this:

SSSSS LLLLLLLLLL SSSSS LLLLLLLLLL SSSSS LLLLLLLLLL LLLLLLLLLLLLLLLL LLLLLLLLLLLLLLLL

[zkamvar]

At the moment, I want to hold off on major structural changes like this until we have gone through the beta phase (starting in April). The reason being is that this layout has had ~20 hours of accessibility testing put into it and a change like this to the navigation has unknown (to me) implications for accessibility of the lessons (e.g. https://github.com/carpentries/glosario/issues/465 or is that going to be distracting for someone with low visibility or dyslexia).

[MCMaurer]

Totally understood, just wanted to log it here for posterity!

[zkamvar]

I was looking a bit more into this and I think we can control this by using the offcanvas class for the sidenav: https://getbootstrap.com/docs/5.0/components/offcanvas/

You can see some fo the behavior here: https://fmichonneau.github.io/2017-useR-tutorial/proposal/

[trhallam]

I would second that significant improvements are needed for the EPISODE side-pane. Currently I find it a hindrance more than a help when teaching.

My main issue, is that if you collapse the pane, you cannot navigate to any other part of your current page, or Workshop without scrolling to the section of interest, or scrolling to the top of the page. This is a huge time waster and disorienting for students if you need to do it to emphasise relationships between ideas or content that you have covered.

There are also some technical issues with the side-pane:

• Collapse button is only visible at the top of page. If you change your mind about collapsing the pane you have to navigate back to the top to do this.
• If you collapse the side-pane, narrow the browser window until the site moves to mobile view, use the "three bar menu" and widen the side pane again, you cannot get the side-pane back without refreshing the page.
• Clicking on a sub-heading link in the "three bar menu" does not automatically collapse the menu obscuring content at the top of the page.
• Sometimes clicking on a sub-heading link in the "three bar menu" will insert excessive white space between the base of the menu and the top of the page content. This affects <div id="sidebar-col"> where the style height becomes huge (~8200px) in my case. I can usually recreate the error by starting with a wide view, narrowing the view with a collapsed nav bar, and then using the a sub-heading link in the "three bar menu".

[zkamvar]

Sorry for the delay, I do want to acknowledge that I've seen this and I want to manage expectations: this is not an easy problem for us to solve due to reasons of deminished capacity and expertise. The good thing is that it will likely be solved exclusively on the {varnish} side, which means that this is purely an HTML/CSS/JS solution.

The challenge is not in the solution itself, but it's choosing a solution that will allow us to retain accessibility and doesn't rely heavily on a series of JavaScript libraries that are delivered via CDN (at the moment, we load the mathjax library via CDN and then and the local minified bootstrap + feather icons + custom JS). The sites retain much of its functionality without a heavy amount of JavaScript and it would be good to minimize the amount of JavaScript we import, as it increases the weight.