7 ms·

OK but if it's that common it shouldn't take more time to create the final result than the time it took to draw it and render it. We don't want to spend time at

by rakoo 3y ago

OK but if it's that common it shouldn't take more time to create the final result than the time it took to draw it and render it. We don't want to spend time at such a low level abstraction, we want to be describing higher-level behavior.

danShumway 3y ago
> it shouldn't take more time to create the final result than the time it took to draw it and render it Ideally it should be faster. Ideally it should be slower to draw and render it than it is to create the final result. My controversial hot take on UI is that I don't think graphical tools like Figma encourage good UX habits. Unless you're doing something really creative, (opinion me) you will get better results if your UI starts in a text editor. You want a slider? What you want is: <input type="range" id="volume" name="volume" min="0" max="11" />  Or better, in a way that your UI designer can understand: Volume (0-11 slider) => Music Volume When we say that these kinds of tasks contain too much boilerplate, its more about the amount of code required to actually wire these things up and about the defaults and caveats of the systems that we're using to build them. And we say that this kind of boilerplate should be eliminated rather than plugged into an AI, what we're talking about is trying to get rid of the stuff that makes people feel like "well, I just need to draw my interface, it's too much work writing it out or programming it." Because web authorship isn't actually there yet, it isn't efficient and easy to do this boilerplate from scratch. But in a way, visual representations of high-level behavior are themselves an inefficient way to describe behavior. It's lossy, it doesn't always represent multiple states well, people forget to handle other setups or states. You need to draw boxes and move them around and if you want to reposition anything you have to move everything else around it? Nah, it's a slider from 0-11, it should be double-bound to some kind of variable. And I don't want to think about boxes, I want to think about what the control is and what it does. When I start building UIs, the first thing I do is I make a markdown list that just lists the controls. I don't start by drawing. This is viewed as a kind of programmer-centric way of thinking about design, but I don't think it is, I think it results in better designs across the board. Drawing shapes should be a step that comes much later in the design process. It should happen, you want to do these kinds of visual tweaks to make sure things line up well and to think about presentation, the same way you want to do a visual pass when typesetting a book. It's not that it's not important, butthe visual position of every element is not the part of the design that's most difficult, figuring out what to show the user and when and how to represent it is the difficult part. And in the same way that you wouldn't write a book and start out thinking about the page breaks, it doesn't make sense to think about the positioning of every control before you've figured out what your controls even are. It's kind of a failure of modern UI/UX toolkits that people are so hungry for visual design. It's backwards, we treat the behavior of controls as an implementation detail and the positioning of controls as the primary design step. It's the opposite, how a control behaves is important, and how it looks is an implementation detail that we may need to change or polish in the future depending on whether our current app-wide default styles work well for the control or not. But that's because people are so used to feeling disconnected from the implementation and are so used to the implementation being a repetitive chore.

by rakoo 3y ago

danShumway 3y ago

> it shouldn't take more time to create the final result than the time it took to draw it and render it Ideally it should be faster. Ideally it should be slower to draw and render it than it is to create the final result. My controversial hot take on UI is that I don't think graphical tools like Figma encourage good UX habits. Unless you're doing something really creative, (opinion me) you will get better results if your UI starts in a text editor. You want a slider? What you want is: <input type="range" id="volume" name="volume" min="0" max="11" />  Or better, in a way that your UI designer can understand: Volume (0-11 slider) => Music Volume When we say that these kinds of tasks contain too much boilerplate, its more about the amount of code required to actually wire these things up and about the defaults and caveats of the systems that we're using to build them. And we say that this kind of boilerplate should be eliminated rather than plugged into an AI, what we're talking about is trying to get rid of the stuff that makes people feel like "well, I just need to draw my interface, it's too much work writing it out or programming it." Because web authorship isn't actually there yet, it isn't efficient and easy to do this boilerplate from scratch. But in a way, visual representations of high-level behavior are themselves an inefficient way to describe behavior. It's lossy, it doesn't always represent multiple states well, people forget to handle other setups or states. You need to draw boxes and move them around and if you want to reposition anything you have to move everything else around it? Nah, it's a slider from 0-11, it should be double-bound to some kind of variable. And I don't want to think about boxes, I want to think about what the control is and what it does. When I start building UIs, the first thing I do is I make a markdown list that just lists the controls. I don't start by drawing. This is viewed as a kind of programmer-centric way of thinking about design, but I don't think it is, I think it results in better designs across the board. Drawing shapes should be a step that comes much later in the design process. It should happen, you want to do these kinds of visual tweaks to make sure things line up well and to think about presentation, the same way you want to do a visual pass when typesetting a book. It's not that it's not important, butthe visual position of every element is not the part of the design that's most difficult, figuring out what to show the user and when and how to represent it is the difficult part. And in the same way that you wouldn't write a book and start out thinking about the page breaks, it doesn't make sense to think about the positioning of every control before you've figured out what your controls even are. It's kind of a failure of modern UI/UX toolkits that people are so hungry for visual design. It's backwards, we treat the behavior of controls as an implementation detail and the positioning of controls as the primary design step. It's the opposite, how a control behaves is important, and how it looks is an implementation detail that we may need to change or polish in the future depending on whether our current app-wide default styles work well for the control or not. But that's because people are so used to feeling disconnected from the implementation and are so used to the implementation being a repetitive chore.