Why we edit in Google Docs and not the back end of our site

This may be one of those polarizing issues, but I’m going to throw it out there. I don’t think that your site’s stories should be edited in the back end of your content management system (WordPress or otherwise).

Well, technically, it’s not the CMS that I have a problem with. It’s a process of editing that presumes the best person to make revisions to a story is an editor. I disagree–even if that editor is more experienced or a better writer.

I’ve heard, recently, of some staffs that have writers upload their stories to their news site, they save the stories as drafts, then editors go in to make changes to the stories, then publish them to the site. While this process might be efficient, I think there’s a key step missing here, which is the opportunity for the writer to learn from his or her own mistakes and take control of his or her own story.

Rather than making changes for the writer, editors use a staff code to indicate where revisions are needed. Then writers are responsible for making the changes, which (hopefully) they learn from.

There are many, many different ways to do this process–and I hope you’ll share yours–but here’s our setup, which changes, at least slightly, each year.

1. The writer sets up a Google Doc for her story. She shares it with a peer editor, who edits using a common code (see below).

2. The writer copies the entire story above the edited version and makes her revisions. Then she invites her section editor to collaborate on the doc. He edits the clean, revised version using the same code but a different highlight color. (The highlighting may change given Google’s new profile integration into inserted comments.)

3. The writer copies the edited version and does the same thing again for several copy edits. After the last edit and revision, the final version of the story is at the top of a long doc that contains all edited versions of the story. Then the writer publishes the story on the site.

Yes, this requires the story to be worked on in two separate spaces, but the benefits are great. For one, each editor can see the suggestions of previous editors. This helps them to hold each other accountable for actually making suggested changes, while also opening up discussion about best practices or common errors.

The newest update of Google Docs allows collaborators to insert comments that are identified with the commenter's Google profile image and display name.

But it’s also great for the writer, who gets to see how his or her story evolves throughout the process. If someone else is making changes to their stories, how will they ever learn? And who could be angry if they continue to make the same mistakes over and over, given that the mistakes are never directly pointed out to them in the first place?

Many of us are adapting to a much quicker production pace online than we grew accustomed to with (mostly monthly) print publications. Yet some of our old strategies to grow strong journalists can, and should, adapt with us. Online collaboration tools like Google Docs have exploded in the last few years. Let’s not forget to use them!

 

Editing key (all are highlighted in editor’s color):

<< >> = delete text
[[ ]] = insert text
(( )) = comment

Michelle Balmeo

Michelle Balmeo, MJE, is the adviser of The Whirlwind newsmagazine and online news publication at West Albany High School in Albany, Ore. She's done some print stuff, some video stuff, and some web stuff over the past 16 years as a student media adviser.

Michelle Balmeo has 66 posts and counting. See all posts by Michelle Balmeo

One thought on “Why we edit in Google Docs and not the back end of our site

  • March 23, 2011 at 7:11 am
    Permalink

    Great, relevant piece. I echo all your thoughts. Google docs really has allowed for better collaboration of stories, which in turn has made copy stronger overall.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.