Wikis Archives - Iva Cheung

Plain language and the historical rain shadow

“I have a theory about the Internet,” said John Maxwell.

“Oh?” I took a sip of my coffee and sat back. “Go on…”

“See, everything before, say, 1970 is old enough to be interesting history, so people have posted that information online. And everything after 1995 is already on the Internet. But there’s this rain shadow of about two and half decades that there isn’t all that much information about. I think there’s a huge opportunity for people to fill in that history.”

John was referring to his research project about Coach House Books (see my summary of an Alcuin Society talk of his on the subject here), but his rain shadow applies just as well to the modern plain language movement, which got its legs in the 1970s, when First National City Bank (now Citibank) revamped its mortgage documents and governments began to recognize the need for plain language communications. The Wikipedia page about plain language offers some history, but most of it is U.S. focused, and it’s far from exhaustive.

Plain Language Association INternational (PLAIN) co-founder and tireless plain language advocate Cheryl Stephens asked me to put together a display table of the organization’s history to celebrate PLAIN’s twentieth anniversary at last October’s PLAIN 2013 conference. Drawing from three boxes of archives, including copies of PLAIN’s old newsletter, Rapport, I made a poster showing some of the major international plain language milestones of the past two decades.

Of course, there’s only so much I could fit on a poster. The archives are replete with important, fascinating historical tidbits that deserve to be documented somewhere. But where?

The need for a plain language repository

At PLAIN 2013, what became clear to me was that the plain language community could really use a repository for:

Clear communication research: Is active voice easier to understand than passive? Is it better to use serif or sans serif body type? I’d love to be able to visit one site to find the latest evidence supporting plain language and clear communication principles. Not only would this research inform my own work, but it would support my efforts to persuade prospective clients and decision makers about the merits of plain language. The Plain Language Advocates group on LinkedIn is fertile ground for sharing links and discussing new research, but the links to the original articles aren’t centrally archived in a useful way.
Case studies: Having a handy set of before-and-after examples, as well as documentation of a plain language campaign’s impacts (particularly on efficiency and the bottom line), would be enormously useful for explaining what we do and why.
Plain language history: Our past—seeing our gains, our losses—lights the way forward. Acknowledging the contributions of the pioneers who have dedicated countless hours to this cause is an important reminder of what we need to do to keep going.

A wiki for clear communication

I’ve sung the praises of wikis in the past: their ease of editing makes them democratic and participatory. So, I’ve set up the Clear Communication Wiki on Wikia, and I encourage everyone from the plain language community to contribute to it. Over the next several months (or, more likely, years) I plan to populate the history section with what I gleaned from my historical project for PLAIN 2013, including what I couldn’t fit onto the poster. Anyone else with relevant historical sources is welcome to fill in the details as well.

I didn’t mean to be unilateral about establishing this wiki—mostly I needed a neutral place to post the Plain Language: Clear and Simple guides I rebuilt, and I figured the wiki could serve many purposes. If there’s already an active international hub for plain language information, I’d be happy to migrate my data there.

I can see the archive of research links eventually creating the need for a full-fledged searchable database of the articles themselves, but for now, I think a wiki is a good first step.

***

Many of the modern plain language movement’s most vocal advocates are either gone or are retiring. The community lost Robert Eagleson in 2013, and Annetta Cheek retired from the Center for Plain Language earlier this year. I don’t know if others are feeling a sense of urgency, but I am. Let’s talk to these pioneers about their experiences, their triumphs and setbacks, and get this history down while we can.

PubPro 2013 recap

Managing editors and publication production managers from across BC gathered at SFU Harbour Centre on Saturday for the first ever PubPro unconference. We had representatives from educational publishers, trade book publishers, self-publishers, magazine publishers, journal publishers, technical publishers, course developers, communications departments, and more.

The day kicked off with session pitches: participants interested in presenting had a minute to pitch their topics to the crowd. Then, based on audience interest, our volunteers assigned each talk to one of our rooms. Yvonne Van Ruskenveld (West Coast Editorial Associates), Rob Clements (Ingram Content Group), Anne Brennan (Allegro Communications and EAC’s Certification Steering Committee), John Maxwell (SFU), and Jennifer Lyons (Influence Publishing) offered to present, and I pitched my talk about the editorial wiki I built as an in-house editor.

