5 ms·

I skimmed the article and closed it when I saw the Scientific Calculator being shown as an example of complexity. Most people would stop using it if a "UX Desi

by jeswin 7y ago

I skimmed the article and closed it when I saw the Scientific Calculator being shown as an example of complexity. Most people would stop using it if a "UX Designer" tried to simplify it. Not everything is a todo list app with rounded corners.

Damogran6 7y ago
I hope you didn't miss the overall message for one poorly articulated example, then. Because there was an informative point put forth.
- mosselman 7y ago
  There might have been, but not a very original one at that. Why waste your time on an article written by someone who doesn't grasp the material fully?
- rq1 7y ago
  This example made the point unbeknownst to the author. This Dieter Rams mantra is a recurring theme. What do you think about cockpits interfaces and Bloomberg terminals? Should we add some more “white spaces”? Prioritising information/functionality does not mean sacrificing their density.
  - Damogran6 7y ago
    I think some things can be easy and some things must trade low learning curve for functionality. I highly doubt Airbus will produce a commercial airliner with a big red “fly to destination” button. (Though I’ve been wrong before)
  - bch 7y ago
    I think your comment points out “context matters”. Cockpits aren’t consumer goods.
    - kinkrtyavimoodh 7y ago
      Yes but most consumers aren't uneducated idiots, and for the purposes of this discussion, there is nothing that specific about a cockpit that can't be true for a scientific calculator or an audio console. This attitude is how you get Macbook "Professional"s whose keyboards stop working in 2 months.
  - meerita 7y ago
    Indeed. As a designer, I've seen 3000 DR articles. It's a pity designers abuse DR work just to justify their hedonisms. All apps I've seen with DR style have failed. I remember a bizarre podcast app for iOS in 2012 that was like insane DR nightmare and it was pleasant to eyes, but completely useless and utterly boring. It died against other options who were using generic iOS components. DR has born in another era of product design: most products had 1 or 2 features max. There were no playlists, no sharing, no connectivity, etc. It's easy to design when you have only those contraints.
atoav 7y ago
But there is a tension between badly implemented feature-rich solutions and well implemented special solutions and very often the specialized solution is much much better than anything else if it fits your usage. I work with modular synthesizers and I certainly would use a well designed interface that knows it’s priorities over one that tries to make every parameter accessible and doesn’t priorize them in any way. If all you want in a car radio is a USB charger and a volume control, a radio with just these two implemented in a deluxe variant (big knob with motor potentiometer?) would be better than say a super duper feature rich car radio that can do everything but hides it behind obscure button combinations and plastic encoders. These complex all purpose devices of course also have their use cases. But very rarely any single user will need more than the most basic stuff. Where it get’s dangerous, is when the general purpose device forgets to design these “90% of the time” use cases properly. So if you scientific calculator design makes it harder to do basic arithmetic, it is probably bad design. On the other hand if you leave out key scientific functionality because you want it to look sleek, it is also bad design. Good design has to be based on real world usage and this is a very case-by-case thing. In the end we need to accept that it is hard to cover all use cases with one interface in a good way — so just make a more than one and let users switch.
- mark-r 7y ago
  I once had a car where I wanted to upgrade the stereo. Never did it, because the station buttons on the replacements were all too small.
tobr 7y ago
> Most people would stop using it if a "UX Designer" tried to simplify it. That’s true, I completely stopped using this type of calculator when the UX designers behind Calca, Soulver and their ilk came up with a much simpler and better design.
- msla 7y ago
  The better design for a scientific calculator is Maxima, or some other keyboard-driven system where the primary UI is a command line. Why? Because you're communicating information-dense messages (equations, arithmetic problems, functions) and text remains the only way we have to do that. The command line is also the least discoverable UI imaginable. It has absolutely no obvious affordances beyond typing something into it and hoping you typed something the program understood. Even the error messages are going to be opaque unless you have some prior knowledge. There is no "just pick it up and go" with this. On the gripping hand, however, a command line is the most fluent UI short of the Emacs/ITS affinity for keystroke bindings. Once you know how to do something, you can get amazingly fast. It actively rewards muscle memory and familiarity, as opposed to menus and progressive disclosure, which are precisely as clunky on day one thousand as they are on day one. Speaking as an HP-48GX owner, a good button array with shift keys and some context-dependent buttons can be nearly as fast as a command line, but it's inherently more limited. My point is this: Discoverability is in tension with fluency, meaning that designing for experts is inherently different for designing for newbies, or people who use the software so rarely they're effectively always newbies. Removing functionality to unclutter an interface is newbie design thinking, as a command line is never cluttered. (Which isn't to say you can't do both. The Emacs GUI is newbie-friendly unless a newbie is in the habit of jamming odd key combinations at random.)
  - strokirk 7y ago
    There's certainly big differences in command line apps and terminals though. Features like tab completion with inline docstrings, fish-style autocomplete, history with search-as-you-type, infinite scrollback, semantic colors, consistent interfaces, good help pages, dry-running and more all help to increase ease of use, discoverability and quicken the learning curve.
