Well, the flood of comments from the last two weeks of musing on Apple’s software deficiencies continues unabated. Many of your comments are very interesting and insightful – thanks to all who replied and forgive me for not replying individually.
Some of the most pointed comments came from those of you who have noticed that the Macintosh operating system has, for some time, had problems when large numbers of fonts are loaded.
According to reader Russ LaPlante (using Mac OS X 10.3), “Our design group would like to keep 700 fonts available. . . . When they run Suitcase X1 [a third-party font utility] to make these fonts available to the system . . . the [Apple font manager subsystem] chokes on the fonts being introduced. I can see the [Apple font manager subsystem] getting ‘hung’ and using something like 5% CPU while it crawls through the task of loading up fonts. Apple needs to beef up this app, big time.”
I looked around the ‘Net to see whether there are other OS X font management problems. There are. It appears that OS X 10.4 (Tiger) might suffer from the same issues even when large numbers of fonts aren’t involved!
Reader Cliff Sobchuk raised an interesting issue over the desire many of us have “to just use the device” without referring to the manual. He asked, “did the user read the documentation and did the documentation indicate the use of libraries to handle large volumes of photos? If not, please rant as loud as you can to Apple’s Customer Care to get them to rectify the situation.”
What he is apparently suggesting is that I should RTFM (which, for you newbies out there, stands for “Read The Freakin’ Manual”). The answer is, of course, no.
I don’t think there’s any reason why we should need a manual for 99% of modern software. Just consider how complex most recent personal productivity applications are. Manuals for these applications can’t even begin to cover what they can do and if you can’t just dive in and figure it out then to hell with it.
Moreover, physical manuals that have any depth can’t be indexed adequately to make it possible to find things that answer questions the indexer hasn’t thought of anyway.
The only really good manuals are more like books and where you often find these kinds of guides is in the graphics world. By way of example, the documentation for Jasc Software’s Paint Shop Pro and ACD Systems’ Canvas have the organization and style that makes them more than manuals.
Even then, wouldn’t it be better to have the documentation built into the application?
To give the company its due, Microsoft has done a lot of work in this area by adding extensive and searchable HTML-based documentation in many of its products as well as extending the information with extra content acquired dynamically from its Web site.
Another good example of this style can be found in one of my favorite products: Infomersion’s Excelsius. Not only is the documentation embedded, it also uses animated demos of the product’s various components to show how they work. This is the way you get users over the learning hump and make them happy.
Future applications will have to meet far higher standards for educating and assisting users than they do today because the user environment is getting more complicated. Any company with a halfway serious application that doesn’t keep pushing the limits of how well the program communicates with and helps its users might as well not bother. That means there are a lot of companies that need to get busy right now.
Good examples of bad manuals to backspin@gibbs.com. Maybe we’ll put ’em on Gearblog.
