API doc site has too many scroll bars

Questions
#1

The API doc pages are kind of a nuisance to navigate now, with two different scroll bars. It’s a nice idea to have the table-of-contents sidebar stay put, but the actually functionality is a mess. It was better without it.

Keyboard and mouse navigation are both a pain now, changing based on where your mouse cursor currently is, or where you last clicked…

Most of the time you can’t see the top, bottom, or the handle of the inner scroll bar, so you can’t tell where you are in the doc. When you hit one end of the inner frame then you start scrolling the outer one, which throws everything off.

Nested, scrolling frames are just a bad idea.

9 Likes
#2

Thank you for the feedback. We made this change as we thought it made sense to try and keep the left menu visible at all times.

2 Likes
#3

Oof, guess I haven’t been to the API page in a while, but yeah, I agree with Ross here.

It reminds me of Freshdesk, which I am forced to use every day for work (it’s way worse, though, with the email composing frame taking up at best like 1/4 of the whole screen, overlapped with other stationary frames, when composing the email is the only thing you generally even care about…)

Any time you can mouse-wheel in a frame to the point that the scroll bar for the frame your wheeling in has been wheeled out of view…

2 Likes
#4

but in other learning section there is no double scrolling. A sameness is one on the basic UI principle. Please, make API ref the same as examples, manuals, etc.

#5

Thank you for the feedback. I’ve added a note to see what we can do to solve this.

By the way: If anyone has examples of API reference documentation that you really like then please share it here for us to be inspired by!

#6

I agree with Ross. Two scrollbars are confusing, and they are hard to use.

P.S.
Possible fix: set position: fixed for the left column, and margin-left: (width from left)% for the right column. Plus, remove scrollable from the right column classes.

2 Likes
#7

Yeap, scrolling frames is a bad idea :frowning_face:

2 Likes
#8

I seem to be on the opposite side of the spectrum, where I think it’s bad when the menu “scrolls away” with the rest of the content, and I have to scroll all the way back up in order to get to the menu again.

Here’s an example what I’m accustomed to when reading API documentation. An expandable TOC to the left. And a content area to the right:
https://docs.unity3d.com/Manual/Joints.html

1 Like
#9

This is correct and good example. There is a main scrollbar for content zone and small scrollbar for menu zone. I like it. Unlike the Defold API reference where main scrollbar works for all page and the content has a small bar, which slider is permanently hidden over the page outside :confused: So, to scroll up to table of contents we need to scroll both scrollbar.

p.s. when you use Mac touchbar with fingers gestures it’s not so pain than when you use a mouse.

5 Likes
#10

+1

I did not notice this change because I always use offline api reference (with Zeal) but I agree the double scrolling is not good. There are other ways to have a main menu more always available.

These kinds of docs have an always visible side menu while still having the main content its own view

https://hexdocs.pm/phoenix/Phoenix.html

#11

Another example… from Firebase
https://firebase.google.com/docs/reference/swift/firebaseauth/api/reference/Classes

1 Like