STC Communication Times Logo
STC Toronto Logo
STC Toronto - Communication Times
November 2004

In the November 2004 Newsletter:

The e-mail part of the newsletter consists of the News and Events section. All links to other articles will take you to our website.

News and Events:
-November Meeting on Nov. 9th: Wayne Debly presents 'Putting a Course Outline'
-Important Reminder to Renewing STC members
-STC Volunteers needed
-Single Source SIG Meeting on Nov. 15th
-Front Runner events & special offer to STC members
-Call for papers: IEEE Professional Communication Society's Conference in Ireland - July 2005

Web Content: Connecting with Customers
Technical communicators have a wealth of skills for creating web content, but are often shunted aside. In the first article in a three part series, Gauri Ahuja examines how technical communicators can play the role of customer advocate, to everyone's benefit.

A Writer's World: Lessons from Star Wars in Information Management
The force is very strong with Andrew Brooke this month. This article read, you should!

September Meeting Report
Susan Webb returns to report on our first meeting of the year. She follows a document as it passes through several desktop publishing tools...

The Wandering Eye: Search Tools
If you haven't made it past the Google homepage, you're missing out. Keith Soltys has some useful tips.

Single Sourcing with XML and XSLT
Alan Houser looks at the capablities of of the W3C standard language XSLT for single-source publishing of XML documents. (Alan will be presenting a course on this topic at Front Runner in November.)

From the President's Desk: It's All in the Mix
Are you continually adding skills to your mix? Robert Milkovich looks at a key to success in our profession.

That was Fun
Sometimes the technical communicator has to play the role of detective, as Keith Soltys found out.

This newsletter is sponsored by
Front Runner would like to offer an STC group discount when three or more register at the same time for Front Runner's upcoming Extensible Stylesheet Language: XSLT Development course on November 10th, 11th & 12th, 2004. Please call (416) 515-0155 or email Veronica for pricing details.


About the STC:

The Society for Technical Communication is an individual membership organization dedicated to advancing the arts and sciences of technical communication. It is the largest organization of its type in the world. Its 25,000 members include technical writers and editors, content developers, documentation specialists, technical illustrators, instructional designers, academics, information architects, usability and human factors professionals, visual designers, Web designers and developers, and translators - anyone whose work makes technical information available to those who need it.

The STC Toronto Chapter was founded in 1959 (then the Society of Technical Writers) and is the largest chapter in Canada.

About this Newsletter:

This newsletter is produced monthly by the STC Toronto Chapter and is sent to all registered members. If you have any feedback or ideas, please e-mail editor Philip Kahn at: newsletter@stctoronto.org

Our mailing list comes directly from the STC, so if you want to receive the newsletter at another address you will need to login to their members profile section and update your information. The STC Toronto Chapter will not share nor sell our address list and will only send e-mails with information we believe to be useful and relevant to our members.


A Writer's World:
Lessons from Star Wars in Information Management
or "Everything I needed to know about technical communication I learned from George Lucas"
by Andrew Brooke

Star Wars is, of course, the famous movie about a document. Specifically, it's about the efforts to deliver a stolen user manual of a killer application called "The Death Star", developed by an evil corporation named "The Empire". "The Empire" consists of various employees running around in extreme hockey gear and doing nasty things like destroying planets and not reviewing the drafts submitted to them.

I remember when Star Wars came to theaters in 1977. I went to see it on my eleventh birthday and vividly recall the excitement it generated. Everyone in the theatre knew they'd seen a film unlike any other. Love it or hate it, most people agree that Star Wars didn't just break new ground - it invented an entirely new type of ground.

The original Star Wars trilogy was recently released on DVD. The set includes a documentary about the making of these films, entitled "Empire of Dreams". This two-and-a-half hour documentary is as entertaining to watch as the films themselves, perhaps more so because it describes the battles that actually took place: the battle between George Lucas and the studio, the battle to get the first film completed against all odds, and the battle within George Lucas himself to stay true to his vision.

I therefore offer the following lessons from Star Wars for all information developers: lessons from the making of the film, from the film itself and from its creator.

Lesson #1: Write like a normal person talks.

In one of most hilarious segments of the documentary, Mark Hamill (who played Luke Skywalker) recalls how he still remembers a long, rambling line he had to recite during his audition. Here is the line - try reciting it without taking a single breath:

"But we can't turn back - fear is their greatest defense - I doubt if the actual security there is any greater than it was on Aqualier Selis and what there is is most likely directed towards a large-scale assault."

"Who talks like this?", Hamill recalls. How true. The films would have failed completely if the language in them had been stilted and unrealistic - fortunately, most the of the dialogue comes across as fairly natural. The same cannot be said of the later Star Wars films: The Phantom Menace and Attack of the Clones. These films, while technically superior in special effects to the earlier ones, are not considered critically as successful, because of their awkward dialogue. There is also little humour in these later films, unlike the earlier ones which did not take themselves as seriously.

