6 ms·

This minimalism fetish is grating. Guess what you need to "just wants to get things done"? Features. If you're in luck, these are standard features, but if not,

This minimalism fetish is grating. Guess what you need to "just wants to get things done"? Features. If you're in luck, these are standard features, but if not, they will be exotic features that would never be built under that "less is more" philosophy. And it's misleading to think that by only implementing the most popular core features, you'll make the most users happy. Projects often rely on those power users using their software, as these same power users will then advertise it by visibly creating great stuff in it and document it on sites like superuser.stackexchange. Not to mention that while every single exotic feature may only get used by 1% of your userbase, chances are most users will at some point need at least one such feature and would get disappointed by its lack. A lot of highly popular contemporary open-source tools are feature-rich. Foobar, Winamp and VLC are all full of stuff you won't need (but what this stuff is depends on you) and extendable. Notepad++ has perhaps the largest number of menu items I've ever seen in a program. Not to mention browsers (whose feature creep is legitimately dangerous, and yet necessary), classic linux tools, office suites, IDEs, PDF editors... Even in the author's example (a sync tool), I'm not sure I agree. Dropbox with its (relatively) minimalist design was fun until at some point it broke for me (getting stuck in an endless sync loop). With some debug info, I may have found the issue and gotten it to work. The way it was, I just switched to Onedrive. A more reasonable rule is probably "don't include features that could be split off into a separate tool without loss of efficiency or functionality".

ghostpepper 7y ago
A great example (IMHO) of presenting the user with only a small subset of the available features is iOS. The tech-literacy bar to make calls, receive texts and install apps is very low, but there are a ton of features hidden for advanced users. Some will complain that these are not discoverable and that’s true but advanced users will often be fine reading the manual and I suppose making them discoverable without confusing the average user is difficult.
- feanaro 7y ago
  Why would it be difficult? Just hide it in an "advanced" menu or something like that.
  - kubanczyk 7y ago
    Because as the bug reports come, you need to care what "advanced option" combination was in play. After fixing you need to test all possible combinations - it's an increase in cost.
    - feanaro 7y ago
      Yes, but that's an entirely different problem then options confusing basic users. If you (as a developer) don't have the bandwidth to handle such use cases, then you don't have it, regardless of whether those options confuse basic users or not. Though, for that particular problem, I think having a UI that produces an automated report for the developer which lists the state of all the relevant options/knobs can improve the situation significantly.
hinkley 7y ago
I’ve been debugging a fair amount of service traffic lately, and I think I’ve about hit breakpoints in all of the major http client implementations in Node. ... Every single one of them has so much delegation (to achieve some fucked up definition of minimalism) that it’s not even funny. And with async await it’s downright maddening. Even in node 12 with the async stack traces flag. I’m taking over maintenance of a service and it’s throwing an unhandled promise rejection that’s a 403 error with a one line stack trace (which is in the wrapper we wrote because the library somehow isn’t minimalistic enough for our tastes). Took way too long to catch in papi. The stack trace is huge, none of our code in it at all, and the request is not even in scope for two or three frames away from where the error is thrown. This is, from a user’s standpoint, an awful library. Anything I struggle to debug, I can guarantee at least a few of my coworkers will bring the same problem to me. Which means I spend three times as much time looking at bad library code as a junior developer would. That fosters a lot of contempt for code that is ugly on the inside. What I really want as an industry is for us to start judging third party code by how sane the stack traces look. This has been bugging me ever since J2EE traces started going north of three pages (with the same series of four frames appearing three times). And sane stacks are going to require us to stop avoiding having a bunch of methods with a single line of duplicated code in them. Quelle horreur! The whole point of code reuse is to reduce duplicated effort not lines of code. Arcane call stacks are huge amounts of duplicated effort, by people already having a bad day. DRY is not worth all the lost hours and energy wasted in debuggers. Do better.
theandrewbailey 7y ago
> A lot of highly popular contemporary open-source tools are feature-rich. Foobar, Winamp and VLC are all full of stuff you won't need (but what this stuff is depends on you) and extendable. I'm not sure if you're implying that Foobar and Winamp are open source. They aren't.
- generationP 7y ago
  Oops, I should have said freeware. (Though I thought of foobar as being OS for some reason -- probably from its aesthetic and design. Winamp, of course, predates the big wave of OSS for Windows.)

ghostpepper 7y ago

A great example (IMHO) of presenting the user with only a small subset of the available features is iOS. The tech-literacy bar to make calls, receive texts and install apps is very low, but there are a ton of features hidden for advanced users. Some will complain that these are not discoverable and that’s true but advanced users will often be fine reading the manual and I suppose making them discoverable without confusing the average user is difficult.

feanaro 7y ago
Why would it be difficult? Just hide it in an "advanced" menu or something like that.
- kubanczyk 7y ago
  Because as the bug reports come, you need to care what "advanced option" combination was in play. After fixing you need to test all possible combinations - it's an increase in cost.
  - feanaro 7y ago
    Yes, but that's an entirely different problem then options confusing basic users. If you (as a developer) don't have the bandwidth to handle such use cases, then you don't have it, regardless of whether those options confuse basic users or not. Though, for that particular problem, I think having a UI that produces an automated report for the developer which lists the state of all the relevant options/knobs can improve the situation significantly.

hinkley 7y ago

I’ve been debugging a fair amount of service traffic lately, and I think I’ve about hit breakpoints in all of the major http client implementations in Node. ... Every single one of them has so much delegation (to achieve some fucked up definition of minimalism) that it’s not even funny. And with async await it’s downright maddening. Even in node 12 with the async stack traces flag. I’m taking over maintenance of a service and it’s throwing an unhandled promise rejection that’s a 403 error with a one line stack trace (which is in the wrapper we wrote because the library somehow isn’t minimalistic enough for our tastes). Took way too long to catch in papi. The stack trace is huge, none of our code in it at all, and the request is not even in scope for two or three frames away from where the error is thrown. This is, from a user’s standpoint, an awful library. Anything I struggle to debug, I can guarantee at least a few of my coworkers will bring the same problem to me. Which means I spend three times as much time looking at bad library code as a junior developer would. That fosters a lot of contempt for code that is ugly on the inside. What I really want as an industry is for us to start judging third party code by how sane the stack traces look. This has been bugging me ever since J2EE traces started going north of three pages (with the same series of four frames appearing three times). And sane stacks are going to require us to stop avoiding having a bunch of methods with a single line of duplicated code in them. Quelle horreur! The whole point of code reuse is to reduce duplicated effort not lines of code. Arcane call stacks are huge amounts of duplicated effort, by people already having a bad day. DRY is not worth all the lost hours and energy wasted in debuggers. Do better.

theandrewbailey 7y ago

> A lot of highly popular contemporary open-source tools are feature-rich. Foobar, Winamp and VLC are all full of stuff you won't need (but what this stuff is depends on you) and extendable. I'm not sure if you're implying that Foobar and Winamp are open source. They aren't.

generationP 7y ago
Oops, I should have said freeware. (Though I thought of foobar as being OS for some reason -- probably from its aesthetic and design. Winamp, of course, predates the big wave of OSS for Windows.)