Textproof Chronicle

Nik Fletcher, in On this Safari 5 Reader Hysteria, discusses the hyperreaction of many link-baiting web publishers to Apple's new Safari Reader feature, which strips sidebar material such as adverts, placed links, comments, and syndication buttons from pages to leave the principal content, the writing that drew the reader to the web page. Nik sums up his reaction:

Amen to that. If anything, instead of this belligerent whinging, web publishers should wise up that people visit their sites to read content. Safari Reader does hide ads, after they - along with the almost-constant barrage of "Share This", "Tweet This", "Buzz This" bullshit - are shown alongside each post, and above all: it's not mandatory to use, or enforced any more than the RSS button. Perhaps instead of flamebait posts of "Apple are out to get us" media companies should be asking themselves "how did reading content online become so sucky"?

There's at least a little irony that Nik's own site has such a high proportion of its layout geometry devoted to non-content material: half as much width as the principal content is taken with syndication "bullshit", and the end of the article devotes a lot of vertical space to reciprocal links — his own site does not seem to value the reading experience emphatically above marketing value. But I agree with what he says; indeed, if he has felt the same need to sacrifice usability to visibility as the link baiters he so despises, that actually can only support his point.

The Google era, that which provided browsers with effective tools for finding the kind of content that reasonably competent web browsers were looking for, made web content an important repository of knowledge, one that could be weighed in value against the now-traditional content available in physical bookstores and libraries. This advance constitutes a fundamental increase in the usefulness, both intellectual and practical, of the sum of public human knowledge.

Against that, the Google era began with the technology and craft of both internet typography and layout lagging far behind that of print, in terms of supporting readability. And since then, the situation has become worse: the link-baiting publisher now values the published content only in drives up visibility, that is, both in attracting vistors to the site who are influenced by the sidebar content, to perform such actions as clicking on adverts, so earning per-click income, or in syndicating the URL via Twitter, so driving up the site's PageRank. Worse still, the competition that print publications face from online content has driven many publishers to make deep cuts into their editing and typesetting functions, leading to an easily observed decline in quality — a decline in standards that has impacted accuracy and must surely have impacted readability.

So the Google era makes it easier for readers find the kind of material they are looking for, but it has undermined the readability and accuracy that is then read. For most readers, most of the time, this is a better situation, but many kinds of reader, for whom accuracy is critical or whose sought information will demand close attention to the text, it may have become harder to find material that meets their needs. Publishers who maintain traditional editorial and typesetting standards have become fewer; the costs borne have become a badge of quality like the tail feathers of a peacock. Or, to put it another way, the needs of the many have been mat at the expense of the needs of an important few.

Innovations such as Safari Reader, together with good technical work that has been improving digital layout and typography, by raising the typesetting standards of web-distributed content, may make more visible the difference between well-edited and poorly edited content.

At least, that is my hope.

Derek Powazek writes, in his Note to Apple: Justified text decreases readability on Flickr:

Safari 5's new "Reader" feature makes my site less readable by justifying the text. Flush-left text (aka ragged-right) is demonstrably more readable, especially when the rendering engine doesn't know how to hyphenate. You never, ever justify text without hyphenation.

Justified text was invented to define columns of text in multi-column layouts (like newspapers). Why they chose to justify the text in a 1-coumn view that's supposed to be more readable is beyond me.

The point about poor hyphenation must be right, but what about the claim that Flush-left text ... is demonstrably more readable? This is widely claimed, but the evidence isn't overwhelming.

First, a point of terminology: flush left and ragged right are actually independent constraints on paragraph layout, and all of the four combinations of either flush or ragged left with either flush or ragged right have their place. Flush right generally means that the right edges of the all the rightmost letters line up —although note that this will not be exactly true if text layout uses microtypography— while ragged right means allows the horizontal distance between the rights edges to vary. Justified text is text that is both flush left and flush right, and for our purposes here, we can simplify and consider only flush left text.

The key point, then, is that ragged right is consistent with using the same width space between words, whilst justified text must allow the interword space to vary.

In an influential article, Williams (2000, p394) recommends the use of [s]et type intended for extended reading flush left, and ragged right because (p390) [n]on-uniform spacing between words decreases reading speed by as much as 11 percent (Trollip and Sales 1986).