After the presentations were added to the schedule, we still had several slots to fill, so I proposed four discussion topics and asked members of the audience to volunteer to lead them. Eve Rickert stepped up to lead the discussion about managing a team of editors and working with freelancers; Jesse Marchand led a discussion about digital workflow; Brian Scrivener chaired the roundtable on project management and workflow; and Lara Smith took on the managing editors’ wish list for production management software.

We planted a volunteer in each of our rooms to help the presenters set up and to keep the day on track. To make sure we captured the day’s main takeaways, we also had a volunteer in each room taking notes. I spent my day in the main event room helping the presenters there, so I didn’t get a chance to partake in what I’ve heard were lively and engaging discussions. I look forward to reading our volunteers’ notes and catching up on what I missed; they will be compiling a full recap of the day for West Coast Editor, EAC-BC’s online newsletter, and I’ll post an update when the article appears.

Here’s a summary of what I did see:

Yvonne Van Ruskenveld—Interactive Editing: Big Project, Big Team, Tight Deadlines

West Coast Editorial Associates’ Yvonne Van Ruskenveld shared with us some of her wisdom gained from her experiences working in educational publishing, which can be vastly more complex than trade publishing owing to the sheer number of people involved. A project manager has to oversee the work of several writers, editors, artists, designers, picture researchers, and layout technicians, and when one phase of a project slips, the problem can cascade and put the entire project in jeopardy. In the planning phase, Van Ruskenveld said, it’s important to map out the whole project and consider issues such as how non-editors might be used to support substantive or developmental editors. Team members should receive an outline of the editorial process, a schedule, and a style sheet, as well what Van Ruskenveld calls a “project profile”—an annotated sample of a unit or chapter showing exactly what elements it has to contain.

A theme that ran throughout Van Ruskenveld’s talk was the importance of considering the social aspect of your team: a team functions more smoothly if members are encouraged to interact with one another and communicate freely. The project manager should set the tone for the group dynamics by being open, acknowledging receipt of messages, and responding promptly to team members. Most importantly, the project manager should be able to troubleshoot quickly and without pointing fingers. Once the project has wrapped up, the project manager should be sure to congratulate the team members and celebrate their contributions.

That said, Van Ruskenveld—and a few audience members—did acknowledge that some editors are just not suited to this kind of a project. Again, because educational publishing is so demanding, editors who can’t deliver on deadline should probably not be assigned to such a project, nor should editors who can’t work without a lot of guidance.

Rob Clements—Print on Demand for Editors

Rob Clements, now a sales manager at Ingram Content Group, began his publishing career at Regent College Publishing, where he eventually became the managing editor. There he helped revive out-of-print titles of Christian academic literature that had a small but enthusiastic readership by acquiring the rights to those books and printing small quantities. After hearing about Ingram’s Lightning Source print-on-demand service, he quickly became a big fan of the platform but expressed to Ingram his frustrations relating to the importation process of the print-on-demand copies. Ingram responded by offering him a job: Clements would be responsible for resolving some of the problems specific to Canadians who wanted to use Ingram’s services.

Lightning Source was founded in 1997 as a division of Ingram Content Group, and it provides digital and offset print services that help publishers sidestep the traditional supply chain, which is full of risk—risk that stock won’t arrive to a retailer in time to meet demand, risk that sell-in will be poor and that copies will sit in a warehouse, risk that sell-through will be poor and returns will have to be remaindered or pulped. Print-on-demand offers just-in-time delivery that not only eliminates this risk but also allows publishers to print in any market. Print-on-demand technology is well suited to Canadian publishing, which by definition is small-market publishing.

For editors, Clements said, opportunities lie in publishers’ and self-published authors’ desires to make reprint changes to their books. Since tweaks and adjustments are now so easy to implement—you need only wait until the next copy to be printed to see your changes made—editors will be called upon to manage and execute this process.

Anne Brennan—EAC Certification

Certification Steering Committee co-chair Anne Brennan spoke to the group about EAC’s certification program. The program was developed over the last two decades, Brennan explained, and is based on EAC’s Professional Editorial Standards. Candidates can write exams to become certified in proofreading, copy editing, stylistic editing, or structural editing—and if they pass all four, they earn the title of Certified Professional Editor. Brennan was quick to point out that not passing the certification tests doesn’t mean that you’re not a good editor, but becoming certified means that you’ve achieved the gold standard in editing.

