As a Roblox developer, it is currently too hard to access the documentation. As it stands, it’s very difficult to scroll through a bunch of classes contained within the sidebar.
If this issue is addressed, it would improve my development experience because it would be easier and faster to find the information that I’m looking for.
As it currently stands, the only way to access the full list is through the sidebar. The links on the main content area of the page just expands the sidebar categories. Accessing the very long list of classes, datatypes, enumerations, globals, and libraries through the sidebar is long and tedious. Especially when many of the names are wrapped around. Furthermore, the sidebar lists aren’t even broken out alphabetically which adds to the difficulty in finding the needed information.
A proposed solution would be to revert the documentation site to a previous version. Specifically, the two column list that was organized by category and alphabet. An enhancement would be to have each link open up a new tab/window when clicked on, so the page wouldn’t have to be reloaded.
OLD INITIAL POST
I’m having a lot of problems using the new documentation setup here: Roblox API Documentation. The problem is when you select one of the options in the main panel, one of the sidebar options expands. For the main classes list, it’s very difficult and time consuming to scroll through hundreds of classes in a narrow 3-inch panel.
The previous iteration of the documentation where the main panel was populated with everything, organized into two columns, with alphabetical headers was much easier to find things. Now I have to scroll and hope I’m in the right area. If I’m not, then I have to figure out where I’m at and correct my positioning.
@Maelstorm_1973 thank you for the feature request, and congratulations on providing the first Documentation Feature Request!
The documentation site is currently in Beta so we appreciate you staying patient while we work on improvements.
I agree that the API names should not wrap. I have filed a bug internally to resolve this.
In the current state I am seeing that all API are organized in the sidebar navigation in alphabetical order. If you are seeing otherwise please send a screenshot.
I’m curious why you feel this would be an improvement - you can always right click to open a new tab. Most sessions involve navigating from page to page and if every change opened a new tab that could become inconvenient.
Other than the above: when you were scrolling through the sidebar of all API, were you looking for one API in particular? In this case I would recommend to use the search functionality at the top of the page to find the page for that API quickly. Otherwise, please let us know more about how the “main panel populated with everything” page is beneficial to your workflow.
The APIs are listed in alphabetical order, it’s just that there is no division between A, B, C, etc… Perhaps I’m not explaining it correctly. The APIs are not grouped is the best explanation I can come up with. By grouping, you have an A header with all the classes that start with A, the same with B, C, etc…
Not all the pages. Just the ones from the main list. What I like to do is open the main class/datatype/enum list and then open links from that in new tabs. After that it’s just normal navigation. That way I have the main list, plus whatever APIs that I have currently open. It’s not a necessary thing since I can always middle-click on the link to open in a new tab. However, it would sure be convenient.
There are some APIs that I find myself going to constantly. Mainly Players, Player, and Humanoid being ones that I visit often. However, it depends on what I’m working on at the time. If I’m working with animations, then I will be referencing the animation documents quite frequently. If I’m working with sound effects, then the Sound class document will be open. I have tried using the search feature before, and it does work if I know exactly what I’m looking for. But if I don’t exactly know what I’m looking for, then Google comes in handy. As I mentioned previously, there’s 1-2 dozen classes, datatypes, and libraries that I use regularly.
As a systems software engineer myself, my workflow involves plan it out first, experiment, modify the plan, then code it, then test it against all possible scenarios, release for alpha test, release for beta test, then production release. The documentation is most beneficial to my experiment and coding steps.