However, I believe that such an increase in reading speed depends on lines being relatively long, where the speed up arises from the better rhythm the eye can achieve as it moves between eye fixations. As lines become shorter, the proportion of time the eye spends moving from the end of one line to the beginning of the next becomes larger. This should be faster with justified text for two reasons:

1. Short lines tend to happen because of either the existence of inset items such as photographs, or multi-column text. Good page layout demands more space between the right edge of a text column and what is to its right for ragged right text than for justified text, because with justified text it is easier for the reader to accurately grasp the shape of the text block (cf. Williams 2000, p387, on complexity). This difference in needed margin is quite significant, and so when there is little width, justified text will have a lower proprtion of expensive line jumps to regular, in-line eye movements.

2. The line jumps are regular with justified text, since the right edge of each line is a constant horizontal distance to the left edge of the next line. Thus, with short lines, there is a better possibility of generating eye-fixation rhythm from line to line with justified text than with ragged.

So, as the line becomes shorter, the case for faster readability of ragged text becomes weaker. With multicolumn page layouts, it may be the case that justified text is generally more readable; certainly, the practice generally is to use justified text with multicolumn layouts. To answer the question: which should I use, I recommend the advice of Newsletter Fillers.

References

Trollip, S. R., and G. Sales, 1986. "Readability of computer-generated fill-justified text." Human Factors 28:159-163.

Williams, T. R., 2000. Guidelines for Designing and Evaluating the Display of Information on the Web. In Technical Communication 2000(3):383-396.

Most word-processing software offer change tracking, the ability to show what changes were made to a text, which provides the most basic feature allowing for authors to review edits. It is typical, though, that the sheer number of edits makes reviewing edits using just this feature tricky, with the more significant changes that need attention being buried under many insignificant edits.

So I pick out areas of text in need of further attention using comment facilities. I use a set of abbreviations to classify these, allowing for shorter, and more quickly acted-upon comments. For an explanation of this scheme, see the list of my Abbreviations for Editing Markup.

There isn't really such a thing as the ratio of comments to all edits: longer texts tend to require fewer explanations, since passages in need of discussion become increasingly likely to have already been explained in an edit, and because I tend to acquire a firmer grasp of what the author is saying, and am more often sure of how to fix an ambiguous or incomplete text. The extreme opposite case is that of the sample edit, needing much explanation; I discuss this in The Sample Edit.

I try to make sure that the end document has the quality that all the English is correct, even though there may be issues I raised in comments where I doubt that the manuscript really says what was intended. This is not always possible for me: for those manuscripts that contain a passage for which I am unable to find a reasonable fix for a passage, I highlight it in blue.

Microsoft Word

Microsoft Word's change-tracking feature, Track Changes, is the most widely used system for reviewing edits, and despite some annoyances, such as the inability to comment within footnotes, it works very well. If you're not familiar with some of Word's options for reviewing tracked changes, however, working through them can be hard work.

It generally makes sense to first deal with the issues that require most judgement to resolve; this means the blue highlight text first, and then the comments. Conveniently, Word has two menu actions allowing you to move from each comment to the comment before or after, and the ability to search for coloured text. Once each comment has been dealt with, it makes sense to delete it — it is possible to review all the comments again from the version I sent: this way the set of comments reprost the "state" of the document, only indicating the outstanding issues, and if new issue come up in review, they can be added.

Then comes the mechanical task of looking over the pieces of text inserted and deleted from the original. If there are dozens of these together, it is much faster to look at all of the edits in a paragraph, reject the changes you disagree with, and then highlight the whole paragraph and accept all of the remaining changes.

It is also possible to view the final version of the document without changes, read through this to see that you find the text acceptable, and then accept all changes in the document together. If you are a careful reader, and have taken into account the issues raised in the comments, then this works perfectly well.

LaTeX

Reviewing changes to LaTeX documents is much more of a free-for-all than Word, because there are so many choices in how to go about it. The two I have found best are:

1. Load the LaTeX source into a new Word document and edit that the same way as any other Word document. This would work much the same if we were to load the source into OpenOffice Writer.
2. Put the LaTeX source into shared distributed version control repositories (DVCS). This allows both of us to work on the document concurrently, which may be valuable for longer assignments. Using LaTeX macros to implement comment facilities, and latexdiff to give a snapshot of the changes made between two states of the manuscript, help with reviewing changes.

