7 ms·

A tight iteration loop is the only solution I've seen for building high quality UI/UX. Embrace that it's going to be terrible the first few times and plan for t

A tight iteration loop is the only solution I've seen for building high quality UI/UX. Embrace that it's going to be terrible the first few times and plan for this. We could save on cost per iteration by avoiding the layout and styling pass until the very end. These interfaces are about communicating information. Plain text and basic form submissions work just as well as anything else when you're still trying to design site map and purpose of each page. There's a direct correlation between the customer-developer distance and the number of iterations required to achieve an acceptable result. You can dramatically reduce the churn by requiring daily builds or screenshots to the customer. If your development process can't support the idea of iterating like this, you need to find one that can. If the actual customer can't handle that amount of traffic, create internal proxies or advocates.

hapticmonkey 1y ago
This has been my experience as well. Something about the human brain just makes it very bad at observing a mocked-up screen layout and understanding how well it works in practice. Apply that to an entire application with multiple functions and the problem increases exponentially. Experience helps speed things up. But rapid iteration with a fast feedback loop is the best practice. Design is not doing the start of the loop, it’s doing the entire loop. Repeatedly.
- lupire 1y ago
  Predicting video from a still image is a fraught task. Predicting interaction from a linear video is another fraught task. It would be surprising if someone had the ability to do this.
pydry 1y ago
Outside in development helps here too.
mpweiher 1y ago
It is also my experience that this is the way to go, and it also matches my theoretical view aka prejudices. It seems to me that one of the things making this approach difficult is that we lack (design) tools that support iteration between design and development. Modern tools make going from design to development easier, but it is still largely a one-way street. And one that's been made worse by recent trends towards building the UI in code, rather than from data. There are good local reasons for doing this, but it does seem to push even more strongly towards a waterfall-y development process (design does pretty mockups, throws over wall)
- WillAdams 1y ago
  For a long while now, what seems to me a reasonably simple project (re-creating the UI of a drawing program and making it straight-forward to re-create program state with annotations/highlighting) has been stalled because I can't find a design tool which works better than just placing the screen grabs in a vector drawing program and annotating by hand.... I'm about at the point where I'm going to just code everything up in METAPOST.... Makes me wish for Display PostScript again....
  - paddy_m 1y ago
    What made display postscript so great? I have only seen it mentioned in frothy marketing terms, not an in depth discussion of its approach, why it worked well, and how that compares to other alternatives.
    - WillAdams 1y ago
      You have to understand or have experienced how fragile the early graphics programs were --- basically a .eps file would be a black box of PostScript code, and would have a pixel image preview used on-screen (a classic gag was to use a resource editor to change the pixel preview) --- whether or no it would actually print/image correctly was something one wasn't certain of until holding the actual output in hand, and even then, it only held for a specific PostScript rasterizer/job setting. Sure, it was okay 99.99% of the time, but that 0.01% could be disastrous. Display PostScript meant that the system used for on-screen display was the same as for actual printed output --- I _never_ had a job on my NeXT Cube fail to print to match the on-screen version. Moreover, one could do cool DPS programming such as custom strokes and fills in Altsys Virtuoso. These days, PDF and Quartz (née Display PDF) mostly address the reliability (and presumably it's gotten even better since I left the industry), but I miss the programmability. Hopefully, using METAPOST will let me get some of that back.
      - paddy_m 1y ago
        Thanks, I'm starting to understand. So Display Postscript was useful because it let you know that what you put on the screen as a programmer would be what's printed? And it allowed for cool graphics effects like custom strokes and fills. So that primarily matters for stuff you want to print. It wouldn't matter as much for assembling a UI. How does windows handle this stuff?
catmanjan 1y ago
Very interested to hear about a high quality UI as I have never encountered one
- XorNot 1y ago
  I would argue Windows Forms somewhere between 3.1 and 95 more or less nailed it. It's boring, but it's clear.