One of the biggest challenges we face as information developers is to take incomprehensible gobbledy-gook and make it sound natural, almost conversational, without losing any of the meaning. To make things sound simple is, ironically, a complex task, but critical in creating successful documentation.

Lesson #2: Even with endless problems, you can still create great documentation.

The fact that Star Wars was completed and released was a modern day miracle. Filming was plagued with various production problems. Studio restrictions meant filming had to complete each day precisely at 5:00 p.m., unless the actors were in the middle of a take. The weather played havoc, with record heat waves in the desert scenes. Major cost overruns almost forced the production to shut down completely. Lucas was allowed to finish the film, but had to work at a breakneck pace to meet the deadline imposed by the studio. The original cut of the film before major editing began was a disaster. The pacing was terrible. Lucas and the editor could not agree on how to edit the film, so Lucas fired him.

But after months of long, hard work, the editing was fixed, the special effects added, the unique sound effects inserted, and, to top it all off, the dramatic memorable music scored was laid in. Initially, most theatres didn't want to show the film, thinking it was just another kid's movie. In the end, though, the film was widely distributed, and was an incredible success. Before Star Wars, most science-fiction films grossed less than $10 million. Star Wars made an astounding $461 million in the U.S. alone, and to date has grossed almost $800 million worldwide. Add to this the success of the later films and all the merchandising, and it's easy to see why Lucas is one of the richest men on Earth.

One lesson here is that the first draft of anything is crap - the final draft is all that matters. Also, the more time you have to work on something, the better it can be. When Lucas re-released Star Wars 20 years later, he was able to clean up and supplement much of the existing footage. Don't you wish we had the luxury of time to rewrite our final drafts, to make them how we really wanted them?

More importantly, though, Lucas's experience teaches us that we can achieve greatness even on a project that seems hopeless. We've all had the projects from hell. No one wants to review the drafts. There's no existing documentation or specifications from which to develop our documentation. We have trouble even accessing the application we're writing about. And yet somehow, adversity gives us the strength we need and we pull through, with great results. We create manuals that are the most complete, the most accurate, the most meaningful and helpful that they have ever been. We get feedback from our end users thanking us for at last creating guides they can actually use. Yes, it's nice to create documentation at a steady pace, with full support, and without pressure. But there is no greater pleasure than creating great work under tremendous challenges. It strengthens you, and ultimately makes you a better technical communicator. As the saying goes: when you hammer steel, it becomes harder.

Lesson #3: Be careful not to become what you condemn about information development.

Lucas was constantly battling the studio for creative control over his film. Therefore, he was obviously happy when the success of Star Wars allowed him to form his own studio, LucasFilms, ensuring he no longer had to fight these outside corporate entities.

However, as Lucas notes at the end of the documentary, he was once against corporations, but now is the head of a corporation. Becoming the very thing you condemn is one of the themes in his films - with Luke battling not to join the dark side as his father had done.

As information developers, we have no shortage of things that we love to condemn. But if we are honest, we'll find that we too can become what we condemn.

We condemn missing, incomplete or inaccurate documentation, but how much do we document our documentation and our documentation processes?

  • Do we document all our troubleshooting techniques and tips for the various tools we use?
  • Do we document our documentation development processes, such as how files should be generated and handed over to development, how to properly use the templates (if we even have templates!), and the standard names for our generated files?
  • Do we keep a centralized list of all our documentation projects, with dates, statuses, estimated completion times and owners, so that we and others can review and prioritize them as necessary?

We condemn reviewers who don't review our drafts, but how much time and effort do we take to when planning and creating the drafts?

  • Do we create documentation plans that specify what we are to produce, what changes need to be done, our requirements and assumptions, the names of the reviewers and a review schedule? Having a documentation plan may not guarantee success, but not having a documentation plan will almost certainly guarantee failure. We more than anyone should know that if something is not written down, there is no way it will be followed.
  • Do we set deadlines for our reviewers and follow up with them, and escalate if necessary?
  • Do we indicate what specific text has changed since the last draft, and which pages a reviewer can find those changes?
  • Do we include internal notes and clear questions on the drafts themselves that stay with the document until they are resolved?

We condemn inconsistent information and seethe when we see variances where there should be consistency. But do we take full advantage of our tools to eliminate or reduce this problem?

  • In FrameMaker, do we use variables and cross-references to store common elements such as the product name, version, and release dates?
  • Do we properly plan and structure our documents using conditional text to avoid storing and maintaining the same content twice?
  • Do we use text insets to store common sections that repeat throughout the documentation, such as copyright and legal information, lists of related documents and contact information?

Finally, we condemn those who do not take us seriously, and complain they don't know what is we do. But how much of an effort do we make to communicate and document our accomplishments?

  • Do we keep a continuous, written record of everything we accomplished, so that we can complete those pesky annual review forms accurately and completely?
  • Do we write down every milestone we achieved? Everything we did that improved the documentation, and how exactly we improved it?
  • Do we continually update that most important of all our documents, our résumé, with these accomplishments?

