The article contains an image of a (relatively basic) calculator, asking the question: "How many of these buttons will you really push?"
Well… all of them. I may not need tan every day, but when I do, I need it to be there.
Well… all of them. I may not need tan every day, but when I do, I need it to be there.
Not everything is a todo list app with rounded corners.
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.
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.
I highly doubt Airbus will produce a commercial airliner with a big red “fly to destination” button. (Though I’ve been wrong before)
This attitude is how you get Macbook "Professional"s whose keyboards stop working in 2 months.
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.
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.)
Minimalism just for the sake of it doesn't end well.
I don't think any company has ever straddled this line well especially if it's market overlaps between mainstream and power users.
Ofc, I mean this is in a general way. The Onedrive example you gave is actually very extreme.
E.g. Despite my background in design I find Bulk Rename Utility UX - regarding its market target - really effective even if it's ugly.
https://www.bulkrenameutility.co.uk/assets/img-bru/mainscr.p...
I once got into an argument with someone (not a designer) about adding an "export" feature to a table UI. It was an easy feature to add, but the argument against it was that it was yet another rarely used button, that further crowded the UI. And further, users shouldn't need to export because they should be able to do everything they needed from within the app.
I was sympathetic to these arguments, especially the second. But many customers repeatedly asked for the export feature. We spoke to several and explained they could do what they needed without exporting, but even after that, they still wanted a "file" they could manipulate.
I won, and we added the export feature, and many other smallish features like it. Even though I love a minimalist design and look and feel, it shouldn't come at the expense of features. And in the end, our designers made it unobtrusive and kept it elegant.
Good design is not about deconstructing things just for simplicity's sake, but to expose the complexity in a way that feels natural.
This is the gist of what I think is good design: don't second-guess your users.
When you're doing the wireframe, you don't have all the information, ever. You don't know what your users are going to need, you don't know how they're going to use your application. You may have the best, most comprehensive specs ever written in the history of software development and users will still find new ways to use your application, that you've never thought about and couldn't even possibly imagine.
So when an user wants something, "good design" consists of figuring out how to integrate it in your application.
Not of patronizing your users and explaining them that they don't really need that, or that a clean, intuitive UI is more important than that thing they asked for. They asked for that thing precisely because that clean, intuitive UI was great but it came short of doing what they needed.
And when an application with a worse UI that does what that user needs comes along, they are going to switch to it, no questions asked. Because a bad-looking program that does what you need -- i.e. that helps you do your job and earn your pay -- will always trump one that doesn't do what you need.
The fact your user understands their requirements better than the designer doesn't mean that the user is a better designer. If only.
That's just greed and extreme entitlement dressed in UX clothes. Your software will never be good enough to suffice for all use cases within a domain; most likely it isn't even particularly ergonomic for bulk of them. Often, the output of your software is needed as input to another piece of software. That's why interoperability is so important, and lack of it is a black mark.
> That's just greed and extreme entitlement dressed in UX clothes.
I understand the passion here, especially today, users should be able to control data the way the want. However, greed or lock-down was not a relevant factor (we already had APIs for bulk data). The resistance to the "export" button was motivated by a genuine curiosity as to why someone would want to do that, and to better understand their use case. If someone is exporting something, it's because they want to do something that we do not do. The resistance was not about letting go of control of the data, but rather losing sight of what our users wanted.
Screenshots can be prevented using DRM. Linux users are hippies anyway so they don't have a job.
People could still photograph the screen or transcribe the data manually. But I'm sure a legislative solution for this problem can be found. After all, you wouldn't download a CSV file.
I hope this proposal won't be read by anyone insane enough not to see anything horribly wrong with it.
(Joe Spolsky wrote about it in the past; lack of vendor lock-in was crucial for it winning the market in the early days.)
tan x = sin x / cos x
cos x = sin π/2 - xDo not listen to those pesky customers who whine they have to press "+" button lots of times.
I used this one for my BE in electronics. Casio 991es. If you look at the button just below the ON button, that is the logx function.
Hard to apply that to a physical calculator I suppose.