- dlivingston 1y ago
  Apple used to be very good at this, especially in the pre-iPhone OS X era. iTunes: https://discussions.apple.com/content/attachment/192853040 https://discussions.apple.com/content/attachment/192853040 Preview: https://www.intego.com/mac-security-blog/wp-content/uploads/2022/02/preview.png https://www.intego.com/mac-security-blog/wp-content/uploads/... Garage Band: https://inside.wooster.edu/technology/wp-content/uploads/sites/83/2018/11/garageband-interface.jpg https://inside.wooster.edu/technology/wp-content/uploads/sit...
  - tarentel 1y ago
    Is that last one actually Garage Band? I used to use it a very long time ago and I don't remember it ever looking like that. It does, however, look basically the same as Logic does today. I'm not sure if I'd consider it a good GUI or not.
- paddy_m 1y ago
  CAD Software. There is CAD vs CAD esports. https://www.youtube.com/live/C1CqIcfDKbQ?t=1987s https://www.youtube.com/live/C1CqIcfDKbQ?t=1987s It seems dominated by solidworks but other programs (NX, Fusion 360...?) are allowed. The bloomberg terminal UI. Some emacs setups. (much more variability than VIM) Some VIM setups. The thing that all of these have in common is that they are designed for experts, not for every user. Also each one of those is a custom full platform app (or primarily text based) vs web app.
  - skydhash 1y ago
paddy_m 1y ago
The best functional specs for a UI have come from business people building their own in excel. At a minimum they will have some idea of layout and what information should be displayed on which screens. This also lets them focus on the core information, not the styling. Building GUIs on the web, there are infinite ways to style every UI element and more attention goes to that then the actual interaction.
- diggan 1y ago
  > Building GUIs on the web, there are infinite ways to style every UI element and more attention goes to that then the actual interaction. AKA bike-shedding, or "Law of triviality", just to put a name on this pretty common occurrence.
- SoftTalker 1y ago
  I'd disagree with that. People build wild shit in Excel that only they can understand. It makes sense to them because they built it. Nobody else can use it. Not all spreadsheets are like this but there are absolutely no guardrails to prevent it. Building a good GUI takes thoughtful design by someone who understands what makes a good GUI and what the goals of the interface are from the user's perspective. Someone who can make it look like what the user is already used to, even if that isn't "beautiful" UI or doesn't follow the latest trends in whitespace and widget appearance.
  - bob1029 1y ago
    > People build wild shit in Excel that only they can understand. If these people are the customer, then a wild shit xlsx file is perhaps one of the better possible scenarios for requirements gathering.
    - pphysch 1y ago
      I've been in this exact situation. Client provides their current workflow, implemented in a spreadsheet. The problem is they make significant concessions in their design to fit the tabular model of spreadsheets. It can be really warping, not only to GUI but also the underlying data model. Then you show them what a relational data model is capable of, and (hopefully) blow their mind.
dlivingston 1y ago
When I do GUI work, it's usually for hobbyist or internal projects. I value quality UI/UX extremely highly. I often get 'analysis-by-paralysis' here because I try to do the design and development in a synchronous single pass. Your comment about tight and rapid iteration being the only solution resonates with me. One 'trick' I discovered recently was to completely ignore UI design and focus on _formatting_ instead -- the placement of elements in a proper and useable way. Saving the visual aspects of design (widget design, margins, padding, color, animations, etc.) until the very very last step. My hypothesis is that "good UI" = "good page formatting" + "pretty UI elements". Any thoughts on this approach?
- lupire 1y ago
  Yes, this is part of Information Architecture https://en.m.wikipedia.org/wiki/Information_architecture https://en.m.wikipedia.org/wiki/Information_architecture
