Paradigm

I worked at a software company for a dozen years that I've described on this blog. One of the five that started the company, LJS, held a class about paradigms. It was many years ago but if I recall correctly, he divided all of the employees into groups and then, for two days in a row, we met in the empty side of the building. Each time we met, the first agenda item was to watch a video about paradigms. What I remember about the video was the example of the Swiss watch maker company. For whatever reason, that company didn't adapt to the changes around them and, eventually, the company went out of business. After watching the video, we had a discussion about what could be changed to make our life better at work. We talked about this statement: "What is impossible today, but if it could be done, it would change the way in which we do our work." Unfortunately, that may be a cheap paraphrasing of what we talked about since it has been several years since I saw the phrase on a PowerPoint slide at a monthly staff meeting or heard LJS say it.

Side note: I also remember that on the second day, a co-worker openly challenged LJS and asked why we had to watch the video. In her defense, she felt the discussion we had were addressing some workplace issues. She asked, "Do we have to watch the video?" Apparently, LJS felt disrespected and ordered her to leave the room. By the end of the day, she had been terminated.

Back to the point. In my career, I've gone through several paradigm shifts. In bullet list form, here are some of the ones that stick out in my mind, though I will tell you that digging through this blog would reveal quite a few more. Here's the bullet list with some highlights of what paradigm shifts I made at that employer over those 12 years:

• I began creating online Help with RoboHelp in a format called WinHelp. In the early days, I considered a "great" and "useful" online Help system to mean that to access field-level information, you clicked a "Help" icon, which accessed a secondary window, which had a list of fields. To get field-level information, you had to click each field individually. 
• The next shift was when the makers of RoboHelp released a DLL for WinHelp called "WinHelp 2000". The selling point of WinHelp 2000 was that it gave you a TOC pane on the left and your content displayed in a pane on the right. The downside of WinHelp 2000 was that secondary windows were not supported. To use WinHelp 2000, I had to remove all of the lists of fields and change to numbered procedures. 
• The next shift was when Microsoft announced that they were discontinuing support for WinHelp. For years, there had been a movement to convert from WinHelp to HTML but I staunchly stood firm as a WinHelp supporter. I refused to convert because there was no business case to do so. Microsoft's announcement gave me the business case to convert. When I began converting my 100 WinHelp files to HTML, I used tables to control my layout. 
• The next shift was when I learned that web pages that used tables to control layout were not highly regarded. Others in the technical writing community were creating HTML-based online help that only used tables for tabular content. 
• The next shift was hearing about something called CSS. Span tags changed my world because I could create a span tag and use it to globally change the appearance of specific text. I began replacing the single span class called "programname" to make text bold with multiple span classes, one each for each UI element. I created span classes named "check_box", "menu_option", "button", and "drop-down." 
• The next shift was hearing about something called JavaScript. I saw a web page that used  JavaScript to create a mini-TOC for the web page. I stopped manually coding a list of headings on each page. 
• Somewhere in the mix of all of this, I heard about DOS batch files. I had been manually copying files from one directory to another but with an amazing command called "XCOPY", I could do all of that manual work automatically (automagically?) by creating a DOS batch file that compiled my RoboHelp projects and copied PDFs from one directory to another prior to publishing. 
• The next shift that was happening over all of this time was to take ownership of the content. I exhumed "Hit the Enter button" in the documentation. I got rid of all the ugly language and poor writing.

I am now undergoing yet another paradigm shift at work and I accept the challenge. I've been a technical writer since 2/10/1995 and feel the beginnings of a paradigm shift in what I do at work, which is write software documentation. For example, why do I need to write that to add a class, you select a button that has a label "Add Class"? Why do I need to write that to enable pay notification, you select a check box that has a label "Enable Pay Notification." Why not tell the user that when you 'enable pay notification' this or that or the other thing happens in the system and what outcome is achieved by selecting that check box?

A lot of this is shifting in my mind on a daily basis. I don't know what it's going to all look like, but I'm excited.