
Ask HN: When will we stop writing UI by hand? - miguelrochefort
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.<p>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.<p>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&#x27;t support their language, or you don&#x27;t support collapsing discussion threads.<p>When you think about it, most UI is &#x27;one size fits all&#x27;. People got used to that, and most people accept a mediocre user experience because they don&#x27;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.<p>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.<p>How come isn&#x27;t UI automated? How come don&#x27;t people complain about how mediocre most software experiences are? This seems so much obvious that I suspect I might be missing something.
======
detaro
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.

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

~~~
detaro
> _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.

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

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

