feat: add table of contents and remove accordion functionality

[blittle]

Table of contents is a simple list of links on the right side of the page. It disappears altogether on mobile (similar pattern as Wikipedia). It is not sticky on scroll (making it sticky will be tricky for components like button that have a lot of concepts and will require a nested scrollbar.

Right now this only shows up on the Analysis pages, but I could change it to show up on all the pages.

Resolves: #289

[gregwhitworth]

Thanks for the PR @blittle - I'm not sure how I feel about having the two sets of navigations on either side. @ststimac has worked on some design comps. Stephanie any chance you can weigh in here because while I think it's helpful I'm not sure how I feel about it in general.

[una]

I personally like having a table of contents for easier navigation, but RE: @gregwhitworth's comment, I'd like to hear from some of the folks who've looked into rearchitecting this UI

[blittle]

@gregwhitworth agreed, I was unsure about it. I'm happy to implement a better UX. One thought I had was to just put the map of links inline at the top of the page? The thing is that the list of links can get very long.

[ststimac]

Yes, not a fan of the secondary ToC on the side there...a bit confusing but perhaps a dropdown that links to the different sections at the top or something? Let me think on this and look into some documentation heavy pages.

[ststimac]

I've looked over a few documentation heavy examples of websites and I see an iterative set of changes to make:

1. if we want to keep the table of contents / navigation as it is for the time being, the accordion that's currently on the right side of the page in this PR, becomes a part of the left menu and would just be underneath each component. Only open and visible for the component that is selected. I can do a quick mock if that isn't clear?

2. A lot of the sites I looked at had the main navigation across the top and then a table of contents on the left hand side. I need to go back and look at notes from the discussion around re-architecting the navigation and where we moved things but I think only having the component list visible when you're in that section of the site will help reduce a lot of clutter and cognitive overload.

So # 1 is my proposed solution for this PR and # 2 is a larger proposal for the whole Nav / TOC that would be addressed in another PR.

Thoughts? Yes/no? @gregwhitworth @una

[gregwhitworth]

I really like option number 2. @blittle @una ?

[blittle]

@ststimac I do think reworking the whole navigation, more along the lines of 2, makes a lot of sense. For 1, part of the problem is the quantity of items on that left menu. Right now it is actually screwed up on slightly lower resolution devices, where if the content on the right doesn't cause the page to scroll, the navigation on the left gets cut off (when too long). So if we add more content to the left nav, we need to fix the overflow/scrolling.

[gregwhitworth]

Closing due to inactivity