Comment by miguelrochefort | Hacker News Reader

Comment by miguelrochefort | Hacker News Reader

Parent Full thread

miguelrochefort

I've been building consumer apps professionally since 2013 on iOS, Android, Windows Phone and the web. I also spent a few years designing and implementing UI frameworks. I've had to deal with all of the problems listed in Dan's article (with and without frameworks).

Over the years, I have grown convinced that designing and implementing UI by hand simply doesn't scale. There are too many things to consider, too many different users, too many preferences, too many possible states. Responsive design isn't just about screen sizes anymore, it's also about the user's language, culture, disabilities, input, context, preferences, connectivity, knowledge, focus, etc.

We can't expect every restaurant, bank, festival and airlines to implement their own apps, and consider all of the above. You won't find a dark theme in the Domino's app. Why do we tolerate these compromises in the name of branding? Why should UIs be tightly coupled with the services and data? Why don't we have general purpose clients?

I think the job of service providers should be to semantically annotate their data, so that a general purpose client can dynamically render it. All of these UI concerns would only have to be dealt with once, and we all would be able to sleep at night. Just let business people do business, and let UI/UX people do design.

How does that scale? It's more than just 'branding' or pretty colours. What about actual featureS? There's the standard say there's the standard 'airline' app, that handles booking flights and then the lifetime of managing that booking. Reserving a seat and so on. Airlines build the data and the APIs, OS vendors (?) build the frontends.

Then Singapore Air or whoever comes out with a new product/service - you can book time in an onboard shower. The 'standard' doesn't allow for ancillary service bookies, so how does Singapore Air get this to their customers? Go through the 'standards body' and wait for that, rather than just building it into their own app that they control end-to-end.

In reality, there are too many variations between different companies offering the same service, that it would be rather infeasible to have a single contract they all follow (without compromise) to develop these provider-agnostic client apps.

In a way, browsers and native mobile SDKs is the solution to that problem - browser/OS vendors have created clients for common APIs and widget toolkits to create interfaces. The 'hard work' in delivery an application has already been done (no need for the bank to worry about HTTP, or building widgets like text fields), leaving them to delivery 'just' the layer on top of that.

You create a standard that covers 90% of most used cases and an nice extension api that allows crazy customization of the last 10%

Ahh cool, so like a web browser?

A related issue is that the means of making web UIs are too low-level. There's no standard ready-made widget kit like on desktops.

HTML and CSS started as a solution for publishing text-based content, like the olde magazines but on the web. For that they are splendid: text rendering and basic input handling are taken care of, and wide variety of output devices were supported since day one (HTML 2.0 without tables works excellent on phones).

Then web 2.0 and web apps happened, web idioms began to change, all of people's activity with computers started moving to the web. And it turned out that to create complex UIs for all of that you have to fiddle with rather low-level primitives and handle interactions between them, because outside of text layout HTML primarily knows about divs and a handful of input widgets.

This may be good because high-level widgets will be developed independently and will evolve faster (and maybe better) than if they were built into browsers. But in the meantime we have to live with the chaos that we have.

>This may be good because high-level widgets will be developed independently and will evolve faster (and maybe better) than if they were built into browsers. But in the meantime we have to live with the chaos that we have.

I don't think that having some good built-in widgets (like a better dropdown, menus, DataGrid) would prevent third parties creating their own custom versions but it would help 99% of users that need the basic stuff (like a dropdown that can have icons)

(I need to add, though, that even if a compete and perfect-in-every-respect third-party widget kit for the web appears today, it will face a huge problem of adoption, or rather lack of it. In this regard, fragmentation on the web is unbelievable by desktop standards―also a consequence of the "web is for publishing" approach.)

Vanity is the reason, in my experience.

For all the downsides of amp, it’s demonstrated that letting go of asthetic vanity in the name of fundamental soundness is a good trade to make.

What you want is gopher[1]. Instead of AMP I think sites could honor requests with an text/plain header, the issue is monetization. But AMP is for content based sites, SPA capture a completely different use cases.

[1] https://en.m.wikipedia.org/wiki/Gopher_(protocol)

> I think the job of service providers should be to semantically annotate their data, so that a general purpose client can dynamically render it.

You mean like HTML? We tried that already and people disliked the lack of branding ability.

> people disliked the lack of branding ability.

What people? Brands or users?

I would argue both. Systems like Bootstrap still get a lot of flak

I've always thought AI would be a good solution for this. The ideal way to create a website is to just express what you see in your mind through drawings, essentially, with a simple way to represent transitions. Doing this in real time with a compiler like in Dreamweaver is awkward because there are too many nonsensical constraints (and other problems that real UI engineers can tell you, I'm just an AI guy).

So to bridge the gap you really need a function that can translate your expression into reality by understanding what parts are important for your design to work and what isn't, and making it work on any platform/client/medium. The type of function that can approximate a potentially extremely complex reality, that can be trained incrementally given examples (bugs)... Sounds a lot like modern machine learning to me.

One UI to rule them all? This would be a really interesting tool for web developers.

Thankfully, modern UI development is blessed with some really professional UI toolkits: elements UI for vue or Semantic React for instance do a great job of making us think in terms of generic interactions instead of reinventing the wheel.

This means we get to focus on improving the existing as the project warrants which is significantly more rewarding.

I would prefer powerful UI widgets built in and if your preferred framework wants it can wrap this widgets or if not it can just use nested divs and css to create an alternative.

Reply on news.ycombinator.com