The program’s advantages for freelancers are often touted: certification demonstrates an editor’s excellence to existing and potential clients, thus allowing that editor to gain confidence, bypass some requirements for certain contracts (e.g., some provincial government contracts allow certified editors to bid without submitting a portfolio), and maybe even raise his or her rates. But why should organizations and in-house editors care about certification? In-house editors who achieve certification are in a better position to ask for a raise or a promotion, Brennan noted, and if you’re looking for an editor, hiring someone who’s certified basically eliminates the need to test them. Opting for someone in the roster of certified editors means you’re hiring a professional who has proven that he or she can deliver excellent work. Organizations that encourage their employees to pursue certification are essentially publicly declaring their commitment to high editorial standards and clear, effective communication.

I added that I pursued certification while I was in house because I was responsible for giving editorial feedback to freelance and junior editors. Being certified gave me the confidence to go into those conversations confident and informed.

John Maxwell—Beyond Microsoft Word

Are we forever trapped in the clutches of Microsoft Word? John Maxwell explored some alternatives to the program in his talk, in which he argued that Word was really made for another time and isn’t well suited to the interactive editor–author relationship we can accommodate and have come to expect today. What are some of the other options out there?

Maxwell said right off the bat that he wouldn’t be talking about OpenOffice, which basically replicates the functionality of Microsoft Office and so isn’t an alternative to it at all. One class of true alternatives are word processors in the cloud, such as Google Docs or the ubiquitous Wysiwyg online editor on platforms like WordPress, although Maxwell did say that the next-generation HTML5 editors would likely overtake the latter very soon. Google Docs allows for collaborative authoring and editing—two people can simultaneously work on a document as long as they’re not making changes to the same paragraph—and you can see the revision history of a document, but it doesn’t really track the changes in a way that editors might want.

Another class of options includes simplified writing tools that allow you to focus on the words and not have to worry about document formatting; these include Scrivener and Editorially (in development). Part of this “back to the simple text editor” movement is the concept of markdown, a very lightweight markup language: gone are the intimidating tags that you see in XML; instead you use underscores to format text into italics, asterisks for boldface, etc.

For versioning and editorial workflow, Maxwell mentioned Git, a software tool that programmers use. It allows multiple people to edit a document at the same time and will flag editing conflicts when they arise. Although there’s a possibility it will creep into the mainstream, Maxwell thinks it will likely remain primarily a tool for the software development community. Other tools that allow versioning are wikis, which allow you to see a page’s revision history, and annotation tools that are used for peer review in scholarly publishing.

Finally, Maxwell gave us a demo of Poetica, which is being developed by a programmer and poet pair. Writers can upload or input plain text and ask for editorial input; an editor can then make suggestions, which appear as overlain editorial markup. The impressive demonstration elicited some oohs and aahs from the audience; as Maxwell later remarked to me, “You could feel the air pressure drop when everyone gasped.” He fielded several questions about what the software could and couldn’t do, and he suggested that people contact the developers for a chance play with it and send them comments about what kinds of features they’d like to see.

Iva Cheung—The Editorial Wiki: An indispensable communication and training tool

I’m glad I got to talk to the PubPro group about the remarkable usefulness of the editorial wiki that I built while I was editorial coordinator at D&M. I’ve covered all of the points in my talk in a previous post, so I won’t repeat them here, but I was so encouraged by the responsiveness of audience members to the idea. I hope some of them will decide to implement a wiki—or something like it—for their own organization, and I’m always available to consult on such a project if they go forward.

The sessions, each only forty minutes long, prompted incredibly interesting discussions that continued through the lunch break and at the afternoon’s networking tea, a completely unstructured session in which participants could grab a tea or coffee and keep the conversation going. We also invited pre-registered freelancers to join us for the tea, because we couldn’t pass up the opportunity to put editors and indexers in the same room as those who might be interested in hiring them.

We wrapped up the day with a brief closing session, where we gave away two books, Adrian Bullock’s Book Production, which went to Lara Smith, and International Paper’s Pocket Pal, which went to Anne Brennan.

All in all, PubPro was an eye-opening, inspiring day. (Check out the Storify that EAC-BC compiled.) A million thanks to our amazing crew of volunteers, without whom the day would not have gone nearly as smoothly: Maria Jose Balbontin, Megan Brand, Lara Kordic, Jesse Marchand, Dee Noble, Claire Preston, Michelle van der Merwe, and Grace Yaginuma. Thanks also to EAC-BC (especially professional development co-chairs Tina Robinson and Eva van Emden) and the Canadian Centre for Studies in Publishing (particularly Rowly Lorimer, Suzanne Norman, and John Maxwell), as well as our event sponsors—Friesens, Hemlock, Ingram, and West Coast Editorial Associates. I’m elated by the positive feedback I’ve received so far from participants. We may have to do something like this again!

