In late 1987, Microsoft shipped a set of OS/2 1.0 user documentation as part of the OS/2 SDK. The set included the Setup Guide, Beginning User’s Guide (a tutorial style document), and User’s Reference. The manuals were similar in style to DOS documentation from that era and likely produced on XENIX using the standard UNIX document production tools (i.e. troff and related utilities).
The manuals shipped by Microsoft were not entirely finished. Some of the more involved explanations were incomplete, screenshots were missing, and a few illustrations weren’t provided. That said, end users were not expected to see those manuals. Instead, OEMs would adapt (or completely rewrite) the OS/2 documentation provided by Microsoft.
Based on the document numbers, the manuals were almost certainly completed in October 1987. That made the job of the technical writers difficult, since they had to write documentation for an unfinished product. It doesn’t explain most of the missing content though; for example, a “diagram of a hard disk” (Beginning User’s Guide, page 18) could have been produced independently of the OS’s completion.
The reason for the missing screenshots might be that the OS was not finished by the time the documentation was printed. Then again, perhaps it was expected that OEMs might slightly change the visual appearance of OS/2, and Microsoft simply didn’t bother taking screenshots that OEMs might end up replacing anyway.
The User’s Reference devoted over 30 pages to EDLIN, a fact both amusing and sad. It’s hard to believe that EDLIN (only usable in a DOS box!) was the only text editor shipped with a “modern” operating system released in 1987/1988. The situation wouldn’t have been so bad if OS/2 configuration hadn’t been heavily dependent on CONFIG.SYS, a plain text file which users typically needed to edit while setting up an OS/2 system. Users had to wait until OS/2 1.1 (late 1988) for Microsoft/IBM to deliver a modern text editor.
In general, the OS/2 user documentation was comprehensive, detailed, and reasonably easy to understand. Even the more esoteric CONFIG.SYS options such as IOPL, MAXWAIT, or PRIORITY were fairly well explained, although their nuances could not be thoroughly documented in the space of a few sentences.
The manuals were scanned at 600dpi in monochrome and processed in Adobe Acrobat X Pro. Scanning was easy since the manuals were delivered in ring binders.
And here are the manuals in PDF:
OS/2 1.0 Setup Guide
OS/2 1.0 Beginning User’s Guide
OS/2 1.0 User’s Reference
“Feel free to experiment with these commands in your CONFIG.SYS file to see which settings work best for you.”
…and today, mobile apps get bad reviews because they haven’t implemented the stylish new UX paradigm du jour.
We expect so little of users today, or they expect so much of us, or both. I can’t help thinking the “ignorance of how things work is OK if the software is shiny” mindset is going to bite us all in the end.
The knowledge gap between the producers and consumers is widening, which is inevitable with the expanding circle of consumers. No one expected a random teen or a grandma to be able to install OS/2.
The consequence is that if anything breaks, the user is completely clueless. That would be fine if things never broke, but users aren’t willing to pay for FAA-level of reliability 🙂
The other funny thing is that software development is increasingly driven by fashion. I’m not sure many people expected that.
Expanding on aaron’s comment:
I’ve noticed with our customers that not only do they not know “how” it works or “why” it works, but they don’t want to. When I tell a customer that I expect them to have at least a rudimentary understanding of how the machine operates (like shutting down your laptop every so often instead of just hibernating, so updates will occasionally run), they look at me like I’ve slapped their mother. If they knew as little about their cars as they do about their computer, they would never be able to drive because they wouldn’t even know where the key goes.