Wednesday, December 30, 2009
Book Review: Severance Package, by Duane Swierczynski
With Severance Package, Duane Swierczynski, author of The Blonde, The Wheelman, and Marvel Comics' X-Men series Cable, has written a furiously-paced crime thriller. Severance Package concerns seven employees of a financial services company called to a Saturday morning meeting in a downtown Philadelphia high rise. Like much about this novel, no character is exactly what he or she first seems. No plot point is presented without complication.
The story shifts into warp speed early on when the boss, David, calls the Saturday meeting to order by informing his underlings that the floor they are on has been secured so nobody can enter or exit without triggering nasty poisonous gas. Their company, actually a front for a covert government agency, is getting shut down. And instead of laying people off, this company's downsizing severance package includes death. All employees are instructed to either drink a cup of poisoned champagne or take a bullet to the head. Without giving much more of the plot away, I can tell you that only one employee goes for the champagne, thinking it's some kind of twisted corporate trust game. When one of the underlings shoots the boss, all hell breaks loose.
As far as characters, there's Molly, the boss's mousy assistant. Jamie, the word nerd who writes press releases. Ethan, ex-military, ex-special forces. Nichole, a spreadsheet workhorse who turns out to be pretty handy with a gun. And so on. The characters are just above stock, but it's not really character development you come to Severance Package looking for. It's action. And this book's got it.
Over the next 263 pages each employee scrambles around the building's 36th floor trying not to die. The timeline of the novel only arcs a couple hours, if that. It's a testament to Swierczynski's pacing that he keeps all his balls in the air expertly, even introducing a hapless security guard who would rather not have to play hero. All the while a pair of men in Edinburgh work a bank of surveillance cameras, keeping check on the unfolding action. It's visceral storytelling that has roots in the cross-cutting style of suspense movies and the dramatic, stylish pull of left-to-right comic book frames. It makes sense then that the pages of the book are peppered with black and white illustrations by Dennis Calero.
It's a body count story, and these are by nature not heavy on the character development. From Agatha Christie's Ten Little Indians to Koushun Takami's Battle Royale, there's an inherent drama in finding out who dies next and how. But it's low-calorie, binge-and-purge fiction, with the thrill coming during the reading, not afterwards.
So that means it's all about the ride. And this novel offers a doozy, full of plot twists, double crosses, daring escapes, and frenetic moments where characters you thought were dead come back into play. Taken at this level, the ride is entertainingly fast and well-drawn, and at times almost believable. I recommend reading the book quickly. If you put it down for too long, the plot holes begin to burn away at the left side of your brain.
Violent and fast, giddy and gory, there's a lot to like about Severance Package. Take a ride.
Tuesday, December 29, 2009
Lost in the Details
I've spent two days writing a scene where one of my characters gets in a freight elevator and rides it up to her loft. Two days. Sometimes the descriptions that encompass small details, everyday actions, take the longest time to render. I might spend twenty minutes writing a paragraph that sums up the vagaries of the human condition. But what about when a character checks her email? Or makes a phone call? Or cooks dinner? These everyday details throw me. How do you describe the commonplace without sounding rote? Or harder still, how do you make these actions convey meaning specific to the character?
I look to other writers to guide me. The action in Stewart O'Nan's novella, Last Night at the Lobster, takes place over one day and (last) night. Because it's a short novel, about the closing of a franchise restaurant and how that affects the employees, there's no room for florid description or long, overheated sentences. Many times I was struck at how O'Nan concisely moved his main character, the restaurant manager, Manny, from point A to B:
"Manny strides to the far end of the bar, dips his hip at the corner, then squares, stutter-steps and shoulders through the swinging door." It's not just movement, it conveys something about the character. Manny's done this a million times before, it's rote to him, but O'Nan makes it feel fresh. It's worth quoting the next line: "It should be no surprise that his body has memorized the geometry of the Lobster, but today everything seems alien and remarkable, precious, being almost lost." We get the memorization part, and it's alien because the place closes for good at the end of the night, making the whole day take on a new quality.
How do characters act when they fight? What is it about their postures and gestures that suggest their inner works? In Richard Yates' modern-novel template Revolutionary Road, Frank and April Wheeler are having another fight. Frank has stopped the car at the side of the road at night, and both are out. April won't tell Frank why she's mad at him. In reaction: "His arms flapped and fell; then, as the sound and the lights of an approaching car came up behind them, he put one hand in his pocket and assumed a conversational slouch for the sake of appearances." Frank feels powerless to understand April's anger (flapping falling arms) and even in the dark feels compelled to keep up appearances.
Richard Russo, a master of small town moments, writes well of cooks and the workings of restaurants and diners. In his first novel, Mohawk, Russo frames some of the story about the denizens of the town of Mohawk, New York at the Mohawk Grill. It's the start of the novel, and Harry, who runs the Grill, is starting his daily ritual, as Wild Bill looks on. "'Hungry?' Harry says. Wild Bill nods, and studies the grill, which is sputtering butter. Harry lifts a large bag of link sausages and tosses several dozen on the grill, covering its entire surface, then separates them with the edge of his spatula, arranging them in impressive phalanxes...(Wild Bill) watches hypnotized as the links spit and jump." It's a nice touch to see an everyday activity through the eyes of the one person in town who appreciates it. We've all seen the spit and jump of cooking food. It's this attention to detail throughout Russo's writing that makes you feel like you're looking through a door propped open by the only person who knows how.
What about recreating a specific historic moment? In Colum McCann's Let the Great World Spin, he configures the small human and mechanical gestures of lower Manhattan on the morning in the early 70s' when Philippe Petit walked between the Twin Towers: "Around the watchers, the city still made its everyday noises: Car horns. Garbage trucks. Ferry whistles. The thrum of the subway. The M22 bus pulled in against the sidewalk, braked, sighed down into a pothole. A flying chocolate wrapper touched against a fire hydrant. Taxi doors slammed. Bits of trash sparred in the darkest reaches of the alleyways. Sneakers found their sweetspots. The leather of briefcases rubbed against trouserlegs. A few umbrella tips clinked against the pavement. Revolving doors pushed quarters of conversation out into the street." Without following one character or sticking to one event, McCann places the reader at a real moment in time with a specificity of place.
Sometimes these descriptions are what genre writers do best; economically flicking through a character's movements to get them to the next scene of action or romance or suspense. Take this nugget early on in Dashiell Hammett's The Dain Curse, as we first meet the Continental Op, looking for evidence in a front yard: "I put (the diamond) in my pocket and began searching the lawn as closely as I could without going at it on all fours." He doesn't have time or inclination to crawl around, but needs to get close enough to rut around the grass just the same.
So, what about my character taking the elevator? I can take a lesson from Frank Wheeler, on his way up to his dreary job: "...he obeyed the pointed finger of the elevator starter without quite being aware of it, nor did he notice which of the six elevator operators it was who sleepily made him welcome...Pressed well back in the polite bondage of the car, he heard the sliding door clamp shut and the safety gate go rattling after it, and as the car began to rise he was surrounded by the dissonant conversation of his colleagues."
It's not about showing what a character does, it's showing how she does it.
Friday, December 25, 2009
Sunday, December 20, 2009
Introducing a Wonderful Storyteller
Allow me to introduce a talented storyteller, a precocious creative force. An animator and writer, I've known him for many years. He's my nephew, Devin Johnson and he's created a beautiful short film for my sister. Both the sister and the film are called Robin.
Check out the film HERE. It's a gem, a must see, and invites multiple viewings. It gets many thumbs straight up and begs the question: when when when will we get to see more films or read more stories this young, but fully-formed talent. Actually, he's got a blog called Fluorescent Moon, where you can check out some of his other animated films. Enjoy, and let me (or him) know what you think.
Check out the film HERE. It's a gem, a must see, and invites multiple viewings. It gets many thumbs straight up and begs the question: when when when will we get to see more films or read more stories this young, but fully-formed talent. Actually, he's got a blog called Fluorescent Moon, where you can check out some of his other animated films. Enjoy, and let me (or him) know what you think.
Wednesday, December 16, 2009
Busy Season
How do you write during the busy season? I blogged nine times last December (yep, this blog is over a year old) and I'm not sure how I did it. This year it's all I can do to get to work on time, prepare for the gift-giving holidays and family commitments, and pick up a Christmas tree. Meanwhile I'm working on posts for blogs not my own. One about movies that I started back in late summer. The other will be my first post for a super secret, not-yet-live group blog that I'm helping start (more on that later). Meanwhile, I can't help but check the website of the lit mag for which I have a story coming out in this month (more on that later as well).
My intention with this blog is to come up with informative, entertaining posts, as many as I can a month. My problem with this is that I end up spending hours on a post. Adding links, adding photos, forgetting to edit and censor the writing. Writing to be concise becomes folly. Still, this blog has given me the opportunity to do different types of writing that I would not have otherwise written. Book reviews, posts about buying books, about movies, interviews. I want to do more interviews, I have a list of post topics that I continue to add to, I have a book I just finished reading and want to review.
Question: what do you want to see when you visit a blog? What holds your interest? What do you like about Unreliable Narrator? What would you like to see more of? Remember, requests are welcome.
Have a great busy season. And hopefully we'll see more of each other next year.
Saturday, December 5, 2009
Reference Guides for Writers
Imagine sitting before a blank monitor ready to start writing Chapter 1 in a series of what you hope to be a multi-chaptered novel. You want to start with the weather. Bad idea. Wait, better idea: start with your main character waking to the sound of nature. A bird call. That's the ticket. More specific, although still mysterious. But, what kind of bird?
That opens an entire world of questions. What time of day is it? Where is your character? Small town by the Atlantic? City by the Yangtze River? Is it morning? Is it winter? You need to answer a few of those questions. And when you narrow that down (see, I'm helping you start your novel!), grab the nearest bird guide and start flipping those pages until you find the perfect bird native to your location.
Sure, finding out things about stuff on the Internet is convenient and timely. But nothing compares to owning a few dog-eared guide books to count on for information that doesn't change overnight. Like information about birds. I recommend The Sibley Field Guide to Birds, the classic bird guide by David Allen Sibley. It's a compact guide with thousands of meticulous illustrations of birds, along with maps of the country colored to show what areas they spend quality time. My guide is about the size of a mass market paperback, so you can thumb through it while staring out your back window at some bird you need to identify for your book.
How about trees? Your noisy bird is sitting on a tree branch. What the hell kind of tree is that again? I recommend The Easy Tree Guide, published by Falcon Guides. This full-color book dedicates two pages to each tree, one page a photograph of said tree, the facing page a breakdown of the leaf structure, height, and details of where you can find said tree. The trees are organized by leaf shape. So, it takes some getting used to if you don't know what you're looking for. But what better way to get to know trees than reading a book about them? You have to start someplace.
After your bird gets tired of singing, he flies up to a roof. The roof of the house your main character lives in (or lives next door to). Need some historical and architectural context to describe the house? Do you forget what eaves and dormers are? What if your character lives in the 1800s? What kind of houses were around then? In Virginia?
I highly recommned Gerald Foster's American Houses, a field guide to the architecture of the home. This guide contains photographs and illustrations of houses, including floor plans so you can see what went on inside as well as out. Key elements of all houses are included. It's organized chronologically, so if you know the era of the house you want to write about, you just head to that chapter. You'll find out that the Craftsman style was popular between 1900 and 1930. What's a Center-Passage House (1700-1860)? Just turn to page 94 to find out. Each house type and style is detailed in accompanying text that puts all American houses in the context of the times in which they were built, and describes their influences. It has a complete glossary.
Say you're writing a fantasy, and your bird of choice flies from your house's roof and lands on a seventeenth century cannon (long story). Or a you're writing an adventure and the bird lands on a derrick of an oil production platform. Maybe the bird is attracted to the mouth of a cave, then flies in. You need to know about these disparate objects, but you may not even know what they're called, let along how to describe them.
You need the Macmillan Visual Dictionary. Not a guide per se, this dictionary includes 3,500 color illustrations of everything from, well, oil derricks to caves. Each image has terms defining what the areas of the subject are called. And in the case of a cave, the illustration shows a cross section, so you see the inside and the outside. My copy is from 1995, bought as a remainder at New England Mobile Book Fair years ago. I still keep it on the shelf and thumb through it. Not only do I often find contained what I need to describe, but I get ideas. Subjects range from astronomy and geography, to the human body, to house furniture, gardening tools, heavy machinery, and weapons.
Weapons. For when your bird characters revolt against human-kind, and need something to fight with.
That opens an entire world of questions. What time of day is it? Where is your character? Small town by the Atlantic? City by the Yangtze River? Is it morning? Is it winter? You need to answer a few of those questions. And when you narrow that down (see, I'm helping you start your novel!), grab the nearest bird guide and start flipping those pages until you find the perfect bird native to your location.
Sure, finding out things about stuff on the Internet is convenient and timely. But nothing compares to owning a few dog-eared guide books to count on for information that doesn't change overnight. Like information about birds. I recommend The Sibley Field Guide to Birds, the classic bird guide by David Allen Sibley. It's a compact guide with thousands of meticulous illustrations of birds, along with maps of the country colored to show what areas they spend quality time. My guide is about the size of a mass market paperback, so you can thumb through it while staring out your back window at some bird you need to identify for your book.
How about trees? Your noisy bird is sitting on a tree branch. What the hell kind of tree is that again? I recommend The Easy Tree Guide, published by Falcon Guides. This full-color book dedicates two pages to each tree, one page a photograph of said tree, the facing page a breakdown of the leaf structure, height, and details of where you can find said tree. The trees are organized by leaf shape. So, it takes some getting used to if you don't know what you're looking for. But what better way to get to know trees than reading a book about them? You have to start someplace.
After your bird gets tired of singing, he flies up to a roof. The roof of the house your main character lives in (or lives next door to). Need some historical and architectural context to describe the house? Do you forget what eaves and dormers are? What if your character lives in the 1800s? What kind of houses were around then? In Virginia?
I highly recommned Gerald Foster's American Houses, a field guide to the architecture of the home. This guide contains photographs and illustrations of houses, including floor plans so you can see what went on inside as well as out. Key elements of all houses are included. It's organized chronologically, so if you know the era of the house you want to write about, you just head to that chapter. You'll find out that the Craftsman style was popular between 1900 and 1930. What's a Center-Passage House (1700-1860)? Just turn to page 94 to find out. Each house type and style is detailed in accompanying text that puts all American houses in the context of the times in which they were built, and describes their influences. It has a complete glossary.
Say you're writing a fantasy, and your bird of choice flies from your house's roof and lands on a seventeenth century cannon (long story). Or a you're writing an adventure and the bird lands on a derrick of an oil production platform. Maybe the bird is attracted to the mouth of a cave, then flies in. You need to know about these disparate objects, but you may not even know what they're called, let along how to describe them.
You need the Macmillan Visual Dictionary. Not a guide per se, this dictionary includes 3,500 color illustrations of everything from, well, oil derricks to caves. Each image has terms defining what the areas of the subject are called. And in the case of a cave, the illustration shows a cross section, so you see the inside and the outside. My copy is from 1995, bought as a remainder at New England Mobile Book Fair years ago. I still keep it on the shelf and thumb through it. Not only do I often find contained what I need to describe, but I get ideas. Subjects range from astronomy and geography, to the human body, to house furniture, gardening tools, heavy machinery, and weapons.
Weapons. For when your bird characters revolt against human-kind, and need something to fight with.
Sunday, November 29, 2009
Patience
Last week I was contacted by Fiction Magazine. They accepted a story of mine for publication. This is, of course, great news. Fiction magazine is carried by better independent bookstores, such as Brookline Booksmith, has been around since the early 70s, and backs up a wonderful history of supporting "new, emerging voices."
The story behind getting into Fiction is worth telling. I sent them my story almost three years ago, in February 2007. The story was fashioned from an outtake of a novel I was working on at the time. It was a stand-alone chapter that dealt with the second love experience of my teenage protagonist, and it didn't fit, so taking it out didn't upset any balance.
Separate from the framework of the novel, and after some revision, the piece stood on its own. Except for the ending. The original ending trails off. The stand-alone version couldn't trail off, it needed a concrete finish. This is the toughest part of shaping novel excerpts or outtakes; you must rework them so that they still make sense outside of the context of the novel. Because this was an outtake, I wasn't worried about maintaining the original spirit of the novel and could make it into what ever I wanted.
I reworked the ending to summarize the bittersweet end of a summer-long teenage relationship. I wasn't sure it worked, so I kept the ending brief; not overwriting, hoping not to call attention to any shortcomings. I sent the story out to Fiction. I must not have been confident with what I had written because I didn't send it elsewhere, and I never revised it.
When I opened and read the acceptance email, it took a couple minutes to realize what I was looking at. Most magazines/journals today will tell submitting writers that if they are not interested in your submission, you will not hear back. So it's heartening to know that us writers are not sending stuff out into an anonymous event horizon. That time waiting for a response isn't time wasted. And that if you sent a story out last year, the year before, or even the year before that, there's still hope. That somebody is spending late nights and weekends reading submissions from the slush pile in hopes of finding an unsung story, an unsung writer, another emerging voice.
Monday, November 23, 2009
The Criterion Collection: An Appreciation
I'm not sure when it started for me. The sudden, very real infatuation, hinting at obsession, for The Criterion Collection. I've always been a film buff. Ever since I studied cinema as an undergrad, I always wanted to own as many great, life-defining films as I could find. Discovering the Criterion Collection has helped me start realizing this goal.
Criterion restores and releases classic and contemporary films for home viewing. They add a few movies to the collection every month, and give each one thoughtful and loving preservation, packaging, and contextual supplements. They champion forgotten or disregarded filmmakers, like Samuel Fuller and Paul Morrissey. And while you expect such reverance for obvious film study mainstays as The 400 Blows, Wild Strawberries, and Breathless, they also make room for popular commercial movies like Spinal Tap, Robocop, John Woo's Hard Boiled, and Michael Bay's Armageddon. Most editions include inserts or booklets with essays and interviews that make a book collector like me not feel guilty for spending money on a DVD.
Sure, these editions are pricey (most run $20 to $40; more if you buy boxed sets), and they sooner run out of stock then sell at discount. But if a film you love finally gets the full-on Criterion Collection treatment, 35 bucks for a 2-disc version that includes a new, restored high-def digital transfer supervised by the now-aged director who came out of seclusion just for this; well, it's is enough to make you forget your soaring credit card interest rate. I only own nine movies from Criterion, but these are movies I expect to watch more than a couple times, and whose special features I enjoy as much as the film itself.
For example, take The Killers. Based on the story by Hemingway about two hit men on the trail of a doomed boxer, this DVD contains two discs and features three very different film adaptations of the story. You get the 1946 Robert Siodmak version, starring Burt Lancaster in his debut, and a young Ava Gardner. Then there's Don Siegel's 1964 version, starring Lee Marvin, Angie Dickinson, and John Cassavetes. If you just can't get enough, they include a student film version directed by Andrei Tarkovsky from 1956. Tucked away in the case are two essays by Jonathan Lethem and Geoffrey O'Brien, from which you can garner tidbits of context and gossip. Like how Don Siegel's version was originally shot for TV, but deemed too brutal for prime time and got a theatrical release.
Most editions include beautifully bound booklets or inserts. The 2-disc version of My Own Private Idaho comes with a 60-page booklet that is full of color photos and includes essays by Amy Taubin and Lance Loud, and an interview with director Gus Van Sant by the great literary imposter JT LeRoy. There are conversations between Van Sant and River Phoenix and a joint interview with Phoenix and co-star Keanu Reeves, both from 1991 Interview magazines.
My most recent purchase was Krzysztof Kieslowski's The Double Life of Veronique. This handsome 2-disc set came with a booklet that includes a series of sublime movie stills, many of actress Irene Jacob, essays by Jonathan Romney, Slavoj Zizek, and Peter Cowie, plus an excerpt from Kieslowski on Kieslowski.
Okay, it's not all sunny brilliance. Their version of Fellini's 8 1/2 includes some additional short films that highlight one very over-indulgent filmmaker (beware Fellini: A Filmmaker's Notebook). And it's not like I want to own every movie they release. If I need to see Chasing Amy again, I'll Netflix it. And I can't imagine slogging through Passolini's The 120 Days of Sodom, let alone owning it.
Already a fan of the Criterion Collection? Which of their films are part of your collection? If you're not a fan, check them out. They just might be releasing that long lost classic you've been pining to see again.
Here's a promo of some of their 2009 releases which gives a good overview of the disparate films they offer:
Tuesday, November 17, 2009
Books in My Lobby 9
This week we have for you some Great American short stories. From Hawthorne to Hemingway. I didn't grab this one. But, what if I had? Then I'd be experiencing Amazon's mighty description firsthand:
"Beginning with well-known stories by Hawthorne, Melville, and Poe, this diverse and colorful collection includes tales by Mark Twain, Ambrose Bierce, Sherwood Anderson, Henry James, Edith Wharton, Willa Cather, Stephen Crane, and Mary Wilkins Freeman. From Sarah Orne Jewett’s portraits of rural Maine to F. Scott Fitzgerald’s brilliant tales from the Jazz Age, these stories span the breadth of the American experience."
Not that I don't love a good American story, but I already have a number of great anthologies that help scratch that story itch. Like The Best American Short Stories of the Century, edited by John Updike. And The Complete short Stories of Ernest Hemingway, The Finca Vigia Edition. The Best Short Stories of J.G. Ballard. The Collected Stories of Richard Yates. Great Esquire Fiction: The Finest Stories from the First Fifty Years. And representing the ladies: Like Life, Stories by Lorrie Moore. That should do me for awhile.
Wednesday, November 11, 2009
Music for Writing
I write better to music. It helps my concentration, keeps me focused. I listen to music whenever I can during the day. During my commute. At home after work. Hanging around the house on the weekend. I have a job that allows me to use my iPod much of the time, filtering out the noise of cube-city and the nearby printing station. Silence is fraught with random pops, bangs, and clicks. It drives me up the wall if I'm trying to concentrate. That's why I go on the counter attack to create my own noise.
Classical music and jazz don't always work for me, unless the pieces are low-key and consistent. Erratic melody interrupts concentration. Instrumentals work best, or music with the lyrics well buried. Buried under what? A wall of consistent, impenetrable sound. I cannot write, or read for that matter, to any music where the vocal tracks are front and center. This includes most pop and rock songs, all rap, r + b, ballads, and standards.
I've put together a series of mix CDs (which, when I went digital, became playlists) that I listen to when writing. They are top heavy with music by bands and artists like Cocteau Twins, Robin Guthrie, Thievery Corporation, Ulrich Schnauss, Brian Eno, Bethany Curve, Air, Lush, Readymade, Slowdive, Engineers, Ride, Chapterhouse. These bands perform music that contain melodies wrapped in guitars and reverb, or mellow beats and airy, atmospheric vocals that sit way back and watch the show, or walls of guitar distortion and effects that allow me to sink into my writing. Most of my output is due to these and other similar-sounding bands.
Here's a sampling:
Here the Cocteau Twins throw down probably their biggest 'hit' (I remember seeing it featured on MTVs 120 Minutes), Carolyn's Fingers, which mixes their dreamy blend of pop sensibility, shimmering guitar, reverb, and Elizabeth Frazier's otherworldly voice singing nonsensical lyrics. This falls right into the category of instrumental music, since I don't know what she's singing about except for an occasional phrase in English.
Robin Guthrie was the guitarist for Cocteau Twins, and he went on to release mostly instrumental music much in the vein of the Cocteau Twins' later output. It's like hearing the Cocteau Twins, minus the instrument that is Elizabeth Frazier's voice:
Thievery Corporation are a bit different, since they use multi-vocalists and meld many different styles, such as salsa, Latin, African, among many others. Not all their stuff is writer friendly, but they are consistent within songs. I know what to expect when a song comes on and can always skip it if it features some inappropriate vocals. Here's a good example of their beat-heavy, but still mellow (chill, if you will) stuff that features delicate female vocals and a dreamy soundscape:
Ulrich Schnauss mixes the best of all worlds; his stuff is mostly instrumental electronica, with harmonies, and perhaps a guitar or two (who can tell?), and the songs that feature vocals have them buried in waves of multi-tracked soundscapes. His music achieves a thoroughly integrated, fugue-like sound. It's especially good to listen to at work; when I have some really dry material to read or write about, I just click on old Ulrich and I'm lost for hours in concentration.
Brian Eno is the father of modern instrumental ambient music (or at least the older brother) and so I find that I can listen to most of his output interchangeably, whether it's his early stuff from the 70s, through to his gorgeous work on Apollo: Atmospheres and Soundtracks in the 80s, or his poppier 90s efforts.
Here's a selection from Atmospheres and Soundtracks:
I discovered Bethany Curve on a website devoted to shoegazer bands. Popularized in the late 80s and early 90s by bands like Jesus and Mary Chain, Slowdive, Ride, and My Bloody Valentine, shoegazer literally refers to some moptop dude or dudette staring at his/her shoes while playing guitar. The music is marked by a wall of guitar distortion and reverb, propulsive drums (sometimes), buried vocals (my favorite kind), and often extended song lengths. Bethany Curve is part of a second or maybe third wave of bands to follow the lead, or continue the cause, since most of the original shoegazer bands are MIA. When I'm feeling less mellow but no less writerish, I'll put on a little shoegazer for the soul.
Slowdive was part of the first wave of dreamy shoegazers, heavy on the echo and thick guitars. Dense but pretty, they never quite got the respect paid to My Bloody Valentine. Or maybe I just made that up. Singer and guitarist Neil Halstead went on to form Mojave 3 and later record solo.
My Bloody Valentine started the whole shoegazery thing. Not always perfect for writing, but occasionally, when I need to go deep, I'll throw on Loveless and the writing time just floats on by and 50 minutes later I'll surface and notice the sunlight and take a breather. Loveless has been influential enough to be beget a book in the 33 1/3 series.
Here's a clip from their recent successful reunion tour:
Do you listen to music when you write? What kind? Or do you need complete silence?
Tuesday, November 3, 2009
Writing Group Plug - Autumn Edition
Short notice (especially if you live on another continent), but tomorrow night get yourself over to Porter Square Books to hear novelist and poet E.B. Moore read from her latest book, New Eden. I've taken Grub classes with E.B., and earlier this year enjoyed the benefit of her calming, practical commentary during our writing group discussions. She's a wonderful reader, and she writes in a vivid, evocative, concise style.
Porter Square Books is located at the Porter Square Shopping Center, 25 White Street, Cambridge. Reading starts at 7 PM. Christine Tierney the opens the reading.
Porter Square Books is located at the Porter Square Shopping Center, 25 White Street, Cambridge. Reading starts at 7 PM. Christine Tierney the opens the reading.
Tuesday, October 27, 2009
Boston Book Festival -- Recap
As everybody knows, it’s book festival time in New England. So this past Saturday Liz and I attended the inaugural Boston Book Festival. It had been a rainy morning, but we made the trip to Copley Plaza and by the time we arrived, the rain had stopped, and the temps were into the 60s.
First stop was the Boston Public Library Abbey to check out Hank Phillippi Ryan’s Guided Open Mic, sponsored by Grub Street. For 90 minutes, writers took turns reading their original work in front of a room of attendees while Hank took notes.
After each reading, Hank gave a helpful critique of the presentation. She commented on material choice, urging readers to really consider the piece they read in terms of how it represents their work. And delivery, telling one young, eager writer to slow down because she couldn’t make out half her words. She was honest but gentle, doing a great job of making each participant feel comfortable, if not perfectly at ease. Reading in front of an audience is difficult enough, so performing to be critiqued must have been twice as nerve-shattering for these hearty writers.
The line waiting to get into an event at the library:
Next up we took in the exhibits set up in tents outside the library and along Boylston Street. The temps were warm and the rain was still holding off, but there was a wicked wind. Luckily the tents held fast.
There were long lines for Green Mountain Coffee and free ice cream. Thankfully, there were also lines at many of the other booths, including publications like The Paris Review, AGNI, the Boston Globe, and Post Road. There were many publishers represented, including David R. Godine, Etruscan Press, and Drawn & Quarterly, which brought along a beautiful selection of posters, comics, and graphic novels.
It was a good opportunity to discover small presses, and that’s just what I did when I stopped at the One Story tent. One Story is a literary magazine that offers one story per issue, one issue every three weeks. Each issue costs a dollar, and is published as a single-colored booklet. I sort of randomly grabbed two issues, numbers 84 and 93. I liked issue 84’s title, Wedding Pictures. The girl behind the table knew the story, by Donald Petersen, and started to describe it to me as a sale’s pitch. It worked. Issue 93 is titled Meeting Elise, by Nam Le. Subscriptions are $21 for a year.
Then it was time to head across Boylston to the Old South Church Sanctuary to see Tim Kring, creator of Heroes, and novelist Reif Larson, author of The Collected Works of TS Spivet. Larson was first, discussing maps and other signage, and how the meanings of this communication can change depending on context. He presented a series of whimsical and sometimes hilarious slides to illustrate his points. Maps and map making figure prominently into his book as a theme and also as margin illustrations.
Tim Kring discussed the myriad ways in which the TV show Heroes is marketed, er, I mean how it presents the many facets of its storyline. He calls it Transmedia storytelling. The idea is that Heroes the TV show is the epicenter of the Heroes universe. While the show is the main engine, other outlets such as websites and action heroes and comic books can all be developed to extend the story, offering specialized content beyond what viewers see on the show. It’s sort of the ultimate in marketing synergy, where you can buy a toy from the show that includes a piece of character mythology or read a graphic novel about an ancillary character from the show, all adding to the Heroes storytelling experience.
Then Tim showed the trailer he created for a series of books he was shopping around a few years ago. He put together a website which hosted the trailer, and kind of like with Heroes, users could go navigate the website and read all about what his books were about, which includes alternate American history. Must have worked, because he got a book deal.
When that ended we had a little time left and went up to the second floor of the church to check out the Grub Street-sponsored Writer Idol, where a professional actor read the first page or two of anonymously submitted work by writers in the audience. After which a panel of 4 agents explained why each would or would not want to see more of the work. There were a few pieces that the agents agreed they might be interested in. Now it’s up to those writers to get their stuff into the agent’s hands.
Overall, a great experience, even for the few events we attended. The festival was smooshed into one day, so I imagine some attendees might have had a difficult time deciding what to see as there was much overlap in the schedule. But the choices were diverse enough so that if you missed one event, hopefully the next would make up for it. I'll definitely keep an eye out for next year's festival.
If you're interested in Tim Kring's theory of Transmedia, here he is expounding on the subject:
First stop was the Boston Public Library Abbey to check out Hank Phillippi Ryan’s Guided Open Mic, sponsored by Grub Street. For 90 minutes, writers took turns reading their original work in front of a room of attendees while Hank took notes.
After each reading, Hank gave a helpful critique of the presentation. She commented on material choice, urging readers to really consider the piece they read in terms of how it represents their work. And delivery, telling one young, eager writer to slow down because she couldn’t make out half her words. She was honest but gentle, doing a great job of making each participant feel comfortable, if not perfectly at ease. Reading in front of an audience is difficult enough, so performing to be critiqued must have been twice as nerve-shattering for these hearty writers.
The line waiting to get into an event at the library:
Next up we took in the exhibits set up in tents outside the library and along Boylston Street. The temps were warm and the rain was still holding off, but there was a wicked wind. Luckily the tents held fast.
There were long lines for Green Mountain Coffee and free ice cream. Thankfully, there were also lines at many of the other booths, including publications like The Paris Review, AGNI, the Boston Globe, and Post Road. There were many publishers represented, including David R. Godine, Etruscan Press, and Drawn & Quarterly, which brought along a beautiful selection of posters, comics, and graphic novels.
It was a good opportunity to discover small presses, and that’s just what I did when I stopped at the One Story tent. One Story is a literary magazine that offers one story per issue, one issue every three weeks. Each issue costs a dollar, and is published as a single-colored booklet. I sort of randomly grabbed two issues, numbers 84 and 93. I liked issue 84’s title, Wedding Pictures. The girl behind the table knew the story, by Donald Petersen, and started to describe it to me as a sale’s pitch. It worked. Issue 93 is titled Meeting Elise, by Nam Le. Subscriptions are $21 for a year.
Then it was time to head across Boylston to the Old South Church Sanctuary to see Tim Kring, creator of Heroes, and novelist Reif Larson, author of The Collected Works of TS Spivet. Larson was first, discussing maps and other signage, and how the meanings of this communication can change depending on context. He presented a series of whimsical and sometimes hilarious slides to illustrate his points. Maps and map making figure prominently into his book as a theme and also as margin illustrations.
Tim Kring discussed the myriad ways in which the TV show Heroes is marketed, er, I mean how it presents the many facets of its storyline. He calls it Transmedia storytelling. The idea is that Heroes the TV show is the epicenter of the Heroes universe. While the show is the main engine, other outlets such as websites and action heroes and comic books can all be developed to extend the story, offering specialized content beyond what viewers see on the show. It’s sort of the ultimate in marketing synergy, where you can buy a toy from the show that includes a piece of character mythology or read a graphic novel about an ancillary character from the show, all adding to the Heroes storytelling experience.
Then Tim showed the trailer he created for a series of books he was shopping around a few years ago. He put together a website which hosted the trailer, and kind of like with Heroes, users could go navigate the website and read all about what his books were about, which includes alternate American history. Must have worked, because he got a book deal.
When that ended we had a little time left and went up to the second floor of the church to check out the Grub Street-sponsored Writer Idol, where a professional actor read the first page or two of anonymously submitted work by writers in the audience. After which a panel of 4 agents explained why each would or would not want to see more of the work. There were a few pieces that the agents agreed they might be interested in. Now it’s up to those writers to get their stuff into the agent’s hands.
Overall, a great experience, even for the few events we attended. The festival was smooshed into one day, so I imagine some attendees might have had a difficult time deciding what to see as there was much overlap in the schedule. But the choices were diverse enough so that if you missed one event, hopefully the next would make up for it. I'll definitely keep an eye out for next year's festival.
If you're interested in Tim Kring's theory of Transmedia, here he is expounding on the subject:
Wednesday, October 21, 2009
October is Book Festival Time
If it's October in New England, than it's time to get your literati on. This Saturday October 24 marks the first Boston Book Festival, held from 10:00 am - 6:00 pm in and around Copley Square. It's free, man. What could be better? Rain or shine (and the weather's leaning more on the rain side--so bring your rubbers). There will be 90 authors and presenters, events, a street fair, music, contests, exhibitions, and book signings.
The line up of authors is damn impressive: John Hodgeman, Elinor Lipman, Anita Diamant, Chris Castellani, Robert Pinsky, Orhan Pamuk (keynote speaker), Ken Burns, Anita Shreve, Iyeoka Ivie Okoawo, Alicia Silverstone (huh?), Richard Russo, Stephen Carter, Andre Dubus III, Ben Mezrich, Tom Perrotta, and many more. Check out the schedule for event times and locations.
At least one event ain't free: Boston Noir Launch. 6-9 at Boston Public Library Rabb Lecture Hall. $15 per ticket, and still available as of this post. "Celebrate the launch of the new fiction collection Boston Noir (Akashic Books) with contributing author and master of the art of noir, editor Dennis Lehane. From Dorchester to Southie and from Beacon Hill to Brookline, Boston Noir features 11 Boston neighborhoods and nearby communities in stories by contributors including Brendan DuBois, Dana Cameron, Jim Fusilli, Lynne Heitman and Russ Aborn, who will attend the launch event. Expect a dynamic, drama-filled presentation." Okay.
Things actually get underway Friday night at Trinity Church where "Robin Young, the host of Here and Now on WBUR, will emcee the evening’s festivities, beginning with Boston Mayor Thomas Menino’s reading of a passage from his favorite book." Then, Livingston Taylor performs and discusses songwriting.
Grub Street is a partner, and as such they are offering some free workshops, including:
- Jumpstart Your Writing (writing exercises with mini-lessons on craft) taught by Grub instructors Stace Budzko and Grace Talusan
- Writer Idol (a chance to get the first page of your book heard and critiqued by a literary agent or editor), judged by agents Esmond Harmsworth, Janet Silver and Eve Bridburg, and editor Helene Atwan
- Guided Open Mic with Hank Phillippi Ryan (a traditional open mic with lessons on how to perform your work). I attended this session when Hank offered it at this year's Muse and the Marketplace. If you ever read your writing in public, this event is a great primer for how to do it right, without putting your audience to sleep.
Wait, that's not all. Starting this Thursday, October 22, and running until November 8, it's the return of the Concord Festival of Books. 18 days, over 40 authors, 22 events. Most events are free. So, unlike the Boston Book Festival which delivers the goods in one day, the Concord festival spreads the love out over two and a half weeks. There will be discussions, readings, and talks. For example, on Monday, October 26th you can catch Larry Tye talking about Satchel: The life and times of an American legend, and Dick Lehr discussing The Fence: A police cover-up along Boston's racial divide. Other authors include Howard Dean (opening day speaker), Chris Bohjalian, Gregory Maguire, Katherine Howe, Jessica Shattuck, Fred Marchant, Mitchell Zuckoff, and lots more.
While this is a Concord, MA-based festival, as in years past some events are held in Lowell, at locations like the Pollard Library, Comley-Lane Theater at UMass, and Wannalancit Mills. A couple years ago Liz and I went to see John Elder Robison and his brother, Augusten Burroughs, speak at UMass as part of the festival. It was a great evening, where the audience heard touching, enlightening, a little horrific, but mostly hilarious stories about Robison's experiences understanding and accepting his Asperger’s Syndrome. Here's Liz getting her book signed afterwards by Augusten:
A big shout out to Rob Mitchell, an all-around great guy who founded the festival in 1993 and still directs the whole she-bang.
Unlike a writer's conference, these book festivals are geared more toward readers and book buyers than to writers. Attending a book festival as a writer, it'll be a relief not to have to worry about getting a manuscript critique or running into an agent I might have had an awkward interaction with last year (I suppose that could still happen...).
I wish the Boston Book Festival a great inaugural event, while also anticipating another successful year for the Concord (and Lowell) Festival of Books.
The line up of authors is damn impressive: John Hodgeman, Elinor Lipman, Anita Diamant, Chris Castellani, Robert Pinsky, Orhan Pamuk (keynote speaker), Ken Burns, Anita Shreve, Iyeoka Ivie Okoawo, Alicia Silverstone (huh?), Richard Russo, Stephen Carter, Andre Dubus III, Ben Mezrich, Tom Perrotta, and many more. Check out the schedule for event times and locations.
At least one event ain't free: Boston Noir Launch. 6-9 at Boston Public Library Rabb Lecture Hall. $15 per ticket, and still available as of this post. "Celebrate the launch of the new fiction collection Boston Noir (Akashic Books) with contributing author and master of the art of noir, editor Dennis Lehane. From Dorchester to Southie and from Beacon Hill to Brookline, Boston Noir features 11 Boston neighborhoods and nearby communities in stories by contributors including Brendan DuBois, Dana Cameron, Jim Fusilli, Lynne Heitman and Russ Aborn, who will attend the launch event. Expect a dynamic, drama-filled presentation." Okay.
Things actually get underway Friday night at Trinity Church where "Robin Young, the host of Here and Now on WBUR, will emcee the evening’s festivities, beginning with Boston Mayor Thomas Menino’s reading of a passage from his favorite book." Then, Livingston Taylor performs and discusses songwriting.
Grub Street is a partner, and as such they are offering some free workshops, including:
- Jumpstart Your Writing (writing exercises with mini-lessons on craft) taught by Grub instructors Stace Budzko and Grace Talusan
- Writer Idol (a chance to get the first page of your book heard and critiqued by a literary agent or editor), judged by agents Esmond Harmsworth, Janet Silver and Eve Bridburg, and editor Helene Atwan
- Guided Open Mic with Hank Phillippi Ryan (a traditional open mic with lessons on how to perform your work). I attended this session when Hank offered it at this year's Muse and the Marketplace. If you ever read your writing in public, this event is a great primer for how to do it right, without putting your audience to sleep.
Wait, that's not all. Starting this Thursday, October 22, and running until November 8, it's the return of the Concord Festival of Books. 18 days, over 40 authors, 22 events. Most events are free. So, unlike the Boston Book Festival which delivers the goods in one day, the Concord festival spreads the love out over two and a half weeks. There will be discussions, readings, and talks. For example, on Monday, October 26th you can catch Larry Tye talking about Satchel: The life and times of an American legend, and Dick Lehr discussing The Fence: A police cover-up along Boston's racial divide. Other authors include Howard Dean (opening day speaker), Chris Bohjalian, Gregory Maguire, Katherine Howe, Jessica Shattuck, Fred Marchant, Mitchell Zuckoff, and lots more.
While this is a Concord, MA-based festival, as in years past some events are held in Lowell, at locations like the Pollard Library, Comley-Lane Theater at UMass, and Wannalancit Mills. A couple years ago Liz and I went to see John Elder Robison and his brother, Augusten Burroughs, speak at UMass as part of the festival. It was a great evening, where the audience heard touching, enlightening, a little horrific, but mostly hilarious stories about Robison's experiences understanding and accepting his Asperger’s Syndrome. Here's Liz getting her book signed afterwards by Augusten:
A big shout out to Rob Mitchell, an all-around great guy who founded the festival in 1993 and still directs the whole she-bang.
Unlike a writer's conference, these book festivals are geared more toward readers and book buyers than to writers. Attending a book festival as a writer, it'll be a relief not to have to worry about getting a manuscript critique or running into an agent I might have had an awkward interaction with last year (I suppose that could still happen...).
I wish the Boston Book Festival a great inaugural event, while also anticipating another successful year for the Concord (and Lowell) Festival of Books.
Monday, October 19, 2009
Technical Writing Vs. Narrative Fiction, Part 4
The last of a 4-part series.
Technical Review
After a technical document has been written—or changed significantly from an earlier version—it needs to be reviewed for technical accuracy by a subject matter expert. A tech writer needs to learn all she can about the feature she is writing about (be it the integration of disaster recovery software or a new part of the user interface), but to ensure accuracy, she must often rely on the people who designed, engineered, and tested the feature. So, before a tech writer can say a guide or help topic is done, it needs to be reviewed from a technical perspective. More than once, if there's time.
If you are writing a novel that has many medical or scientific facts and concepts, and this is not an area of expertise for you, then you probably want somebody who knows more than you do to read your manuscript. Even if you interviewed a subject matter export and maybe even visited her at work to see what it’s like to be an emergency room doctor, getting the expert to do a technical review of your book is necessary to ensure you get the details right. Get more than one expert to read it if you can. That way you get different points of view, different feedback, and different ideas.
Peer Edits
Peer editing is a term we use in the tech writing biz. When you finish a draft of a guide, you want another writer to check it for consistency, logic, structure, and corporate standards, and to give a good proof reading. Getting a peer edit on your documentation is not just a good idea but is necessary to ensure you’re not distributing sloppy, confusing material. Sometimes you don’t have the time to get another tech writer to review a guide, and you just have to be your own peer editor.
There’s no time to let a draft of a user’s guide breathe. You can't let it sit in a drawer for a few months to come back to with fresh eyes. You finish the guide as much as you can and move on to the next. But technical documentation is a living document. Meaning, you’ll get another chance to make it better when you update it for the next release. How many times do you get to rewrite a story or novel after it’s published? Following pre-determined corporate writing standards and conventions help get it right the first time.
I enjoy reading other writers’ work and try to give an honest, helpful appraisal of the writing. Peer editing has helped me when it comes to editing my narrative fiction, training me to focus on problem areas and to be more objective.
Technical writing in fiction and non-fiction
As I mentioned, you might include information in your novel or story that must be technically accurate. This includes doctor, police, and lawyer stuff. If you include this stuff, make sure you’re a doctor, policeman, or a lawyer. Or you’ve interviewed one or had one review your story for accuracy. Or you've lived with one or are married to one (this is research—take advantage of it). Because if you haven’t done any research, your lack of knowledge will be noticeable on some level, especially to people in the field you’re writing about.
If you’re not writing fiction but another type of book, say a how-to like a cook book or craft book, then you are getting much closer to writing a technical document. You should be using more technical writing elements. These basic elements include:
- Numbered and bulleted lists
- Tables
- Hierarchical headings
- Cross references
- Chunked information
- White Space
- Indexes, glossaries, and tables of contents
These are all important and all help a user find information. My favorite is the list.
Don’t be afraid of the list. The mighty list is your friend. Read through your book. Every time you give the reader a task to perform, put it in a list. This list must start with 1. 1 Open the book. 2 Read every chapter. 3 Break nested tasks and sentences of items into lists. A task shouldn’t be too many steps. If it’s longer than 10 steps, break the task into two or three smaller tasks. Another type of list has bullet points rather than numbers. A bulleted list is a good way to organize stuff. It’s easy to read and helps to break up the monotony of a paragraph of text.
Here’s a rewrite of the last paragraph, using tech writing elements:
How to Use Lists
Don’t be afraid of the list. The list is your friend.
Guidelines:
- Read through your book. Every time you give the reader a task to perform, put it in a list.
- This list must start with 1.
1. Open the book.
2. Read every chapter.
3. Break nested tasks and sentences of items into lists.
Tasks
A task shouldn’t be too many steps. If it’s longer than 10 steps, break the task into two or three smaller tasks.
Bullet points
Another type of list has bullet points rather than numbers. A bulleted list:
• Is a good way to organize stuff
• Is easy to read
• Helps to break up the monotony of a paragraph of text
The idea is to break the information into chunks to facilitate easier reading and to help the reader find the information she needs quickly. Using the above rewrite as an example, say the reader is interested in learning about bullet points, and not tasks and numbered steps. Then, she can skip to the sub-heading Bullet points after finding the main section of How to Use Lists.
Is Technical Writing For You (or, do fiction writers make good technical writers)?
The early 00s was not a good time to be undereducated. Jobs were scarce, even in the Massachusetts high tech industry. I had a film making background, and had spent all of the 1990s working in the wedding video and video duplication business, while also writing short stories and novels. By the end of the 90s, video work was drying up and writing fiction wasn't paying the bills.
I kept reading the classifieds in the Boston Globe and seeing jobs for technical writers. I had no idea what this was, but if being a writer was part of the job description, then I was half-way there. I looked into a few programs in the area, and in 2002 I completed a technical writing program at UMass. It was a big career change. I was starting way over. It took a few years to land a job, but I eventually nabbed an entry-level position at a medium-sized software company and have been employed ever since.
Writing is not a big part of technical writing. It’s maybe 20% of the job (less or more, depending on where you work). It’s more about organization and research and learning what you are writing about. The product I work on is very technical and is constantly changing and improving, so the opportunity to learn about it never flags.
Questions to ask yourself:
Am I logical?
You don’t have to be an engineer to be a technical writer. In fact, being an engineer is a detriment to technical writing. (That’s not to say every software engineer shouldn’t take a technical writing class—she should, so she can better understand how to communicate all that tasty knowledge about the tools she writes code for.) But you will need to be logical in terms of knowing how a subject should be organized, how to approach writing about a subject (start to finish or easiest to hardest), and what information should and should not be included. I am not logical like an engineer is logical—I can’t always get to point F without forgetting or questioning how I managed just to get to point D. But luckily, I don’t have to be an engineer to write.
Am I organized?
You need to be organized. You need to be good with details and time management. But, aren’t most writers pretty good at this already? It helps to skew a little toward the compulsive side here. On the job, you need to pick up details about consistency. This takes practice, and you probably have skills you don’t even know you have. That’s what happened to me. I had no idea I had capacity to notice details, to be organized, and to learn fairly quickly. It took a technical writing program to make me recognize skills I had but was barely using.
Another part of being organized is file management (on your PC or laptop). Go to your C drive. Is it a mess? Are there files and folders in there that you have never seen? Do you have multiple Documents folders? Are you constantly confused about where you saved things? That was me when I first started tech writing. Man, it was rough. For some reason, this type of logic escaped me. But I was forced to learn quickly where and how to save files. There are myriad formats in the software industry, and you will deal with many of them. Don’t be frightened, you’ll learn as you go.
Am I technical?
I’m not technical. But I can learn. And, of course the longer you’re a tech writer, the more generally technical you’ll get. But you’re not expected to be a master at the technology you’re writing about. In fact, often you shouldn’t be. Usually you need to come to a subject as a novice. That way you approach a subject like most of the users you are writing for: fresh and with a lot of questions. But, you have the advantage of working with the people who can answer your questions. Every time you question how or why something works the way it does, you are learning about the product; incorporate this new information and the documentation will be better for it.
That said, some tech writing jobs insist you be technical. A company like Framingham-based Mathworks wants its writers more on the egghead side, with a mathematics background. Some companies that work in the medical field want writers that have medical writing experience. Generally, when you go in for your first tech writing position, you can spin your lack of technical experience with whatever product or technology they deal with into a plus; you need to learn about it so you can better write about it.
One more thing: There are multiple computer platforms. You are used to Windows or Macintosh. But, you might have to work with UNIX systems. UNIX, and all its many flavors (Linux, HP-UX, Solaris, etc.), is an entirely different kind of computer system. One where you type commands into a basic text editor to access files and run programs. It’s not much fun. It’s really basic but powerful, and programmers and developers love to work on UNIX. So, you will eventually run across UNIX systems. Don’t be afraid, just let it happen. Learn a few basic commands, and everything should be fine. Oh, and you’ll never touch a Mac on the job. Unless you work at a fancy start-up where everybody is 25 and they have unlimited cash resources. …oh wait, it’s no longer 1998.
What tools will I use on the job?
You need to know your way around some word processing programs. Master Microsoft Word for a start. Still, when you’re on the job, you’ll need to learn industry-standard programs, like:
• FrameMaker. A powerful word processing program designed for writing books with chapters and an index and glossary, like user’s guides and installation guides.
• Robohelp, AuthorIT, or MadCap Flare. Online help authoring tools. Also, these tools are used more and more as a single-source environment, where you write and store pieces of content that can then be reused in multiple places. Whenever you update the content at its source, the changes are propagated wherever it is used.
• PaintShop Pro or Snagit. Most of the companies I’ve worked for have had basic graphics programs. These are simple programs that allow you to take a screenshot of the user interface (like when you hit print screen on your keyboard and save a copy of what you see on your monitor) and do some minor edits to it, then drop it into your document. I also have Microsoft Visio, which allows me to create simple or complicated flowcharts or logic trees. Also, PowerPoint can be good to create some simple flowcharts as well.
The Technical Writing Life
Technical writing is not a bad gig. You deal with deadlines, egos, myopic and sometimes uncommunicative (but often very nice and willing to share) engineers, and the pressure of getting the software documentation out the door on time. And in a down economy sometimes I feel like the tech writer will be the first to get axed if layoffs hit. But, since first finding steady work as a technical writer in 2005, I haven’t got laid off. I don’t work crazy hours, and only need to put in more than 40 hour weeks during real crunch times before a release. The high tech industry is still in decent shape (depending on where you live, of course); there are still some tech writing jobs out there.
I get up an hour early most work days to write my own stuff. I also take advantage of weekends to write. Having a job where I write is, in the end, a benefit to a fiction writer. It's like having both sides of your brain available for writing, which side you use depends on whether you're writing a user's guide or a novel.
Technical Review
After a technical document has been written—or changed significantly from an earlier version—it needs to be reviewed for technical accuracy by a subject matter expert. A tech writer needs to learn all she can about the feature she is writing about (be it the integration of disaster recovery software or a new part of the user interface), but to ensure accuracy, she must often rely on the people who designed, engineered, and tested the feature. So, before a tech writer can say a guide or help topic is done, it needs to be reviewed from a technical perspective. More than once, if there's time.
If you are writing a novel that has many medical or scientific facts and concepts, and this is not an area of expertise for you, then you probably want somebody who knows more than you do to read your manuscript. Even if you interviewed a subject matter export and maybe even visited her at work to see what it’s like to be an emergency room doctor, getting the expert to do a technical review of your book is necessary to ensure you get the details right. Get more than one expert to read it if you can. That way you get different points of view, different feedback, and different ideas.
Peer Edits
Peer editing is a term we use in the tech writing biz. When you finish a draft of a guide, you want another writer to check it for consistency, logic, structure, and corporate standards, and to give a good proof reading. Getting a peer edit on your documentation is not just a good idea but is necessary to ensure you’re not distributing sloppy, confusing material. Sometimes you don’t have the time to get another tech writer to review a guide, and you just have to be your own peer editor.
There’s no time to let a draft of a user’s guide breathe. You can't let it sit in a drawer for a few months to come back to with fresh eyes. You finish the guide as much as you can and move on to the next. But technical documentation is a living document. Meaning, you’ll get another chance to make it better when you update it for the next release. How many times do you get to rewrite a story or novel after it’s published? Following pre-determined corporate writing standards and conventions help get it right the first time.
I enjoy reading other writers’ work and try to give an honest, helpful appraisal of the writing. Peer editing has helped me when it comes to editing my narrative fiction, training me to focus on problem areas and to be more objective.
Technical writing in fiction and non-fiction
As I mentioned, you might include information in your novel or story that must be technically accurate. This includes doctor, police, and lawyer stuff. If you include this stuff, make sure you’re a doctor, policeman, or a lawyer. Or you’ve interviewed one or had one review your story for accuracy. Or you've lived with one or are married to one (this is research—take advantage of it). Because if you haven’t done any research, your lack of knowledge will be noticeable on some level, especially to people in the field you’re writing about.
If you’re not writing fiction but another type of book, say a how-to like a cook book or craft book, then you are getting much closer to writing a technical document. You should be using more technical writing elements. These basic elements include:
- Numbered and bulleted lists
- Tables
- Hierarchical headings
- Cross references
- Chunked information
- White Space
- Indexes, glossaries, and tables of contents
These are all important and all help a user find information. My favorite is the list.
Don’t be afraid of the list. The mighty list is your friend. Read through your book. Every time you give the reader a task to perform, put it in a list. This list must start with 1. 1 Open the book. 2 Read every chapter. 3 Break nested tasks and sentences of items into lists. A task shouldn’t be too many steps. If it’s longer than 10 steps, break the task into two or three smaller tasks. Another type of list has bullet points rather than numbers. A bulleted list is a good way to organize stuff. It’s easy to read and helps to break up the monotony of a paragraph of text.
Here’s a rewrite of the last paragraph, using tech writing elements:
How to Use Lists
Don’t be afraid of the list. The list is your friend.
Guidelines:
- Read through your book. Every time you give the reader a task to perform, put it in a list.
- This list must start with 1.
1. Open the book.
2. Read every chapter.
3. Break nested tasks and sentences of items into lists.
Tasks
A task shouldn’t be too many steps. If it’s longer than 10 steps, break the task into two or three smaller tasks.
Bullet points
Another type of list has bullet points rather than numbers. A bulleted list:
• Is a good way to organize stuff
• Is easy to read
• Helps to break up the monotony of a paragraph of text
The idea is to break the information into chunks to facilitate easier reading and to help the reader find the information she needs quickly. Using the above rewrite as an example, say the reader is interested in learning about bullet points, and not tasks and numbered steps. Then, she can skip to the sub-heading Bullet points after finding the main section of How to Use Lists.
Is Technical Writing For You (or, do fiction writers make good technical writers)?
The early 00s was not a good time to be undereducated. Jobs were scarce, even in the Massachusetts high tech industry. I had a film making background, and had spent all of the 1990s working in the wedding video and video duplication business, while also writing short stories and novels. By the end of the 90s, video work was drying up and writing fiction wasn't paying the bills.
I kept reading the classifieds in the Boston Globe and seeing jobs for technical writers. I had no idea what this was, but if being a writer was part of the job description, then I was half-way there. I looked into a few programs in the area, and in 2002 I completed a technical writing program at UMass. It was a big career change. I was starting way over. It took a few years to land a job, but I eventually nabbed an entry-level position at a medium-sized software company and have been employed ever since.
Writing is not a big part of technical writing. It’s maybe 20% of the job (less or more, depending on where you work). It’s more about organization and research and learning what you are writing about. The product I work on is very technical and is constantly changing and improving, so the opportunity to learn about it never flags.
Questions to ask yourself:
Am I logical?
You don’t have to be an engineer to be a technical writer. In fact, being an engineer is a detriment to technical writing. (That’s not to say every software engineer shouldn’t take a technical writing class—she should, so she can better understand how to communicate all that tasty knowledge about the tools she writes code for.) But you will need to be logical in terms of knowing how a subject should be organized, how to approach writing about a subject (start to finish or easiest to hardest), and what information should and should not be included. I am not logical like an engineer is logical—I can’t always get to point F without forgetting or questioning how I managed just to get to point D. But luckily, I don’t have to be an engineer to write.
Am I organized?
You need to be organized. You need to be good with details and time management. But, aren’t most writers pretty good at this already? It helps to skew a little toward the compulsive side here. On the job, you need to pick up details about consistency. This takes practice, and you probably have skills you don’t even know you have. That’s what happened to me. I had no idea I had capacity to notice details, to be organized, and to learn fairly quickly. It took a technical writing program to make me recognize skills I had but was barely using.
Another part of being organized is file management (on your PC or laptop). Go to your C drive. Is it a mess? Are there files and folders in there that you have never seen? Do you have multiple Documents folders? Are you constantly confused about where you saved things? That was me when I first started tech writing. Man, it was rough. For some reason, this type of logic escaped me. But I was forced to learn quickly where and how to save files. There are myriad formats in the software industry, and you will deal with many of them. Don’t be frightened, you’ll learn as you go.
Am I technical?
I’m not technical. But I can learn. And, of course the longer you’re a tech writer, the more generally technical you’ll get. But you’re not expected to be a master at the technology you’re writing about. In fact, often you shouldn’t be. Usually you need to come to a subject as a novice. That way you approach a subject like most of the users you are writing for: fresh and with a lot of questions. But, you have the advantage of working with the people who can answer your questions. Every time you question how or why something works the way it does, you are learning about the product; incorporate this new information and the documentation will be better for it.
That said, some tech writing jobs insist you be technical. A company like Framingham-based Mathworks wants its writers more on the egghead side, with a mathematics background. Some companies that work in the medical field want writers that have medical writing experience. Generally, when you go in for your first tech writing position, you can spin your lack of technical experience with whatever product or technology they deal with into a plus; you need to learn about it so you can better write about it.
One more thing: There are multiple computer platforms. You are used to Windows or Macintosh. But, you might have to work with UNIX systems. UNIX, and all its many flavors (Linux, HP-UX, Solaris, etc.), is an entirely different kind of computer system. One where you type commands into a basic text editor to access files and run programs. It’s not much fun. It’s really basic but powerful, and programmers and developers love to work on UNIX. So, you will eventually run across UNIX systems. Don’t be afraid, just let it happen. Learn a few basic commands, and everything should be fine. Oh, and you’ll never touch a Mac on the job. Unless you work at a fancy start-up where everybody is 25 and they have unlimited cash resources. …oh wait, it’s no longer 1998.
What tools will I use on the job?
You need to know your way around some word processing programs. Master Microsoft Word for a start. Still, when you’re on the job, you’ll need to learn industry-standard programs, like:
• FrameMaker. A powerful word processing program designed for writing books with chapters and an index and glossary, like user’s guides and installation guides.
• Robohelp, AuthorIT, or MadCap Flare. Online help authoring tools. Also, these tools are used more and more as a single-source environment, where you write and store pieces of content that can then be reused in multiple places. Whenever you update the content at its source, the changes are propagated wherever it is used.
• PaintShop Pro or Snagit. Most of the companies I’ve worked for have had basic graphics programs. These are simple programs that allow you to take a screenshot of the user interface (like when you hit print screen on your keyboard and save a copy of what you see on your monitor) and do some minor edits to it, then drop it into your document. I also have Microsoft Visio, which allows me to create simple or complicated flowcharts or logic trees. Also, PowerPoint can be good to create some simple flowcharts as well.
The Technical Writing Life
Technical writing is not a bad gig. You deal with deadlines, egos, myopic and sometimes uncommunicative (but often very nice and willing to share) engineers, and the pressure of getting the software documentation out the door on time. And in a down economy sometimes I feel like the tech writer will be the first to get axed if layoffs hit. But, since first finding steady work as a technical writer in 2005, I haven’t got laid off. I don’t work crazy hours, and only need to put in more than 40 hour weeks during real crunch times before a release. The high tech industry is still in decent shape (depending on where you live, of course); there are still some tech writing jobs out there.
I get up an hour early most work days to write my own stuff. I also take advantage of weekends to write. Having a job where I write is, in the end, a benefit to a fiction writer. It's like having both sides of your brain available for writing, which side you use depends on whether you're writing a user's guide or a novel.
Tuesday, October 13, 2009
Technical Writing Vs. Narrative Fiction, Part 3
Editing
At most companies today, a technical writer also acts as a technical editor. Back in the day (the mid-80s, which I hear about a lot in the software industry) technical writers were only expected to write. Technical writing departments often had their own editors and illustrators or graphic designers.
That is almost never the case anymore. Desktop publishing has given writers all the tools they need to produce a document. Graphics programs (for example, Adobe Photoshop or InDesign) are so prevalent that a tech writer is expected to be her own graphic designer. And most technical editors are probably now technical writers or educators.
For example, in my last job there were about 200 technical writers for a company of approximately 16,000 employees. There were about 4 or 5 technical editors who were also educators and trainers. They didn’t have much time to edit. When I left the company these technical editors had been absorbed into the technical writing organization proper, and no longer did any editing.
Editing is arguably the most important part of any writing project, fiction or non. I’ve broken editing down into four sub-categories:
• Structure
• Pacing
• Consistency
• Standards
Structure
Narrative fiction and technical writing both need a consistent, meaningful structure. Structure is borne of logic.
In tech writing you need to know your structure before you start writing. Structure is dependant on your main intended audience (the user), the “story” you are telling (how users accomplish a task), and the level and order of the information needed to tell a complete story. Often, after you’ve planned and researched a subject, you use an outline and/or table of contents to figure out the structure. Remember I talked about two ways to tell the story of a user’s guide: From easiest to most difficult or from start to finish. This story helps dictates your structure. It can change as you go (the configuration chapter should go after the installation chapter—who knew?), but your research and planning takes care of most structure questions beforehand.
Narrative fiction is a different animal. You might be saying (if you haven’t attempted a novel), well damn Unreliable Narrator; the structure of a novel is however you write your story. Structure? Follow your muse.
Following your muse alone might work for a couple of months or years. You finish a couple drafts, fix your typos, dot your i’s, cross those t’s, and then you send it out to a bunch of agents and forget about it for a while. Why? because you are done! Congratulations. In the following months you receive (if you’re lucky) a slew of rejections. Form letters or emails saying Not right for us or Not accepting new clients at this time. Fancy letterheads lose their impact when nobody signs the letter. Maybe you get one or two handwritten notes (but probably not) saying thanks but no thanks. What the hell went wrong? With all those novels getting published every week, where’s the love for your opus?
Chances are you’ve got some problems with your novel’s structure. Structure problems can be tough to spot. You need other eyes reading your manuscript. It doesn’t matter how closely you adhere to an outline or an overarching vision—your novel must strike a delicate balance, reflected in its structure. A novel’s structure can mean things like how to present multiple characters. Or when to reveal important information. Or weaving in a character’s back story or other important events that happened ten years earlier, but somehow affect all the characters now.
For example, say you decide to tell your story from the points of view of four characters, and you give each chapter over to a character’s third person view. The problem is, not all these characters are main characters. Two of them are main characters, and the other two, not so much. So, you can’t give the minor characters equal time, you have to strike that perfect balance, giving the main characters more air time or else the reader will wonder who the story is about, who they should root for and empathize with. But, you already wrote the book, and sent it out, before one of your readers pointed this out to you.
Structure problems for both tech writing and for narrative fiction can be fixed. For tech writing it’s usually a matter of cut and paste. Or adding and subtracting. Sometimes it works the same way for narrative fiction. But novels are much more delicate. Pasting a paragraph from chapter 2 into chapter 10 will probably have repercussions, ripple effects. But don’t be afraid to tear up your structure and rebuild it. It might take some time, another draft or two, but if it makes a better novel, you have to consider invasive surgery.
Pacing
This is closely related to structure, especially for narrative fiction. In tech writing the structure, story, and the main audience of the document dictates the pacing. You don’t want a user/reader to fall asleep reading your guide/online help, but you also have to give all pertinent information. Pacing for tech writing involves being concise and striking the right balance of information.
Writing concisely is tech writing 101. Don’t use ten words if you can use four. On the other hand, don’t leave out conjunctions just to save space. Just the facts. But not too many. Again, much of this is dictated by your audience. Are they new users that need more context and overview information? Then you’ll have to include an overview chapter with concept material. That’s tough reading, a slog if you will, so you want to write clean and tell your story with just the right words. Also, your company or your documentation group will have standards in place to follow. You don’t have to reinvent the user guide every time you write one. Good pacing in a tech document strikes a balance between giving the user the information she needs and keeping her from slamming the book closed in disgust because you gave her either information overload or not enough information.
Pacing in narrative fiction is closely related to structure. Let’s go back to my example: four characters spread throughout all your chapters. You don’t want to give one of the more minor characters the same number of chapters as the main character because this throws off the pacing. The reader might slog through minor-character chapters just to get back to a main character chapter. Give the main characters three chapters (for example) to every minor characters’ one chapter.
Pacing also comes into play at the beginnings and endings of novels. Where does your story begin? On page 1, hopefully. Maybe. Sometimes not. Sometimes your story doesn’t start until page 40, when your main character first steps into the crack house. So what about the first 39 pages? Read them again. You were finding your character, and anything important can be woven into the story after page 40; which is now your new page 1.
So your hero kicks drugs, joins the local police force, and eventually goes back to that crack house with his squad to bust the nefarious drug dealer. Ah man, great scene, full of action and pathos and irony and it’s obvious you’ve done your research. And the story is about to end, right? Wrong. You drag it out for another 75 pages. And the reader is stuck wondering what they’re reading. Did you introduce a love interest on page 350? Is she a new main character? How about the cop’s best buddy, a retired cop who’s now hanging around the station giving sage advice. Don’t end your book too many times. Know when to get out. Give the reader what you’ve set up in the first 90 thousand pages, and don’t give them another 15 to gnaw on. As with tech writing, you don’t want to give your reader unnecessary information that clouds the story.
Consistency
In your novel, if a main character drives a Prius on page 3, he better drive a Prius on page 303, unless he sold it and bought a Humvee. If your main character is the type of guy who seethes with anger because he hates his job, then by the end of the novel he better have:
• Quit the job to follow his bliss
• Shot his co-workers because they were making his life a living hell
• Met and married a woman who showed him how great love and life is, making his day-today job more bearable
• Get very close to one or all of the above, but in the end doesn’t change
If you don’t follow through with all the emotions and situations you introduce, then you’ve got a consistency problem. If you think no reader noticed that offhand reference to bestiality in chapter two (you thought it would give your antagonist shading), you’re dead wrong. Readers notice the smallest details, even if they don’t know they’ve read them. After they finish the book and say, “Hey, not a bad little literary novel,” three or four weeks later they’ll start remembering odd bits and pieces that don't fit, including how you never followed through on that bestiality thing. It can be even more amorphous than that: they know something is wrong with the story but can’t explain what. Readers know a bad piece of writing, even if they can’t tell you why.
The same goes for technical writing, except in a more crucial way. Everything about a technical document must be consistent. Everything from the terminology you use to the minutia of spelling and structure. You must present a feature or concept the same all the way through. And not just in one document, but throughout a company’s literature. From online help, to a user guide, main corporate website, and marketing material. This can be a huge, odious, and time consuming job. And terminology is constantly changing as products continue to be modified and integrated. Consistency is really the heart of technical writing.
One of the most important jobs of a technical writer is to set the user at ease. Introduce the conventions of the guide in the preface, introduction, or first chapter, so that as the reader moves through the document, she knows what to expect. Unlike narrative fiction where a writer can turn all lyrical and subjective, or screw around with time or point of view, a technical document must lead the user through the logical progression of tasks with tact, clarity, and consistency.
If you use the term failover a certain way in chapter one, you must use it the same way throughout not just this guide, but in the online help, and in the marketing material. And you better describe failover the way it actually acts in the product: Your documentation must mimic what the user sees when she uses the product. Consistency is in the details. Cross references to other material (“See page 12 for more information.”) better be accurate, or users will get frustrated and stop turning to page 12 for more information.
Consistency must be maintained at all levels, even those a user may not even notice. But, like with a novel, they will be able to tell that something is not right. Even if they can’t put their finger on it. If you start the first procedure with an introductory sentence, then start all procedures with an introductory sentence. If you don’t, the user will wonder where the damn introductory sentence is, and say, “Maybe this procedure is in some way different from that other procedure; maybe it’s not as important. That’s it! I don’t have to follow this procedure because there is no introductory sentence.”
When you first tell a user to click Tools > Insert > Table, you are introducing a couple of conventions. What are they? Can you spot them? Bold. Whenever a user needs to click a button or other item on a user interface (like the one in which you are reading this blog) then it should be presented in bold text. What else? The > between items to click. This means the user is to click these items as a series of steps to insert a table. I used as few words as possible and I have the user trained for the rest of the user’s guide.
If you screw this up, the user will lose confidence in the guide. Will be more likely to contact technical support rather than touch another technical document from your company. Ever. Ever again. You’ve lost them. Forever. Introduce conventions and standards and use them consistently.
Noticing consistency in my technical documentation has helped me appreciate and discover it in my narrative fiction. Most of the editing techniques I’ve picked up on the job have come in handy when planning, executing, and editing my novels, stories, and outlines.
Standards
Predefined standards give a technical document much of its consistency. By standards I mean a set of rules you follow to give a company’s technical documentation a similar look and feel. It includes things like font type, how to format a numbered list, and putting a preface and index in every document.
Fiction writers define their own standards. They might pick them up from an aesthetic they learned in school. Or from certain writers that they read and emulate. Standards in narrative fiction have less to do with typeface and kerning than with how to use the rules of grammar, and breaking them or incorporating them when the story calls for it. Do you place a character tag before or after a line of dialog? Do you place description in the same paragraph as a line of dialogue or in a separate paragraph?
For my novel, "A Little Disappeared," I set a standard over the first two chapters for the reader to follow. The first chapter introduces my main character, Keith. Keith is 38 and his wife has left him. He has embarked on a cross country trek to find her. This storyline takes place in a contemporary setting and is told from the first person. Chapter 2 introduces the same character when he is 14 and is told in third person point of view. I follow this standard throughout the novel. If I’ve done my job correctly, the reader should be able to read the story and accept, or at least understand, this structure as a standard I’ve introduced early on. (Hopefully they’ll accept it, because it’s harder and much more expensive to get in touch with narrative fiction support than technical support.)
Whether you’re a tech writer or a novelist, you train your readers (usually in the first chapter) how to read your writing, creating a trust. If you break this trust with inconsistencies, then readers will be wary on some level of the story you are telling them.
These are just a few examples of where technical and fiction editing crossover. I tried to cover the most important ones. If you can think of others, let me know.
Tune in next time for the 4th and final post in this series when I’ll discuss:
- Technical reviews
- Peer editing
- Technical writing in fiction and non-fiction
- Is Technical Writing For You (or, do fiction writers make good technical writers)?
At most companies today, a technical writer also acts as a technical editor. Back in the day (the mid-80s, which I hear about a lot in the software industry) technical writers were only expected to write. Technical writing departments often had their own editors and illustrators or graphic designers.
That is almost never the case anymore. Desktop publishing has given writers all the tools they need to produce a document. Graphics programs (for example, Adobe Photoshop or InDesign) are so prevalent that a tech writer is expected to be her own graphic designer. And most technical editors are probably now technical writers or educators.
For example, in my last job there were about 200 technical writers for a company of approximately 16,000 employees. There were about 4 or 5 technical editors who were also educators and trainers. They didn’t have much time to edit. When I left the company these technical editors had been absorbed into the technical writing organization proper, and no longer did any editing.
Editing is arguably the most important part of any writing project, fiction or non. I’ve broken editing down into four sub-categories:
• Structure
• Pacing
• Consistency
• Standards
Structure
Narrative fiction and technical writing both need a consistent, meaningful structure. Structure is borne of logic.
In tech writing you need to know your structure before you start writing. Structure is dependant on your main intended audience (the user), the “story” you are telling (how users accomplish a task), and the level and order of the information needed to tell a complete story. Often, after you’ve planned and researched a subject, you use an outline and/or table of contents to figure out the structure. Remember I talked about two ways to tell the story of a user’s guide: From easiest to most difficult or from start to finish. This story helps dictates your structure. It can change as you go (the configuration chapter should go after the installation chapter—who knew?), but your research and planning takes care of most structure questions beforehand.
Narrative fiction is a different animal. You might be saying (if you haven’t attempted a novel), well damn Unreliable Narrator; the structure of a novel is however you write your story. Structure? Follow your muse.
Following your muse alone might work for a couple of months or years. You finish a couple drafts, fix your typos, dot your i’s, cross those t’s, and then you send it out to a bunch of agents and forget about it for a while. Why? because you are done! Congratulations. In the following months you receive (if you’re lucky) a slew of rejections. Form letters or emails saying Not right for us or Not accepting new clients at this time. Fancy letterheads lose their impact when nobody signs the letter. Maybe you get one or two handwritten notes (but probably not) saying thanks but no thanks. What the hell went wrong? With all those novels getting published every week, where’s the love for your opus?
Chances are you’ve got some problems with your novel’s structure. Structure problems can be tough to spot. You need other eyes reading your manuscript. It doesn’t matter how closely you adhere to an outline or an overarching vision—your novel must strike a delicate balance, reflected in its structure. A novel’s structure can mean things like how to present multiple characters. Or when to reveal important information. Or weaving in a character’s back story or other important events that happened ten years earlier, but somehow affect all the characters now.
For example, say you decide to tell your story from the points of view of four characters, and you give each chapter over to a character’s third person view. The problem is, not all these characters are main characters. Two of them are main characters, and the other two, not so much. So, you can’t give the minor characters equal time, you have to strike that perfect balance, giving the main characters more air time or else the reader will wonder who the story is about, who they should root for and empathize with. But, you already wrote the book, and sent it out, before one of your readers pointed this out to you.
Structure problems for both tech writing and for narrative fiction can be fixed. For tech writing it’s usually a matter of cut and paste. Or adding and subtracting. Sometimes it works the same way for narrative fiction. But novels are much more delicate. Pasting a paragraph from chapter 2 into chapter 10 will probably have repercussions, ripple effects. But don’t be afraid to tear up your structure and rebuild it. It might take some time, another draft or two, but if it makes a better novel, you have to consider invasive surgery.
Pacing
This is closely related to structure, especially for narrative fiction. In tech writing the structure, story, and the main audience of the document dictates the pacing. You don’t want a user/reader to fall asleep reading your guide/online help, but you also have to give all pertinent information. Pacing for tech writing involves being concise and striking the right balance of information.
Writing concisely is tech writing 101. Don’t use ten words if you can use four. On the other hand, don’t leave out conjunctions just to save space. Just the facts. But not too many. Again, much of this is dictated by your audience. Are they new users that need more context and overview information? Then you’ll have to include an overview chapter with concept material. That’s tough reading, a slog if you will, so you want to write clean and tell your story with just the right words. Also, your company or your documentation group will have standards in place to follow. You don’t have to reinvent the user guide every time you write one. Good pacing in a tech document strikes a balance between giving the user the information she needs and keeping her from slamming the book closed in disgust because you gave her either information overload or not enough information.
Pacing in narrative fiction is closely related to structure. Let’s go back to my example: four characters spread throughout all your chapters. You don’t want to give one of the more minor characters the same number of chapters as the main character because this throws off the pacing. The reader might slog through minor-character chapters just to get back to a main character chapter. Give the main characters three chapters (for example) to every minor characters’ one chapter.
Pacing also comes into play at the beginnings and endings of novels. Where does your story begin? On page 1, hopefully. Maybe. Sometimes not. Sometimes your story doesn’t start until page 40, when your main character first steps into the crack house. So what about the first 39 pages? Read them again. You were finding your character, and anything important can be woven into the story after page 40; which is now your new page 1.
So your hero kicks drugs, joins the local police force, and eventually goes back to that crack house with his squad to bust the nefarious drug dealer. Ah man, great scene, full of action and pathos and irony and it’s obvious you’ve done your research. And the story is about to end, right? Wrong. You drag it out for another 75 pages. And the reader is stuck wondering what they’re reading. Did you introduce a love interest on page 350? Is she a new main character? How about the cop’s best buddy, a retired cop who’s now hanging around the station giving sage advice. Don’t end your book too many times. Know when to get out. Give the reader what you’ve set up in the first 90 thousand pages, and don’t give them another 15 to gnaw on. As with tech writing, you don’t want to give your reader unnecessary information that clouds the story.
Consistency
In your novel, if a main character drives a Prius on page 3, he better drive a Prius on page 303, unless he sold it and bought a Humvee. If your main character is the type of guy who seethes with anger because he hates his job, then by the end of the novel he better have:
• Quit the job to follow his bliss
• Shot his co-workers because they were making his life a living hell
• Met and married a woman who showed him how great love and life is, making his day-today job more bearable
• Get very close to one or all of the above, but in the end doesn’t change
If you don’t follow through with all the emotions and situations you introduce, then you’ve got a consistency problem. If you think no reader noticed that offhand reference to bestiality in chapter two (you thought it would give your antagonist shading), you’re dead wrong. Readers notice the smallest details, even if they don’t know they’ve read them. After they finish the book and say, “Hey, not a bad little literary novel,” three or four weeks later they’ll start remembering odd bits and pieces that don't fit, including how you never followed through on that bestiality thing. It can be even more amorphous than that: they know something is wrong with the story but can’t explain what. Readers know a bad piece of writing, even if they can’t tell you why.
The same goes for technical writing, except in a more crucial way. Everything about a technical document must be consistent. Everything from the terminology you use to the minutia of spelling and structure. You must present a feature or concept the same all the way through. And not just in one document, but throughout a company’s literature. From online help, to a user guide, main corporate website, and marketing material. This can be a huge, odious, and time consuming job. And terminology is constantly changing as products continue to be modified and integrated. Consistency is really the heart of technical writing.
One of the most important jobs of a technical writer is to set the user at ease. Introduce the conventions of the guide in the preface, introduction, or first chapter, so that as the reader moves through the document, she knows what to expect. Unlike narrative fiction where a writer can turn all lyrical and subjective, or screw around with time or point of view, a technical document must lead the user through the logical progression of tasks with tact, clarity, and consistency.
If you use the term failover a certain way in chapter one, you must use it the same way throughout not just this guide, but in the online help, and in the marketing material. And you better describe failover the way it actually acts in the product: Your documentation must mimic what the user sees when she uses the product. Consistency is in the details. Cross references to other material (“See page 12 for more information.”) better be accurate, or users will get frustrated and stop turning to page 12 for more information.
Consistency must be maintained at all levels, even those a user may not even notice. But, like with a novel, they will be able to tell that something is not right. Even if they can’t put their finger on it. If you start the first procedure with an introductory sentence, then start all procedures with an introductory sentence. If you don’t, the user will wonder where the damn introductory sentence is, and say, “Maybe this procedure is in some way different from that other procedure; maybe it’s not as important. That’s it! I don’t have to follow this procedure because there is no introductory sentence.”
When you first tell a user to click Tools > Insert > Table, you are introducing a couple of conventions. What are they? Can you spot them? Bold. Whenever a user needs to click a button or other item on a user interface (like the one in which you are reading this blog) then it should be presented in bold text. What else? The > between items to click. This means the user is to click these items as a series of steps to insert a table. I used as few words as possible and I have the user trained for the rest of the user’s guide.
If you screw this up, the user will lose confidence in the guide. Will be more likely to contact technical support rather than touch another technical document from your company. Ever. Ever again. You’ve lost them. Forever. Introduce conventions and standards and use them consistently.
Noticing consistency in my technical documentation has helped me appreciate and discover it in my narrative fiction. Most of the editing techniques I’ve picked up on the job have come in handy when planning, executing, and editing my novels, stories, and outlines.
Standards
Predefined standards give a technical document much of its consistency. By standards I mean a set of rules you follow to give a company’s technical documentation a similar look and feel. It includes things like font type, how to format a numbered list, and putting a preface and index in every document.
Fiction writers define their own standards. They might pick them up from an aesthetic they learned in school. Or from certain writers that they read and emulate. Standards in narrative fiction have less to do with typeface and kerning than with how to use the rules of grammar, and breaking them or incorporating them when the story calls for it. Do you place a character tag before or after a line of dialog? Do you place description in the same paragraph as a line of dialogue or in a separate paragraph?
For my novel, "A Little Disappeared," I set a standard over the first two chapters for the reader to follow. The first chapter introduces my main character, Keith. Keith is 38 and his wife has left him. He has embarked on a cross country trek to find her. This storyline takes place in a contemporary setting and is told from the first person. Chapter 2 introduces the same character when he is 14 and is told in third person point of view. I follow this standard throughout the novel. If I’ve done my job correctly, the reader should be able to read the story and accept, or at least understand, this structure as a standard I’ve introduced early on. (Hopefully they’ll accept it, because it’s harder and much more expensive to get in touch with narrative fiction support than technical support.)
Whether you’re a tech writer or a novelist, you train your readers (usually in the first chapter) how to read your writing, creating a trust. If you break this trust with inconsistencies, then readers will be wary on some level of the story you are telling them.
These are just a few examples of where technical and fiction editing crossover. I tried to cover the most important ones. If you can think of others, let me know.
Tune in next time for the 4th and final post in this series when I’ll discuss:
- Technical reviews
- Peer editing
- Technical writing in fiction and non-fiction
- Is Technical Writing For You (or, do fiction writers make good technical writers)?
Saturday, October 10, 2009
Technical Writing Vs. Narrative Fiction, Part 2
Telling a Story
Chapter 3 – Configuring Disaster Recovery for Zombies
Disaster recovery is a system configuration that helps ensure your network environment remains secure and online in the case of a physical catastrophe; for example:
• Earthquakes
• Hurricanes
• Zombies
How Disaster Recovery Works
When the primary system on which the software is installed goes offline (when zombies chew through the wires or set the building on fire), failover is initiated, and the secondary system is automatically brought online at another location (Alaska, where there are no zombies…yet!) and continues to function with a minimum of downtime.
This chapter describes the procedures necessary to configure disaster recovery in your infrastructure and fend for your life from flesh-eating zombies, including:
• Installing the software
• Killing zombies: guidelines and best practices
• Configuring disaster recovery
To install the software
1. Log on to the server system as the administrator.
2. Navigate to the closest exit.
3. Double-click……Zombies!
A software user's guide tells a story (sans zombies). A novel tells a story (about anything, including zombies). It could be argued (I double dare you) that any book, technical or otherwise, has to tell a story. What kind of story does a software user guide tell? Well, in the planning phase of my disaster recovery user guide (my example from Part 1 all the way through here) I have to determine who my audience is so I have a better understanding of what they need to know about disaster recovery. Is the user very technical? If not, I will need to include more introductory and concept material. Is the user a network administrator? If so, my user won’t need a lot of setup, she will just need the procedures to configure her software for disaster recovery.
Where’s the story in that? Well, look at the outline. Chapter 1: Introduction. Chapter 2: Install and Configure software. That’s for the new user. The experienced user does not need as much intro material, so that will not be part of the story. What is the motivation? Why tell this story? My audience, new or experienced, needs to install and configure the software correctly. I have to tell the story of this install and configuration.
During my planning phase, I’ll determine how I will tell the story. There are two ways I can go:
• Start with the easiest information and then, continuing through each chapter, get more and more detailed, more technical. This might be the way I write one user guide for both those audiences (new and experienced). The new user will get all she needs in the first few chapters and then can stop reading. The experienced user might skip the early chapters, and get to the nitty gritty of the story: the procedures she needs to configure the software for every disaster recovery scenario (there is more than one type of failover—but I digress).
• Tell a story from start to finish, logically, like documenting each point of a flowchart. Maybe every user needs all the information, so chapter 1 begins my story from where any user needs to start the process. Chapter 2 continues it, and so on, through to the last chapter. You can look at the table of contents of my user guide and consider each chapter as one process in a complete series of necessary processes (Chapter 1=Process 1, Chapter 2=Process 2), with each chapter/process broken into all the procedures needed to complete the process.
No one, and I mean absolutely no one, reads a technical document for fun. (Unless you’re a technical writer studying bad tech writing to figure out what not to do.) But many people, whether they’re an engineer (learning a new product or reviewing technical documentation because they’re the only person in the world who knows how a piece of the software puzzle works because they wrote the code) or a soccer mom (installing the latest version of iTunes) will at some point have to read a user guide or some online help topics. The more concisely you present and tell the story, the better experience any user will have with her product. Often a user clicks that Help button because she can’t do something. She needs information fast; she’s pissed off, and she’d rather not call tech support. This is when telling that story about the installation and configuration saves the day.
It should go without saying that narrative fiction also tells a story. I mean, that’s why it’s narrative; it tells a story, somehow, from start to finish. But how are these two types of storytelling similar? Okay, you’re in a book store and you pick up a copy of the new hardcover by that hot young author who looks good in heels and has a haircut you envy. You’ve heard good things, read decent to excellent reviews, and you need to find out for yourself. You read the first paragraph. It doesn’t grab you. You read two pages; you’re still not sold. One more page, and the hot young author has lost you. You put the book down, walk away, and buy a new book by a writer whose ten other books sit happily read on your bedroom bookshelf (yes, I have a bookshelf in my bedroom).
What the hell just happened? This reader clicked Help and tried to determine what the story was. And she either had no idea what the author was trying to say, or it wasn’t for her. She may or may not know why. I’ll argue that a reader of a user guide can get the same feeling—this book sucks, but why? In both cases, the story failed. For the fiction reader (reader A) the author failed at storytelling. But, we can assume that if it didn’t work for reader A, there’s a reader B and C for whom it didn’t work equally well. She is not alone.
Novels and user’s guides must tell a story clearly, concisely, and with a minimum of bullshit, or readers will give up out of frustration. Which brings us to the most important part of this comparison: Editing.
Tune in next time when I’ll discuss the following parts of editing:
• Structure
• Pacing
• Consistency
• Standards
Chapter 3 – Configuring Disaster Recovery for Zombies
Disaster recovery is a system configuration that helps ensure your network environment remains secure and online in the case of a physical catastrophe; for example:
• Earthquakes
• Hurricanes
• Zombies
How Disaster Recovery Works
When the primary system on which the software is installed goes offline (when zombies chew through the wires or set the building on fire), failover is initiated, and the secondary system is automatically brought online at another location (Alaska, where there are no zombies…yet!) and continues to function with a minimum of downtime.
This chapter describes the procedures necessary to configure disaster recovery in your infrastructure and fend for your life from flesh-eating zombies, including:
• Installing the software
• Killing zombies: guidelines and best practices
• Configuring disaster recovery
To install the software
1. Log on to the server system as the administrator.
2. Navigate to the closest exit.
3. Double-click……Zombies!
A software user's guide tells a story (sans zombies). A novel tells a story (about anything, including zombies). It could be argued (I double dare you) that any book, technical or otherwise, has to tell a story. What kind of story does a software user guide tell? Well, in the planning phase of my disaster recovery user guide (my example from Part 1 all the way through here) I have to determine who my audience is so I have a better understanding of what they need to know about disaster recovery. Is the user very technical? If not, I will need to include more introductory and concept material. Is the user a network administrator? If so, my user won’t need a lot of setup, she will just need the procedures to configure her software for disaster recovery.
Where’s the story in that? Well, look at the outline. Chapter 1: Introduction. Chapter 2: Install and Configure software. That’s for the new user. The experienced user does not need as much intro material, so that will not be part of the story. What is the motivation? Why tell this story? My audience, new or experienced, needs to install and configure the software correctly. I have to tell the story of this install and configuration.
During my planning phase, I’ll determine how I will tell the story. There are two ways I can go:
• Start with the easiest information and then, continuing through each chapter, get more and more detailed, more technical. This might be the way I write one user guide for both those audiences (new and experienced). The new user will get all she needs in the first few chapters and then can stop reading. The experienced user might skip the early chapters, and get to the nitty gritty of the story: the procedures she needs to configure the software for every disaster recovery scenario (there is more than one type of failover—but I digress).
• Tell a story from start to finish, logically, like documenting each point of a flowchart. Maybe every user needs all the information, so chapter 1 begins my story from where any user needs to start the process. Chapter 2 continues it, and so on, through to the last chapter. You can look at the table of contents of my user guide and consider each chapter as one process in a complete series of necessary processes (Chapter 1=Process 1, Chapter 2=Process 2), with each chapter/process broken into all the procedures needed to complete the process.
No one, and I mean absolutely no one, reads a technical document for fun. (Unless you’re a technical writer studying bad tech writing to figure out what not to do.) But many people, whether they’re an engineer (learning a new product or reviewing technical documentation because they’re the only person in the world who knows how a piece of the software puzzle works because they wrote the code) or a soccer mom (installing the latest version of iTunes) will at some point have to read a user guide or some online help topics. The more concisely you present and tell the story, the better experience any user will have with her product. Often a user clicks that Help button because she can’t do something. She needs information fast; she’s pissed off, and she’d rather not call tech support. This is when telling that story about the installation and configuration saves the day.
It should go without saying that narrative fiction also tells a story. I mean, that’s why it’s narrative; it tells a story, somehow, from start to finish. But how are these two types of storytelling similar? Okay, you’re in a book store and you pick up a copy of the new hardcover by that hot young author who looks good in heels and has a haircut you envy. You’ve heard good things, read decent to excellent reviews, and you need to find out for yourself. You read the first paragraph. It doesn’t grab you. You read two pages; you’re still not sold. One more page, and the hot young author has lost you. You put the book down, walk away, and buy a new book by a writer whose ten other books sit happily read on your bedroom bookshelf (yes, I have a bookshelf in my bedroom).
What the hell just happened? This reader clicked Help and tried to determine what the story was. And she either had no idea what the author was trying to say, or it wasn’t for her. She may or may not know why. I’ll argue that a reader of a user guide can get the same feeling—this book sucks, but why? In both cases, the story failed. For the fiction reader (reader A) the author failed at storytelling. But, we can assume that if it didn’t work for reader A, there’s a reader B and C for whom it didn’t work equally well. She is not alone.
Novels and user’s guides must tell a story clearly, concisely, and with a minimum of bullshit, or readers will give up out of frustration. Which brings us to the most important part of this comparison: Editing.
Tune in next time when I’ll discuss the following parts of editing:
• Structure
• Pacing
• Consistency
• Standards
Subscribe to:
Posts (Atom)