Ask HN: When will we stop writing UI by hand? | Hacker News Reader

Ask HN: When will we stop writing UI by hand?

2 pointsmiguelrochefort5 comments

Designing UI is complicated. You need to think about your users and the context in which they will interact with the software. You need to support many different form factors, input methods, preferences, accessibility concerns, locales, etc.

Then, you need to implement it on a bunch of different platforms, all using their own UI framework and tools. It can easily take months to build the UI of a simple app across multiple platforms.

At the end of the day, you end up with a mostly static UI that only supports cases you could predict in advance. Even if your service is top-notch, people might go with a competitor because you don't support their language, or you don't support collapsing discussion threads.

When you think about it, most UI is 'one size fits all'. People got used to that, and most people accept a mediocre user experience because they don't know how to build their owns. The few that are able to build an app that fits their needs, quickly discover the chicken-and-egg problem and end up being the only person using their app and service.

When I talk to people doing UI, nobody even considers that such a thing could be automated. All they look for, are tools that make it easier for them to build their arbitrary UI by hand. This saddens me.

How come isn't UI automated? How come don't people complain about how mediocre most software experiences are? This seems so much obvious that I suspect I might be missing something.

Some enterprise software already works like that (especially to generate Web/mobile/desktop versions from the same code & description).

But I bet you can tell when you look at it that it has been fit to a limited set of templates, instead of each screen being "properly" designed. There is a lot of devel-in-the-details with UI, even if the general style is similar.

And I would argue against software being "one size fits all". Different styles approaches might make software unattractive for some users, but in the same way can be the critical decider towards your software for other users. Look at the mountains of different text editors out there. They all edit text completely fine and have tons of overlapping features, but they still can be a near religious topic.

> Even if your service is top-notch, people might go with a competitor because you don't support their language, or you don't support collapsing discussion threads.

You can't automate support for different language. And other people might use a competitor that doesn't even have threads, because that's their preferred style.

> Some enterprise software already works like that (especially to generate Web/mobile/desktop versions from the same code & description).

Can you name a few?

> And I would argue against software being "one size fits all". Different styles approaches might make software unattractive for some users, but in the same way can be the critical decider towards your software for other users. Look at the mountains of different text editors out there. They all edit text completely fine and have tons of overlapping features, but they still can be a near religious topic.

I meant that software that currently exists is 'one size fits all', and that we should get away from this.

> You can't automate support for different language. And other people might use a competitor that doesn't even have threads, because that's their preferred style.

Not if software can adapt to its user's needs.

> Can you name a few?

I know SAP has internal tools that do that. Can't remember the name right now, but you might be able to find presentations on it online.

> Not if software can adapt to its user's needs.

I haven't seen a forum software that was switchable between threadable and linear in which both views worked well, simply because they are used differently and you miss context if you use a different view.

Why don't you start by describing how your theoretical UI generation would work?

You start with a semantic graph of knowledge.

Then people use the universal query interface to pick a node (abstract or concrete) from the graph.

Then they repeat the step above to pick another node from the graph.

Once they have 2 nodes, they can pick an edge (relationship) that works between those two.

There is your basic interaction, where people can communicate semantic statements.

You can easily expand from there.

Reply on news.ycombinator.com