-
Notifications
You must be signed in to change notification settings - Fork 26
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Make collection sidebar sticky and scrollable #1312
Comments
@ggeisler That's a great catch -- turns out to be just a mistake/oversight on our part. I'll get that fixed in our app. Overall, I'd say we really like having the collection/nav context stick and think it enhances the UX. We valued that kind of thing even in our pre-ArcLight finding aids application (2016 blog post). It used to be challenging to pull off across browsers, but these days with |
PR to add this functionality: #1438 |
I'd consider this a UX enhancement more than a bug fix because the collection/component pages currently work acceptably in terms of scrolling, but if and when someone has time I think it's a better user experience when the sidebar remains in-place when the main content area is scrolled. This keeps the sidebar in view and accessible when the user scrolls down longer collection/component pages. Duke's implementation does this and is just what we'd ideally want in core, I believe.
You can't see the sidebar scrollbar in my screenshot above but part of this solution is that the sidebar needs to be scrollable itself, since a content inventory can taller than the content in the collection/component show page.
This only applies to viewports at
lg
and above, since belowlg
we now collapse the sidebar and display it as an off-canvas panel.@seanaery One question about your implementation of this: I noticed that you don't use the sticky sidebar until you get to the
xl
viewport width. So thelg
viewport width has a different behavior (visible sidebar that scrolls with the main content area) than belowlg
(sidebar collapsed) and abovelg
(sticky sidebar). Just curious what the reason for that was, in case it's relevant to how we should replicate your approach in core? (And any thoughts you have about implementing this in core, if you have them - thanks!)The text was updated successfully, but these errors were encountered: