I'm super interested in the UI design of really complex applications (like Audacity, or Photoshop, etc.). I would adore some kind of writeup on y'all's design process whenever you towards the end!
(Obviously a big ask for someone already doing a bunch of work for free, pls feel free to ignore me; just saying that I'd be interested :D)
"Dark mode" is not an innovation. It's a half-assed reversal of a regression.
Computers used to show light characters on a dark background. 8-bit platforms often defaulted to white text on a dark-blue background, which until just a few years ago was still available in Word as a checkbox option.
Then the "desktop publishing" craze came along, and brought the analogy of a computer screen to a piece of paper. But this inverse (black text on a white background) scheme ignored the fact that paper doesn't EMIT light. Using these systems was akin to reading the label on the surface of a lit light bulb all day.
But for two decades, Windows let you set up a system-wide color scheme whose colors would be inherited by (nearly) all applications. It was great; you could (and I did, in the early '90s) replace the dumb inverse default color scheme with a "charcoal" scheme... essentially exactly what most "dark modes" are today.
I think Unix GUIs allowed you to set up color schemes too, leaving only the vaunted Mac GUI as the hard-coded,glaring eyeball-strainer of the era.
But now that people are finally realizing that inverse color schemes suck, what did Microsoft do? REMOVE the color-scheme editor from Windows. So now we're being dribbled out "dark mode" one OS, Web page, and application at a time. And it's still hard-coded.
I fully agree that customization regressed, and it's a pity. However...
>paper doesn't EMIT light
Your retina doesn't care if the photons it receives are emitted (as with CRTs) or reflected (as with paper). If you feel like you're staring into a lightbulb, your monitor's brightness is set too high. Set it properly, and, in a well lit environment, your monitor's white should match that of the wall behind it, or that of a piece of paper on your desk.
Even more interesting to me, at least, would be a writeup on how the project came to be in the first place. Long-running open-source projects have a (perhaps unfair) reputation for being somewhere between ambivalent and hostile toward proposals for sweeping UX improvements, and it could be instructive to learn how this initiative got off the ground.
There was an interview many years ago, back when I was a student maybe, but I cannot remember where I read it (best guess is Sourceforge "Project of the Month" which used to be a thing back then at least.
The only thing I think I can remember clearly however was the question about the biggest regret which I think was one particular core datastructure that was an array but which they later wished they had used a linked list for instead.
I found that video fascinating even though I couldn't really related to any of the tools he was talking about since I've never composed music in the past.
Having actually used Audacity and Photoshop, I'd love to learn a bit more about how those design decisions were made.
I've never composed either, but most of his complaints are not about the specifics of the programmes but about how they fail at communicating them. Repetition, omission, modality, hiding, or over-highlighting, are problems that can crop up in any software, and he's teaching you how those are perceived by users.
I'm super interested in the UI design of really complex applications (like Audacity, or Photoshop, etc.). I would adore some kind of writeup on y'all's design process whenever you towards the end!
(Obviously a big ask for someone already doing a bunch of work for free, pls feel free to ignore me; just saying that I'd be interested :D)