← Back to context

Comment by noduerme

6 hours ago

Rarely commented upon: It was Windows, with its horrific mess of user settings and sub-settings panels dating back decades, which introduced the idea of just typing in what setting you were looking for and pulling up a list of relevant panels. That was...kind of smart? If you're not going to actually go through and optimize everything? And then MacOS copied it, VSCode copied it... it became the default way to find whatever you were looking for. Need to fix the way your trackpad is working? Here: Instead of spending an hour digging through the mouse and input and keyboard and trackpad and accessibility and all the drivers for everything you own, just type in "speed". Okay, better.

The problem is that this doesn't really fix the underlying issue, which is the bozo explosion of footguns in the UI itself. In fact, it just papers over all the problems.

A good UI needs to be opinionated. And also, getting rid of cruft is at least if not more important than building any new feature.

This happened earlier, with various power-user programs that had hundreds of settings leading the charge. I think TOAD for Oracle had this feature back in the 00s. Or does `grep .vimrc` count, perhaps?

No, a good UI needs to serve the needs and wants of the user - not those of the developer.

  • No, a good developer needs to anticipate the needs of the user. The ones they didn't even imagine. And then fix the system and take out all the garbage.

    • Maybe, the correct approach is not 'predict everything' and not 'have users tell you what they need', but something more akin to:

      1. have defaults 2. have ways to change defaults 3. have dev actually have an interest in the actual workflow, because while you can anticipate a lot, real use case will carry the day

      I played with a 'sound editing software via prompt' the other day, and there was still crazy how much distance there was between 'what i think i want' vs 'what i actually apparently want'.