STS Blog

The Work Management Process is an initiative of one of our clients to standardize the process of work identification, planning, and completion at power plants the Company owns and operates. This process aims to transition work activities at power plants from a reactive to a planned mode, thereby improving asset reliability and lowering costs.

The purpose of this training is to present an overview of the Work Management Process either as a refresher for existing employees or as an introduction for new employees.

The training is broken down into six lessons, each of which correspond to a particular step within the Work Management “Wheel.”  Unlike a training course delivered via a learning management system, this training is completely open-ended so learners are free to explore and learn at their own pace.

Although this training is open-ended, some managers wanted their employees’ progress  to be tracked to test their mastery of the content.  Learners can directly link to a short quiz stored within an online learning management system from the Work Management Process Training site.

Goals and Objectives

The original Work Management Process Training existed as a 180-page document that learners had to read.  Once our Technical Communications project team got our hands on that, we all recognized that we had an opportunity to create a unique eLearning experience from this training.

The primary goal of the training site is to create an interactive, online resource that employees can visit to learn about the Work Management Process.  Using a simple design, contextual links and actions, drill-down exploration of content, and leveraging interactive learning experiences, our training site easily stands out as a technology-based learning site unlike any other training initiatives we have created in the past.

The objective of this training is to promote and encourage learners to “explore the content” rather than simply read it. Many learners have become too accustomed to reading through text-heavy documents and diagrams, which can detract from the learning experience. We set out to create an engaging and immersive learning experience that would change the way our employees viewed eLearning, and based on the positive feedback this training has generated within all levels of the company, we would like to think we have succeeded.

Design Theory

The graphical user interface for this training was developed progressively over the course of a series of design review sessions. In an effort to make this training the first of its kind for our client, we decided to use a bold UI design that would capture the learner’s attention and stand out in their minds from the typical text-heavy, online training modules that they have seen for the past decade. Pulling design theories from software user interfaces, our UI aims to make navigation intuitive, thus simplifying learner actions.

The Work Management Process Training was built by deploying custom code and content onto a Microsoft SharePoint site. Since SharePoint has the ability to integrate with many types of content, we found it advantageous to use it as the platform for our backend. The build process was relatively simple and straightforward — custom CSS code was applied to the existing SharePoint template and then an assorted set of content was added to each page, including Flash interactions, Captivate movies, and custom Javascript functionality.

Figure 1: The Work Planning lesson within the Work Management Process Training site

Our goal was to attain a clean and simple “web 2.0” visual style in this interface.  We achieved this through the marriage of custom code and graphics with the simplicity and flexibility offered by SharePoint. Through our modifications to the backend and our design of the user interface, we created a smooth and visually appealing interface.

Success through teamwork

One of the most successful elements of this project was the dynamic that our project team shared. With a small project team, we found that having a solid plan of attack would be paramount in making forward progress and meeting our deadlines. Before development began, we created a role-based division of labor which would allow us to work effectively in our areas of expertise.

Using this approach, we adapted an agile development method, focusing heavily on collaboration, constantly adapting our design. Throughout the project life-cycle we had at least one design meeting per week, and this allowed us to openly share our work, obtain feedback and criticism, and to brainstorm ways of approaching and overcoming various challenges. We set many short milestones for our team over the course of the project, typically lasting one to two weeks. After each milestone, we held a meeting to present and review our deliverables and determine if we needed to adapt our design to technical limitations, design flaws, or inconsistent learning experiences.

Technical challenges

With innovation comes technical challenges and creating this training had its share of obstacles. The first 3 months of this project were spent on rapid prototyping in Flash and SharePoint and for the remaining 6 months, we were in an agile development mode, constantly building and revising along the way. Most of the technical challenges came within the latter portion of the project life-cycle, as we were rethinking the designs used in our beta prototype. For example, one large challenge we faced was selecting how to best present the content of the training to the learners.

In our first prototype, we tried to make the content more aesthetically pleasing by turning it into a series of images which we turned into a slideshow using simple Flash interactions, but this method made it too difficult to edit the content and too difficult to maintain via Photoshop and Flash.

