alan-turing-institute / AutSPACEs

Code respository for AutSPACEs: the Autistica/Turing citizen science platform
MIT License
36 stars 18 forks source link

[BUG]: Help page contents list overlaps main text and doesn't scroll #576

Closed llewelld closed 1 year ago

llewelld commented 1 year ago

Describe the bug

On the help page there is a Contents list shown on the page. In desktop mode this positions itself on the left of the page with the main help text to the right.

There seem to be two potential issues with the contents list:

  1. [x] If there are too many items in the list so that it extends beyond the bottom of the page, it's not possible to access the items that are cut off (e.g. no way to scroll the list).
  2. [x] If the width of the page is too small the main help text will overlap the contents list.

Steps to reproduce

  1. Select 'Help' in the menu along the top of the site.
  2. Either reduce the height/width of the browser window until the errors appear; or
  3. Select the Browser's Responsive Design Mode and adjust the viewport height and width to give the same result.

In which environment are you using AutSPACEs?

MacOS and Firefox.

Other comments

No response

gedankenstuecke commented 1 year ago

The user testing found this to be a problem as well, in particular when the viewport is too narrow (e.g. on an iPad in portrait orientation).

There's two aspects to this:

  1. If the viewport is too narrow (left-to-right) to display side-by-side, the navigation should turn into a traditional table of contents on the top
  2. If the viewport is not tall enough, it could either become a scrollable menu on the left or also go to the top
gedankenstuecke commented 1 year ago

Example screenshot of the issue

see screenshot above for an example of the problem

llewelld commented 1 year ago

The problem appears to be that the content-bar (which contains the menu items) has no height. As a result, although Bootstrap tries to position the right hand columns below it when the width of the page gets too small, it positions it on top instead.

llewelld commented 1 year ago

The lack of height seems to be caused by the fact that the bar has its position fixed:

#content-bar {
 padding: 2% 0 0% 5%;
 position: fixed;
}

Removing the position: fixed; "fixes" the issue, but also makes it so that the menu scrolls with the page (rather than remaining on the page).

It's possible this can be fixed by using the @media width declarations (i.e. make it fixed when the page is wide enough, relative otherwise).

gedankenstuecke commented 1 year ago

Thanks for all that investigating @llewelld! The work in #628 is already doing a great job in fixing some of the biggest issues with it! I feel like having the menu scroll would potentially be quite confusing (having 2 independent vertical scroll bars in the same browser window always feels somewhat jarring to me).

Do you think there'd be a way to use the height of the viewport to otherwise force the menu up top like in the fix you did for the overlap?

llewelld commented 1 year ago

Do you think there'd be a way to use the height of the viewport to otherwise force the menu up top like in the fix you did for the overlap?

This is a much nicer solution if we can get this to work.

I've been having a play just now and it seems to be a little tricker because the arrangement mechanism is controlled by BootStrap, plus we don't know how tall the menu will be (at least not in the CSS).

It should be possible to do this with some JavaScript though. I'll persevere.

gedankenstuecke commented 1 year ago

If you want we can do some co-working next week to try to figure it out!

llewelld commented 1 year ago

I'd definitely be up for some co-working (Maybe on Tuesday again?).

One of the challenges is that when the menu is above the text (rather than to the left of it) we don't know what height the menu would be if it were to the left of it, so we don't know whether it'll fit on the viewport to move it back.

We could probably make a guess, but getting it right in all cases could be tricky.

One option would be to render a second hidden version of the menu and use the height of that but... that would probably be horrible for screen readers (and feels a bit too hacky).

llewelld commented 1 year ago

We meay want to refine the approach in future, but maybe we can create other issues in that case. I'll close this one as done following #628.

gedankenstuecke commented 1 year ago

Yeah, that's fab, thanks @llewelld!