Aeolun 7y ago
A lot of applications would be a lot better if all their functionality could be covered in one page with a bunch of buttons.
meerita 7y ago
I agree. If any UX Designer thinks that SC are badly designed let them do one and let us figure out how good is their approach. 99.9% of failure for sure. Years and years of iterations on calculators can't be that wrong. But some designers love to write hedonist articles.

by jeswin 7y ago

Damogran6 7y ago

I hope you didn't miss the overall message for one poorly articulated example, then. Because there was an informative point put forth.

mosselman 7y ago
There might have been, but not a very original one at that. Why waste your time on an article written by someone who doesn't grasp the material fully?
rq1 7y ago
This example made the point unbeknownst to the author. This Dieter Rams mantra is a recurring theme. What do you think about cockpits interfaces and Bloomberg terminals? Should we add some more “white spaces”? Prioritising information/functionality does not mean sacrificing their density.
- Damogran6 7y ago
  I think some things can be easy and some things must trade low learning curve for functionality. I highly doubt Airbus will produce a commercial airliner with a big red “fly to destination” button. (Though I’ve been wrong before)
- bch 7y ago
  I think your comment points out “context matters”. Cockpits aren’t consumer goods.
  - kinkrtyavimoodh 7y ago
    Yes but most consumers aren't uneducated idiots, and for the purposes of this discussion, there is nothing that specific about a cockpit that can't be true for a scientific calculator or an audio console. This attitude is how you get Macbook "Professional"s whose keyboards stop working in 2 months.
- meerita 7y ago
  Indeed. As a designer, I've seen 3000 DR articles. It's a pity designers abuse DR work just to justify their hedonisms. All apps I've seen with DR style have failed. I remember a bizarre podcast app for iOS in 2012 that was like insane DR nightmare and it was pleasant to eyes, but completely useless and utterly boring. It died against other options who were using generic iOS components. DR has born in another era of product design: most products had 1 or 2 features max. There were no playlists, no sharing, no connectivity, etc. It's easy to design when you have only those contraints.

atoav 7y ago

But there is a tension between badly implemented feature-rich solutions and well implemented special solutions and very often the specialized solution is much much better than anything else if it fits your usage. I work with modular synthesizers and I certainly would use a well designed interface that knows it’s priorities over one that tries to make every parameter accessible and doesn’t priorize them in any way. If all you want in a car radio is a USB charger and a volume control, a radio with just these two implemented in a deluxe variant (big knob with motor potentiometer?) would be better than say a super duper feature rich car radio that can do everything but hides it behind obscure button combinations and plastic encoders. These complex all purpose devices of course also have their use cases. But very rarely any single user will need more than the most basic stuff. Where it get’s dangerous, is when the general purpose device forgets to design these “90% of the time” use cases properly. So if you scientific calculator design makes it harder to do basic arithmetic, it is probably bad design. On the other hand if you leave out key scientific functionality because you want it to look sleek, it is also bad design. Good design has to be based on real world usage and this is a very case-by-case thing. In the end we need to accept that it is hard to cover all use cases with one interface in a good way — so just make a more than one and let users switch.

mark-r 7y ago
I once had a car where I wanted to upgrade the stereo. Never did it, because the station buttons on the replacements were all too small.

tobr 7y ago

> Most people would stop using it if a "UX Designer" tried to simplify it. That’s true, I completely stopped using this type of calculator when the UX designers behind Calca, Soulver and their ilk came up with a much simpler and better design.

msla 7y ago
The better design for a scientific calculator is Maxima, or some other keyboard-driven system where the primary UI is a command line. Why? Because you're communicating information-dense messages (equations, arithmetic problems, functions) and text remains the only way we have to do that. The command line is also the least discoverable UI imaginable. It has absolutely no obvious affordances beyond typing something into it and hoping you typed something the program understood. Even the error messages are going to be opaque unless you have some prior knowledge. There is no "just pick it up and go" with this. On the gripping hand, however, a command line is the most fluent UI short of the Emacs/ITS affinity for keystroke bindings. Once you know how to do something, you can get amazingly fast. It actively rewards muscle memory and familiarity, as opposed to menus and progressive disclosure, which are precisely as clunky on day one thousand as they are on day one. Speaking as an HP-48GX owner, a good button array with shift keys and some context-dependent buttons can be nearly as fast as a command line, but it's inherently more limited. My point is this: Discoverability is in tension with fluency, meaning that designing for experts is inherently different for designing for newbies, or people who use the software so rarely they're effectively always newbies. Removing functionality to unclutter an interface is newbie design thinking, as a command line is never cluttered. (Which isn't to say you can't do both. The Emacs GUI is newbie-friendly unless a newbie is in the habit of jamming odd key combinations at random.)
- strokirk 7y ago
  There's certainly big differences in command line apps and terminals though. Features like tab completion with inline docstrings, fish-style autocomplete, history with search-as-you-type, infinite scrollback, semantic colors, consistent interfaces, good help pages, dry-running and more all help to increase ease of use, discoverability and quicken the learning curve.

Aeolun 7y ago

A lot of applications would be a lot better if all their functionality could be covered in one page with a bunch of buttons.

meerita 7y ago

I agree. If any UX Designer thinks that SC are badly designed let them do one and let us figure out how good is their approach. 99.9% of failure for sure. Years and years of iterations on calculators can't be that wrong. But some designers love to write hedonist articles.