Elemental editorial checklists

Waaay the hell back, I posted this tribute to the dependable, indispensable checklist, and I promised to return with more posts about creating effective editorial checklists. A bunch of events and conferences and book reviews took priority, and the checklist got pushed to the back burner. So before it gets boiled dry, here’s the first of a few posts I have planned about simple editorial checklists that can save you time and, potentially, a lot of money.

In Atul Gawande’s The Checklist Manifesto, a checklist expert in the aviation industry, Daniel Boorman, tells the author about the two main types of checklist:

You must decide whether you want a DO-CONFIRM checklist or a READ-DO checklist. With a DO-CONFIRM checklist… team members perform their jobs from memory and experience, often separately. But then they stop. They pause to run the checklist and confirm that everything that was supposed to be done was done. With a READ-DO checklist, on the other hand, people carry out the tasks as they check them off. (pp. 122–23)

That distinction may work well for checklists designed for large teams of people performing complex tasks, but for editing and publishing, I find a different kind of division more practical: most editorial checklists will be either elemental or procedural, and it’s the former I’ll talk about here, because it’s the easiest to get started with.

Whereas procedural checklists give you a series of tasks to perform, elemental checklists tell you what elements to include. Publishers will find them useful for all of the constants across their publications; for example, cover copy on all of a trade publisher’s books will have the same components, the chapters within a textbook will have the same structure, and a market research firm’s reports will typically include the same sections each time.

Elemental checklists serve multiple functions:

The person who first drafts the copy can use them to make sure he or she has covered all bases.
The editor, designer, and proofreader—not to mention the person who checks the printer’s proofs—can use them to double, triple, and quadruple check that nothing critical has been left out or, in a more likely scenario, dropped out from one stage of production to the next.
They are a powerful, authoritative training tool for new editorial and production staff members, as well as freelancers.

That third function underscores why you would bother creating elemental checklists. When I first started out in trade publishing and had to write cover copy for the first time, I was told to look at another of the publisher’s books as a guide, yet I wasn’t sure if the book I had chosen was representative. Having a checklist would have saved me some second guessing. And if I had been a freelancer, I might not have had access to the publisher’s backlist from which to choose a sample.

Even for seasoned veterans in house, these checklists are invaluable. We’d all like to believe that once we’ve worked somewhere long enough, we’ll have internalized all of the details, such as what goes on a title page. But with everything that an editor has to do, having a reminder in the form of a checklist—”a kind of cognitive net [that] catch mental flaws inherent in all of us” as Gawande says (p. 47)—is extremely helpful. A checklist frees your mind from having to remember these details and allows you to focus your task.

And those “mental flaws” Gawande mentions can be costly to publishers. Forgetting to include the company URL on the back cover copy may not be a huge problem, but inadvertently dropping an acknowledgement clause could get your funding pulled, and missing a disclaimer could have legal repercussions. Every publisher has a war story about having a book rejacketed at the eleventh hour (or worse, pulped and reprinted) because it had left off a copublisher’s imprint information or having to get a shipment of books stickered because the barcode was missing.

For recurring items that use boilerplate text—for example, the copyright page, with its standard copyright and acknowledgement clauses—using a template rather than a checklist would save you a lot of rekeying, but the principle is the same: the template, like a checklist, ensures that the essential elements aren’t inadvertently omitted owing to a lapse of memory.

Developing elemental checklists is simple:

Suggestions for publishers

1. Pull out some representative publications

If you publish multiple genres or multiple formats, it’s helpful to have one of each in front of you.

2. Identify all of the constants

Some examples, for trade books, are the half-title page, title page, and all parts of a jacket (e.g., front flap, front cover, spine, back cover, back flap). Textbook chapters will often have recurring elements, structured in the same way (for example, introduction, lab activities, career profile, chapter summary, glossary), and each of those elements may in turn have a recurring structure (e.g., activity title, list of equipment, numbered method, analysis questions), so be sure to consider constants at both a macro and a micro level.

3. Identify required components and optional components

For example, a trade book’s front cover must have the title, subtitle, and author’s name, and it may have a short endorsement quote. (If you’re thinking, “Well, surely we don’t need a list for three items,” let me assure you that, yes, there have been publishers that have forgotten to include an author’s name on the front cover.)

4. Create generic elemental lists that apply to all of your publications

Start with broad lists that everyone will use, then…

