Working on doingText is not just about developing a web application - though this is, of course, our daily action. In the more general frame, doingText is about collaboration and writing. In this context the idea for doingText came up last year. Experience with the existing tools and with working in groups are the background for our work here and not only the background, but a recurrent theme in our daily work. For that reason I want to bring up several issues and links related to group work and writing here, hoping it will be interesting for you as well.

Today, I start with an article by Misti Wolanksi, published on Freelance Switch: That’s Not What I Thought I Wrote! He writes about solo proofreading and minimizing comprehension problems for others when writing a text. The starting point is surely known to everyone of us: “When you read it [the text] yourself, you read what you meant to say rather than what you actually wrote. Everybody does it. It’s unavoidable.” The possibility of misunderstandings doesn’t only count for journalists or alike. It is also the meeting protocol you write for your absent coworker or the exam question you give to your students that’s open for comprehension problems.

Wolanski gives 4 hints on how to improve the writing with regard to your target audience. None of it alone is the final answer, but a mixture of it will do - always depending on how much time there’s left and which method you prefer for yourself.

A few hours or days of rest before proofreading is the classical method taught since the first days of your school time. It’s taught because it works. If you only have a few hours time, Wolanski points out a good thing as to what you should do in the meantime: namely something totally different. With me, for example, it works best to go off the computer and do something practical. Sounds simple, but mostly we all just switch to the next thing done on our computer.

The next option is printing the text. Though used to working at the computer, a printed text still works different. The distance between your eyes and the paper is different to the screen and so you read differently. Also, a screen offers a limited size when it comes to keeping a 10-pages-strong paper in your visual field. For exapmple, if it’s necessary to compare the beginning and the end of a text, it’s probably easier to do so with a printed version.

Reading a text aloud is the best way to check if your text is written fluently. Reading aloud forces you to read each and every word of the text. Thus reading becomes more slowly and thorough. If you happen to stumble upon single words, it’s the hint to change something at that point.

To especially check on spelling mistakes and there’s no software dictionnary at hand, the backwards method is your choice. Read every word starting with the last sentence. This brings you totally out of the logical concept and focusses your attention to the word itself.

So much for the solo proofreading. Of course, the proofreading can also be done by friends, coworkers or your boss. In this team proofreading process you should always clear what parts of the text the corrector should look for, only the spelling side or also stilistic aspects.

Have you got even other approaches? Let us know in the comments.

[Update] Tom left some more very helpful strategies for proofreading your own texts in the comments.

Also, I’d like to recommend an article by Paul Graham (the guy with the Good and Bad Procrastination). Its title is “Writing, Briefly“. It’s mostly about the writing part, but also has some words regarding proofreading.

Easily sharing your text with others has been raised to a whole new level. As from now you can embed a text to your own website. This is really some nice variation of your data belongs to you.

So how does it work?
Behind the menu item “Share” you find the embed code. Insert it to your latest blog post or create a new page on your site. Done.

At the moment, the embedded text shows the first 40 lines of the discussion and no comments. There’s a link to the discussion, so anyone interested in cowriting can do so with just one click (given the discussion is not password-protected).

In what kind of scenario can embedding be useful?
Some of you use doingText as a preparation tool for later blog posts. Instead of copying the text, you can now simply insert the code.
Another scenario would be planning an event (a workshop or alike) with some folks, you surely want to promote this on your blog by creating a new page there. Your visitors will then always get the latest status of the planning process.
Or, you have a discussion outlining a paper or experiment or alike for university. You could then not only write about the idea on your website and set a link to the discussion, but also bring an illustration of the developing process.

For the future we’re already thinking about offering a scaled embed code. A small version could be used for sidebars and would involve the first 5 lines. At the other end of the scale embedding the whole text would be surely great for publishing writing results on your website.

Have fun exploring.