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!
1 Like
The same issue with other apps or processes. If something is the default or most common, Perplexity will veer towards that.
1 Like
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.
4 Likes
More on this topic in a discussion with @podfeet
Tick tock, tech writers