Figure 2: Content delivered through Flash in the beta prototype

The failures that we encountered throughout this project’s life-cycle only made it easier for us to adapt to the problem and find innovative solutions to bridge the next gap. In our next prototype, we took the content, dropped it into a PowerPoint presentation, and exported it as an MHTML file, which was then embedded within the SharePoint page. This method made it much easier for content maintenance and allowed our content to look however we wanted it to, but since the presentation was scaled down drastically to fit within the space we had, it was impractical for us to include any interactive elements.

Figure 3: An embedded PowerPoint presentation in the training site.

We spent a lot of time in design meetings discussing how to best approach this challenge and how to find a good middlegroud – we needed something that was easy to maintain yet visually appealing and allowed for interactivity.

Figure 4: The final lightbox version of how we display content.

In our final prototype, we achieved the balance of aesthetic and functionality by putting our content into a Captivate movie. We displayed the content in a series of slides, interspersed with quizzes, and also included other interactive elements to enhance the learning experience and boost retention. Additionally, to overcome the constraints of embedding the content directly into the SharePoint page, we built a “lightbox” by modifying third-party code, which could open a separate layer over the current site and play a Captivate movie, giving us the learner’s entire screen to display information.

An interactive approach

The Work Management Process itself has numerous process flow diagrams within it, since each part of the process has a series of steps that must be followed to complete it. Instead of simply placing the image of the process flow in the content on the training site, we thought that this would be a good opportunity to use interactivity to bring a static image to life.

Figure 5: The Process Flow Viewer promotes learning through interactive, drill-down learning.

After many prototypes and putting a lot of thought into both the interactive design and the instructional design, we created the “process flow viewer.” This interactive process flow takes the simple image of the process flow and lets the learner overlay information on top of it, such as what steps of the process flow apply to them based on their job role. This activity also allows learners to engage in drill down learning – each step within the process flow can be clicked to learn more about that step in detail. Learners can also play a simulated walkthrough of the process flow, allowing them to see the process flow in action.

The process flow viewer can be launched from the menu of a lesson or while viewing the content itself.  In both cases, it launches in a separate window so as to not interrupt the main navigation, allowing learners to view the content and the process flow side-by-side if they are using a dual monitor setup.

Tell Someone About This Post:

Aberdeen Group completed a study earlier this year that indicates when technical communications are approached strategically, companies provide significant customer-facing value. – David Houlihan, Senior Research with Aberdeen’s Product Innovation and Engineering Practice.

What does this mean for technical documentation departments and companies? It means that companies researching, authoring, and producing technical communications need to focus on pertinent data which consumers will actually use. When people comment on the entity that is technical documentation, they use the words “concise” and “practical.” Why does the majority of technical documentation fail to follow these expectations? One of the many problems with technical documentation is that it very rarely uses orality. Many of you might be considering, “Orality? What does that mean?” It means that technical documentation is not written as one would speak which further alienates consumers from ideas and communications which they do not fully understand. Step one in writing anything is to know what you’re writing about. Step two is to understand your audience. This doesn’t mean that when technical documentation is written it should include colloquialisms, vernacular, or regional phrases, but that it should be easily accessible and understood by consumers who are unfamiliar with the product.

Further strategic movement by industries is the idea of globalization. The true aim of a company is to make money; ok, understood. By reaching out to consumer territory they have not yet approached, companies and industries expand their potential growth market. Technical documentation must grow with business. Technical documentation has often been difficult for readers to relate to or get themselves engaged in – small wonder that technical documentation was loathed and strategically placed in the circular file. Today, technical documentation has the added hurdle of identifying with readers from different backgrounds, different languages, and different countries. Because technical documentation is meant to be instructional, it has to be extremely clear in meaning, and thorough in its explanations. It’s important to remember that consumers are usually only going to turn to technical documentation when they have a problem, or if the documentation is meant to be training material. Writers of technical documentation need to anticipate problems that will arise in the consumer’s daily use of a product. A great example to this issue occurred to me and my own family during the holiday season.

