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!)

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.)

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.

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...

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

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.

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

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 :)

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...

Sometimes however it is entirely possible to "go sideways" sometimes. This is the Answer to the wuesrion: "Why not both?".

This approach takes however a lot more energy usually. More thoughts and modifications are needed compared to just quickly adding some feature. And sometimes there just might be no solution at all.

But we are talking about software. So even if there is no organic solution that gets you both, it might be totally viable to hide some feature in a "pro user" section in the preferences or something among these lines.

After all most people will not click into the Preferences, but very few power users wouldn't.

20 years, I still dont understand how most developers dont understand. I guess that is the difference between a developer mindset and product manager mindset.

And hence why lots of startups failed.

Look at the tools developers use throughout their careers: Powerful version control systems that support nearly every operation you could imagine. Command line tools with pages and pages of documented switches. Server software with configuration options for every little thing you could ever want to adjust. Well documented open source software that can be changed to your liking with a simple fork. Websites full of fellow developers freely asking and answering almost any question you might have.

When dealing with complexity is the story of your career and you spend 40 hours per week doing this for years on end, it's easy to forget that your customers aren't in the same boat. Most of your customers are using your products to get their job done. They want to learn it quickly, get in, get out, and get back to their work as quickly as possible. They might not even know if they're going to use the same tool at their next job, so taking time to learn it in depth isn't appealing.

As a professional user, I bought a $2,000+ workstation. I expect the applications I run on it to be powerful tools, not toys. But, there are also plenty of other people who run apps on $200 mobile devices who are fine with fewer features. Pick one market and go after it.

> Most of your customers are using your products to get their job done. They want to learn it quickly, get in, get out, and get back to their work as quickly as possible.

This is true, but a missed opportunity. Many people could benefit from more powerful tools to do their work more quickly than currently possible. The "get back to their work" part is the dissonant part; the reason the power tools work for developers is that using those tools is our work, not something we have to leave to get back to it. This should be the case for more people than it currently is. It is not just developers though, there are really powerful tools for a bunch of high-leverage fields, for example image, video, and audio editing, and many different jobs in finance. A lot of the low hanging fruit may have been picked, but I suspect there are huge industries where this sort of thing is still ripe for picking. For instance, I still constantly interact with professionals using awful underpowered tools for their very specialized jobs, for example lawyers, accountants, and teachers.

So may be it's important to understand your target audience.

Of course some people just hate their job and the only thing that makes them happy is the end of the day...

Remember, as someone on this forum, you're on Over Achiever Central.

Devs have to deal with all the bugs and messy codebase

It’s promotion-driven-development.

I generally feel that most things are best when they are in some kind of healthy tension. Appeasing power users happens because it appears to align with both of the above.

We built these empires. But then we get kicked out because stupid people are stupid.

Do we elevate these folks to power user status? No. Instead we stoop to their level, all in service of making more money.

Sick of watching tech (and people) functioning at a tiny fraction of their potential. We could be living in a beautiful world where people bend tech to their will, and not the other way around

First point of complexity that's always being lost: power users aren't born, they're made - made from repeated exposure. First point of nuance being lost: being nice to power users means having features available and discoverable; it doesn't mean you have to clutter your pretty, simple, polished UX with it (and so decide to not do the features in fear of design impact).

Why it matters? Because operating a lot of hot, hip software - like Trello - ends up being a dayjob for many people. If you're sitting 8 hours a day, 5 days a week, for years, using mostly a single piece of software, you're in a perfect position to become power user of that product, entirely effortlessly. If that software is "pandering to power users", then your work speed, quality and reliability will keep going up over time, as you get more proficient and efficient at using the tool. Whether you'll use saved time to rest, to slack off, or to get more work done - that's up to you, but you have a choice, and your employer saves money (whether through increased efficiency or reduced risk of employee burnout). Meanwhile, if the software embraces the "simple use only" principle, you'll just be wasting your life in front of a glorified Fisher-Price toy.

"Power user friendly" really means "leaving space for users to grow".

"stupid people" is also a strawman. There are plenty of smart people out there who just want shit to work. They don't want to fiddle with everything like power users do.

Medical/healthcare professionals are a good example of this.

