3 ms·

Huh? UIs should be repetitive not impressive or original, so users don't have to learn different new interface for every app.

by spyder 3y ago

another-dave 3y ago
I think the parent's comment isn't saying that UI should be wildly different from each other but moreso highlighting that this is a prime usecase for an easy abstraction over the top.
creshal 3y ago
UIs should be repetitive, but we keep reinventing them anyway to satisfy the vanity of product owners/designers/managers/clients/... and built entire industries around making slightly the UIs slightly more differently than the last time.
- gtirloni 3y ago
  Usually things naturally get mature and stop changing so much (e.g. some software reaches such maturity level that it starts offering LTS releases). This doesn't seem to be the case with UI toolkits. Is that because we still don't understand things well enough to design a decent foundation?
  - creshal 3y ago
    I suspect a large part is that the visual nature of the topic simply lends itself to endless bike shedding and fashion cycles; maturity and stability are going to be anathemata in these contexts. But it also doesn't help that input/output formfactors keep changing. We just about understood what did and didn't work with terminals when desktop GUIs sprung up, by the time those started maturing, we had to figure out how to adapt to PDAs and pen inputs, then came smartphones and tablets, then 3D for a while, then VR, and in parallel to that increasingly exotic "classic" form factors like folding devices with fluid screen sizes, ...
  - pc86 3y ago
    In my experience it's because every time you give a page or product spec to a designer they give you something slightly different based on however they happen to be feeling that day. Combine that with whatever product people do, and you get basically random UIs for each task.
  - dogleash 3y ago
    > Is that because we still don't understand things well enough to design a decent foundation? Nope. Don't let the conmen fool you that the incremental changes in HCI justify all the new coats of paint. Form and function changes are happening in parallel. Fashion has to change, that's just the nature of fashion. Fashion will also spin yarn to justify itself. That's also just the nature of fashion. Don't get me wrong, I want all my software to be palatable to modern tastes. But entropy always increases with time.
  - dghlsakjg 3y ago
    I would say that in the long term/big picture we have figured out a pretty standard UI for computers. In the 1980s you probably had to read a pretty hefty book for any given model of computer to be useful. Now, we can sit down in front of just about any computer and trust that the Mouse and Keyboard will exist, and act like we expect (i.e. the left button on the mouse is for selecting, there are arrows on the keyboard which can control a cursor, etc), and that the GUI software will be substantially similar regardless of manufacturer (windowed programs, a bar of some sort on the lower edge of the screen for controlling the OS, a bar at the top of the screen for controlling the active window, etc.) The parts of the UI toolkits that change are the least consequential. Round or square corners, buttons, skeumorphism, etc...
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.
deleted 3y ago
[deleted]
blehn 3y ago
So then every app should be a CLI? Not sure how you can actually believe a statement like that.

Huh? UIs should be repetitive not impressive or original, so users don't have to learn different new interface for every app.

by spyder 3y ago

Huh? UIs should be repetitive not impressive or original, so users don't have to learn different new interface for every app.

another-dave 3y ago

I think the parent's comment isn't saying that UI should be wildly different from each other but moreso highlighting that this is a prime usecase for an easy abstraction over the top.

creshal 3y ago

UIs should be repetitive, but we keep reinventing them anyway to satisfy the vanity of product owners/designers/managers/clients/... and built entire industries around making slightly the UIs slightly more differently than the last time.

gtirloni 3y ago
Usually things naturally get mature and stop changing so much (e.g. some software reaches such maturity level that it starts offering LTS releases). This doesn't seem to be the case with UI toolkits. Is that because we still don't understand things well enough to design a decent foundation?
- creshal 3y ago
  I suspect a large part is that the visual nature of the topic simply lends itself to endless bike shedding and fashion cycles; maturity and stability are going to be anathemata in these contexts. But it also doesn't help that input/output formfactors keep changing. We just about understood what did and didn't work with terminals when desktop GUIs sprung up, by the time those started maturing, we had to figure out how to adapt to PDAs and pen inputs, then came smartphones and tablets, then 3D for a while, then VR, and in parallel to that increasingly exotic "classic" form factors like folding devices with fluid screen sizes, ...
- pc86 3y ago
  In my experience it's because every time you give a page or product spec to a designer they give you something slightly different based on however they happen to be feeling that day. Combine that with whatever product people do, and you get basically random UIs for each task.
- dogleash 3y ago
  > Is that because we still don't understand things well enough to design a decent foundation? Nope. Don't let the conmen fool you that the incremental changes in HCI justify all the new coats of paint. Form and function changes are happening in parallel. Fashion has to change, that's just the nature of fashion. Fashion will also spin yarn to justify itself. That's also just the nature of fashion. Don't get me wrong, I want all my software to be palatable to modern tastes. But entropy always increases with time.
- dghlsakjg 3y ago
  I would say that in the long term/big picture we have figured out a pretty standard UI for computers. In the 1980s you probably had to read a pretty hefty book for any given model of computer to be useful. Now, we can sit down in front of just about any computer and trust that the Mouse and Keyboard will exist, and act like we expect (i.e. the left button on the mouse is for selecting, there are arrows on the keyboard which can control a cursor, etc), and that the GUI software will be substantially similar regardless of manufacturer (windowed programs, a bar of some sort on the lower edge of the screen for controlling the OS, a bar at the top of the screen for controlling the active window, etc.) The parts of the UI toolkits that change are the least consequential. Round or square corners, buttons, skeumorphism, etc...

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.

deleted 3y ago

[deleted]

blehn 3y ago

So then every app should be a CLI? Not sure how you can actually believe a statement like that.