This past Saturday's Financial Times ran a story, Brown to tackle
Newsweek turnaround, reporting on Tina Brown's
acquisition of Newsweek, as part of a leveraged merger with her The
Daily Beast, creating the unimaginatively named Newsweek
Daily Beast Company. The piece that sparked my interest was a
paraphrase of something she had said last year, declaring that "books
are the new magazines".

The paraphrase was taken from an FT interview from 14th
October, 2009, and titled The beast of new journalism;
the context of the claim was:

She is also getting back into printed media. Given her record, it is
startling when she announces that she sees no future for long-form
magazine pieces "of the old kind", outside the pages of The New
Yorker, The Atlantic and Vanity Fair, and proclaims that "books are
the new magazines".

Towards the end of the piece, the theme of traditional media's doom is
developed a little:

For Ms Brown, the problems of traditional media are as much to do
with "self-inflicted damage" stemming from "corporate greed" as with
competition from the internet.

Speaking hours before a book launch for her husband, Harry Evans,
that was filled by grand old names from journalism's print heyday,
she warns: "These big companies are cutting editorial costs to get
greater returns. The product becomes an empty shell and readers
drift away."

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 so far as it 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 met 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.

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:

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 proportion of
expensive line jumps to regular, in-line eye movements.

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.

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:

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.

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.

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:

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;

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.

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.

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;

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.