As an interface designer I am completely confident that you're looking at old usability through rose colored glasses. Most software these days doesn't come with a big monolithic manual because it doesn't need one. More people directly use software now than ever before and most of them will probably never read a single line from a software user manual; not because they don't exist, it's because they don't have to. The vanishingly small percentage of folks very experienced with interfaces designed for professional software users– often using old interface flows and metaphors– get frustrated with software designed for everybody else. Your understanding of software usability isn't representative– that's why almost no open source software, no matter how big the manual is, gains anywhere close to the same usage as their commercial equivalents.
That's not what the article ssys though.. do you really think "everybody else" would have discovered the actions described without any sort of help page?
I think the modern software does not come with the manuals because it simply has severly reduced functionality compared to the old days. For example, when was the last time you had used a navigation software with "avoid area" and "add custom road" features?
There was always a tradeoff between "more features thus more UX complexity" (power user approach) vs "cut features to keep UX simpler" (UX designer approach). Sadly, the designers won.
> do you really think "everybody else" would have discovered the actions described without any sort of help page?
No, the article is completely accurate about the lack of discoverability of those features. It highlights them because they are a direct contrast to nearly every other interface feature on iOS. That's what makes them interesting to interface designers.
> I think the modern software does not come with the manuals because it simply has severly reduced functionality compared to the old days.
Oh?
> For example, when was the last time you had used a navigation software with "avoid area" and "add custom road" features?
Did those navigation applications offer traffic overlaying satellite imagery? Public transit directions with real time vehicle tracking? Were you able to just type an address as we parse them or did you need to enter it in some weird little-endian order? Density of people at any given location, how many people are on a bus, or how busy Home Depot is? Up-to-date business hours? Alternate routes on regional rail and airlines? Up-to-date road closures even for temporal events? 3D photographic street-level POV navigation? Terrain maps? Cycling instructions? Weather? Descriptions of area attractions with an array of photographs for each? Wildfire maps? Hail you a ride share?
The number of gained features dwarfs the number of lost features by an order of magnitude in software lasting that long.
> There was always a tradeoff between "more features thus more UX complexity" (power user approach) vs "cut features to keep UX simpler" (UX designer approach).
You're wrong. Our software today does vastly more than software of yesteryear. Most of it feels so natural-- like those maps features-- that you don't notice it coming into existence. It just sort of fits right into the ecosystem-- and that's the whole point.
FOSS is a perfect example of what happens when software interfaces are assembled by developers rather than designed. I've been a developer, mostly towards the back of the stack, for a good 11 years. I also have art school education in interface design. Most developers have no idea how little they know about the way people use interfaces. To us, a GUI is a visual wrapper that facilitates interacting with the underlying software, like an API. Obfuscating functionality when it's not likely useful seems wasteful to someone used to reasoning about complex software. The problems arise when they take their personal usage preferences, assume they're representative of all users, and treat them as broadly applicable maxims in all of the software they create.
Most users don't have the mental models in place to reason about the software functioning behind the interface-- to them, the interface is the software. An interface that doesn't consider what users need to and almost as importantly, don't need to see at any given point is confusing. Confusing is bad, so to them, the software is bad. To a developer, a confusing interface is something to be overcome by reading a manual.
For example, you'll regularly catch professional photographers kvetching about the cost of adobe products... they have almost all tried Gimp but nearly none of them use it. There's little photographers (vs. say, graphic designers) can do in Photoshop that they can't do in Gimp... so why don't more photographers use it? Because it was designed by developers, for users who already have a mental model of the way software works with little regard for everyone else. Literally the only people you see advocating for Gimp are more FOSS fans than artists. Ask photographers why they don't use it and they'll mention the same things every time-- the interface sucks. It's confusing. Things are in unexpected places and function in unexpected ways. Affinity Photo, on the other hand, is starting to get a following.
Photoshop is far from simple, but both the new user experience and the overall capability vastly surpass Gimp. That's why Adobe's userbase grows by millions of users every year despite direct competitors and people having complained about the price since they released v1. Software with expert users will either accommodate expert workflows or they'll no longer have expert users. Software with new users will accommodate beginners or nobody will adopt the software, if there's competition.
Inkscape, on the other hand, enjoys a decent-ish reputation among professional vector graphics artists and unlike Gimp, is sometimes considered a viable tool of the trade. Illustrator and other tools do a hell of a lot more, but people don't roll their eyes when someone brings it up as a FOSS alternative.
Design vs functionality is a false dichotomy. The fact that so many developers assume complexity in interface == good functionality is the reason open source alternatives are alternative rather than the standard.
> Sadly, the designers won.
Your misplaced blame betrays your lack of understanding of what interface designers actually do. Only managers controlling the purse strings want software to do less. Designers are perfectly happy doing the hard work of figuring out the best ways to communicate software's functionality by what is shown, and what is not shown, on any given screen.
Could you imagine people with different domain expertise, like health insurance claims, designed the interfaces around people with their level of familiarity with the underlying systems? What would you say when they scoffed at your lack of sophistication when you refused to crack open a 400 page manual to file a simple claim? After all, it's right there on page 288 in the manual! How do you find it? Just look for 'adjustments, claims' in the index! How would you know to look for that term? "Hhhhhhhh... you don't deserve to have that claim filled!"
Hyperbolic? Sure. But you shouldn't need an existing mental model of the underlying insurance claim machine to file an insurance claim, and that flavor of contempt for users not already understanding "how software works" is endemic in software development, and exactly what designers mitigate.
I think you might be misreading the intent behind those statements in one of two ways:
1) Capability != Experience. Gimp is capable of doing about what Photoshop can do for photographers but with a much, much worse experience.
2) Photographers aren't the only Photoshop users and Gimp's shortcomings are much more consequential for, say, Graphic Designers. Comparing Gimp's typesetting tools to Photoshop's is like comparing a screwdriver to a fully-stocked workshop. Since those features generally aren't on photographers radars, let alone in their regular workflow, I didn't include them.
You know, I've had experience teaching elderly and computer-illiterate people tech. It was much easier to teach them Windows in early 00s than iOS today, because the former, while looking more complicated, was also very consistent - once you explained the basics like drop-down and context menus and drag and drop, those things generally worked everywhere throughout the system, even in new apps they haven't seen before.
Conversely, with iOS, the problem isn't just that all those techniques are undiscoverable - it's that the tricks you learn for one app will rarely work in another. Well, that, and the fact that they regularly change basic UX, too, like removing the physical home button.
