For the first three years of the millennium, I worked as a technical documentation specialist for what was then an early-stage startup, DataCore Software. In addition to pioneering virtualized storage, DataCore created a gold standard for me in terms of work culture — diverse, transparent, brilliantly innovative, and deeply human. Everyone remembers where they were on 9/11. I’m very grateful I was with this group. (Visionaries from this era of DataCore, mentored by the late CTO Ziya Aral, later went on to develop LucidLink.)

Our core product, SANsymphony, was an operating system for storage. Our first users were UNIX administrators who were used to managing storage by doing the best they could with what they had. They’d never done anything like what you could do with SANsymphony. No one had. So they didn’t just need step-by-step procedures, they needed conceptual introductions in order to understand what they were doing. Documentation was critical. 

Back in those days, Internet access was not ubiquitous. (Neither was XD design.) Our product shipped with a 500-page manual in a four-inch wide three-ring binder. The corresponding interactive help system, which was my baby, was embedded into the software. Authoring tools like RoboHelp, back when it was under the umbrella of Blue Sky Software, were geared towards exporting these files into offline-ready, closed system formats.

To keep content up-to-date and customer-driven, I spent a lot of time talking with engineering, testing, training and technical support. But my main responsibility was ensuring that the same content that was in the manual was integrated into the interactive help system. It was an early example of content design that gave me a solid introduction into information architecture. The search feature only worked for keywords that had been manually tagged (at each instance) and added to an index. Default navigation buttons followed the linear flow of drag-to-order topics, but there was an option to break out into non-linear navigation. That was an important feature when we decided to create a troubleshooting section that addressed our users’ most common questions.   

Offline help systems were the industry standard from the mid-90s to the early 2000s, when the offline user experience was still a common concern. I’m sure software engineers weren’t sad to see them phased out. More variables to package into a build, more things to go wrong. For me, offline help systems meant days, sometimes weeks of feverishly documenting eleventh-hour work-arounds, not knowing when the final whistle would be blown on a stable release. The thrill of closing the chapter on a new version would inevitably be followed by epilogues of technical bulletins and patches, sent off to clients by way of printed inserts and compact disks. (It now makes the marketing parts of me shudder.)

Actual writing samples from the early versions of SANsymphony are lost in the sands (SANs?) of time. They were conceptual and procedural, and strictly followed what was then the Microsoft Style Guide for Technical Publications. They included Visio diagrams that demonstrated networking scenarios. They won the APEX award in 2003 for best hardware/software manual, and hopefully they were a light in the dark for those early SAN administrators, rubbing sticks together to mirror disks and configure alternate pathing.