[fairpx]

I work On UI/UX for B2B software businesses and the reason Isee for the problem is that the web is built by engineers. There has been a big focus on code quality, best practices, frameworks etc. But the majority of these engineers didn’t spend time on UI. This is definitely changing. 95% of our customers are great engineers that are seeing the value good UI/UX can add to their product and help deliver a better experience to their user. We’re in the early stages of this shift, but forward thinking engineers are already paving the way.

http://fairpixels.pro

[PretzelFisch]

winform and win32 were built by engineers. Wpf had much more thought put in place for design aspects. The problem s we try to write applications in a system designed for documents.

[mickronome]

UI would be a solved problem from an engineering perspective if someone could define what was necessary for building a good UI, for all time, without working directly with pixels, and without completely obliterating the at least somewhat secure browser sandboxing.

There are essentially no unknowns from an engineering perspective to create any possible ( not impossible ) solution in this space, except for two: What is a good UI, and how do we make almost intrinsically safe execution environment for categorically untrusted code?

There might be, and probably is objectively good UI practices, but what is considered by most to be good UI changes with fashion, with what primitives are available, and what is almost - but not entirely - possible at any point in time.

The kind of freedom the author seem to want is probably not possible to do in any reasonable secure way without all operative systems makers agree on a rather advanced security model that continues far outside the browser, in fact it has to essentially replace the default OS model for all content generated from the browser, and for any application that has ever interacted with any such content.

Looking at saving a file without a save dialog as an example, it might sound trivial, but then the smallest bug in the browser, which is a very complicated runtime for executing distributed content of mostly untrusted nature, could rewrite any file into an executable Trojan horse, completely taking over control the next time you run it.

To avoid this, the OS would have to restrict anything saved or generated from a page to the same set of restrictions that page had, transitively.

Even the possibility to save anything at all opens this window quite a bit, but not at all to the same extent as being able to do it silently. In addition to the obvious reasons, there are other benefits like not having to keep a list of allowed files, and thus can't as easily be tricked as easily to reveal the local names of those files either through direct attacks, or side-channel attacks. Unless you are okay with the 'application' not knowing the name of the files, but then someone is going to complain that it's impossible to make a 'recent files' menu, and thus the circle continues.

There are actually solutions to this that are plausible from a technical and engineering perspective, but they all work by extending the sometimes cumbersome restrictions of the browser right into the native environment to an extent that would probably make OS companies extinct in short order. They are likely to want to either avoid this, or try to become a single supplier. The various strategies of the actors in this space seems to be rather obvious.