great!
Can now something be done for the readability of the class names that link to the corresponding doc?
The purple-over-black isn’t exactly the most readable… paired with how thin the typeface is, that makes them hard to read IMHO.
(I have never been a fan of that particular typeface that was chosen since JUCE 4, but that’s subjective, I know)
It would be nice if you would share your plans. What kind of improvements?
There was no vitriol. Nobody was cruel or bitterly criticizing. Quite the contrary. I was extremely constructive and even provided you with an alternative.
That is a severe understatement and has little to do with the truth. It was broken for more than 24 hours and was only fixed because of complaints on these here very forum.
So in other words: everything is as it was before it was broken.
Thank you.
So… web development is happening on a production server…? 
Just in case people are looking for an alternative, I’ve provided my own doxygen JUCE documentation here:
https://juce.refx.com/annotated.html
This will slowly improve (style changes only), but the documentation itself, its structure and search-functionality will stay as long as doxygen can create it.
I welcome any and all feedback on the style. I tried to get rid of all gradients and removed rounded-corners (except in a few special cases).
I have one more idea how to improve this further: a theme switcher at the top, which allows to toggle between light and dark mode. The light more is the current theme (light background, dark-blue for the text etc.). The dark mode would be a dark-grey background with light-grey text. A little less contrast, but good to read at night (on a laptop, tablet or phone) while lying in bed.
Again: any and all feedback welcome.
A reorganisation so that documentation readers aren’t just presented with a huge list of classes. We’ve grouped the classes by module, 404 - Missing Page - JUCE, and, whilst the page could certainly be improved, it’s already a more useful representation than we had previously. We’d also like to present the whole-project examples and the example code in the JUCE Demo example in a much more accessible way, possibly breaking everything up into individual, previewable snippets or something similar. One of our main aims is to improve the experience for people starting out with JUCE.
That’s not constructive. Aside from the documentation one of the most important things that JUCE beginners have fed back to us is that the forum can feel hostile, which makes them reluctant to ask questions. I realise that by the standards of most online forums this one is very friendly, but that’s a pretty low bar! Please moderate your language, even if you are very passionate about something.
We realised almost immediately (before it was reported on the forum) and I put in a quick and dirty fix before we configured proper redirects and requested a Google recrawl later on that day. If the changes took much longer to propagate out to everyone I wasn’t aware of that. I imagine there might have been some caching or something similar happening.
No, classes are now grouped by module and the Doxygen search box has been injected into the top of each page.
No. I should have said “features will appear gradually so we can get feedback from the community”. Given that our staging server is not accessible via Google the broken external links were not flagged up.
No, but also not cruel. Maybe a bit bitter. Sorry, but I was very frustrated.
At least now we have some insight. Why not be more open about this stuff and share more information? These are hardly state-secrets that you can’t talk about.
But it limits the chance to react to things that happen in the real life, because everybody will go “But you promised…”. That is something, every developer working with deadlines will face, you can put softening words like “we try to have it done by x” or “we are not sure if we will finish until x”, it just won’t save you.
People will expect things to be finished and become frustrated, if it wasn’t.
A team needs to be able to reschedule for emergencies e.g. if something seriously needs fixing.
I also wish very often, to at least see the priorities, and what is being worked on and what is on the bottom of the backlog (which is one more time something, a real issue tracker could help). But I definitely understand the reluctance to give estimates and deadlines.
I really don’t understand this. When I said “these are hardly state secrets”, what gave you the idea I was talking about timelines?
I was talking about the ROLI employees should be more open about what they are doing/planning. Just saying “wait until we improve things” is very secretive and non-commital. Simply saying “we’re adding the search back” or “we’re planning on grouping the documentation by modules” would at least give us an idea on what you’re working on.
Just saying “we’re improving things” is so generic that it could literally mean anything. Or nothing. Sharing plans, the more detailed the better, allows for others to comment and thus maybe avoid disasters like the recent documentation debacle.
@t0m just wanted to thank you for reorganizing the documentation so individual classes have their own pace and for the new clear modules page. Only complaint now is that the current modules page has the tree view automatically expanded but that’s probably because I’m just used to opening only the module I need to view. I for one am glad about the documentation change, it’s definitely more browsable at the moment, sorry for being frustrated with a few of the immediate changes!
I like the expanded view because it gives more immediate visibility into the contents of things like juce_core, which doesn’t really give much away from its name. This would be helpful for beginners, but seasoned JUCE users might have to scroll more (or use the search).
