How Siri Could Become the Mac’s New Help System
Using modern software is often less about doing the work than about figuring out how to do the work. Even those of us with decades of experience regularly find ourselves leaving an app to search the Web, skim documentation when it exists at all, read forum threads, or watch YouTube videos to discover how a feature works, where an option lives, or what a cryptic setting actually does. The more powerful the app, the more likely this is to happen. I’m not a graphics guy, so as much as I like having access to all the capabilities in Canva’s Affinity app, nearly everything I want to do requires research (see “Canva’s Affinity Combines Photo, Designer, and Publisher into One Free App,” 31 October 2025).
TidBITS exists largely because of that gap. For decades, we’ve explained how macOS and Mac software works, what features really do, and how to accomplish tasks that aren’t obvious from the interface. We started TidBITS Talk in part to provide answers for more specific concerns, with users asking (and answering!) questions that have caused consternation. Many of these questions aren’t inherently difficult, but built-in help systems are seldom useful, and users often don’t know how to frame a question well enough to find an answer through search. Sometimes, the easiest approach is simply to ask a smart friend. The problem is not ignorance or lack of effort—it’s discoverability.
To be clear, most tech support questions have good answers, just not ones the system can provide directly. The information is scattered across developer documentation, release notes, blog posts, forum replies, and half-remembered advice from friends. Users are forced to assemble understanding from fragments, often without knowing which sources are trustworthy or if the advice applies to the version of the app they’re actually running. The process is inefficient, error-prone, and increasingly out of step with how capable our devices have otherwise become.
That good help is hard to find isn’t a new problem, and Apple has tried to solve it before. What is new is the opportunity to approach it differently. In this article, I argue that Apple Intelligence and Siri could finally fulfill a long-standing promise: letting the system itself explain how its apps work, accurately, contextually, and without forcing users to leave what they’re doing.
Apple has already taken a step in this direction. Starting in macOS 15 Sequoia, Siri gained some awareness of macOS help content and can answer some questions about macOS and bundled Apple apps without deferring to a Web search. (When it does defer to a Web search, it often presents Windows or Android answers. Embarrassing!) That change matters less for what it accomplishes today than for what it signals: Apple is trying something new with system-level help.
However, the current implementation also demonstrates why this problem remains unsolved. Siri’s responses are inconsistent and don’t extend beyond Apple’s own apps, so few users have gotten in the habit of asking. System-wide help systems succeed only when they are broadly and reliably helpful; sporadic insight into a subset of apps isn’t enough to change behavior.
Previous Help Systems
Apple has long recognized the need for a system-wide help system and has made repeated, serious attempts to address it. One of the earliest and most ambitious was Balloon Help, introduced with System 7.0 in 1991 (see “What Good is the Help Menu?,” 29 July 1991). When enabled, hovering over interface elements revealed explanatory text describing each button, menu item, or control. By System 7.5, Balloon Help was often paired with Apple Guide information, which went further by offering task-oriented walkthroughs (see “Future System Software,” 28 March 1994). Together, they represented a coherent effort to make the system explain itself in context.
Balloon Help was genuinely forward-looking but ultimately collapsed under its own weight. Functionally, it was slow and hard to enable, so it quickly led to third‑party utilities that made toggling it easier. It also often obscured the very interface it was meant to clarify. More importantly, the utility of Balloon Help depended on developers writing good descriptions, which many did unevenly or not at all. Apple Guide, while conceptually elegant, suffered from the same problem.
In Mac OS 8.5, Apple tried again with Help Viewer, an HTML-based online help viewer (see “Delving Further into Mac OS 8.5,” 26 October 1998) that Apple opened up to developers in the next release (see “Apple Rolls Out Mac OS 8.6,” 10 May 1999). Help Viewer made the jump to Mac OS X, though Balloon Help and Apple Guide did not (see “Mac OS X Report Card: October 2002,” 7 October 2002). Help books shipped within apps, were indexed by the system, and were searchable, all things requested by developers and users.
In theory, Help Viewer provided richer content, consistent presentation, and centralized access. In practice, Help Viewer has quietly faded into the background of most users’ everyday Mac experience. People rarely opened Help Viewer proactively, search results were often vague or outdated, and many developers treated help as an afterthought, both because the tooling was awkward and because writing good documentation is genuinely hard. As Web search improved, attention shifted from in-app help to Google results, forum posts, and video tutorials.
What survived from Balloon Help is its least ambitious descendant: tooltips and menu item descriptions. (We also joked that it’s where Apple got the idea for conversation styling in iChat, now Messages; see “Jaguar: Mac OS X Prepares to Pounce,” 6 May 2002). Tooltips are still genuinely useful, and they embody the part of Balloon Help that worked best—brief, contextual hints. But they are intentionally shallow. They explain what a command does in a word or two, not how or why to use it. They improve discoverability in small ways but don’t meaningfully reduce the need to look elsewhere.
The takeaway is that Apple has genuinely tried to solve this problem multiple times over the decades. Developers often produce weak documentation and in-app help, but that’s usually due to limited time, resources, and ability rather than a lack of desire; all developers want to reduce support costs. Even today, Apple continues to address the problem through online user guides, the Tips app, and Siri answering user questions. What has been missing is a help system that can adapt to context, stay aligned with the running version of an app, and draw on multiple sources of knowledge rather than relying on static pages—qualities that Apple Intelligence, if applied carefully, is positioned to provide through Siri.
A More Helpful Siri, Not an Agent
Apple keeps talking about a “more personalized” Siri, but an easier—and likely more helpful—step would be to give Siri deeper awareness of its machine environment so it can explain how to use all available apps and tools, rather than focusing primarily on personal data. Many questions users have aren’t about themselves at all; they’re about the software in front of them. What does this feature do? Where is that setting? Why does this option behave the way it does? How would I accomplish this task?
Answering these questions does not require Siri to take actions on the user’s behalf or attempt to drive interfaces. That approach has historically been brittle, and the recent focus on autonomous agents—such as the security issues now surrounding OpenClaw—underscores how quickly complexity and risk can outweigh practical benefit. For now, the safer and more valuable role for Siri lies in explanation, not execution.
Explanation is entirely achievable today. A more helpful Siri that can answer questions in plain language—naming features, clarifying concepts, and describing where to look—would address a large fraction of users’ everyday friction. Even something as simple as identifying what a feature is called can be enough to unlock further exploration, whether through menus, settings search, or additional documentation.
In addition, explaining software helps users build mental models of how an app works; performing actions for them bypasses that understanding. For tasks users expect to repeat, learning how something works is always more valuable than having it done once on their behalf.
Just as importantly, explanation fails more gracefully. If Siri’s role is to advise, being incomplete or occasionally wrong is an inconvenience, not a catastrophe. Users can verify, adapt, and continue. That kind of failure is tolerable—and familiar to anyone who has read an outdated article or received bad advice on a discussion forum. By keeping Siri on the explanatory side of the line, Apple can make it useful without eroding trust when it inevitably gets things wrong.
Where Will a More Helpful Siri Get Its Information?
For Siri to explain how apps work in a way users can trust, it must draw on multiple sources of information. No single repository of knowledge is sufficient, and pretending otherwise results in incomplete or even misleading answers. A more helpful Siri should rely on a three-layer model that acknowledges that different kinds of information are authoritative in different ways:
- Layer 1: Developer-Provided Documentation: The most important source is documentation provided by the developer and bundled with the app. When developers take the time to describe features, workflows, and constraints in a structured way, that information should be treated as canonical. It reflects how the app is intended to work, applies to the version installed on the user’s device, and eliminates the guesswork that comes with using external sources. If Siri is going to explain the impact of a setting or how a feature functions, documentation from the horse’s mouth is the place to start.
- Layer 2: Implicit Information: Some questions don’t require documentation at all, just orientation. Users often want to know what a feature is called, where it lives, or whether a capability even exists. macOS already has access to a limited but reliable set of structural information about every app it runs: menu hierarchies, toolbar items, keyboard shortcuts, accessibility labels, automation dictionaries, supported file types, and configuration panes. This information isn’t deep, but it is always present and version-accurate. Siri should be able to use it to answer basic “what” and “where” questions, identify the correct terminology, and point users in the right direction, reducing friction without pretending to replace real documentation.
- Layer 3: External, User-Generated Knowledge: In reality, developer documentation is often incomplete, overly abstract, or focused on how features work rather than how people actually use them. That’s where Web-based, user-generated knowledge becomes essential. Forum posts, blog articles, and troubleshooting guides often capture how software is actually used, not just how it is intended to work. They reveal edge cases, workarounds, and limitations that developers either don’t document or prefer not to acknowledge. Developer documentation rarely says that an app can’t do something, whereas users are quick to explain what doesn’t work and how they cope. User-generated knowledge is less authoritative, but more candid and often more useful. It shouldn’t replace official documentation, but it’s essential when local sources are incomplete or lack task-oriented guidance.
Siri needs to draw from each of these layers appropriately. Developer documentation should generally carry more weight than a random forum comment, but a detailed blog post describing an expert workflow is likely more useful than a terse official description. In its responses, Siri should indicate whether specific details reflect documented behavior or common practice, and any external information should be cited and linked so users can assess its relevance.
Getting Developers on Board Through Xcode and AI
A strength of this proposal is that it benefits from developer participation without depending on it. Our more helpful Siri can still fall back on the structure of the app and widely available community knowledge to answer many basic questions. These Layer 2 and Layer 3 information sources ensure that there’s always some sort of answer.
That said, developer participation would dramatically improve the quality, precision, and reliability of Siri’s answers. When developers describe their app’s features, particularly in a structured way, that information can underpin explanations about how the app is intended to work. How then can we encourage developers to write in-app documentation when such efforts have failed in the past?
First, we have to acknowledge that developers who document their apps typically do so on the Web, using whatever tools fit their workflow, because that’s where documentation has the clearest payoff in supporting existing users and providing pre-sales information to potential buyers. Asking developers to write separate help content just for Siri would repeat the mistakes of Apple’s earlier help systems. Instead, Apple should support developers in writing documentation that can be reused across multiple uses.
Apple’s Xcode development environment is well-positioned to help here with the help of AI. Xcode already understands enough about an app’s structure to generate a useful starting point: a map of features, their names, and where they live in the interface, supported where possible by comments in the code. What if Xcode automatically drafted this baseline and then prompted developers with focused questions about intent, usage, and limitations—information only the developer can provide? (I’ve found that asking a chatbot to ask interview questions, one at a time, and answering them via dictation is a good way to collect thoughts.) The result would be structured information that the developer could then refine.
From that source, Xcode could produce bundled, versioned help for Siri to consult locally and export clean, search-friendly Web documentation for online discovery. Developers who opt in would get better Siri answers, fewer repetitive support questions, and cleaner onboarding for new users. That’s the carrot that Apple Intelligence is positioned to dangle.
Making Apps Deeply Discoverable
The payoff for users from an Apple Intelligence-powered help system should be obvious. A more helpful Siri that can reliably answer questions about how apps work would reduce the time users spend searching the Web, skimming forum threads, or watching videos just to solve small, specific problems. It would also slow the steady stream of basic questions that flood support forums, freeing those spaces for deeper and more interesting discussion.
More importantly, good help leads to better understanding. When users can easily learn what features exist, what they’re called, and where they live, they develop stronger mental models of the software they use. That confidence makes it easier to explore new capabilities, use advanced features, and become expert with complex apps.
Apple has been circling around this problem for decades through various help systems, none of which have quite solved it. With today’s large language models, richer app metadata, online resources, and tighter system integration, it’s now possible to provide accurate, contextual help directly within apps.
The real question is whether Apple is now willing to treat help as a first-class operating system feature open to all developers, rather than an afterthought or something limited to bundled apps. If it does, Apple Intelligence could give Siri a genuinely useful new role—not as an agent or a personal assistant, but as the help system Apple users have needed all along.
All software suffers from this. Good software developers are rarely good tech writers or graphic designers. And vice versa.
You rarely get really good documentation from small projects, because they can’t afford a team of experts who can write the documentation. And even the big companies often don’t bother, because they consider documentation to be an added expense that doesn’t add value to a product.
No amount of OS-level features can ever change this.
A chatbot isn’t likely to get better “Layer 1 - Developer-provided documentation”, because it is going to be subject to the same problems that cause all other help/documentation systems to fail.
The other two categories may do a lot better, but the layer-3 data won’t exist until the product has been around long enough and has gotten popular enough for a pool of knowledge to build up.
Assuming Apple follows Adam’s suggestions, I think the part about “Getting Developers on Board Through Xcode and AI” offers a solid way to improve layer 1 in a win-win way for both Apple and its developers. I know that I have numerous pieces of software that are much more powerful and useful than the way I normally use them; often because it’s too hard or time consuming to figure out what they are and how to use them.
Another thought, and this would likely be down the road a bit; a next step might be an intelligent Siri that could watch how I use an app and, when appropriate, offer a suggestion on how I might use the app’s features more effectively. The key here for me would be that it “suggest” without trying to do it for me.
Good article Adam!
If this ever comes to pass, please let it be optional — we don’t need an Apple version of Clippy.
With respect to Adam’s article. For the most part, I’ve replaced web searches via traditional search engines with inquiries to an answer engine. When it comes to figuring out software, I can post an inquiry and refine it to get a more precise answer. The engine I use, Perplexity, also provides a source reference for its statements, so I can verify its assertions (it sometimes goes beyond what the claimed source says).
You may have noticed that many of my responses to questions raised on Tidbits Talk provide links to sources. That usually comes from me posing the question to Perplexity and finding a source that provides a more definitive answer than I can write.
Reminded me of a University of Maryland course I took when I was stationed in Germany back in the 80s. It was on Technical Report Writing. Of course 40 some years later I don’t remember much of it! Too bad small developers couldn’t take a similar course in their local college extension classes.
Brilliant proposal, Adam. This is a strategic proposal for Apple to implement, as this approach will take time and require a long term commitment. Levels 2 and 3 are the kinds of things that can be built soonest. I’ve been impressed with my experiences with Anthropic’s Claude when I need to crack a coding nut. The references and proposed code always beats me digging through my own notes and online searches, and saves me from the occasional warring arguments online. I think Level 2 and 3 is doable now
Level 1, especially if it’s ‘auto-coded’ through x-code is the exciting idea.
In my mind, an analogy is inter-app communication was the carrot that drove (drives?!) AppleScript and the desire for app developers to integrate Dictionaries in their apps. Do all app developers provide Dictionaries? No. Do many? Yes.
So back to the idea of ‘auto-coding’ the Level 1 help system. It might not be adopted immediately by all developers, but will some developers adopt it? I’m betting they will. Developers like Culture Code, Omni, and Bare Bones have solid documentation. Would they be pioneers of this? I hope they would.
The idea that Siri could become the OS and App help system is a worthy experiment for Apple to adopt.
Well done, Adam!
By the way, Adam:
“as much as I like having access to all the capabilities in Canva’s Affinity app, nearly everything I want to do requires research”
It’s not that you’re not a graphics-oriented user. The original Serif applications, Publisher, Photo & Design, while very good in many ways, were hardly transparent; and Affinity is a stew, frankly.
I’ve used Publisher extensively for five years or more, setting a fairly big bimonthly newsletter in it – and use Photo regularly. While I have ready understanding of the fundamental DTP controls in Publisher, there are corners of the app I don’t make sense of; and in Design plenty eludes me. And the ‘Help’ isn’t very helpful…
It’s not just you!
This is extremely well-thought-through and correct in every detail. Excellent! I hope Apple listens!
What I am desperately waiting for is some clever application of AI in Apple Mail. I have loads of nested mailboxes that contain my work mails and I spend a lot of time sorting my incoming mail into these mailboxes, so that my Inbox only contains mail that still requires some action. Mail proposes a mailbox in the menu, but this is invariably based only on the sender’s email address. There is a wealth of information available in the subject header that would be much more useful, but which is completely ignored. Most of the time I have to bypass the suggestion and manually scroll through the list of mailboxes, which takes multiple seconds per message.
Great article. I am sure people at Apple read your stuff, so let’s hope they take this on board.
Speaking as someone who has from time to time had to write help, I can confirm that it is genuinely hard, and yes, a skill that not all developers posess. One approach is via ‘use cases’ – what might users want to do in an app, and how to do it. In the days of printed documentation we used to discriminate between a ‘user guide’ – how to do stuff – and a ‘reference guide’ – what all the bits are for.
I have generally found most in-app help all but useless right across the board, and forums (fora?) might give you the answers you need if you are prepared to spend a whole lifetime looking for them. Now we have chatbots, my go-to one being Anthropic’s Claude, and Siri has a long way to go to catch up.
The worst examples I can remember are searches in Microsoft’s on-line ‘help database’, with it’s 400,000 answers to a simple question. Many of you will know this already, but it’s worth retelling the old joke about M$ help.
An executive is travelling by helicopter from his home to Seattle airport when fog comes down. This is unfortunate, the the heli pilot and his machine only cleared for clear air flight. Panic ensues, when a tall building looms out of the mist. On inspiration, the pilot gets his passenger to write ‘WHERE ARE WE?’ on a large sheet of paper and hold it to the window while the pilot flies slowly around the top of the building. The guys inside scrabble around and soon hold up their own sheet of paper, which reads ‘YOU’RE IN A HELICOPTER’.
Without hesitation, the pilot plots a new course and flies safely through the fog to the airprt. His passenger is amazed: “How did you do that?!'“. “Simple”, replies the pilot, “The answer was factually correct but damn all use. That told me it was the Microsoft building.”
It’s really a shame, because (a long time ago), their documentation was wonderful.
When I started college in 1987, I received a copy of Microsoft Word for DOS (version 3, 1986) as a part of my computer bundle. In addition to having a good printed manual, it included several floppies containing interactive tutorial apps. These apps walked you though all of the app’s features and by the end, you knew how to use everything. It took me about two days (part-time) to go through all the lessons.
A few releases later (version 5.1, 1991, I think), they dropped the tutorial discs, forcing you to learn the app from the manual, which didn’t work nearly as well.
A good justification for their excellent, original printed manuals!
Which no one read.
Making a better Level 3: prioritizing ‘trusted information’. Sometimes, what I need to know is in, e.g., a Take Control book that I already own (and meant to read/have forgotten a detail of). If my own collection of trusted resources were a prioritized part of the search and presentation of the solution, it would both be more likely to be a right and useful solution for me and an encouragement to buy (and to remember to read) more help books that I know are trustworthy and useful.
I have found AI (ChatGPT, often) to be such a time-saver this way. I feat the suits will say the same, and blow off your excellent thoughts on this.
There are no easy answers here. You have to know your audience as well as your subject, and knowing your audience is tougher. When I wrote Understanding Lasers, Understanding Fiber Optics, and The Laser Guidebook, I was writing for industry trade magazines and knew the audience. The first editions of all three came out in the 1980s, and I was introducing new technologies to readers of my books as I had been explaining new technology to readers of laser magazines. It was a big broad task and all told I reached around 150,000 readers.
But when you’re writing for Mac users you have to reach a much much larger audience and a vastly more diverse one. You have to write for people from 10 to 100 with educations from grade school to PhDs, and from immigrants whose English is shaky to top scientists and scholars with PhDs in Byzantine History. You can’t assume much about your readers, so you don’t know whether or not you can use an acronym or industry buzzword. I could get away with using laser geek speak – industry jargon – as long as I explained it first, but you can’t do that with an audience in the hundreds of millions. You can’t do it right without doing hard work, and the industry does not want to pay for that.
You are a better person than me. Photo and Design are both readily understandable to me because they are modeled after a certain 800-pound-gorilla’s functionally-equivalent applications.
Publisher is still poorly thought out and organized. The huge deficit is in importing content. The 800-pound’s InDesign, and PageMaker before it, were both conceived as Rosetta-Stone-style content hubs, where content is created in the text or graphics application of one’s choice and then integrated into a publishable document. Import (integration) is aided by a myriad of content translation filters. I’m a now-lapsed expert in both systems, including their scripting languages.
Publisher seems to be more of a copy-and-paste integrator, at least in my experience, and I am never quite sure how things are going to land, be altered, or otherwise macerated on their way in to my document. I find myself using the documentation way more when I’m trying to lay out a publication, and it doesn’t help that Publisher has defaults like “12 pts space after paragraphs” baked in to its DNA.
So yes, it’s not just you, me, or them.
[long post]
Here’s a use case that involves AI, no Siri, but is in the spirit of this excellent proposal:
I produce music notation these days using Dorico. It’s a stellar application produced by brilliant humans, and includes help in the form of an exhaustive HTML-based system meticulously developed and curated by a very gifted human.
Dorico has its very own world of notation standards, and if you are grounded in other notation software as this 30-odd year veteran of Finale is, you have to learn how to “think like Dorico.” And Dorico, er, thinks different.
One blind spot in the docs is that they sometimes presume the user is approaching a problem the same way Dorico does. An example is Tuplets. (Tuplets are those notes you see in engraved music that have a number over them, like this:
Musicians know that standard meter (“beats”) is divided like so: 1 whole bar, divided in 2, 4, 8, 16, 32, 64 and so on, exactly like base 2 numbers. If you want the performer to divide a beat differently, then you need some form of tuplet, such as the “3” indicated by the orange arrow. Tuplets can divide a beat into any ratio of divisions, such as 2 or 7 into 3, or even be nested within another tuplet. Good luck and well done to performers handling those!
Dorico by default will divide a beat into 3 when a tuplet is called for. But what is presumed is that Dorico is calling for 3 sub-beats in the metrical space of 2 sub-beats. Because you can indicate the tuplet with the single character “3”, it is not obvious that Dorico is actually notating this with the specific ratio “3:2” (or “3 sub-beats in the space of 2”).
The documentation presumes the user knows this, and so does not provide that explanation or any other to show how the tuplet may be called for. The examples presume the user is “thinking like Dorico” without revealing how Dorico thinks about a tuplet. In the Dorico user forum, asking for an explanation would yield a mix of unhelpful responses and, maybe 20 replies in, one user who accidentally reveals the construct the program uses and is very helpful indeed. No knock on that forum—much like TidBITS Talk which is also platformed on Discourse, the conversation is mostly civil and moderated.
So, I turned to ChatGPT, and asked the very specific question:
This is a question I could ask of ChatGPT without shame. And the response was brilliantly laid out, conceptually accurate, and included both specific examples and a general rule that was specific to the Dorico 6.1 application.
I can only presume that OpenAI allowed its LLMs to read and train on both the HTML help files, which are carefully tagged for application version and platform, and the Dorico help forums. But the result was exactly what @ace Adam was describing in his essay, at least for Layers 2 and 3, and I would argue Layer 1 was heavily incorporated as well. Unlike canned documentation, the ChatGPT bot allowed for a conversational followup that made it easy to ensure I understood what it was saying.
Orienting Siri and Apple Intelligence toward a System-aware help system in this manner would lift a lot of veils, because the response can be contextually tailored to the user’s knowledge level based on the prompt. “I don’t understand how to get Mail to sort my messages for me! Show me how Mail does that, and tell me what I need to do to get started.” Because Siri would “know” which version of xOS and Mail are in use, it could start with a response tailored to the user’s specific circumstances rather than a general survey of Rules.
I think Adam’s insight may be a key to making Siri relevant instead of a novelty.
I attended a programming conference a few years ago when ChatGPT was new and LLM-based AI was just getting going. One presenter did a talk on AI and basically pointed out that if computers can really understand us via voice, it changes everything about programming. Basically, user interface, as we know it, is done.
Experts in a topic (such you with music notation), can just describe what you want in your own way and the AI can understand and implement. No more need of complex UI that is only “intuitive” to a select set of minds.
More than half of programming today is creating the user interface. With no UI needed, just voice, programmers can have more time to do focus on the core product.
Language/culture becomes less of a barrier. Instead of having to write software that works in multiple language and not supporting rare and exotic languages such as a small country in Africa, the user can just talk in their own language and the AI can understand.
“Help,” so to speak, is not really necessary since the AI does all the work. If something doesn’t work right, you just tell it what you really wanted and it does it.
I think this idea is brilliant and definitely the future… though it may not happen as fast as we think and there will always be some need for user interface in certain situations (or as a backup for voice as voice isn’t always the ideal interface).
This also potentially changes the complaints in the anti-Liquid Glass camp and those who think Apple’s UI skills have gone downhill. Even if that’s true, it might not matter in a world where voice control is the OS!
Who cares what the Pages icon looks like or the menu icons are inscrutable if you aren’t seeing any of that because you’re talking to you computer instead?
I have hacked up Keyboard Maestro to replicate the function of the sadly defunct Mailhub, so that I press “/”, then type the first few letters of the relevant mailbox, then Return (or Command-Return, which is my habit), to stick it where it goes. Saves me tons of time.
I appreciate the support, but I had exactly the same problems with Adobe Photoshop and Illustrator when I still subscribed to Creative Cloud. Too many little icons!
I almost wrote a section about that. There’s no question that the chatbots do a pretty good job of offering suggestions, but they often suffer from not being able to distinguish what version you’re using, so it’s common to be told to use controls that no longer exist. The big advantage Apple would have is being able to peer into the app structure to some level.
I may not care much about icons, but I can’t dictate at all, and the talking to AIs is a type of dictation. I write on screen, look at what I wrote, and rewrite until I like it. All people do not work in the same way. What works for some people will not work for others. This is a fundamental problem of any help system that is supposed to work for everyone.
I think SIRI should be fired and Adam put in it’s place: he has excellent answers to most Mac questions and is definitely helpful!
On the subject of useful user manuals, I always would buy David Pogue’s “The Missing Manual” when new MacOS versions were released. I’ve never been comfortable with online manuals because I have to launch them and they then cover up the application I’m having a problem with. I prefer a printed manual I can have open on the desk beside my Mac.
BTW, I just placed a pre-order for David’s new book “Apple: The First 50 Years”
I’m 88 years old, and have been a Tidbits supporter for years. I remember Adam and Tanya making presentations at SDMUG in its infancy. I’m a retired musician who still uses music software, and now Final Cut ProX for making videos. For decades it has been so difficult getting support and answers to problems using this specialized software (and most everything else, for that matter). But in the last months, I’ve been able to go to Safari, ask a detailed question about using FCPX, Dorico, as another person mentioned, Logic etc. and get precisely the information that I need to continue my work! It’s fucking unbelievable. If I were still working for a living, this would be a life changer—so much time saved. So much more productive. I must be good at asking the questions, because I seldom get wrong or misleading answers. And it is not unusual to be asked if I want to dig deeper into the topic. I don’t know what Apple Intelligence is using, and I don’t care, I’m just happy that finally, some meaningful help has arrived after all of these years. True, it isn’t in-app, but Safari isn’t that far away. Hallelujah!
It really feels that way, Miles. If what I want to do is my project, I want an answer so I can move on.
It’s worth mentioning that the Dorico docs writer weighed in on a thread about another user’s experience with using ChatGPT to get an answer that eluded them in the help files. The writer felt understandably defensive about their work, and pointed out all the links and subtle gems that they had buried in the system.
The point they were standing beside was we want to carry out our projects, not comb through documentation. The original Mac’s brilliance was grounded in the interface being self-evident. Controls and menus worked exactly as a user thought they should work.
Things have gotten much more complex in the past 45 years, and “the computer that you can use without looking at he manual “ now has both too much and not enough documentation.
Being able to ask a semi-knowledgeable question and get a focused answer is potentially Siri’s hidden superpower.
That was the basis for the tag line “The computer for the rest of us.”
Agree with everything you say, but you still have to be careful.
I just decided to install WhatsApp to follow some friends in France but was worried about the default install which grabs everything in your address book (it’s been that way since its inception) but I remembered catching somewhere that you could now limit the contacts it could harvest. So I asked Claude about that and it said that you couldn’t do it short of extreme workarounds. Hm, said I, let’s just do a web search. Lo and behold, IOS 18 put in the ability to select the contacts in the address book that an application can see. I pointed this out to Claude with a url reference and the response was, ≈"Gosh! You’re right. I’m out of date."
The responses from the more recent LLMs are getting really good but don’t go round assuming those responses have been run through the mill of tech writers, copy editors, and publishers who have a monetary interest in making the information correct and truly up-to-date. And when it comes to technical instructions that’s a big deal. Hand-waving around the true impact of Mongol horse manure on Turkic agriculture in 1200 has a little more LLM wiggle room.
Dave
I have been thinking about this for ages, but there are two problems:
One is that, like all data, metadata is usually what is missing.
Two, the desire to do it.
Machine learning is at its best when presented with a good data set that is tagged, where relationships and patterns can be deduced, so that meaningful output can be generated.
My feeling is close to Adam’s, in that the information should be apparent from scanning the application itself. Every menu item, every button, every function, needs a structured way to declare itself to the help system. Notwithstanding that writing a manual for your own SW makes for much better code (because you plainly see the absurdities you have made for yourself), this form of declaration could be easier to write and maintain. It might even be made compulsory in the App Store eventually.
I envisage a table of entries declaring properties such as purpose, starting conditions, appearance in the UI, the transformation applied, reversibility, version limitations, etc. ML specialists can better devise ways to design this metadata for the model they use. There are many possibilities. The primary goal, from the user’s POV, is always purpose and meaning.
Awards were won in the past for the quality of Apple’s documentation, but I see no desire to even attempt this level of commitment today. Ex-Apple people have often commented of understaffing of SW development, and I think the corporation no longer institutionally cares about this, seeing the state of their developer documentation.
Yes, superior help and discoverability would be a valuable asset for burnishing the value of the platforms, but does a $4T corporation even register this factor? The idealist visions of the founders are long gone.
Mostly. I remember a lot of people being very confused by the trash can’s dual “throw things out/eject a disc” functionality. “This isn’t going to erase my disc, right?”
Nooooooooo!
This is a really important point. If you ask a chatbot about something that matters and you don’t see it doing a search while building the answer, follow up with “Confirm with a search.” That forces it to go out and double-check against current results and produces either confirmation or a mea culpa and new answer.
That sounds worryingly like a strategy my wife could use profitably with me.
That’s part of the Apple Spouse feature in OS 26.4, which we’ll keep discussing over here:
Yes, and my reflection on the experience I related is that everything I asked was circumscribed and could be sanity-checked. I think what @ace is suggesting is in a very different sphere from the “Let’s have Claude write program code for us.”
I’ve had a couple of frustrating experiences where I experimented with asking ChatGPT to propose formulas for Apple Numbers. It was really good at sounding plausible, and even better at hallucinating solutions. The most common one was conflating Numbers’ capabilities with those of Microsoft Excel.
The third thing it was good at doing was “Sorry/Not Sorry” responses when challenged.
The great thing about Dorico’s online help is that every article includes tags for the versions to which it applies. I can see where a tightly-trained, internally hosted AI reference tied to Siri would avoid version and platform errors.
The Trash Can was a whole lot of paradigm hurt because of that.
When Microsoft introduced Windows 95 they included a “Recycle Bin” as a sort of dig at you/not copying you gesture. It was, of course, even more obtuse.
But of course I’ll stand with the “mostly” crowd here. Somewhere deep in storage I have the spiral bound manuals for my Mac SE, and the pages don’t have any signs of wear.
It was weirder than that. The “Eject” menu-bar command would eject a disc, but leave it mounted (as a grayed-out icon) on your desktop.
The intent was so people with only a single floppy drive could perform actions that should require two drives (e.g., copying a file from one floppy to another). You could eject one disk, insert another, and then drag an icon to the grayed-out floppy. The system would then eject media and prompt for the other disc as necessary.
In the context, dragging to the trash made sense - it would remove the icon from your desktop in addition to ejecting the media. But most people were not geeky enough to figure out/understand/approve of that paradigm.
Interestingly, Apple eventually resolved this (sort of) in Mac OS X (not sure which version) by making the Finder’s trash can change to an “eject” logo when you’re dragging a storage device.
I’d forgotten about the copying thing as the motivation, but in any case the example definitely undercuts the point that the original MacOS was so obvious that it was self-evidence to any user.
That’s one reason why an AI-based voice recognition system could be revolutionary. Everyone just talks to it at their level. The physicist can use big words and jargon, and the layperson can use every word, and the AI will understand.
If some people want advice or help and others want the AI to actually do the task for them, the AI can accommodate both options.
The most successful use of AI I have seen is Otter.ai’s transcription of interviews of people who speak English with a thick accent. However, I think the Otter system may benefit from not having to respond in real time. I can understand recorded interviews better if I play them back at half of three-quarters speed.
On the other hand, the AI system TurboTax is using for customer “support” when I called last night was an almost total failure. I tried to explain that TurboTax would not accepting my Activation Code but it could not understand that. Nor would it understand “human,” only offering to send me instructions. When I finally accepted the offer for instructions, the link it sent me was to a dead page. That is fairly typical of my experience with speech recognition from help lines, but it might be because people calling help lines usually are already annoyed.
Hopefully if anything like this is in the works, it will be much more inclusive than software. Apple wants people to use their entire system of devices and now have unified the OS system version numbering. Getting the iPad, iPhone, Apple Watch and iMac all on the same page is a herculean task (and I mean the stable cleaning one). The Apple advice is always the same: wipe everything, update to the latest system on all devices and then restart them all.
As someone who uses Finale infrequently enough that I typically am searching for answers at the start of every project, I have been dragging my feet with the forced switch to Dorico, but your posts are making me feel like it won’t be that bad/that my lack of being great at Finale may actually make the transition easier than anticipated, so thank you for giving me a bit of hope there!
The same issue with other apps or processes. If something is the default or most common, Perplexity will veer towards that.
I remember the weird aspects, and also how it resolved. My Mac SE had the single 800K drive (double-sided, but not high density!), and a 20 MB internal hard drive. So it made sense to me that the Desktop would “remember” an ejected disc, because it would need it back at some point.
But that may have made sense only because I had previously (in early 1985!) worked with an original Lisa, and then with a Mac Plus with the dual drives. I was in that geeky population, I guess.
Even those very first Macs had text-to-speech capabilities, with “Fred” becoming an iconic pop voice of the period. In my opinion this is one of the foundation stones that was laid for the eventual “Siri” paradigm, because speech was woven into the Macintosh culture from the beginning.
<Engaging “Back In My Day” Mode>
System 7’s Balloon Help was a clever idea, and I really wanted to see it work out, but it had some fatal flaws:
First, it was deadly slow. It didn’t so much pop up when you moused over things as it decided after a few moments of hovering that “yes, the user is interested in this, and perhaps it might be a good idea to go out to the disk and load the resource to display the content, so just hang on while I rummage… and rummage…. and rummage.” If you weren’t there, remember: it’s entirely possible that your WiFi today is faster than some hard disk interfaces then. System 7 was running on the bleeding edge of what was possible on a 68K processor in 1991.
Second, it was a pain in the fundament to write for. Each bit of content was in a separate resource. There was a BalloonWriter app, but it was buggy as all get out. I know they tried very hard on it, but I remember being driven to distraction by it. I remember needing to do everything in ResEdit, and it was not strongly optimized for use by tech writers. Since you had to work on the raw resources, that meant coordination with the development team, who never ever want to spend time dealing with end-user documentation if they can possibly help it.
Finally, BalloonHelp was optimized for delivery of tiny pieces of content. It was at its best when it delivered sentence fragments, not complete chunks of content. It’s a very tough skill to write meaningful content that is that tight. Very few people can do it really well. And it’s only really for “what’s this thing do?” or “what data do I put in this field?” help. All too often, users (and product managers) want that sort of thing to be “How do I use this to make my life better/easier/faster?” That’s just not what BalloonHelp was for.
So why does it matter? Simply this: BalloonHelp was a clever idea and an interesting implementation that demoed well in specific environments… but it probably never should have shipped. I think Adam’s right that AI systems have great possibilities for the future, and they need to be explored… but I’m not sure they’re ready for prime time yet. I’ve seen AI search engines mangle some stuff that I’ve written to completely reverse what I wrote. We need the engines to get better at actually connecting the user questions to the correct answers.
tl;dr: AI user assistance is a great idea. For now, AI help is not even at the Beta stage.
Oh, wait: “Hey! You kids! Get off of my lawn!”
Ok, I’m done.
More on this topic in a discussion with @podfeet
Tick tock, tech writers