I didn’t wake up one day in 1984 and say, “I’m going to optimize this print workflow.” I don’t think I really knew what a print workflow was. Back then, I was an undergraduate at the University of Wisconsin, pursuing a double major in Journalism and History. I had a student hourly job at the Trace Research & Development Center where I compiled listings for their publications for disabled people. Back in the mid-80s, there was a lot of attention on the use of computers to assist disabled people, but the center also focused considerable effort on low-tech communication aids and environmental controls.
When I inherited the job, all the product listings were stored in individual WordStar word-processing documents. One product, one listing, one file. It was a mess to maintain. And then one day one of the biggest vendors of communication aids moved. That meant I had to open a zillion single-page WordStar files and change the vendor’s address. Over and over. (Keep in mind that this is the early era of DOS.)
Once I got to the other end of this repetitive-stress endeavor, I declared, “We should put all this in a database. Then we could store the vendors once, and link each vendor to their products.” I really didn’t have much idea what I was talking about. I’d left the College of Engineering after my freshman year, but I’d taken some basic computer programming classes while I was there. I’d never made a database, or as far as I knew, even used one. Still, it makes sense, doesn’t it? Why were we storing all this static text in WordStar files that are impossible to search, difficult to maintain, and subject to loss if a disk fails? (Oh, I forgot to mention the WordStar files were stored on floppy disks, back when floppy disks were still floppy.)
Dave, the chief engineer, declared what I was describing “couldn’t be done” since it was all text. Databases weren’t for storing text – they were for storing data! Silly kid, studying advertising. What could I possibly know about data?
I didn’t know much about data, but I know this about myself: when someone tells me something can’t be done, I tend to get very motivated to prove them wrong. So I did.
I was a low-paid hourly worker, and I was pulling more than my weight already by handling all this writing and editing. This meant I had a lot of latitude to tinker as long as the real work got done. So I found some dBase II disks and taught myself how to make it all work. I set up two databases – one for products, capturing all the information in the WordStar documents, and another database for vendors, which I linked to the products database. I’d just created a relational database, just like the front of the dBase manual said I could.
I honestly don’t remember how I got the text out of WordStar and into dBase II. I’m sure it was not pretty. I think I’ve blocked the memory. But soon I was managing the data in a database, and it got the attention of some of the higher-ups. They were contemplating changes to the format of the publications, and I’d separated the content from the format. Since the data was no longer locked up in static WordStar layouts, we had some flexibility to spin the output in a different way. Soon we were re-thinking everything about the publications. It was great that my scheme to make my own work easier was inspiring so much brainpower on other aspects of our publishing process.
I started taking a hard look at the single-page product entries. I figured out how to eliminate some redundant information, remove the vendor’s address altogether, and change the typography. Suddenly, we had ample room for two entries per page – each with a photograph or a screen capture showing the product. Wow!
Several months before our annual publication deadline, we switched from WordStar to Microsoft Word. Word had a clever way of storing formatting information – hidden from the user – at the end of each paragraph. Engineer Dave, who had completely reversed his position that this couldn’t be done, actually got very excited about what I was doing and spent some time writing some dBase export routines that actually embedded the hidden Word paragraph formatting codes as the text was exported from dBase. It took all night to do an export, but the next morning, all we had to do was open the export file in Word and it would magically format itself. It took a few tries to get it right, but we had it down by the time we did our final push to publish.
By the time we published the 1986 version of the resource books, we were dumping data directly out of dBase to create the formatted entries, categorical indexes, and a formatted list of vendors. We still had to have the printer strip in the product photographs and screen captures, but we’d greatly reduced our production cost and our time to produce page originals. Oh and our printing cost dropped by nearly half because we were printing two products per page now, instead of just one.
I can’t tell you how rewarding it was to have my ideas – as the lowest of the lowly hourly workers there – embraced by people further up the pecking order and improved upon by their own ideas and years of experience. In the end, we’d figured out how to use technology to more quickly produce a better product at a lower cost.
It all sounds pretty hokey today, but it was pretty out there for the mid-80s. This was a time when most things that went to a printing press were still typeset by a human reading off a hand-written manuscript. And here I was, in some unfashionable corner of a UW research building, making about $4/hour, pushing the envelope and balancing on the cutting edge of database publishing
In 1986 I took my first job in marketing at a software company and left TraceBase (well, what else would we call it?) in the hands of a good friend who cared for and fed it – and its successors – for nearly a decade. When I left the Trace Center, the staff made me a plaque: they copied my source code onto a floppy disk and nailed it to a piece of plywood. It was one of the nicest gestures anyone has ever made. I still have it.
At my new job, I almost immediately optimized another print workflow, but that’s a story for another time.