It’s typically the case that for any powerful tool, any power user might use only 10%, but it’s often a different 10%.

The solution is to design a good on boarding process / learning curve which lets users figure out what subset works for them. Are we going to be forever stuck in the purgatory of having limited tools because the UX has to involve no learning/development (I.e. be “intuitive”)?

Contrast that with many popular SaaS products, which seem designed around capturing a particular workflow and building a shiny structure around it. This allows new users to complete the desired workflow with nearly zero learning - but then they can't do anything else. There's no space to grow.

It feels like a fundamental difference in thinking. Excel is like a box of tools. Initially you only need to drive a few nails, so you grab a hammer and start pounding. Over time, you'll figure out how to use every other tool around your house, swiftly and efficiently. Modern SaaS tooling is like Juicero. Beautiful on the surface, extremely inefficient and wasteful (and to think of all the engineering hours behind it!), and at the end of the day, all you can use it for is squeeze some DRMed juice until eventually the company folds and you're left with an expensive paperweight.

I mean, the number of products I've seen that would be more ergonomic if implemented in, and distributed as, an Excel spreadsheet, is getting too large to even call it funny. Sometimes a smart business embraces this analogy literally. Ever heard of Palisade? They're leading the information security risk modelling market, and their product is literally an Excel plugin. And, having worked in this space, were I a CISO, I'd chose them over the various startups that've been popping up over the years, simply on the grounds of ergonomics.

So by all means, design a good onboarding process. But it's good to have something to onboard people into.

(Excuse the rant.)

This is part of the reason why iTunes beat WinAmp and that other player from Panic. It's why 99% of people buy cars to drive them, not to tinker under the hood on weekends. It's why people will pay for Photoshop and Windows, instead of using GIMP and Linux for free.

GIMP is arguably no more complex than Photoshop, it's just badly designed. And the UX is inconsistent with the look and behavior of pretty much every other app on Mac/Windows.

Popularity is the sum of a number of factors, and simplicity is just one of them. It may not even be the primary factor. I think we've had a bit of a reset, spearheaded by Apple, because bad UX got out of control, but phones are still gaining more features not less. We just have to make sure that the race for features doesn't get too far ahead of the UX teams having time to make it good.

Almost all orgs I know which were at first happy with Trello, eventually had to move to something more powerful. Jira used to be the default choice, but in the last year I see a lot of movement towards ClickUp, which I think has a good combination of simple defaults and powerful customization.

As such, I'd suggest Trello try pandering a bit more to power users - if for no other reason, then because if they don't like your app, they'll advise their less tech savvy friends to stay off it too.

I admire Trello's desire to keep things simple. I think what you're overlooking is that software is eating the world and if people shy off Trello, who cares. They are not going to run out of customers. We haven't hit a plateau of software projects in the world. And people that trade productive effort against the project for power user fun are probably going to hit a point where the burden of their reporting needs on the project becomes visible to everyone doing the work. (If I sound jaded, blame jira).

Usually power users and their dashboards feed back into projects arcane and fragile rules around how tickets are marked, categorized and written all for the better visibility. I think this is a project anti pattern, it's like the song that plays before the death march.

Generally, I think managers are looking for a magic bullet for complex project management. They are thinking that a some uber reporting and dash board vomiting software package will save them. I know it won't.

I have Visio, but I sure do use WebSequenceDiagrams a lot and enjoy the speed it delivers me with it's focus.

Perhaps. But then I feel there's a big hole on the market, something desirable by both individual contributors and product managers. A lightweight ticketing/work planning system that supports certain (arguably fundamental) task management features like:

- Infinite nesting (not just 1 or 2 levels).

- Fast adding of tasks

- Modelling tasks as DAGs, not trees. That is, allowing for proper dependency graph between the tasks.

- Allowing entering both absolute and relative time estimates ("start: 2020-11-01, end: +5 days", and "start: N/A, end: +5 days", where "N/A" means "once all dependencies are complete").

- Turning said task DAG with estimates into a GANTT chart.

- Turning said task DAG into a PERT chart and computing the critical path.