5. Devise genre-specific sublists if necessary

For example, you may wish to have a disclaimer on all of your medically themed books or ensure that you include a co-publisher’s logo on the title page of co-published titles.

6. Share the checklists with all team members, including freelancers

Better yet, make them available for browsing or searching on an online tool like an editorial wiki.

7. Periodically revisit and revise your checklists

All checklists should be regularly revised for relevance, although elemental checklists generally tend to change less frequently than procedural checklists do. Still, those of us in publishing who saw the transition from 10- to 13-digit ISBNs, for example, will recall how much even small details matter to workflow. Make sure team members are aware of any changes. (An easy approach is to use an editorial wiki as the authoritative central repository for this kind of information. Editors and designers will always know that the material on the wiki is the most up to date.)

Suggestions for freelancers

Request checklists

If your publisher clients don’t voluntarily offer checklists, ask for them. If your clients don’t have checklists at all, your enquiry may well prompt them to think about developing some.

Oh wiki, you’re so fine; you’re so fine you blow my mind

In my consulting work, one question I always ask my clients is, “Do you have a central repository for your editorial information?”

If not, I say, get one. (And by posting this, I’m pretty much giving away the farm here.) If all of the editing is done in house, this repository could be as simple as a folder on a shared server. If you do any work with freelancers, this resource must be online.

Most clients I edit for understand the importance of regularly reviewing and adjusting house style guidelines for relevance. But how those changes are communicated to editors—and freelancers in particular—can make the difference between a seamless transition to the new style and a confused mess that someone in house is left to clean up. Having a single online editorial resource means that you’re making changes in one place: all of your editors, including your freelancers, learn to look there, every time, to check for updates; you’re not having to email everyone each time the guidelines are modified; and editors aren’t left with numerous copies of a style guide on their computers, wondering which is the most up-to-date.

There are probably a number of feasible forms such an online resource could take, given the flexibility and accessibility of content management systems out there today, but the one I’ve found easiest and most effective is the wiki. Wiki pages are extremely intuitive to create and update, the entire wiki is searchable, and, best of all, wikis are structurally flexible—internal links are a snap to make, and there is no inherent hierarchy, which allows you to arrange your content for one group of users and do it completely differently for another group, all the while not having to change the underlying content. Wikis are designed for collaboration, so they are ideal for resources that require contribution from several sources (for example, if the editorial director wants to update style guidelines while the managing editor clarifies invoicing procedures and the art director wishes to give a list of specifications for digital images). What’s more, thanks to Wikipedia and the like, most Internet users are already comfortable using wikis to seek out information.

One of my most well-received projects while I was editorial coordinator at D&M was the editorial wiki, which turned out to be so useful for in-house editors and freelancers alike that I expanded the model to a wiki for authors. Before the editorial wiki, every time a template was tweaked or the house style updated, the managing editor had to send a note to all editors alerting them to the changes. And each time she had to decide who should receive it. That freelancer she hasn’t used in a few seasons but might use again when things get busy? And the relatively new contractor—does he have all of the guidelines and templates he needs? It’s easy to see how time-consuming and fallible this system can be—and with a central editorial wiki, it’s completely unnecessary. Send all of your editors to the same place, and they can access the up-to-date resources as they need them.

When I initially put the editorial wiki together, I used a free but proprietary WYSIWYG wiki program, but eventually I migrated all of the content to MediaWiki. It’s the open-source wiki software behind Wikipedia, so it’s certainly been well tested, and its default look is something most people are familiar with. Because it’s so widely used, it has a vast support community, and learning how to solve a problem or customizing a feature on MediaWiki is usually just a Google search away. MediaWiki has its own search feature, it has the ability to show users the full history of page edits, all pages can be tagged with categories for easy organization and navigation, files like Word documents, PDFs, and JPEGs can be made available to users, and templates can be used for multipurposing content. And if you don’t want your style guidelines broadcast to the public? No problem—MediaWiki can be customized with password protection.

So what should go on an editorial wiki? At minimum, include your house style, any specific editing and formatting guidelines, editorial checklists (more on these later), templates, and, perhaps most importantly, a description of the steps in your editorial process. After I transferred this bare-bones content to MediaWiki, I found that the latter’s ease of use and extensibility made it a breeze to create new content specifically for fiction editors or cookbook editors or art book editors. The editorial wiki became an extremely powerful tool that, all at once, improved communication with our freelancers, empowered them to find their own information, and freed in-house staff from having to answer recurring editorial questions.