- fuzzfactor 1y ago
  >GUIs are built at least 2.5 times Unfortunately what is more often needed is 3.0+ and far too many fall short :\ >"good UI" = "good page formatting" + "pretty UI elements". Nice to have, icing on the cake, but what I need if it was to be mission-critical is at least 10x better workflow than average these days. As a child, before I had any concept of software, I just wanted to get something worthwhile out of electronics itself. I'm so old that most adults didn't have a concept of software either in those days. "Software awareness", that it even exists as an entity of its own has by now proliferated by many orders of magnitude like most other things do not. One thing that's stood the test of time, if you can make the electronics do something it wasn't doing before, well that might just be remarkable. Maybe even game-changing. Maybe even like never before. Sometimes you program, sometimes you don't. In the right balance it can end up quite a system. Decades ago for my own purposes I separated the UI from the rest of the code, and this was of course a monolith with line numbers. The equivalent of punch cards, but when you think about it the UI could be in the final 25% of the deck of cards, and quite easily physically replaceable in that media form factor. Plus, if you're transparent about it, it can really come in handy sometimes to deal from the bottom on the deck. GOTO can easily be your friend if you know how to accommodate each other ;) But code also doesn't necessarily have to have any electronics involved. Software alone can be considered more independent of constraint by a "system", because it can be so abstract. Doesn't have to be so abstract, but that is a serious option sometimes. The ultimate would be pure software which is not part of any other "system" at all. I'm so out-of-date I'll probably just stick with the electronics ;) >Any thoughts on this approach? Sorry, my head's a blank ;)
codyb 1y ago
The fact frequent, repeated contact with the customer isn't the norm is why so many interfaces suck and so many engineers could't design a decent one with a gun to their head (although, frankly, that level of stress might not induce thoughtful design patterns). Instead engineers get hit with micro view after micro view, and they build it using test flows that don't mimic the real world, and then they all tie it in to create a tangled macro view that's a shit show for the user. I've been working to bring recurring Shadow Sessions here at my workplace by creating a basic scheduler (which is really the pain point at scale) that just sends you and somebody working in the tooling you're building (we're internal tooling) every three weeks and the feedback is overwhelmingly positive and we're working to expand the functionality a bit. So, all you out there who want a nice win, set up a little scheduler and get your Product, Design, Engineers, Managers, and TPMs in rotating sessions with actual customers at a lightweight pace with minimal asks to create greater empathy which translates to all of us potentially ending up with better software in the world as a whole. A fella can dream.
bsder 1y ago
> A tight iteration loop is the only solution I've seen for building high quality UI/UX. Embrace that it's going to be terrible the first few times and plan for this. The problem I have seen is that all the GUI toolkits weld themselves way too hard to the code. Consequently, when you want to adjust the UI, you always have to rewrite big chunks of the code.

hapticmonkey 1y ago

This has been my experience as well. Something about the human brain just makes it very bad at observing a mocked-up screen layout and understanding how well it works in practice. Apply that to an entire application with multiple functions and the problem increases exponentially. Experience helps speed things up. But rapid iteration with a fast feedback loop is the best practice. Design is not doing the start of the loop, it’s doing the entire loop. Repeatedly.

lupire 1y ago
Predicting video from a still image is a fraught task. Predicting interaction from a linear video is another fraught task. It would be surprising if someone had the ability to do this.

pydry 1y ago

Outside in development helps here too.

mpweiher 1y ago

It is also my experience that this is the way to go, and it also matches my theoretical view aka prejudices. It seems to me that one of the things making this approach difficult is that we lack (design) tools that support iteration between design and development. Modern tools make going from design to development easier, but it is still largely a one-way street. And one that's been made worse by recent trends towards building the UI in code, rather than from data. There are good local reasons for doing this, but it does seem to push even more strongly towards a waterfall-y development process (design does pretty mockups, throws over wall)

WillAdams 1y ago
For a long while now, what seems to me a reasonably simple project (re-creating the UI of a drawing program and making it straight-forward to re-create program state with annotations/highlighting) has been stalled because I can't find a design tool which works better than just placing the screen grabs in a vector drawing program and annotating by hand.... I'm about at the point where I'm going to just code everything up in METAPOST.... Makes me wish for Display PostScript again....
- paddy_m 1y ago
  What made display postscript so great? I have only seen it mentioned in frothy marketing terms, not an in depth discussion of its approach, why it worked well, and how that compares to other alternatives.
  - WillAdams 1y ago
    You have to understand or have experienced how fragile the early graphics programs were --- basically a .eps file would be a black box of PostScript code, and would have a pixel image preview used on-screen (a classic gag was to use a resource editor to change the pixel preview) --- whether or no it would actually print/image correctly was something one wasn't certain of until holding the actual output in hand, and even then, it only held for a specific PostScript rasterizer/job setting. Sure, it was okay 99.99% of the time, but that 0.01% could be disastrous. Display PostScript meant that the system used for on-screen display was the same as for actual printed output --- I _never_ had a job on my NeXT Cube fail to print to match the on-screen version. Moreover, one could do cool DPS programming such as custom strokes and fills in Altsys Virtuoso. These days, PDF and Quartz (née Display PDF) mostly address the reliability (and presumably it's gotten even better since I left the industry), but I miss the programmability. Hopefully, using METAPOST will let me get some of that back.
    - paddy_m 1y ago
      Thanks, I'm starting to understand. So Display Postscript was useful because it let you know that what you put on the screen as a programmer would be what's printed? And it allowed for cool graphics effects like custom strokes and fills. So that primarily matters for stuff you want to print. It wouldn't matter as much for assembling a UI. How does windows handle this stuff?

