The problem with this is that you don’t learn any new features that you wouldn’t have come up with on your own.
I loved reading the well-written manuals and “on-line” (integrated into the software) help of the 90s (and 80s) that explained all the concepts and features of the particular software. You’d learn a ton of new ideas and possibilities. It was really fun and exciting, and it gave you the perception of a well-designed and well thought-out whole. You built up a consistent mental model of the software, and you thus ended up with the feeling of mastery and control over the software.
Nowadays it feels more like poking the software with a stick in an attempt to build a mental model and discover its capabilities by trial and error, often remaining in doubt about the actual intent of how exactly things are supposed to work.
It does get a bit ridiculous though. There's entire sites and content creators focused solely on VS Code tips. At what point are we gonna end up with engineers working on adding a feature to VS Code that they didn't know already existed?
I don't think those have ever come up at the right time, usually only when I'm halwfway in the middle of an action, and not in the headspace for a tutorial or tip.
And that tiny little tooltip, that offers no screenshot or example gif isn't going to get me to learn.
If anyone knows how to invoke this feature, I’d love to know. Just not enough to try to find out from checking more than about three search results. Anyway, ahhh discoverability. I remember you…
† Typed these on mobile, of course. Android, in case you're wondering.
If you enable that, each key on the keyboard now shows an additional symbol you can get to by long press, for example, 'a' now also allows you to type '@'. If you try and long press for 'a' you'll suddenly see that accented versions of 'a' are also available. And that's the story of how I "naturally" discovered that same feature.
For “consumer” software I usually don’t need manuals, I can find what I need via poking; this often includes power user features (when I use something sufficiently often).
Is it possible that what you’re feeling is nostalgia? Have you actually read the manual for your phone?
I have, and it’s abysmal, because it doesn’t make any attempt at explaining anything on a conceptual level, or even explaining basic UI elements. It doesn’t teach you how to interpret what you see on the screen. It does the bare minimum of enumerating the steps to activate a given feature, presuming that you are able to match those descriptions to what you see on the screen (there are barely any screenshots) and that you know why you would want to use that feature in the first place. It also doesn’t address any failure modes, and doesn’t discuss relevant considerations regarding the use of the given feature.
https://www.oreilly.com/search/?query=missing+manual&formats...
Then again, today’s smartphone operating systems are as popular as home appliances in the 90s.
Maybe if we took something modern that is as niche as software in the 90s then it might come with a manual with a mental model too.
But of course, there’s a phone app you can download and give the company a bunch of personal information to connect your washer to your home network so you can get notification when it’s done with its cycle.
Now they're developing products for themselves. No customer ever asked for a TV that plastered the screen with ads every time they adjusted the volume, or a lightbulb you need some shitty app to turn on and off, but now it seems everything comes with some kind of hidden monkey paw style gotcha attached to it.
- 2020s appliances (throw away manuals) are like 90s hardware toolbox (throw away manuals)
- 2020s smartphones (easy to understand manuals) are like 90s appliances (easy to understand manuals)
- 2020s specialized tools (manuals with mental models) are like 90s computers (manuals with mental models)
This make some sense for Web Product development where you want to find a market fit, VC and media were all over it. But it doesn't work as well for Desktop and other type of Apps. Or in System Programming.
And it is funny we start seeing push back against it 10 - 15 years later.
Except we’re really not. Tools like container registries, software dependencies on remote repos, and cheap infrastructure have brought the fast half-baked iteration to systems programming, desktop apps, etc.
https://www.ableton.com/en/manual/welcome-to-live/
Wish more software companies were this thorough.
The manual is also available as an 843-page ebook [2], and is accessible via the Tips app, which is preinstalled on the home screen.
It's not quite like the days when a paper manual would be right in the box, but it's close. And I think most people would be unhappy if their sleek new phone came with an 843-page tome (not to mention how much paper that would waste).
[1] https://support.apple.com/en-gb/guide/iphone/welcome/ios
I didn't know that. I thought Tips was an app that gave you a couple of dozens of tips, and nothing else.
Would naming it "User Manual" be any better?
That’s why they’ve never read the manual.
I tried to find the answer to a problem I had and it's not there. I inherited an iphone where the side ringer mute toggle bounces back after setting, it's a mechanical error. There is no software "unmute" override - unless you use assistive touch. It took quote a while of wading through google results and well-intentioned-but-clueless advice from people before I found someone who revealed this. The manual just says assistive touch can help adjust volume so it is technically true I guess but the keyword "mute" is not there.
I did learn about the triple-click shortcut from than online manual just now, so I should thank it for that (even though it neglects to mention it needs to be enabled first).
It's hard to Google things you don't know exist. And it's hard to Google things that changed. If you've ever had a problem on macos, Googling is only useful if the problem is new; if it's been an issue in older versions, you're going to find all those questions and maybe some answers but they likely don't apply because Apple broke it differently now. Other vendors are not immune to this either, of course. I understand Apple actually does have manuals, they just don't print them and if they reference them, many people (including me) never noticed.
Note that iPhones have a manual too, it’s easy to navigate and quite comprehensive. E.g. here’s a page that describes the “trackpad” action: https://support.apple.com/en-gb/guide/iphone/iph3c50f96e/16.... .
https://support.apple.com/en-gb/guide/iphone/iph3afc3b3fc/16...
UI design takes time and thought; that's true. But why does a company with Apple's resources not bring the necessary effort to bear on it? It's not as if they can't afford it. Sure, there are time constraints, but if you're going to fold to those and trowel out shitty UI, then don't presume to publish "human interface guidelines" or other such bibles.
And it's high time to stop tolerating smug douchebags who denigrate any complaint about missing functionality and declare, "Well, you simply long-press Option-Shift-Command-Q to bring up the configuration menu."
Then there is the problem of authors using product- and version-specific jargon that I haven't mastered yet, precisely because one can usually pick up the basic operations without reading a manual - "1. From the customization agent..."
Especially in coding I see this as the major difference between a good and great engineer - google things at the right time to find the best solutions. You don’t have to build it all yourself.
https://wiki.preterhuman.net/The_Macintosh/Newton_Easter_Egg...
OK, that's my #2 blocker. My #1 blocker is that I am no longer 15 and have things to do other than just poke about until I master a new text editor.
100% this. Once upon the time my attitude would have been a bratty "you just don't want to do the work to master your tools!" My response to that now is "no the fuck I do NOT, I want problem number 8131 solved yesterday so I can move on to problem number 8132 which btw requires entirely different tooling."
I was lucky enough to have first encountered LaTeX and LilyPond while still in high school.
We have other capabilities now, nobody is forced to work on the CLI anymore - I also refuse to spend weeks to „master“ my editor
I agree with all of that, but from the vim side of things. Although these are not my main concerns with organizing a development process, I find it troublesome to set up and tune a modern IDE into a useful state either, and refuse to do that unless it’s a workplace requirement.
Typing code is literally the least bad thing slowing me down when creating software.
Typing code in vim-insert or emacs is the same as in any other editor. You press keys, they show up on the screen. Press F1 and type a command. Press a shortcut to enter files pane and select a file to edit. Press C-K C-9 to expand all user folds. Install a plugin, map some keys and now you can set and cycle through bookmarks easily.
I strongly believes the “Think about it” -> “Express it” -> “See it done” is much better the whole ballet your hand would be doing with the mouse and keyboard.
That does NOT solve the original discoverability problem.
>>I've been astonished at how often a feature was added 3 years ago to a program I've used for 8 years, or there's a secret swipe that avoids a bunch of menus, or an unofficial command-line flag.
THAT is the problem right there. You're a likely typical example of someone who is smart, knowledgeable, experienced, and motivated, probably beyond what used to be called a "power user". Yet great swaths of features, and the work of scores of designers, developers, & testers for years, simply escapes our notice.
The result is that vast amounts of productivity go squandered until we discover by chance accident or encounter with some "You didn't know this!" post.
I've occasionally seen some introduction wizards be somewhat helpful, but they are never in any kind of depth. It's like they are afraid to show you what the software can really do — but the real case is some marketing dude thinks (likely sometimes correctly) that if the intro is too long, people will think it's complicated and won't use it. If that's the case, we're again being dragged down by the lowest (of most ordinary) common denominator.
Solutions? How about the Quick Tour, and even the outline/TOC of a full manual, so we can at least skim it and see if some feature exists and then Google/DDG it...?
So, I'd say, google can be wrong, the ideal case is modify your existing tools as needed to maximize discoverability and minimize friction to actual documentation
Games are patched live, browser in constant update etc etc
This looks suspiciously similar to lifecycle of a social media, especially how they grow new features and eventually dies when users migrate.
Maybe it's a viable strategy for a social media, mobile OS, MMORPG, anything aaS to not explain features or educate users, but to grow as users consume added mechanics, until it becomes impossible for new users to catch up and old users to keep up?
Today, they can find the equivalent information for free without leaving the device where the software is running.
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.
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.
> There's little photographers (vs. say, graphic designers) can do in Photoshop that they can't do in Gimp
> Photoshop is far from simple, but both the new user experience and the overall capability vastly surpass Gimp.
I agree with the second you.
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.
Hahaha, really? That's a laughable claim. Tell us how to remove a city from the Weather app then.
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.
Probably the single most useful skill I've had to learn in my life is, whenever you wonder something, just Google it. If you don't think your software does X... don't just assume it. Look it up.
I've been astonished at how often a feature was added 3 years ago to a program I've used for 8 years, or there's a secret swipe that avoids a bunch of menus, or an unofficial command-line flag.
And it really leaves me feeling deeply conflicted. Because on the one hand, I still believe in the virtue of learning your tools inside and out. I would read the manual and be proud I knew exactly what every program/language could and couldn't do. But on the other hand, is that really just a waste of time? Programs have so many features now, that instead of learning all the things via discoverability or a manual, we just learn them by... querying how to do things when we need them.
I don't really like the idea of so fundamentally relying on Google and forums and tutorials and Reddit and YouTube videos as the main way of learning how to use software. But at the same time, software does so much now and adds new things so quickly that it appears to be the only reasonable way.