This is just a rant about some minor usability issues in a very small selection of applications used by the author, and mostly Gnome. There’s is nothing behind it.
The title is click-bait and the article is a waste of time.
There’s some very dubious claims, such as:
> There was a time (roughly between 1994 and 2012) when a reasonably computer-literate user could sit down in front of almost any operating system and quickly get to grips with the GUI, no matter what their home base was. Windows, MacOS, CDE, OpenStep, OS/2 and even outliers like Amiga, Atari and BeOS all had more in common than what set them apart.
Personally, having used many of these systems during those years, I completely disagree.
There is no further context or evidence to support this claim. It’s just “the premise”.
This is then contrasted with vague generalizations about the current situation:
> Today, it seems we're on another track completely. Despite being endlessly fawned over by an army of professionals, Usability, or as it used to be called, "User Friendliness", is steadily declining. During the last ten years or so, adhering to basic standard concepts seems to have fallen out of fashion
While there is no evidence for the claim that usability was better in the 90s, there are some examples to show that it’s worse now.
But these are more like pet-peeves, and there’s no evidence or theory to show why they’re good or bad, just more vague generalizations.
> Since Windows 2 (not 2000 - I'm really talking about Windows 2), users have been able to resize windows by dragging their top border and corners. Not so with Slack, anymore.
This is not the decline of usability. It’s the decline in respect for the reader.
There really was a time when a title faithfully represented the text that followed it, right? It must have been sometime around 1994.
But note that it’s up from #30. So this debacle is inflating the importance of Apollo way beyond what it normally would be, at least with regards to its placement in this chart.
Not that that’s a good look for Reddit, to throw Apollo under the bus, then to find the bus they threw them under was Reddit, and it threw it completely off course.
It is mind boggling that they could not anticipate this response. That memo they sent out after this and which got leaked was such an example of poor leadership, it would really be a shame if this doesn’t lead to some changes there.
> People don't know what they want until you show it to them
You won’t know what people want or how to build it if you don’t _look at what they actually do_ first. There’s no other way of doing it, even Steve Jobs did it this way.
It sounds like a contradiction, but I don’t think it is. He’s talking about people’s biases about new products. Understanding people’s biases is part of watching what they do, as opposed to just considering what they say. He doesn’t say you’re supposed to come up with what people want out of thin air.
> The tool may save the developer, let's say 3-4 hours / week
This is the main flaw in your argument. For any developer who will actually save 3-4 hours a week with this tool, there are a thousand developers who will only save 3-4 hours a year.
As a potential user, how do you know which group you’ll be on?
And as business, how do you make the decision to only target one in a thousand potential users?
This is a case where thought experiments based on your own assumptions just aren’t very useful.
It’s very way to end up arguing with straw men about made up categories.
What you define as “paper cuts” is probably very arbitrary and would differ significantly between individuals. It only makes sense in the context of an existing backlog of issues that is properly groomed and labeled. Otherwise you may as well just call them “pet peeves” instead. It’s totally subjective.
So whether they “matter” or not is really unanswerable outside of that context, and frankly not very interesting within that context as well. If they mattered they would already have been fixed…
> If they mattered they would already have been fixed
I just don’t think this is true at all. I’ve always been on teams where the backlog of issues with very real business value (for any value of “matters”) far exceeded the capacity of the team. Given that, it meant that there was a constant battle of prioritization. That process ought to include “Papercuts” as an input variable, for sure.
It’s short and to the point with practical lessons about things like layout, contrast, etc.
https://www.amazon.com/Non-Designers-Design-Book-4th/dp/0133...