Home » Geoff Hart

Geoff Hart

During a sometimes checkered career, Geoff has worked for IBM, the Canadian
Forest Service, and the Forest Engineering Research Institute of Canada. In
2004, he threw away all that job security stuff for the carefree—not!—life
of the freelancer. Geoff works primarily as a scientific editor, but also does
technical writing and French translation, and occasionally falls into the trap
of leading or managing groups.


A Fellow of the Society for Technical Communication (STC, www.stc.org), he's
published more than 300 articles, most now available on his Web site (www.geoff-hart.com), as well as the book Effective Onscreen Editing. Geoff spends an altogether unreasonable amount of his time mentoring colleagues around the world. Contact him at ghart
(at) videotron (dot) ca or geoffhart(at) mac (dot) com.

design-volumeknob-sm

Ten Design Principles and When to Violate Them

Written by on

Dieter Rams, a German industrial designer from the functionalist school, followed a philosophy that will sound familiar when I paraphrase it: “form follows function” and “usability is fitness for purpose.” You know his work if you've used any Braun products released from the 1960s to the 1990s, or if you've used recent Apple products, many of which were inspired by his design principles. Let’s look at what technical communicators can learn from these principles—and when we should consider violating them. Continue reading ...

zombie-group-sm

Undead Americans and the Need for Improved Audience Analysis

Written by on

Undead Americans are a rapidly growing market segment, and are predictably attracting increasing attention from technology companies that have recognized the profit potential from this market segment. Before continuing, I should note that technical communicators must avoid using the dismissive abbreviation “UAs", not to mention the offensive epithet “zombies”, to describe these individuals. Such diminutives lead us to objectify these important members of our audience rather than treating them as individuals, leading to stereotyping rather than the effective creation of empirically derived, audience-focused personas. Continue reading ...

zombie success story

Onshoring: a Zombie Success Story – Part 2

Written by on

Not only did I not eat the donuts; I went across the street for my chai. No sense taking any chances, and I needed a change of scene to think things through. What I’d learned about zombies was only reassuring from the perspective that nobody would be trying to eat my brain at work, and we wouldn't be locking the doors and hiding out with shotguns and talwars to ward off the zombie apocalypse. Continue reading ...

c165943_sm

Onshoring: a Zombie Success Story – Part 1

Written by on

The whoosh of six simultaneously released bated breaths drowned out Cook's next words. We’d been expecting the worst, and had spent more time during the last month helping each other polish our résumés than actually documenting the software. Nobody had noticed, lending an uncomfortable amount of credibility to the rumors. Continue reading ...

writer-photo-1904-sm

Writer’s Block: Different Causes Have Different Solutions – Part 2

Written by on

Practicalities are obstacles you can solve by choosing an appropriate strategy and then gritting your teeth and doing the necessary work. Because they aren’t psychological barriers, they’re much easier to get past because all you need to do is force yourself to follow the appropriate steps, possibly with help from friends and colleagues. You don’t always need your muse to be able to write: some aspects of writing, such as developing a timeline or plot outline, are fairly mechanical. Since you’re the only one who will see them, they don’t have to be perfect. Continue reading ...

blank page typewriter-sm

Writer’s block: Different Causes Have Different Solutions – Part 1

Written by on

Writing should be exciting and pleasurable, and most of the time it is. But if you’re a dedicated professional who earns your living from writing, writing is also a job, and even the most exciting job sometimes grows boring or frustrating or stressful. When that happens, you may find yourself “blocked”: unable to write, and not sure why. That’s particularly true for technical communicators like me, who also enjoy writing fiction in those rare free moments between paying work. ( Continue reading ...

review meeting

Peer Review Strategies for Technical Writers

Written by on

Writers’ groups have existed for as long as there have been writers. Their goal, other than providing an excuse to gather with kindred spirits over coffee or beer, is to obtain expert critiques of your writing. By understanding the comments and learning to distinguish between valid and invalid criticisms, you learn to write better stories. I’ve participated in such groups, and members have ranged from supporters who actually cared about my aspirations as a writer to ruthless egotists who mostly wanted to prove how much better they were than me. Most technical writers have encountered this approach in the form of peer review, but peer review most often has a different focus: to replace a full-time editor rather than to teach writers to write better. Continue reading ...

Gestalt-1-reification

Technical Communications Primer: Gestalt Theory and Visual Design

Written by on

Understanding gestalt theory is important for anyone who wants to master information design, not to mention visual design disciplines such as instructional design and user-interface design. But this understanding is important even when all we want to do is create a simple graphic such as a bar chart or an annotated screenshot. Four main principles of gestalt-based design provide this understanding and the tools we need to use it in practice. Continue reading ...

checklist-laptop

Create Technical Writing Consistency While You Write—Or Add it Later

Written by on

One of the primary tasks any writer or editor must perform is to impose consistency on a manuscript. Consistency is particularly important for technical writers, because it makes the task of writing easier: if you don’t have to develop a new solution each time you face the same problem, you can simply find a solution that works for all occurrences of that problem and use it thereafter. From the technical writer’s perspective, it’s best if you try to build in that consistency right from the start, because it can save you a lot of time both in your initial draft and in your subsequent revisions. Continue reading ...