The Elements of UI Engineering

Post by nojvek » Mon, Dec 31, 2018, 9:09 PM UTC

madeofpalk wrote: post #40

miguelrochefort wrote: post #2

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 d…

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…

Post by HedgeSparrow » Mon, Dec 31, 2018, 9:49 PM UTC

austincheney wrote: post #52

0xCMP wrote: post #45

Earlier quoted context omitted.

You're being toxic by calling people "cowards" for simply using a package instead of writing it themselves which reduces the amount of code they need to directly maintain. Displays a complete misunderstanding of the tradeoffs involved as well as being rude. And what's funny is that if you hadn't been a jerk the original point of Frameworks and NPM Packages for everything is a good point and probably would have been w…

Thank you for having the balls to respond. I could have tap danced around that by using a bunch of words like: demonstrating a proportional degree of insecurity to the depth of requirements presented across the breadth of considerations required by this responsibility . I found the word coward to be more honest and fitting, though. Ultimately, the rampant insecurity isn't a technology problem. It is a personality con…

Post by miguelrochefort » Mon, Dec 31, 2018, 11:16 PM UTC

ggpsv wrote: post #55

miguelrochefort wrote: post #38

Earlier quoted context omitted.

There's no reason for route transition to be a special case of state transition. Here are some examples of state transitions that can be augmented with animations: - reorder items in a lost - add/remove an item from a list - expand/collapse an element - hover/press/disable a button - show a popup - show an inline error message - open a drop down menu - open/close a burger menu - change the burger menu button to a bac…

Interesting! Are there any resources or books that you might share that delve into this kind of reasoning towards UI engineering?

Post by simplify » Mon, Dec 31, 2018, 11:39 PM UTC

pdrummond wrote: post #57

danabramov wrote: post #35

Earlier quoted context omitted.

That's exactly how some of the newer libraries in React ecosystem work btw. For example, Downshift is that "DYI Autocomplete" — it handles a11y and mechanics but you can compose any kind of behavior and styling out of its primitives. https://github.com/paypal/downshift I'm glad to see this trend.

I've used Downshift before and while I like the idea, what I am suggesting is broader in scope. A set of primitives such as Overlay, Rectangle, Circle, List, Row, Column, etc that still allow you to apply styling but overall they sit at a lower level of abstraction than ready-made components, even ones based on something like Downshift. The more I think about this the more I feel like I'm describing exactly how "Qt Q…

Post by pjmlp » Tue, Jan 01, 2019, 1:15 AM UTC

c-smile wrote: post #64

pjmlp wrote: post #62

Earlier quoted context omitted.

If I am not mistaken, Houdini will allow similar features. But it is still far away from standardization.

> still far away from standardization. Sciter uses this feature almost 10 years. All these 10 years we have libraries of reusable components and so no need for React. Same is about flexbox and grid: https://terrainformatica.com/2018/12/11/10-years-of-flexboxi...