Seriously, the last three are kind of fundamental if you want to do some kind of scheduling around planned work, and yet I haven't seen a single developer-oriented product that could do it. I'm not pulling this list out of my ass - this is what we came up with at my previous job, and we spent time looking for a solution implementing even a subset of this. But for some reason, it's become a religion in our industry that tasks shall form trees, of depth no larger than 2, and GANNT and PERT are for PHB MBAs and not for self-respecting developers. sigh.

If I wasn't a busy parent with a job and a videogame to write, I'd probably write this myself.

Most systems I've seen allow you a one top-level of Task (under some "project", "epic" or whatnot). Then you can - in some - add a kind of degenerated, impotent Subtask to that task. And then your next level of nesting is just a humble bullet-point checklist.

What I want is truly composable Tasks. Because sometimes real-world work expands like that. Because I want to subdivide my work within the ticket I'm assigned to. Because sometimes I don't know how much the entire ticket will take, but I have a pretty good estimate on what the subtasks will take, so I want to input that, and then both me and my manager will have a ticket estimate that's a little bit less nonsense.

The DAG part enters the picture here: I want to be able to have tasks depend on each other. I want to be able to make a top-level ticket depend on a sub-sub item of another ticket, because sometimes your co-worker can start working on their part once you do one small part of yours, and it would be nice to have that information correctly recorded in the system (instead of Task B being blocked by the entire Task A).

(I talked about nesting before, but the truth is, with a DAG, nesting stops being a first-class concept. It's just a matter of presentation, of which you could offer many types - but underneath, it's all just a graph of tasks that connect to each other. A simple and elegant model.)

Now I know that there's a lot of software "agile" philosophy that essentially makes you implement that DAG in your head. No point of cross-subtask dependencies if your agile dogma tells you tasks need to be small. No point in complex linking if half of it won't fit in a sprint, etc. But that's using philosophy as a hack around inadequate tooling.

There comes a time in a team's life where you want to plan out some complex work that spans multiple stories/epics/whatnot. Many months. Tooling for that is scarce (and this is how we discovered the desired features I listed in the previous comment). But I see no reason why you should do that work on a different tool than the one you'll be using for day-to-day work. Imagine instead that, during a planning session, you subdivide work as deep and wide as you can, you link it all into a dependency DAG, enter initial estimates, etc. Then, day-to-day, people will adjust and subdivide and relink nodes as the work demands, but at all times, the entire plan, the entire schedule, and the critical path, is visible to everyone.

That's what I want. A ticketing system that also works for project planning, locking day-to-day work and planning into a tight feedback loop - so that you have both high and low-level views available, and always in sync.

This is what I was wondering about. Please correct me if am wrong. If tasks are indeed modeled using a DAG, then there is essentially no nesting, right? What we think of nesting in the traditional sense can just a bunch of small tasks with varying dependancies.

The metaphor of nesting is a solid one - tree structure does capture a good subset of thoughts about task management. So I'd start with a proper tree of subtasks, not limited by depth[1], and then add the ability to link any other task as a dependency (as long as no cycle is formed).

You could expand the types of edges[2] to allow things like "optional dependency" or "starts when dependant task starts" to model parallel work. But I'd begin with just augmenting a tree with backlinks and surfacing the graph structure. And then providing GANTT charts and PERT analysis. I really do want to have the critical path be always computed and evident to the team, as well as available slack on each task.

--

[0] - I haven't seen a tool like that nor do I have working prototypes, so I'm all playing it out in my head.

[1] - I currently have such proper tree in Org Mode - and my tasklists tend to routinely grow 3-4 levels deep.

[2] - Instead of edge types, you could use node groups. Like, have "Task 3.a.1" represented as "Start of Task 3.a.1" -> [subtasks of 3.a.1] -> "End of Task 3.a.1", but multiple edge types are likely to be much easier to work with.

The most difficult part I think would be to make entering graph nodes ergonomic. In my experience, these kinds of tools live and die by the speed at which you can enter, modify and move things around in them. If you have to click a lot and type data in a bunch of forms, developer won't be using it.

Example: that time when I first compiled the list of desired features, we were trying out YouTrack from JetBrains. My co-worker liked it, but found entering subtasks annoying. I wrote a little script inside YouTrack that turned every Markdown checklist into new tickets, backlinked to the parent one. A total hack, but made a big qualitative difference in terms of working with the tool.

