What I'm now expecting out of docs is a general structure for the comments:
There's a lot of stuff that's not documented, and a CI action like the panic reducing check that ensures we check that functions in the std lib are all documented.
More importantly (but also more difficult) is testing of doc examples a la Rust. It means that a doc reader and we the maintainers can have confidence that docs are at least syntactically correct, as well as understood to work as intended (unless they're transparently marked as not being tested).
The only GitHub issue I can find on this is on ensuring that the docs for builtins match the type of the documented builtin, meaning I don't think there's been work on this. We should get an issue together on this to make sure our "front door" is painted well.
And thanks to @Anton for his feedback as well as Richard for both his feedback and letting me take this on after complaining about one small issue with the old docs. That’s a lot of trust and I appreciate it
This doesn't have anything to do with the doc styling, more just to say that the style of the docs have gotten good enough to slide way down to the bottom of the totem pole for "important stuff to fix on Roc documentation".
it looks awesome, amazing work on it @Anthony Bullard - thank you so much!!! :heart_eyes:
Yes I think that is an important next step.
I think we will need to wait for the next nightly, before the common man can re-generate docs for their packages... at least those of us who use @Hannes GH workflow :smiling_face:
Ok, I will love seeing these docs spreading across the land
I also will run lighthouse again on them from prod and take some notes on needed improvements
Would very much like to move the search items html into a separate doc and transclude it lazily
Stylistic nitpicking suggestions on this:
Sam Mohr said:
Stylistic nitpicking suggestions on this:
- syntax highlighting of search bar results (probably that match the indentation of generated docs, because long function defs can be hard to parse when they text wrap)
- Different sections for types and values/functions
- Type annotation in a tooltip on hover for the sidebar items
- Allowing collapse of a module on the sidebar so I don't have to scroll so far to get to the next module after Num
- maybe a "sturdier" font? This one feels a little thin to me
None of these are hard, and I agree with all of them! The font was something I punted on but I think could help a lot!
other suggestions
@lue that second suggestion is a godsend in the Rust docs!
Oh and the link for the current module name at the top of the main content brings you to https://www.roc-lang.org/ instead of the module-specific docs
lue said:
Oh and the link for the current module name at the top of the main content brings you to https://www.roc-lang.org/ instead of the module-specific docs
Interesting. Didn’t change anything about this. But it shall be fixed
I’ll compile a list of fixes / enhancements into a tracking issue after a couple of days feedback
I can put another week into this. But I also want to work on the compiler at some point :wink:
suggestion:
The opposite case from one of lue
s suggestions; in a tall and too thin window, it'd be nice if the left navigation bar hides to show more of the content. see examples from other docs like ramda or rust docs.
@Hannes Carlsson Sounds like you want the mobile breakpoint to go up to something like 700px instead of only 480px (basically have mobile be mobile AND tablet)
@Anthony Bullard yeah, I think that might do it. I'm not too familiar with frontends, though.
My specific usage is typically that I split my screen between editor, browser and terminal horizontally and the less space I need to give to the browser while still having it be readable the better
For sure
I think that makes sense
Need some Rust help to do the whole "have the type annotation be syntax highlighted" thing
These look fantastic!!
Anthony Bullard said:
Need some Rust help to do the whole "have the type annotation be syntax highlighted" thing
I have some ideas on syntax highlighting for the annotations in the headings specifically
something I want to start doing is to have them become links
I have a branch with progress on that
Could you share? Or do you want to finish it and work on other feedback?
I'll probably just defer to Richard for now and work on these much smaller items
yeah I just need to land that branch, hoping to have some time over the next week to finish it up
Different sections for types and values/functions
Personally I love introducing types in the docs only once they become relevant/used (example). Big modules tend to have lots of types and introducing all of them upfront isn't helpful. Or did I misinterpret the suggestion or how docs are read/specified?
lue said:
Different sections for types and values/functions
Personally I love introducing types in the docs only once they become relevant/used (example). Big modules tend to have lots of types and introducing all of them upfront isn't helpful. Or did I misinterpret the suggestion or how docs are read/specified?
The idea here is for each module has its own sections for types and then functions. And usually a summary at the top
Here's a video showing some of the improvements that I was able to do this morning. Next up: Separating out Summary, Types, and Functions!
After I recorded this, I made a couple other _tiny_ tweaks
Screenshot 2024-12-20 at 8.48.06 AM.png
Got rid of that annoying border for the sub-entries extending oddly up, and aligned it _perfectly_ with the module name
And now works correctly at 200% zoom
Screenshot 2024-12-20 at 8.50.27 AM.png
And 400% zoom
Screenshot 2024-12-20 at 8.51.09 AM.png
For all viewers: there is audio but it is very quiet
Oh really? Sorry, I need an editor :-)
38 messages were moved here from #announcements > New docs template is live ! by Anton.
The zoom changes look great!
I'm not sure about the collapse arrows. It seems like their usefulness does not offset the visual clutter they add. I quite like the changing background on hover, it makes the interactivity of the component clear as well as its boundaries.
I don't have strong feelings either way about the hover, but I agree about the visual clutter on the arrows...what if we only showed the one arrow for the currently-opened module? that was the original motivating use case, after all!
Loving the font!
I was thinking of only showing the arrows on hover, do you think that would assuage your concerns about the Noise @Anton ?
:thinking: how would that work on touchscreens?
Of course not. The options there are to show them on mobile always, or just do what you said before and only have it for the current module
Which I think is fine, but might be surprising to many
That's what it looks like
What is your opinion on optimizing touchscreen usage of docs?
hm, optimizing how?
I see some other docs that have collapsible section in the sidebar retain the affordance on mobile, but they are not sized appropriately for touch targets
ah I see
What I mean is - do you think the touchscreen experience should be equivalent to the desktop
not necessarily
it's okay if some non-essential things don't work on touchscreens
but yeah if we do have them, they should have appropriately sized hitboxes :big_smile:
I guess now we have to agree on whether or not this collapse functionality falls into that bucket :-)
I took pains to make them appropriately sized even on desktop
out of curiosity, did you try having them left-aligned instead of right-aligned?
And that the text highlight happens on the thing that will trigger when clicked
I did not
But I can easily
Thank you flexbxo
yeah I wonder if it might look less noisy if they're more like bullet points
maybe with lower opacity as well?
Here you go!
And Anton had complained about the "fat"(2px) borders, especially here:
Screenshot 2024-12-20 at 2.43.01 PM.png
Here's a version with 1px borders
Screenshot 2024-12-20 at 2.42.38 PM.png
And a version with 2px border only on the left
Screenshot 2024-12-20 at 2.42.18 PM.png
Screenshot 2024-12-20 at 3.05.12 PM.png
Here's a preview of the v3 sidebar if you don't want to open the video
Ticks on the left is a nice improvement I think.
What do we think as a stand-in for Richard's solution? This ended up being easy than I was making it...
Screenshot 2024-12-20 at 4.49.44 PM.png
I'll probably have to adjust the colors in there
One option for the a11y portion is to just lower the luminance of the violet background color to 15%, just like the code background - which avoids some of the washed-out colors when we raise luminance too much in the syntax highlighting pallete
Screenshot 2024-12-20 at 5.00.56 PM.png
I think it's pretty metal with the left-only border (slightly fatter) on the entry names...
Screenshot 2024-12-20 at 5.03.41 PM.png
Sorry I had some time after an early day of work and before christmas break
I like the look of that last one.
I don't have any strong preferences among these, so happy to defer to others' preferences!
Seems like the last design has a good number of fans
I have that work completed locally
I think I'll push that up this morning, and then take on the signature tooltips
I'll hide this so you don't get flashbanged, but this is the light theme of the same:
Light theme
I personally don't love it, but I really don't like light theme in general, so I don't really know how those who do would improve it.
Some good suggestions from Claude for the light theme:
- The search bar could be more prominent and styled consistently with the purple theme
- The "(press $)" hint looks like a placeholder - this should be integrated more elegantly, perhaps as an icon or keyboard shortcut tooltip
The syntax highlighting colors could be improved (those for the dark theme are really good).
The purple background color for the sidebar does not look great. A white sidebar could be an option but that change alone would probably not look good yet.
The search bar would probably look better without rounded corners, making it consistent with the rest
Yeah, I think I'd like to punt on light theme for this PR, but here's what a square search input looks like:
Screenshot 2024-12-21 at 9.15.23 AM.png
Uhu, it needs some additional changes, it's probably not too difficult to find a bunch of inspiration for search bars
But yeah, not needed for this PR
For light... I think it would be good to switch the darker color in the sidebar and the lighter behind the logo/header
Yeah, I've also seen a light theme with a relatively dark sidebar in protonmail
Also the dark purple on the scrollbar and the LH side of the boxes feels very bright and draws attention. That feels a little wrong as they're not important visual elements.
What about this @Luke Boswell @Anton . I have seen a lot of "bare white" designs for light mode that seem to work well.
Screenshot 2024-12-21 at 7.25.35 PM.png
I like it... though now the border around the types is intense... maybe just a light background with a LH side border like the dark mode?
I think all that needs to change is just the border on the LH side only
And maybe the border on the search box... not sure but is that a different color?
To extend what Luke is saying and also what he said a few messages ago, I think we should have a 3-step scale from white to light-violet/purple: the main panel should be white, then the sidebar should be a very light purple, then the logo rectangle in the top-left should be a darker purple
I like the round corners.
I think just a light violet for the search border is nice. Similar to dark mode. It just chills there and doesnt stand out too much
If the top-left corner is lighter than the sidebar as it is in the last demo, it makes the website feel "off-balance"
That's not going to be there (Meant to be a reply)
What's not gonna be there?
Sam Mohr said:
To extend what Luke is saying and also what he said a few messages ago, I think we should have a 3-step scale from white to light-violet/purple: the main panel should be white, then the sidebar should be a very light purple, then the logo rectangle in the top-left should be a darker purple
I tried this and it looked _terrible_
Luke Boswell said:
I like it... though now the border around the types is intense... maybe just a light background with a LH side border like the dark mode?
That's not going to be there
I'll try a different version of what you suggested later Sam
Right now I'm fighting with strange formatter code
Thanks!
I have seen a lot of "bare white" designs for light mode that seem to work well.
That sidebar looks great :)
Last updated: Jul 06 2025 at 12:14 UTC