My mother is, as she terms it, “computer-illiterate.” Sometimes I’m lucky that she knows how to turn the computer on, much less navigate through the internet. Initially, I would get frustrated with her because she didn’t understand what I was trying to tell her. “Type the URL in the address bar” just didn’t cut it. First off, she had no idea what an “URL” was. So I had to explain, “URL is the web page address for where you want to go. It’s the identifier of the web page.” Then I gave her an example, www.shoap.com. “The address bar is at the top of your web browser, normally white, and shows the web address.” Ok. So now she knows how to get from one web page to another. Recently, she wanted to upload photos from her camera to Walgreens so that she could make copies of those photographs as Christmas presents. This was a difficult predicament, as I had to direct her how to do this over the phone. She was able to upload the photos from her camera to the computer on her own, but moving them from the computer to the website was causing problems.

In this instance I was removed from the consumer. I had to anticipate that she would not be as familiar as I was with uploading pictures and navigating through the website. Fortunately, I’ve used the upload procedure on the website before, so I was familiar with how it works, (step one complete!). Now I have to properly explain it to my mother, someone unfamiliar with the process (step two complete!), in a precise, easy-to-understand manner without oversimplifying: What I did for my mother was basically a walkthrough. I was on the phone with her, telling her what to do as I was also going through the process to make sure it was accurate. First, she had to open the web browser, (I advised her not to use Internet Explorer, but Mozilla Firefox, instead). She brings the browser up and I ask her to type in the address: www.walgreens.com into the address bar located at the top of the browser. We magically portal over to the website through the internet, and we are faced with the Walgreens’ home page. I ask her to click on the photo icon at the top of the page, which she does. She then has to log in; she already has a username and password, so she does that. Now we have a slight problem.

It appears that my mother’s web browser version is outdated and does not have the latest version of Flashplayer. My web browser is perfectly fine, so I have to walk her through updating Firefox. I search for “Adobe Flashplayer” in my search bar and come up with http://get.adobe.com/flashplayer/. I have to relay this to my mother, so I tell her to go to the address bar, delete the current address, and type the above mentioned URL. She does so, and it takes her to the installation page. I ask her to uncheck the McAfee Security Scan and click the yellow “agree and install now” button. I tell her to the save the file which pops up, and then the update downloads. I tell her to double-click on the install_flash_player.exe file, and the computer does its thing. But wait! We still have the Firefox program running! I ask her to close the browser by clicking the red X in the right hand corner, and then double-click the install file. The installation is successful; we close the dialogue box, and restart Firefox. We go back to walgreens.com, click the photo icon and she logs in again. Now I direct her to look for the “Get Started!” header in orange, and click on the “upload photos” text beneath it in blue. She does that and it brings up a pop-up for her to add to a new album or add to an existing album; she decides to add to a new album and names it. Then I ask her to click on the blue, “select photos” button on the bottom right. After that, she is taken to a folder to select photos. The folder is not the one she wants!

Now I have to walk her through changing the file path so that she can get to the folder which has the photos she wants to upload. I ask her if she sees the dialogue box that says, “Select file(s) to upload…” and she affirms. I tell her to go to the “look in:” area at the top of the box and click on the drop down menu. At this point, I’m not sure where she stored her photos, but I have a good idea: I tell her to click on the “My Documents” folder in the menu, and then click on the “My Pictures” folder in the box showing a lot of different folders. She then recognizes the title for her album, clicks on it, and sees the pictures she wants. Now I tell her to position her mouse in the white space above and slightly to the left of the first picture, hold the mouse, and move it to the bottom corner of the last picture she wants to select. I have to tell her this because Walgreens does not have a check mark option to select multiple photos, and it must be done in the drag-highlight method. After the photos are highlighted, I tell her to click the “Open” button, and the website automatically begins uploading each picture. Once all of the photos are marked “Done” the web page moves to a screen saying, “Your photos have been uploaded! What would you like to do next?” I tell her to click the “Order Prints” button, and follow the steps Walgreens provides from there.