catmanjan 1y ago

Very interested to hear about a high quality UI as I have never encountered one

XorNot 1y ago
I would argue Windows Forms somewhere between 3.1 and 95 more or less nailed it. It's boring, but it's clear.
dlivingston 1y ago
Apple used to be very good at this, especially in the pre-iPhone OS X era. iTunes: https://discussions.apple.com/content/attachment/192853040 https://discussions.apple.com/content/attachment/192853040 Preview: https://www.intego.com/mac-security-blog/wp-content/uploads/2022/02/preview.png https://www.intego.com/mac-security-blog/wp-content/uploads/... Garage Band: https://inside.wooster.edu/technology/wp-content/uploads/sites/83/2018/11/garageband-interface.jpg https://inside.wooster.edu/technology/wp-content/uploads/sit...
- tarentel 1y ago
  Is that last one actually Garage Band? I used to use it a very long time ago and I don't remember it ever looking like that. It does, however, look basically the same as Logic does today. I'm not sure if I'd consider it a good GUI or not.
paddy_m 1y ago
CAD Software. There is CAD vs CAD esports. https://www.youtube.com/live/C1CqIcfDKbQ?t=1987s https://www.youtube.com/live/C1CqIcfDKbQ?t=1987s It seems dominated by solidworks but other programs (NX, Fusion 360...?) are allowed. The bloomberg terminal UI. Some emacs setups. (much more variability than VIM) Some VIM setups. The thing that all of these have in common is that they are designed for experts, not for every user. Also each one of those is a custom full platform app (or primarily text based) vs web app.
- skydhash 1y ago

paddy_m 1y ago

The best functional specs for a UI have come from business people building their own in excel. At a minimum they will have some idea of layout and what information should be displayed on which screens. This also lets them focus on the core information, not the styling. Building GUIs on the web, there are infinite ways to style every UI element and more attention goes to that then the actual interaction.

diggan 1y ago
> Building GUIs on the web, there are infinite ways to style every UI element and more attention goes to that then the actual interaction. AKA bike-shedding, or "Law of triviality", just to put a name on this pretty common occurrence.
SoftTalker 1y ago
I'd disagree with that. People build wild shit in Excel that only they can understand. It makes sense to them because they built it. Nobody else can use it. Not all spreadsheets are like this but there are absolutely no guardrails to prevent it. Building a good GUI takes thoughtful design by someone who understands what makes a good GUI and what the goals of the interface are from the user's perspective. Someone who can make it look like what the user is already used to, even if that isn't "beautiful" UI or doesn't follow the latest trends in whitespace and widget appearance.
- bob1029 1y ago
  > People build wild shit in Excel that only they can understand. If these people are the customer, then a wild shit xlsx file is perhaps one of the better possible scenarios for requirements gathering.
  - pphysch 1y ago
    I've been in this exact situation. Client provides their current workflow, implemented in a spreadsheet. The problem is they make significant concessions in their design to fit the tabular model of spreadsheets. It can be really warping, not only to GUI but also the underlying data model. Then you show them what a relational data model is capable of, and (hopefully) blow their mind.

