4 ms·

Ever since software design became a thing there's been a tug-of-war between visual design and interaction design. And it doesn't help that those skills are usua

Ever since software design became a thing there's been a tug-of-war between visual design and interaction design. And it doesn't help that those skills are usually not held by the same person on a design team (even if many visual designers think of themselves as interaction designers). I agree with the general thrust of this piece, and think we're in a bit of a dark age of interface design right now. Too much attention is paid to visual design and not enough to interaction design. But while speed of response in a UI is certainly a factor in usability, it's not as significant as things like mode, navigation, habituation, vocabulary or consistency. So to that extent I think the article isn't really addressing the main problem, which is that time spent on visual design should be better spent on designing for usability. I'm also not sure what to make of the idea of calling for the terminal to be revised and considered the way forward in user interfaces. Apart from speed, what problem would that solve? And I'm intrigued when it says interfaces should be "composable by default so that good interfaces aren’t just something produced by the best developer/designers in the world, but could be reasonably expected from even junior people in the industry". I'm afraid I don't understand what that means.

brandur 10y ago
Thanks for reading! (I wrote this.) > I'm also not sure what to make of the idea of calling for the terminal to be revised and considered the way forward in user interfaces. Apart from speed, what problem would that solve? So I didn't mean to imply exactly that this is definitively the way forward. What I meant to imply is that the terminal programs we have today are flawed, but overall closer to a better model compared to other interfaces we're producing — mainly the web. Interfaces in web browsers are decently okay, but they have some fundamental problems that are unlikely to ever be tractable. For example: * Speed. Even the fastest websites are slow compared to native applications. The median speed of a web application (for say your bank, credit card company, or local utility) is _terrible_ because that's the default given the current framework. You need to a high level of mastery and knowledge beyond what most developers have to build something better. * Consistency. Every web app looks and behaves differently. Instead of learning common conventions once, users learn everything afresh over and over again. * Usability. You'll never get better at using most web applications because there's no framework for advanced usage at all; instead all of them cater to the lowest common denominator. There are a few exceptions like Gmail's keyboard shortcuts, but they're rare, and not very powerful compared to something like Vim, where the more more you learn the greater your productivity becomes. * Composability. I try to show in my GitHub copy + paste video that even copying things out of web pages is hard. (This one addressed further below.) > And I'm intrigued when it says interfaces should be "composable by default so that good interfaces aren’t just something produced by the best developer/designers in the world, but could be reasonably expected from even junior people in the industry". > > I'm afraid I don't understand what that means. I might have mixed a couple different ideas there, but when I'm talking about composability, think like pipes in a shell. Just imagine if I could say something like: "okay Credit Card App, pipe the list of charges that I've tagged with 'corporate' into Concur and file expense reports for each one". The closest we can hope for something like that is for someone to build a third party app that uses the APIs of both your credit card and Concur and does this for you, but even there, you're still operating along the fixed rails provided by another app. Imagine if you had flexibility on your own terms that was available to even non-power users by having your credit card and Concur provide standardized primitives that your web shell could hook into and use. As for the comment on junior developers: what I meant is that it's possible to create a fast and good interface on the web, but the amount of knowledge that you need to do so is mind boggling. You'll need to understand at least: design, CSS, JavaScript and probably using it to build fast client-side interfaces, asset compilation, CDNs, server-side performance measurement, etc. The barrier is just too high. I hope that helps to clarify some things!
- ooqr 10y ago
  Do you think it's totally out-of-line for me to expect front-end web frameworks to help alleviate the style consistency and response-speed problems? Certainly we can come upon design conventions, but people would have to willingly subscribe to them. For speed, we could embrace background processing of tasks and have much of the page remain static. > I might have mixed a couple different ideas there, but when I'm talking about composability, think like pipes in a shell. Just imagine if I could say something like: "okay Credit Card App, pipe the list of charges that I've tagged with 'corporate' into Concur and file expense reports for each one". This, I think, is too generous to the command line, even as I am a vim/grep/etc fan. When it comes to real life data coming through grep, for example, cleaning that data, iterating through it with bash, and passing it along is often not worth the bother and I end up manually processing it. Unless it's a recurring script and I can reliably parse and clean the data, handle failure, etc, it's not worth automating.