The steps on the Walgreens photo uploading site are fairly good, especially since they anticipate the needs of consumers and alert them to things that will happen next, such as the “Order Prints” page. It reads, “Select the album with the photos you’d like to print. You’ll choose quantities and sizes on the next page. Need help?” And then directs consumers to click the photos they want to order, which conveniently show up in a side bar apart from the bulk of the album.

So how does this tie in to large-scale, profitable technical documentation for companies, and useful, instructional material for consumers? I’ve just demonstrated that while you should never patronize the consumer and oversimplify directions, you have to be aware of who your audience is when constructing and presenting technical documentation, training, or instructional material. This almost always means that you are going to have to explain methods in a simpler, yet thorough process.

My earliest recollection of instructional material came from second grade when we were asked to write instructions on how to make a peanut butter and jelly sandwich. I couldn’t believe my luck at the simplicity of the assignment! I initially wrote: put peanut butter on bread, put jelly on bread, and cover with second slice of bread. This was apparently wrong to my teacher. Why? Well, I had left a lot of things out. For example, where did I get the peanut butter and jelly? How did I get the peanut butter and jelly out of the jars? What did I use to put the peanut butter and jelly on the bread? “Well that’s stupid!” I said. “Everyone knows you have to open the jar, get a butter knife and put it in the jar to get the peanut butter and jelly, and then spread the peanut butter and jelly on the first slice of bread!”

Well, that’s probably true, people know how to make peanut butter and jelly sandwiches, and lots of things can be inferred, but when they are first taught, they have to be precise, step-by-step instructions, considering that the reader may never have done such a thing before. The peanut butter and jelly story is extreme, but if I had simply told my mother, “Go to walgreens.com, pick the photos you want and upload them, and then choose how many of what photo you want to order,” she wouldn’t have been any better off than when she first asked me for my help. In this way, technical documentation should be viewed as a communication meant to help others and educate them with precise, clear, and easily understandable instructions. I walked my mother through a – to her – complicated process, using precise instructions and minimal technical jargon. Any technical references I made, I explained in more familiar language. Overall, technical writers need to take into consideration who is reading the document, and what they are going to have questions about so that consumers can relate to their instructions and have a more enjoyable, and understandable experience with the product.

Tell Someone About This Post:

Christmas, 2009:

The penguin wrapping paper is shredded from an oblong, rectangular package, carefully branded by a stark white apple on black monochrome — The Apple iPod ® Nano. The product is reverently lifted from the case along with the ear buds and sleek quick start guide, leaving the thick, intimidating, and unhelpful paper manual in the bottom — it might as well have been packing peanuts. Why do manufacturers bother with the archaic manual documentation which wastes paper, takes up unneeded space, and adds weight to the shipping fee? The product is blithely toyed with, prodded, poked, and explored without so much as a cursory glance to the woe begotten manual in the box, the user happily glancing through the quick start guide if they come upon any snags in the process of operating their new system. The manual is never read, collects dust, and slowly sinks into oblivion. Let’s explore why the manual falls to such a fate.

I have to read through all of that!?

Technical manuals are daunting. Easily composed of at least 50 or more pages, documentation in manual form is a stack of paperwork bound together with minimal organization, most of which is inaccurate and leads the user into an hour-long search for the index and the appropriate page for “diagram b-1.2.” Not to mention when the appropriate page is wrangled, the content is full of jargon, technical words, and number/symbol references which often do not correspond to the device or your particular model. Ignoring the fact that most manuals are dry, boring, and do not communicate well to the average reader, they are poorly designed. Logically, a user would immediately peruse the front or back of the manual for the index or the appendix; unfortunately, staggering amounts of manuals do not provide those, causing the reader to flip through endless amounts of pages, glancing over the titles and hoping what they think is organized there really is. Ever walk into a grocery aisle and wonder why your favorite brand of iced tea is located in the ‘juice’ aisle, but not in the ‘specialty drinks’ with the rest of the beverages?

Insert tab A into slot B

