---

SmILE: My first product

The context

There are two or three former gigs I refer to as "my first real job." This is the really real one.

I was hired—as a content writer—very early in my career at Enspire Learning, a wonderful, tiny, talent-laden little start-up in Austin, Texas that made e-learning content. My job was to quickly become an expert on whatever field to which the newest project pertained, and to write interactive training materials on the subject, to the specifications of our clients' needs. We were a small, but surprisingly nimble and capable crew, producing high-quality content, crafted with care and attention to detail.

The problem

The tooling available to us as writers was challenging to work with. The process was:

1. Write your content in a prescriptive format within Microsoft Word
2. Save your work in rich text format (a .RTF file)
3. Open a DOS prompt, find the right directory, and run a command that executes some Perl a former employee had written to transform the .RTF file into the XML format our platform could read
4. Wait while your computer did its poor impression of a terminal from The Matrix
5. Hope and pray that there aren't any errors

At first, I thought this all felt quite normal. I was a nerd. I was not the least bit afraid of the DOS prompt. To a certain extent, I understood what the script was doing, and when there were errors, I could often understand the cryptic error messages and find a way to fix the problem. I thought this was just what was expected of a professional writer.

After a while, though, it dawned on me that I'd become a bit of an "IT person" for the writers team. Of the twenty or so of us, I was the only one that truly felt comfortable using teh conversion script. I was quickly becoming the first-responder when others were having problems with it. And I found that when I couldn't fix the problem, the engineers assigned—on the fly—to help were not terribly familiar with Perl, and were about as frustrated as the writers with trying to use the script. I observed that this tool was costing the writers, and the company, quite a lot.

My part in finding a solution

I had come to this job from one in which I wrote Visual Basic scripts that ran within Microsoft Word for the purpose of transforming source documents in various formats (often .RTF files) into a custom extension of .RTF that worked with an early e-book reader, so I had an inkling that there might be a better way.

I sheepishly approached the head of engineering—Hi, Joel!—and asked if I could pitch him on a project. The fact that he took my up on that was a pivotal moment in my career, and I'll be eternally grateful to him (and so many people at Enspire who behaved similar in my time there) for giving me that chance. I proposed to him that I might be able, with some help, to write something in Visual Basic that would:

• Run within Microsoft Word—no longer requiring writers to use a DOS prompt (Visual Basic fo Applications allowed us to surface this script as a button within the toolbar in Word itself)
• Give us a way to validate the source document before attempting conversion (Visual Basic for Applications, being a first-party scripting environment, had a full suite of features that would allow a new script to analyze the source document within Word itself, in its original format)
• Give us a scripting environment in a language much more similar to the ones the engineering team used all day long (Visual Basic is a bit easier to read for Java and ActionScript developers to read than Perl)
• Give us a better way to interact with the writers, both in terms of error messaging, but even more excitingly, in terms of authoring-time features

Joel was convinced. The first three bullet points there were enough to seal the deal, but I was most excited about the final idea: that I could offer tools for the author at writing time. Our custom format required a lot of boilerplate, and the idea of hitting a button and getting all the templatized content set up for me so that all I had to do was "fill out the form" was very appealing.

The process

We started slowly. We pair-programmed the first couple of basic features: getting the button to show up, getting something to happen when you clicked it, etc. I knew Visual Basic fairly well, but I'd only written what were essentially macros before. Joel was teaching me how to structure an application. I bought some textbooks and O'Reilly books and began learning software development both at work and on my own time. I did all of this in "spare time," I was still fully resourced as a writer.

Before long we had a compelling prototype which I was using on an actual client-facing project. I began recruiting other writers to test it out, gathering feedback on the interface I was slowly building up—a menu of options for inserting features into your document, for validating your document, and for exporting to our proprietary XML format. I learned from that feedback that things that seemed obvious or explicit to me (the meanings of abbreviations or icons, for instance) could be confusing or even meaningless to others. I learned to workshop ideas, test things with real users, and to prize feedback.

The outcome

I arrived at work one Monday morning to find Joel waiting for me at my desk. "How would you like to join the engineering team" he asked. The rest has been the past 20 years of my career. Thank you, Joel. So, so much.

SmILE—named that because, like so many in-house tools, it ended up being represented in its menu button within Word by a smiley face icon, and because our platform was called the "Integrated Learning Environment"—was a big hit. A couple weeks after its initial release, a coworker posted on an internal message board, "Thomas owes me a new pair of shoes." She had calculated that, as an hourly worker, the time saved in just the couple of weeks in which she had used SmILE was enough to have paid for a new pair of shoes she'd been eyeing. The writers were more productive, needed less support, and when they did need support it was easier and faster for the engineering team to find and fix problems. But that wasn't all!

Just a few months later Harvard Business School Publishing (HBSP) put out a request for proposal (RFP) for a mammoth endeavor—larger than any project Enspire had yet worked on. HBSP would also be the highest-name-recognition client Enspire had yet worked with. As it turned out, we would need to create an all-new document format to achieve what HBSP needed, and SmILE provided the support to build what we needed. Had we still been using the Perl script at that time, we would not have been equipped to answer the RFP. We won the job, and a year and a half later shipped the first online interactive version of HBSP's ManageMentor program.

This project was a great success for Enspire. SmILE was still in use for several years after I'd moved on from Enspire. It was a great success for me, too, not only by kicking off my career, but in being my own personal bootcamp in product design, user research, and software development.