- vickychijwani 10y ago
  I'm late to this thread, but quite surprised to see nobody mentioned Mozilla's Ubiquity addon [1], which I think best demonstrates the idea of "composability" in a GUI you're trying to convey. I think adding a description/screenshot of Ubiquity or explaining one of its use-cases would explain your idea more clearly and actually put someone on the right path if they accept your call to action. Incidentally, Aza Raskin, one of the main developers of Ubiquity is the son of Jef Raskin who led the work on Apple's Macintosh. At one point in college I was fascinated enough with Ubiquity to try to continue the work on it (since the project was shelved), but my programming skills were just not up to it. Perhaps I'll get back to it sometime soon :) [1]: https://wiki.mozilla.org/Labs/Ubiquity/Latest_Ubiquity_User_Tutorial https://wiki.mozilla.org/Labs/Ubiquity/Latest_Ubiquity_User_...
  - ProxCoques 10y ago
    Ubiquity (and it's related predecessor, Enso) was an excellent idea and I'd almost forgotten I'd used it for about 18 months before the project died out. Raskin took the idea from his father of course, and it's discussed in his book "The Humane Interface", one of the best books about software design ever to have been written.
coldtea 10y ago
>And I'm intrigued when it says interfaces should be "composable by default so that good interfaces aren’t just something produced by the best developer/designers in the world, but could be reasonably expected from even junior people in the industry". I'm afraid I don't understand what that means. It means that you should be able to re-use (compose) interface elements, so that even a junior developer could create a great interface (UX-wise) by assembling one from parts that are made to work well together. Sort of like anybody can make a command line app and trivially have it work with other cli tools like grep, tail, awk, sort, uniq, cat, ps and the like. Or like anybody could throw together a perfectly good hypercard UI.
- vickychijwani 10y ago
  > It means that you should be able to re-use (compose) interface elements, so that even a junior developer could create a great interface (UX-wise) by assembling one from parts that are made to work well together. I don't think "compose" == "reuse" as you suggest. Reusing well-designed interface elements gets you very little in terms of usability, because the important parts of UX design - like page structure and navigation - cannot be handed to developers in ready-made toolkits. I do agree with the second half of your comment though. Mozilla's Ubiquity project [1] is the best example I know (see [2]) of on-the-fly composability in modern GUIs. Admittedly Ubiquity is somewhat underdeveloped, but the core idea is solid, in my view. There's also things like IFTTT, Zapier, and Slack integrations, but: 1. They involve up-front configuration, and, 2. You need to redo this configuration for every pair of apps you want to compose together, which is obviously not scalable. [1]: https://wiki.mozilla.org/Labs/Ubiquity https://wiki.mozilla.org/Labs/Ubiquity [2]: https://wiki.mozilla.org/Labs/Ubiquity/Latest_Ubiquity_User_Tutorial#The_Map_command https://wiki.mozilla.org/Labs/Ubiquity/Latest_Ubiquity_User_...

brandur 10y ago

Thanks for reading! (I wrote this.) > I'm also not sure what to make of the idea of calling for the terminal to be revised and considered the way forward in user interfaces. Apart from speed, what problem would that solve? So I didn't mean to imply exactly that this is definitively the way forward. What I meant to imply is that the terminal programs we have today are flawed, but overall closer to a better model compared to other interfaces we're producing — mainly the web. Interfaces in web browsers are decently okay, but they have some fundamental problems that are unlikely to ever be tractable. For example: * Speed. Even the fastest websites are slow compared to native applications. The median speed of a web application (for say your bank, credit card company, or local utility) is _terrible_ because that's the default given the current framework. You need to a high level of mastery and knowledge beyond what most developers have to build something better. * Consistency. Every web app looks and behaves differently. Instead of learning common conventions once, users learn everything afresh over and over again. * Usability. You'll never get better at using most web applications because there's no framework for advanced usage at all; instead all of them cater to the lowest common denominator. There are a few exceptions like Gmail's keyboard shortcuts, but they're rare, and not very powerful compared to something like Vim, where the more more you learn the greater your productivity becomes. * Composability. I try to show in my GitHub copy + paste video that even copying things out of web pages is hard. (This one addressed further below.) > And I'm intrigued when it says interfaces should be "composable by default so that good interfaces aren’t just something produced by the best developer/designers in the world, but could be reasonably expected from even junior people in the industry". > > I'm afraid I don't understand what that means. I might have mixed a couple different ideas there, but when I'm talking about composability, think like pipes in a shell. Just imagine if I could say something like: "okay Credit Card App, pipe the list of charges that I've tagged with 'corporate' into Concur and file expense reports for each one". The closest we can hope for something like that is for someone to build a third party app that uses the APIs of both your credit card and Concur and does this for you, but even there, you're still operating along the fixed rails provided by another app. Imagine if you had flexibility on your own terms that was available to even non-power users by having your credit card and Concur provide standardized primitives that your web shell could hook into and use. As for the comment on junior developers: what I meant is that it's possible to create a fast and good interface on the web, but the amount of knowledge that you need to do so is mind boggling. You'll need to understand at least: design, CSS, JavaScript and probably using it to build fast client-side interfaces, asset compilation, CDNs, server-side performance measurement, etc. The barrier is just too high. I hope that helps to clarify some things!

ooqr 10y ago
Do you think it's totally out-of-line for me to expect front-end web frameworks to help alleviate the style consistency and response-speed problems? Certainly we can come upon design conventions, but people would have to willingly subscribe to them. For speed, we could embrace background processing of tasks and have much of the page remain static. > I might have mixed a couple different ideas there, but when I'm talking about composability, think like pipes in a shell. Just imagine if I could say something like: "okay Credit Card App, pipe the list of charges that I've tagged with 'corporate' into Concur and file expense reports for each one". This, I think, is too generous to the command line, even as I am a vim/grep/etc fan. When it comes to real life data coming through grep, for example, cleaning that data, iterating through it with bash, and passing it along is often not worth the bother and I end up manually processing it. Unless it's a recurring script and I can reliably parse and clean the data, handle failure, etc, it's not worth automating.
vickychijwani 10y ago
I'm late to this thread, but quite surprised to see nobody mentioned Mozilla's Ubiquity addon [1], which I think best demonstrates the idea of "composability" in a GUI you're trying to convey. I think adding a description/screenshot of Ubiquity or explaining one of its use-cases would explain your idea more clearly and actually put someone on the right path if they accept your call to action. Incidentally, Aza Raskin, one of the main developers of Ubiquity is the son of Jef Raskin who led the work on Apple's Macintosh. At one point in college I was fascinated enough with Ubiquity to try to continue the work on it (since the project was shelved), but my programming skills were just not up to it. Perhaps I'll get back to it sometime soon :) [1]: https://wiki.mozilla.org/Labs/Ubiquity/Latest_Ubiquity_User_Tutorial https://wiki.mozilla.org/Labs/Ubiquity/Latest_Ubiquity_User_...
- ProxCoques 10y ago
  Ubiquity (and it's related predecessor, Enso) was an excellent idea and I'd almost forgotten I'd used it for about 18 months before the project died out. Raskin took the idea from his father of course, and it's discussed in his book "The Humane Interface", one of the best books about software design ever to have been written.

coldtea 10y ago

>And I'm intrigued when it says interfaces should be "composable by default so that good interfaces aren’t just something produced by the best developer/designers in the world, but could be reasonably expected from even junior people in the industry". I'm afraid I don't understand what that means. It means that you should be able to re-use (compose) interface elements, so that even a junior developer could create a great interface (UX-wise) by assembling one from parts that are made to work well together. Sort of like anybody can make a command line app and trivially have it work with other cli tools like grep, tail, awk, sort, uniq, cat, ps and the like. Or like anybody could throw together a perfectly good hypercard UI.

vickychijwani 10y ago
> It means that you should be able to re-use (compose) interface elements, so that even a junior developer could create a great interface (UX-wise) by assembling one from parts that are made to work well together. I don't think "compose" == "reuse" as you suggest. Reusing well-designed interface elements gets you very little in terms of usability, because the important parts of UX design - like page structure and navigation - cannot be handed to developers in ready-made toolkits. I do agree with the second half of your comment though. Mozilla's Ubiquity project [1] is the best example I know (see [2]) of on-the-fly composability in modern GUIs. Admittedly Ubiquity is somewhat underdeveloped, but the core idea is solid, in my view. There's also things like IFTTT, Zapier, and Slack integrations, but: 1. They involve up-front configuration, and, 2. You need to redo this configuration for every pair of apps you want to compose together, which is obviously not scalable. [1]: https://wiki.mozilla.org/Labs/Ubiquity https://wiki.mozilla.org/Labs/Ubiquity [2]: https://wiki.mozilla.org/Labs/Ubiquity/Latest_Ubiquity_User_Tutorial#The_Map_command https://wiki.mozilla.org/Labs/Ubiquity/Latest_Ubiquity_User_...