Simplicity is the best way to communicate unfamiliar tasks and procedures. One has to wonder if the paper manual is so large due to all of the explanations for explanations. Consider your grade school Social Studies class: What was the point of “skimming” through paragraphs of information for one-or-two word fill-in-the-blank papers? Perhaps it was to prepare consumers for the need to sift through pages of useless information. If the manual is already a compiled document on the intricacies and complexities of your product, e.g., research, why must you continue to research that document for the appropriate solution? Manuals could be more effective if the words were tightened, the ideas communicated thoroughly, and the explanations given simply, scaling a 250 page document down to 100 pages of useful information. Brevity is indeed an acquired skill.

No John, you cannot wirelessly link to my brain to upload those system specs…

Since brain to brain communication has yet to be achieved, we must rely on verbal, written, and many times visual communication to express our ideas and thoughts. Keeping in mind how the consumer learns is an advantage in creating useful documentation for their purposes. The ink saved on extraneous explanations can be applied usefully to helpful pictures, diagrams, and visual representations of written instructions. Knowing what you’re writing about will also help to convey detail about certain aspects of a product; however, you must understand that the average consumer does not have the expertise, knowledge, or familiarity with technical data like developers do. While developers are a mountain of knowledge about the product they have created, they are so familiar with it and technical processes that they cannot detach themselves from it in order to effectively communicate to end users how to operate it. Developers are brilliant on many accounts; sadly, communication is not one of them.

Solutions

As always, if you have a problem, you’d better start thinking about how to solve it. In point of fact, manuals are outdated, unhelpful, poorly written, and hard to understand; what the consumer wants is a concise, easy-to-read instruction booklet on how to operate, solve problems with, and utilize the products they buy. This can be achieved in thin, well written quick start guides that are packed with the necessary information in a succinct form. Larger, more detailed manuals can be put on discs, digital media applications, or in web-based user help forums to help negate cluttered product boxes, waste of paper, and frustrated consumers.

Tell Someone About This Post:

For the past three years, I have been trying to find a way to automate the tedious task of printing two copies of 30 plus PowerPoint Presentations to PDF, first as Notes Pages and then as 3 Slides Per Page Handouts.  Every six months I would spend a few hours testing various batch printing applications to see if they would complete this task for me.  Unfortunately, every time I would find they would only print the standard One Slide Per Page view without the Notes field included.

Well, Thursday of last week, I had a breakthrough!  I came across a Visual Basic script which created a new PowerPoint Presentation and manipulated the Print Options.  Eureka!  This was how I was going to solve my problem.  Instead of trolling the Internet for a batch print application, I would write one myself using Visual Basic!

I should point out that before Thursday, I had never used Visual Basic to do anything and had no idea how the language worked.  However, I have many years of experience with Java, JavaScript, PHP, and ActionScript, and I have an Internet connection, so what more could I need?  Apparently that was it, because before noon on Friday, I had a script which would scan a specific folder on my Desktop, record all of the file names, open each of them up, set the Print Options, Print to PDF, and then close the files.  A task that used to take me several hours now takes about a 10th of that time.

Having never used VBScript before, I found it fairly easy to learn. I definitely recommend it if you are trying to automate some tedious task using an MS Word product.  There is a fair amount of information online to help you.  Besides, why pay for someone else’s product that doesn’t work when you can build a simple script to do it for you and get exactly what you want

Here’s the code I created to accomplish my printing task:

Const sFolder = "D:\Documents and Settings\username\Desktop\PPT_Printer\to_print\"

Sub makeFileList()
On Error Resume Next
Dim fso, folder, files, i
Set fso = CreateObject("Scripting.FileSystemObject")
Set folder = fso.GetFolder(sFolder)
Set files = folder.Files
Set i = 0
For each folderIdx In files
If i = 0 Then
file_list(i) = sFolder & folderIdx.Name
Else
redim preserve file_list(ubound(file_list) + 1)
file_list(i) = sFolder & folderIdx.Name
End If
i = i + 1
Next
End Sub

Call makeFileList()

'Const ppPrintOutputThreeSlideHandouts = 3
Const ppPrintOutputNotes = 5