Other technologies

OpenOffice Writer and Adobe Acrobat's comment facilities don't allow comments to be associated with a highlighted text, but instead point to a particular place in the document. I use the same comment scheme, where "highlighted text" is interpreted to be some region of text following the comment.

Generally, the simplest way to get a sense of what a —so far unknown— proofreader or editor offers in terms of being able to improve a manuscript is to find a short, sufficiently representative excerpt of the manuscript, and edit it. This shows what kind of things an editor pays attention to, how they communicate issues with the text, and provides a basis for the client and editor to discuss what kind of edit is best.

With nearly all of my clients, therefore, I've given a sample edit before agreeing on the terms of the edit.

Some points:

• I use abbreviations for my comments - these are explained in my guide to editing abbreviations;

• There are some ways in which my sample edits will typically be unrepresentative of the editing I would later do in a line edit on the full document. Most importantly:

  1. Far fewer edits in the full edit will have comments: when I make the sample edit, I will have made only a cursory investigation of the manuscript, and I will not usually have had a chance to ask questions about the text. By the time of the line edit, I will know much more that helps me resolve these issues for myself;

  2. One of my aims in the sample edit is to expose as many issues as possible. Typically, therefore, I will choose a sample to edit that is particularly problematic, or that illustrates things that should be discussed before editing begins.

Steven Rainwater, Advogato's maintainer, posted an article there, Happy 10th Birthday, Advogato, which provoked me to think a bit about where the site is going. I've put together a timeline, consisting of a link from each of the ten years that gives an idea of what Advogato was like that year.

• 2008 — GNU and FSF News for January 2008
• 2007 — Advogato and Hateful/Divisive Posts
• 2006 — Articles 871-900 — Thirty consecutive articles, up to Raph Levien's decision to abandon, and Steven's decision to rescue, the site.
• 2005 — Article:advogato.org and advogato.com renewed.
• 2004 — A diary post by Graydon Hoare, which shows how the action back then had moved to recentlog.
• 2003 — Article: Is the active user-base of Advogato incompetent?; note moshez' response, on the advantages of managing where your content is posted.
• 2002 — Articles Mixins for PHP and Thoughts on voting machine fraud
• 2001 — Article The Rules of Open-Source Programming, to which Raph replied with Some more "rules".
• 2000 — Alan Cox wrote two articles about patent law and practice, both widely cited: one, two.
• 1999 — This year's anniversary article, Happy 10th Birthday, Advogato, gives a feel for the first days; my post there has some links from that time.

Advogato is one of the older social networking sites, for free software developers, from before the days when that term was used, and it's maybe the one with the most unappreciated lessons, in both senses. I greatly admire what Raph Levien has done with the site, and am very happy to have been involved with it during most of its history.

Revised: 28th April 2010

With respect to reviewing edited manuscripts, the abbreviations I use to communicate issues needing special attention are:

• ALT — I offer an alternative text to that highlighted;
• AMB — The highlighted text is ambiguous;
• CK — Check the highlighted text: there may be an issue concerning factual accuracy, style, etc. This kind of comment raises "Are you sure?" questions;
• CR — I've changed the highlighted text, but my text may still have an issue. In contrast to the CK scheme, this kind of comment asks "Is what I've written OK?" questions;
• DEL — I've deleted a lot of content-carrying text at point. Typically, this is because my editing brief asked for shortening of the text, and I consider the sentence either redundant (repeating what has already been said), or that it doesn't help establish the theses asserted in the abstract and introduction;
• NB — ''Nota Bene'': there is some general point worth taking into consideration;
• NC — The highlighted text was not clear to me, and I did not understand it fully;
• STY — The highlighted section raises some issue concerning the agreed-upon style guide.

For systems allowing comments spanning a segment of text, such as Word and Latex, then this will be the appropriate highlighted text.

OpenOffice Writer and Adobe Acrobat's comment facilities don't allow comments to be associated with a highlighted text, but instead point to a particular place in the document. I use the same comment scheme, where "highlighted text" is interpreted to be some region of text following the comment.