The key two principles for me therefore are:

- Fast to enter and manipulate data in it. Everything doable from keyboard, and little waiting for things to process (hello, Jira).

- Embrace the fact that plans and work subdivisions keep changing all the time. Allow users to restructure their tasks, warn them when they affect other parts of the graph, and just persist the changelog so that a broken graph can be easily fixed.

I have some more ideas in this space, but little time to deal with the surrounding work that's required to turn it into an application prototype.

I still love Trello for its fantastic info architecture, the card interface, and the data I have in it, but I barely use it anymore because it's not as good at organizing as a database, and not as good at scaling to docs and projects as a tool like Notion.

As you mentioned, power-users bork their own data and power-users at big companies bork everyone's data at the company.

Another thing is that exposing an API makes you into a platform, on which third-party developers will try to build businesses. At this point you wind up having a small-scale version of Apple's dilemma. Third-party developers don't want you to encroach on their "turf" with first-party features, but it may be much better for your users if you're the one executing that feature. Third-party developers will try constantly to get you to do their jobs. You'll be locked into backwards compatibility in a way that you wouldn't be if you didn't have an API.

To be clear, this isn't an argument against exposing an API. Power users and their preferences are one thing, but another benefit is the ability to expand into foreign markets by partnering with local entities. If your software interacts with government regulation in some way, for example, it can require substantial interface changes and putting that maintenance burden on a third party more familiar with the government in question is a big win-win. This is especially true when you are in several markets, all with diverging UI needs - an API and local partnerships save you from trying to be everything to everyone.

I'm sure for some codebases this is true but are y'all not just giving customers (basically) the same endpoints you give yourselves/your frontend team to build your 1st party UI?

I wonder what the world would look like if the creators of the spreadsheet had this attitude.

Formulas are awfully complicated, after all - to say nothing of pivot tables...

As an example, Pivot Tables are an attempt at an "easier" UX for a very common sort of (set of) formulas: What is the "summary" here? What does this table look like "sideways", and is that a useful summary? (I've seen spreadsheets with manually built pivot tables in hideous formulas. Pivot tables really are easier than that mess.)

Formulas are what a spreadsheet user comes to a spreadsheet for. So most of the complexity of the spreadsheet "has to be there" for people to consider it a working spreadsheet.

That's a big source of friction for me as a developer because I know when someone asks "Can you make it more like Excel?" they don't mean "can you make an uglier data grid here" they more often really mean "how interested are you in rebuilding Excel's formulas engine, it's charts engine, and maybe it's pivot tables system, and a few other things I regularly use?" but they don't know that they mean it (because they don't understand themselves the tools they use, they just use them). Raw rectangular data grids aren't actually a very useful user experience, and a lot of users ask for them because they are familiar, but also a lot of them ask for them because they've got a head full of unchallenged assumptions that "computers are math machines, I should be able to just insert a formula here" without realizing it. More often than not when a user is asking me "Can you make it look more like Excel?" it's that there is some formula they want to run and asking the follow up questions what formula they think that is is often more interesting/useful than "make it look more like Excel" ever is. At least in my experience.

Power users need “user accessible parts”. Unfortunately we often either don’t scratch this itch, or scratch it with plugins on the server. Which means if I really want a feature, I have to inflict it on everybody on the team, as they inflict their preferences on me.

Having the app behave differently for five users is a bit too much of a combinatorics nightmare and most of us will run away from any such discussion as fast as possible.

With most things there is a middle ground that gets most of the benefit with a fraction of the trouble. I’m not sure I’ve seen anyone find it though. Or at least outside of video games.

I'm the opposite: my life as a dev is already so complex that the less knobs I have to adjust on a new piece of software the better I feel (then of course you'll hear me complain a few days later that if only I had the source of this app to implement this missing feature ;)

That's their own fault IMO. Power users by virtue of their name shouldn't need babysitting.

In practice, you can't simply divide customer problems into self-inflicted and company-inflicted and decline to support the customers' self-inflicted problems. The line between the two types of problems is too blurry to enforce, but the reality is that customers don't care either way. They just want you to fix it, and they expect your product to prevent them from shooting themselves in the foot in the first place.