For j = 0 To ubound(file_list)
Set objPPT = CreateObject("PowerPoint.Application")
objPPT.Visible = True
Set objPresentation = objPPT.Presentations.Open(file_list(j))
Set objOptions = objPresentation.PrintOptions
'objOptions.OutputType = ppPrintOutputThreeSlideHandouts
'objPresentation.PrintOut
objOptions.OutputType = ppPrintOutputNotes
objPresentation.PrintOut
objPresentation.Close
Next

If anyone else has ever needed to do this, I hope it helps make your life a little easier too. If you’re new to VBScript and want to know some details about how to use this script, post a comment and I’ll be happy to answer your questions.

Tell Someone About This Post:

… we have come to value … working software over comprehensive documentation…

Agile Manifesto

We don’t do a lot of work with practitioners of agile methodologies. I think that’s partly because there’s some built-in hostility towards documentation in the values of agile development. Of course, while the Agile Manifesto is referring mostly to documentation for the front end of the cycle (i.e., the giant FRS), that hostility ends up spilling over to end-user documentation as well. (I don’t think that was the intention.)

Over the last couple of months, one of my main clients has been moving our documentation processes to an agile methodology in order to align with development processes.  It has been interesting, to say the least. The biggest change is the move towards small iterations of documentation that match the iterations of the development process. It means that instead of documenting twenty new features at the end of a three month development cycle, we document a handful of features (or parts of features) every couple of weeks.

What are the challenges?

Get me the code! One of the first challenges we faced was that there wasn’t yet a process in place to get the newest iterations of the applications to me as each iteration of development is completed. This one is a work in progress thus far, but getting the working software iterations to the doc team needs to become part of the process in order to do doc in an agile world.

Get in the conversation. The nice part about the giant FRS is that it’s (often? sometimes?) a great source of information for the end-user documentation. (We’ve converted specs to user manuals and user manuals back to specs, the latter not being a practice we would recommend.) Without the spec, you have a lot more work to figure out just what the application is doing and why. For this specific client, not much has had to change in this respect since I’ve already been able to spend a lot of time with the development honchos, been indoctrinated into their ticket tracker, and have a good background in their apps after several years working with them. Additionally, I’m now working with a great project manager who facilitates my information gathering needs.

Iterations don’t tell the whole story. Each of the iterations we’ve worked on so far has contained parts of features. The most challenging issue so far has been figuring out how to incorporate partially finished features into the overall story of the document as well as how to document the whole story of any given feature when only parts of the feature are complete. One strategy I’ve been using is taking a holistic look at each of the documents I’m working on before each iteration to identify areas that may be affected two or three iterations down the line in a sort of pre-emptive review.

Version control. Simply put, the more times you have to edit a document, the more version control can be an issue. Additionally, with the agile methodologies we have to worry about patching previous versions of the documentation while updates to the newest version are already in progress.

What are the benefits?

Eliminate the big push. The biggest benefit is eliminating the one huge documentation effort for each release. Iterations are quicker and more frequent, but the limited scope makes it easy to get a few changes done at a time.

More review cycles are always better. Of course, each iteration is supposed to come with its own review cycle. I’m willing to bet that some of those review cycles will be missed; however, even if only half of the iterations get a new review cycle, that’s still many more reviews for the documentation than you would get for that one big push.

On the same page. Agile documentation forces the documentation team to be on the same page as the development team. That makes it harder for this or that feature to slip past the documentation team. It also makes it easier for project management since you know just how far along the documentation effort is at any given time.

Get the doc team involved. Documentation folks have a natural affinity to other software related disciplines such QA and UX. How many times do technical writers say “Hey, that doesn’t work quite right” or “Hey, that’s really hard to use” when it’s too late to do anything about it? Getting the documentation folks involved in the development process while the software design is still an evolving thing can help to make the final product a more polished, usable application.

Tell Someone About This Post:

Clients often want everything, but the simple truth of the matter is that nobody gets everything they want – there is always a tradeoff somewhere, and that can be hard to explain to management types.  This is a struggle that every hired gun will have to deal with eventually, but it CAN be done!

