-
Notifications
You must be signed in to change notification settings - Fork 54
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
Navigation of API Pages #54
Comments
And to make that contents-listing even more useful, it would be great if it were sorted alphabetically instead of what seems to be a rather subjective relationship-based way, which can make it quite hard to look for a specific attribute, especially if you're not entirely sure of the exact name or meaning. And when I look at the properties of e.g. |
So, should it be completely alphabetical? Or should some things (like sub-types, enums) be hoisted towards the top/bottom? |
I would suggest grouped by member-type, and completely alphabetical within those groups--so methods and functions all together, in alphabetical order; enums all together, in alphabetical order; and so on. |
That's what I would prefer too, if possible. As for what goes where, I'd place those things that are smaller in number above those of which there are more (on average), which should require less scrolling to the bottom to find something in particular. |
I believe we can use the autodocsumm extension for this. |
Looking at the page for the NodePath class, navigation seems a little inconvenient to me:
For one, there's no contents listing to allow quick-skimming of member-names. If one already knows the name of the member in question one can, of course, just use a browser page-search to find it. However, if one doesn't, one can only scroll through the page, for potentially some distance, in order to find it.
And for another, there's no clear delineation between methods, variables, and enums. This further reduces the ease of seeking through a given page.
What I suggest, then, is this: that API pages include a contents-listing near the top, which would hold only member-names, and which would be separated by member-type (i.e. method, variable, enum, etc.). This should, I hope, allow for easier skimming and seeking in the API.
The text was updated successfully, but these errors were encountered: