alt Hacker NewsThe case against complex UI hides the fact that nobody wants to take their time to learn a piece of software anymore. Attention spans are so short, if the system doesn't do all the thinking for you, why bother with it? We are just moving the human laziness through another layer of indirection. The fact never changed in the past 30 years: some domains are complicated and you need smart people on both ends who can bridge the gaps. The dream has always been the same with nocode, lowcode and whatever, it doesn't change this fundamental flaw.
Consider building your own blender software. If you know nothing about 3D you start off in your language and the LLM will happily produce UI for your level of understanding, which is limited. Over time you will reach an understanding that looks just like the software you were trying to replicate.
Currently the ecosystem around UI changes so much, because its always been a solved problem that people just keep reinventing to have... something to do I guess?
Replies
Are you talking about non-business customers?
B2B is a lot more rewarding in this sense. When you've found your power-user any piece of feedback is useful. If it's good enough for them, then the rest typically follows.
This also keeps my motivation when developing UI, because I know someone else cares.
Businesses forgot about this and I ended up a job where I just do whatever my PM says.
> The case against complex UI hides the fact that nobody wants to take their time to learn a piece of software anymore. Attention spans are so short, if the system doesn't do all the thinking for you, why bother with it? We are just moving the human laziness through another layer of indirection. The fact never changed in the past 30 years: some domains are complicated and you need smart people on both ends who can bridge the gaps. The dream has always been the same with nocode, lowcode and whatever, it doesn't change this fundamental flaw.
This has nothing to do with laziness or attention span. 20 years ago you'd have maybe a dozen programs tops to juggle and they were much better designed, because they were made by people who actually use the software instead of some bored designer at FAANG sweatshop who operates on metrics. Now you have 3-5 chat clients, 20 different web UIs for everything on 3 different OSs, all with different shortcuts. And on top of that it CONSTANTLY changes (looking at you Android and material 3).
5 things deserve knowing in-depth: browser (not a specific website, but browser itself), text editor, Spreadsheet application, terminal and whatever else software you use to put a bread on your table.
For any VCs that seriously think I'll invest non-trivial amount of time into learning their unique™ software – you're delusional. Provide shortcuts that resemble browser/vim/emacs/vscode and don't waste yours and my time.
I sometimes have this argument with my Product Owner, despite believing we both want what we individually believe is best for our users. I've tried to suggest that the ideal interface for a power user is not the ideal interface for a novice, and that none of our users should be novices for long as an expectation.
I work on an internal app for an insurance company that allows viewing and editing insurance product configuration data. Stuff like what coverages we offer, what limits and deductibles apply to those, etc. We have built out a very very detailed data model to spell out the insurance contract fully. It has over 20 distinct top-level components comprising an "insurance product". The data generated is then used to populate quoting apps with applicable selections, tie claims to coverage selections, and more.
Ultimately these individual components have a JSON representation, and the "power user" editor within our app is just a guided JSON editor providing intellisense and validation. For less technical users, we have a "visual editor" that is almost fully generated from our schema. I thought perhaps this article referred to something like that. Since our initial release, a handful of new top-level components have been added to the schema to further define the insurance product details. For the most part, these have not required any additionally coding to have a good experience in our "visual editor". The components for our visual editor are more aligned to data types: displaying numbers, enums, arrays, arrays of arrays, etc, which any new schema objects are likely to be built from. That also applies to nested objects i.e. limits are built from primitives, coverages are built from limits. Given user feedback we can make minor changes to the display, but it's been very convenient for us to have it dynamically rendered based of the schema itself.
The schema is also versioned and our approach ensures that the data can be viewed and edited regardless of schema version. When a user checks out a coverage to edit it, the associated schema version is retrieved, the subschema for coverages is retrieved, and a schema parser maps properties of the schema to the appropriate React editor components.
p.s. These patterns might be commonplace and I'm just ignorant to it. I'm a backend dev who joined a new team that was advertised as a backend gig, but quickly learned that the primary focus would be a React Typescript app, neither of which I had any professional experience with.