I recently came across an intersting post at Future Perfect which explains the concept very simply using Rhys Newman’s handy graphical representation of the triangular relationship between fast, good, and cheap.  Just remember, the closer you get to one of these, the further you are from the other two.

This is defnitely something you’ll want to keep in your toolbelt when pitching projects to clients.

Happy estimating!

Tell Someone About This Post:

As a technical writer, I feel communicating well is the primary focus of my job. Perhaps this is why I found the following email exchange particularly comical today:

Email from <name deleted to protect the innocent … or not so innocent>:

Hey Will,

I have a question about the <xyz project>.  Do you know if the <important information> was added to the curriculum?

My response:

Hey <unnamed person>

Yes, I was able to add the <important information> last week.

Her response (not edited):

Thank you for the fup!

After my initial shock, I determined “fup” stood for “follow-up”, but this was not my first reaction.  I won’t share with you what I first thought “fup” stood for, but I bet you can guess.

When you’re trying to communicate something to someone in a business setting, I advise you really think about how someone might interpret your abbreviations before you send out that message.  I know in this day and age everyone likes to use shorthand and abbreviations because text messaging and tweeting limits the number of characters, but maybe we should keep our abbreviations to those forms of communication and out of email. 

Feel free to “fup” this post with your own comments on the subject

Tell Someone About This Post:

It is often difficult to know what the priorities are when creating a successful new program. As a project manager for Shoap Technical Services, I have a fair amount of experience initiating new projects. Over the years, I have developed a few key “rules” for every project. While I could just go through my list and explain why I think each rule is important, I think it is easiest to learn through experience, so I have illustrated them through a case study of a recent project.

In October 2008, I was placed on a small project team at one of our clients to begin work on creating a training initiative for Work Management. Our client represents one of the largest energy-traders in the nation, with many of its power plants in the northeast.  Each of these plants operates by a Work Management Process, which is a way of detecting and successfully resolving problems or repairs.  Before today, plants would conduct training solely from a paper document that describes the entire process, supplemented by instructor-led training with a PowerPoint presentation.  I have highlighted some key points that have helped me through the process of creating this new training initiative.

Understand your objective.

Our client wanted my assistance in converting a 180-page document into an interactive, web-based training application that would be used by hundreds of employees within the company. The existing standard for online training at this company was a static and linear approach, using HTML with limited CSS to essentially place the contents of the document into web-based slides. 

Because of this, the client was very open to pursuing alternative options for delivering the training and suggested doing something more interactive.  Interactive web-based training creates a win-win scenario by increasing retention rates since the employees are more engaged in the content, and by providing a fun and memorable learning experience for the user.

While revamping the training program it was tempting to create new product guide videos or flash applications, but the interactive training program online was the objective. It was important to remember to accomplish that first, and only add the other things at a later time if these additions genuinely helped making the interactive web-based applications more useful for the learners.

Know your strengths.

I began working on this project with the understanding that I would be working with a very small team and was the designated “expert” since I had to simultaneously fill the roles of graphic designer, web designer, interaction designer, and lead developer.

There was much to be done on this project – there wasn’t a single piece of existing or reusable code anywhere. All of the graphics, web components, and interactive elements had to be created from scratch, and I was the one doing it.  Though challenging, these job responsibilities were easy for me to handle because of my strengths in both technical and creative fields, and I was able to offer many ideas due to my previous experience in IT training.  I doubt that without my help the client would have been able to accomplish this type of initiative. The lesson here is simple: Know what you can do on your own and what to outsource to someone with greater knowledge in the field.

Plan your approach.

First, I identified Adobe Photoshop CS4, Adobe Flash CS4, Microsoft Office 2007, and Microsoft Sharepoint Portal Designer 2007 as essential programs. Next, I generated a series of storyboards to allow me to quickly mock up different methods I could use while designing this project.  I had numerous mockups of the website design, user interface, and even some of the interactive elements of the training.  This made conveying ideas and approaches very simple and effective, and these materials gave me a better sense of where to begin. Finally, I established a reasonable timeline for producing a working proof of concept. 

Work around problems.