dlivingston 1y ago

When I do GUI work, it's usually for hobbyist or internal projects. I value quality UI/UX extremely highly. I often get 'analysis-by-paralysis' here because I try to do the design and development in a synchronous single pass. Your comment about tight and rapid iteration being the only solution resonates with me. One 'trick' I discovered recently was to completely ignore UI design and focus on _formatting_ instead -- the placement of elements in a proper and useable way. Saving the visual aspects of design (widget design, margins, padding, color, animations, etc.) until the very very last step. My hypothesis is that "good UI" = "good page formatting" + "pretty UI elements". Any thoughts on this approach?

lupire 1y ago
Yes, this is part of Information Architecture https://en.m.wikipedia.org/wiki/Information_architecture https://en.m.wikipedia.org/wiki/Information_architecture
fuzzfactor 1y ago
>GUIs are built at least 2.5 times Unfortunately what is more often needed is 3.0+ and far too many fall short :\ >"good UI" = "good page formatting" + "pretty UI elements". Nice to have, icing on the cake, but what I need if it was to be mission-critical is at least 10x better workflow than average these days. As a child, before I had any concept of software, I just wanted to get something worthwhile out of electronics itself. I'm so old that most adults didn't have a concept of software either in those days. "Software awareness", that it even exists as an entity of its own has by now proliferated by many orders of magnitude like most other things do not. One thing that's stood the test of time, if you can make the electronics do something it wasn't doing before, well that might just be remarkable. Maybe even game-changing. Maybe even like never before. Sometimes you program, sometimes you don't. In the right balance it can end up quite a system. Decades ago for my own purposes I separated the UI from the rest of the code, and this was of course a monolith with line numbers. The equivalent of punch cards, but when you think about it the UI could be in the final 25% of the deck of cards, and quite easily physically replaceable in that media form factor. Plus, if you're transparent about it, it can really come in handy sometimes to deal from the bottom on the deck. GOTO can easily be your friend if you know how to accommodate each other ;) But code also doesn't necessarily have to have any electronics involved. Software alone can be considered more independent of constraint by a "system", because it can be so abstract. Doesn't have to be so abstract, but that is a serious option sometimes. The ultimate would be pure software which is not part of any other "system" at all. I'm so out-of-date I'll probably just stick with the electronics ;) >Any thoughts on this approach? Sorry, my head's a blank ;)

codyb 1y ago

The fact frequent, repeated contact with the customer isn't the norm is why so many interfaces suck and so many engineers could't design a decent one with a gun to their head (although, frankly, that level of stress might not induce thoughtful design patterns). Instead engineers get hit with micro view after micro view, and they build it using test flows that don't mimic the real world, and then they all tie it in to create a tangled macro view that's a shit show for the user. I've been working to bring recurring Shadow Sessions here at my workplace by creating a basic scheduler (which is really the pain point at scale) that just sends you and somebody working in the tooling you're building (we're internal tooling) every three weeks and the feedback is overwhelmingly positive and we're working to expand the functionality a bit. So, all you out there who want a nice win, set up a little scheduler and get your Product, Design, Engineers, Managers, and TPMs in rotating sessions with actual customers at a lightweight pace with minimal asks to create greater empathy which translates to all of us potentially ending up with better software in the world as a whole. A fella can dream.

bsder 1y ago

> A tight iteration loop is the only solution I've seen for building high quality UI/UX. Embrace that it's going to be terrible the first few times and plan for this. The problem I have seen is that all the GUI toolkits weld themselves way too hard to the code. Consequently, when you want to adjust the UI, you always have to rewrite big chunks of the code.