If we are not doing these things, we no different than the doctors who smoke, the lawyers who break the law, and the accountants who can't do their own taxes. We must stay clear of the dark side of condemnation, and look inwards first. That is the only way we can grow in our profession.

Lesson #4: To succeed in the world of information development, you must change it.

Back in the mid-1970s, when Lucas was originally pitching his idea of a space fantasy film, most studios thought it was ridiculous and would fail completely. At the time, Hollywood was producing mostly dark, gritty films that offered pessimistic views of the world. These films were simply a reflection of the somber times, with high inflation and gas prices, the Vietnam war raging and the Watergate scandal. The idea of upbeat science fiction film with good and evil clearly defined was thought to be childish and out of place.

Lucas, though, had his vision and never strayed from it. He instinctively knew the time was right for a break with the bleak films of the past. However, in order for his vision to succeed, he knew that he would have to change the way movies were made.

At the time, studios didn't really have special effects departments. There was little need, because of the realistic films being produced. Lucas had to hire the best and brightest to create new technologies and techniques - specialists in photography, model making and electronics. They even had to build their own computers since none were commercially available.

Among the pioneering techniques developed for the special effects were:

  • Advanced use of blue-screen and motion-capture processes to create sweeping, dynamic views. For example, not only did the spaceships move at various complex angles, the view of the ships (the movie-viewer's view) was also moving, giving the incredible sensation of flying.

  • The concept of a "used future". Previously, science fiction films had pristine sets in which everything looked clean and brand new. Lucas felt that the ships and surroundings should have a dirty, used appearance to add realism to the story. This look is still used today.

  • Advances in sound mixing and engineering to create the spectacular sound effects in the film. For example, various animal sounds were recorded to make the grunts and groans of Chewbacca. A metal rod tapping on a steel suspension cable was used to make the sound of the laser guns.

Star Wars not only set new standards for special effects, but added a key element to the film industry: merchandising. At the time Lucas was negotiating his contract, he had the foresight to ask for the merchandising revenues. Since merchandising was virtually a non-existent concept for the studios, they had no hesitation about accepting his request, because they assumed merchandising would not generate much revenue, if any.

Such utter lack of vision and foresight can been seen throughout the history of computing, with Xerox allowing Apple to steal the graphical user interface and the mouse, and IBM allowing Microsoft to license operating systems. In hindsight, it's easy to say these were terrible business decisions, but at the time they seemed logical for the large corporations that made them. These companies simply did not have the vision that others had. That's why Lucas, Steve Jobs (the founder of Apple) and Bill Gates are often called visionaries.

As a former executive of 20th Century Fox stated, "George was enormously far-sighted. The studios weren't because they didn't know that the world was changing. But George did know - he changed it."

The unexpected success of Star Wars completely changed the movie industry. It was the first real blockbuster. It had international success. It set new standards in visuals, sound and story telling. It created a whole culture of movie fans. But none of this would have happened if there had been no vision, no one willing to challenge the studios and change how films are made.

As information developers, we are at a crossroads in our profession. Just as the film industry changed, new ways of creating and delivering information are slowly but surely being developed. Enterprise content management systems, single-sourcing, structured writing, extreme documentation, XML, object-oriented documentation, and real-time on-demand documentation are all dramatically altering how we work, and will continue to. But we must be the ones who lead this change.

Most companies don't use these new systems because:

  1. They don't know these systems exist.
  2. They know these systems exist but don't know anything about them, or how they can potentially save huge sums of money using them.
  3. They don't know how to implement these systems.
  4. They don't want to spend the money to implement these systems.
  5. They don't like change.
  6. They are just plain evil, like Mr. Vader.

In the future, these new systems and processes will be as prevalent as the Internet. Remember when no companies had websites? Now they all do. How did this happen? Because companies recognized the new technology as an expensive but necessary cost of doing business. So it will be with these new informational systems. Once companies realize that they cannot compete without them, they will be dragged, kicking and screaming, into the 21st century.

As information developers, it is our duty to lead these organizations forward. Because if we don't, the same problems that plagued web page design will plague these new systems. So many early websites were awful, and many still are, because programmers, artists and business people, and not information developers, were given the task to create them. If we allow database managers and programmers to design and implement these systems instead of us, we will again be heading for disaster. We must be the ones to take charge, to shape our profession and our destiny.

And after we have changed how content is created, we will remember the insane way we used to create it "a long, long time ago, far, far, away."

***

These are the lessons from Star Wars, and there are many others. But the main lesson remains: have a vision and stay true to it, even when the odds are against you. Use the Force of knowing you are helping others get the information they need so that they can do their jobs. Who knows? You may even change the world.

May the "single-source" be with you...

Andrew Brooke (abrooke@insystems.com) is a Senior Information Developer at InSystems and blogs regularly.