Even though I had named the Adobe programs as essential, I only was approved for the Microsoft products. I had to settle for Photoshop CS2 and Macromedia Flash MX 2004. Although I was disappointed because these programs are less effective for what I wanted to accomplish, I simply reworked some of my ideas to fit with the programs I had been given.

Execute your plan.

The project started off very smoothly thanks to the plan I had created. I created a Collaboration Team Site on a server running Windows Sharepoint Services, which would be the home for the training site.  Using the document’s outline, as well as Sharepoint Designer and Photoshop, I created sub-sites and a persistent left-navigational menu, providing employees with constant access to all levels of the site. Essentially, just get to work on what is in your plan and don’t worry about new things that may be harder than you intended. Until you run into a problem, don’t concern yourself with the possibility. That doesn’t mean to ignore foresight, but rather to only worry about things as they arise.

Be innovative.

A goal of this project was create a memorable experience in terms of user interface design and interactivity.  Presenting creative solutions to challenges can really go a long way to accomplishing this goal.

After reviewing the source document many times, my team and I realized that we should try to bring life to the many process flow diagrams within it.  These black-and-white diagrams contained the standard boxes, diamonds, and ovals connected by a mess of spaghetti-like arrows.  Diagrams such as these can be useful to an employee who is very familiar with the process, but to a new hire, there is always some degree of ambiguity or confusion.

Using my experience as a video game interface designer, I created a very innovative method of reinventing the process flow and making it completely interactive.  My initial approach was taking the employee on a step-by-step walk-through of the process.  Presented and completely custom scripted in a Flash movie, users see a low-level view of each step in the process on the left and, on the right see a high-level view of the entire flow, effectively a mini-map. The low-level view illustrates the progression through the process by showing a directional arrow going from one step to another. Users have the ability to dig as deep as they wish to learn about each step.   

I essentially took something that was always assumed to be static and made it dynamic and responsive to user input.  I successfully placed the learning experience in the hands of the learner, making for an interactive and engaging process. My innovation had transformed a previously marginally useful guide into something that was integral to training.

Make your work easy to adapt.

Recently, our project team decided we should make some changes to the interactive process flows, and this sent me into a panic. However, I developed the first set of process flows in such a way that many of the elements could be reused with little need for additional work. The process of constantly evaluating your work and adapting to the changing needs of the client really helps in driving your overall level of quality.  Having the foresight to develop your code or graphics in such a way that would allow them to be easily readapted in the future is a great strategy.  Incorporating principles of flexibility allows me to continuously be productive and still generate quality products in the end.

Tell Someone About This Post:

Recently, I was working on a new Captivate project when I noticed that one of my go-to buttons did not show up in the drop-down menu with button styles.  Most of the projects where I used that particular style were created in Captivate v.2, so I assumed that the button styles were unique to that version of the application.

Wrong.

The button styles were all still there.  Just for some reason, Adobe decided that instead of putting them in the “Buttons” folder and making them available as drop-down menu options, they would put the old button styles in a sub-folder called “More.”  All you need to do to make the buttons visible in the drop-down menu is to move the entire contents of “More” into its parent folder.

Enjoy.

Tell Someone About This Post:

If you’ve just started using Captivate, the best advice I can give is the kind that should be printed in big, friendly letters on the front of every technology-related reference guide or manual… DON’T PANIC.  While there are a million and one reasons to use our favorite demo/presentation/simulation software, there are a few issues that you are inevitably going to have to deal with.  In the past I’ve written about consistent, reproducible errors that I’ve had to work around, but once in a while I run into something entirely new and unpredictable.

After recording a demo today, I went back into the project to edit the auto-generated captions.  I checked the “Apply To All” options and then changed the caption style from Adobe Blue to Haloblue.  The default text size for both caption styles is 12 pts, but when I clicked OK, it changed all caption text to the Haloblue style… at 16 pts.

I undid the change, re-tried it on the same caption, and saw the same behavior.  After closing and re-opening Captivate, I could no longer replicate the issue.

So don’t panic.  Always reboot first.

Tell Someone About This Post: