Hacker News Reader

Comment by alex_c | Hacker News Reader

>But the number of your customers who want unbounded complexity is very, very low.

It's worth making a distinction here between complexity and flexibility, which I think some designers / product managers fail to grasp.

Users don't want complexity, but they do want flexibility, especially from tools they use all the time. It's a hard balance to make products that are simple and flexible, but the products that pull it off tend to rule the world. The humble spreadsheet software is the ultimate example.

For example: adding more whitespace and limiting the number of fields on a screen will reduce complexity for users, but it may also reduce flexibility and end up as a net negative. (looking at you FreshBooks, I'm still angry about that redesign a few years back!)

View on HN

> Users don't want complexity, but they do want flexibility

I think Alan Kay said it best: Simple things should be simple and complex things should be possible.

Excel is an example of software not meant for programmers that exemplifies this principle. Doing simple things in a spread sheet is simple, it doesn't take more than a few minutes to learn how to sum up some columns and manage a simple budget in a spreadsheet, but there is still a lot of room for power users to stretch their muscles. (Whether or not some excel power users would be better off hiring a programmer is another matter, but excel has doubtlessly empowered millions of non-programmers regardless.)

Yep, and pandering to the lowest common denominator means that complex things are probably impossible.

Making a complex thing simple is the goal we should strive for.

Edit: I forgot where I was going. Here it is: I don't understand why HAVING TO LEARN HOW TO USE A PROGRAM is such a terrible thing. I remember when there were books for things like Lotus 1-2-3. People learned.

Besides, a blank GUI with 10 kinds of swipe gesture isn't exactly "user friendly" lol.

I think the ideal is when programs are accessible to novices but at the same time provide instruction to those who care to pay attention and hone their skills. For instance, in Excel, when a user uses their mouse to highlight some cells and create a formula, the formula they created with their mouse is shown in the formula entry form, demonstrating to the user how they might have accomplished the same using their keyboard. This introduces users to 'power user' workflows or tools, while not imposing complexity on the users who aren't interested in learning [at that moment.]

Meanwhile, it's not clear to me how a novice is meant to figure out 'three-finger-swipe-to-undo' on iOS but apparently iOS is the poster-child for intuitive friendly design...

I think you should strive for what your customer base wants, if the lowest common denominator is 90% of users, then that should be priority

> Edit: I forgot where I was going. Here it is: I don't understand why HAVING TO LEARN HOW TO USE A PROGRAM is such a terrible thing. I remember when there were books for things like Lotus 1-2-3. People learned.

Lotus probably had 500k users and Excel probably has 500m.

I feel like UNIX tools do this very well.

Setting aside the random naming and inconsistent argument placing, most UNIX CLI tools have sensible default behavior.

But you can man the tool and find a whole bunch of switches etc that offer up a lot of complexity.

The piping system similarly is brilliant. It’s a simple and easy way to make extremely complex workflows using simple tools, but you could spend your entire life never knowing about piping and still do just fine with the individual tools.

I am the biggest fan of Unix commandline tools but I think you vastly overestimate how universal unix pipes are. For example, if I asked you to guess (no reading man pages or trying commands out!) how `find(1)` interprets input supplied to `stdin`, what would your guess be?

Comparing your guess with what you learn from the man pages is an indication of how inconsistent most of the classic Unix tools are.

> how `find(1)` interprets input supplied to `stdin`, what would your guess be?

I'm on OS X here, and I can't find any info about this at all in the man pages! I'd never really thought much about it; usually find is the very start of the pipeline for me. I have run into the -print0 option before though when passing the output into xargs :)

There is a tipping point where my flexibility becomes your complexity. As you say, it’s hard to get right. It’s also hard to know when you got it wrong, since customers overwhelmed by the complexity will choose another product, while power-users clamor for more “flexibility.”

Came here to say this.

It could be summarized simply as: decrease options, increase option depth.

Apple does this very well with its products. From the 'unboxing' experience, down to the dashboard UI's and functions. Every complex function is 'unfolded into', while only the things that are immediately necessary are made obvious.

I made a drawing to help to further illustrate this idea: https://twitter.com/PlanFlowDev/status/1311356383221223424/p...

Spreadsheets are some of the most complex applications I can think of that average computer users are probably familiar with. I don't know if that's a great example.

Reply on news.ycombinator.com