4 ms·

My pet hypothesis for years has been that developers always vastly underestimate the difficulty of doing a UI framework or environment. They think it'll just be

by api 4y ago

My pet hypothesis for years has been that developers always vastly underestimate the difficulty of doing a UI framework or environment. They think it'll just be a matter of painting widgets and presenting data. As a result they under-build the foundation. The insufficient structure is then released out to the world for everyone else to build upon. Once people realize the soul devouring chthonic difficulty of doing good modern UI, they've already built on a shit foundation and been forced to realize the full system with a heap of ugly hacks and workarounds. Then someone thinks "wow, this is way too complex! All I need is a simple UI." Then history repeats. You can see this with immediate mode clean simple GUI library of the week. They all stagnate after getting all the basics working, and there's a reason for this. A good mature modern UI is at least on par with a high-end game engine like Unity in terms of feature surface area and difficulty. In some ways it's worse because while the breadth and size of the problem domain is similar the problems you encounter in a game engine are probably a lot more fun. UI is a hell of incredibly hairy state management and a really long tail of edge cases.

cloogshicer 4y ago
I think you're spot on. My hypothesis has been for a while: UIs essentially are video games. They have animations and interactions that rival the complexity of video games. Sometimes they even have sounds too. The rendering is not quite as complex (usually!), but everything else definitely is. I'd like to see a UI system that is built by experienced game devs, who also are good at and understand interaction design.
- jwatte 4y ago
  This is probably a better comparison than one might at first think. A game engine has a second, hidden, part of the iceberg: The production pipeline for all the 3D world/art assets. That's actually where most of the work goes -- hundreds of artists go into a AAA game, and all the art they produce must be technically excellent along a bunch of dimensions that have nothing to do with what it looks like (and in fact, generally make it harder to achieve the look you want.) Game engines that can wire physics simulation to 3D rendering to window abstractions are easy-ish to make, similar to how web UI frameworks are easy-ish to make. All the production pipeline stuff is where the real meat is, similar to how in WebUI and, package management and transpiling and bundling and deploying is a hard problem. I think the game side has it even harder than the web side, though, although they usually have the benefit of only needing to work on a defined set of platforms, rather than in "the" browser.
michaelchisari 4y ago
> developers always vastly underestimate the difficulty of doing a UI framework or environment Developers, managers, designers, executives, the whole process chain underestimates the complexity of building a stable and maintainable UI. Everyone feels in their gut how complex building out a data processing pipeline or a scalable backend should be, but even people who should know better can't help but think of the UI as the "easiest" part. In my experience, the only solution is forced minimalism. A sort of "Dogme 95" for UX. Force your UX to be a haiku, not an open-ended novel. This means pushing back hard on unnecessary complexity and focusing like a laser on what really matters. In other words, the problems might be technical, but the solution are likely political. https://en.wikipedia.org/wiki/Dogme_95 https://en.wikipedia.org/wiki/Dogme_95
spiralx 4y ago
> Then someone thinks "wow, this is way too complex! All I need is a simple UI." Then history repeats. This gives me flashbacks to writing a Java applet (supporting the MS JVM!) in which my boss has decided AWT (no Swing lol) was verboten and implemented his own widgets. Which was great up until I had to implement dropdowns, because then you need a concept of z-ordering, which meant refactoring almost everything in order to include. And this pattern repeated several times for "simple" new features I was asked to add. Writing a primitive windowing system with nested menus in GFA Basic and getting lost in a rabbit-hole browsing the Turbo Pascal object hierarchy as a teenager was a good way to teach me to not try and write my own UI library if I wanted to get anything else done :)

by api 4y ago

cloogshicer 4y ago

I think you're spot on. My hypothesis has been for a while: UIs essentially are video games. They have animations and interactions that rival the complexity of video games. Sometimes they even have sounds too. The rendering is not quite as complex (usually!), but everything else definitely is. I'd like to see a UI system that is built by experienced game devs, who also are good at and understand interaction design.

jwatte 4y ago
This is probably a better comparison than one might at first think. A game engine has a second, hidden, part of the iceberg: The production pipeline for all the 3D world/art assets. That's actually where most of the work goes -- hundreds of artists go into a AAA game, and all the art they produce must be technically excellent along a bunch of dimensions that have nothing to do with what it looks like (and in fact, generally make it harder to achieve the look you want.) Game engines that can wire physics simulation to 3D rendering to window abstractions are easy-ish to make, similar to how web UI frameworks are easy-ish to make. All the production pipeline stuff is where the real meat is, similar to how in WebUI and, package management and transpiling and bundling and deploying is a hard problem. I think the game side has it even harder than the web side, though, although they usually have the benefit of only needing to work on a defined set of platforms, rather than in "the" browser.

michaelchisari 4y ago

> developers always vastly underestimate the difficulty of doing a UI framework or environment Developers, managers, designers, executives, the whole process chain underestimates the complexity of building a stable and maintainable UI. Everyone feels in their gut how complex building out a data processing pipeline or a scalable backend should be, but even people who should know better can't help but think of the UI as the "easiest" part. In my experience, the only solution is forced minimalism. A sort of "Dogme 95" for UX. Force your UX to be a haiku, not an open-ended novel. This means pushing back hard on unnecessary complexity and focusing like a laser on what really matters. In other words, the problems might be technical, but the solution are likely political. https://en.wikipedia.org/wiki/Dogme_95 https://en.wikipedia.org/wiki/Dogme_95

spiralx 4y ago

> Then someone thinks "wow, this is way too complex! All I need is a simple UI." Then history repeats. This gives me flashbacks to writing a Java applet (supporting the MS JVM!) in which my boss has decided AWT (no Swing lol) was verboten and implemented his own widgets. Which was great up until I had to implement dropdowns, because then you need a concept of z-ordering, which meant refactoring almost everything in order to include. And this pattern repeated several times for "simple" new features I was asked to add. Writing a primitive windowing system with nested menus in GFA Basic and getting lost in a rabbit-hole browsing the Turbo Pascal object hierarchy as a teenager was a good way to teach me to not try and write my own UI library if I wanted to get anything else done :)