Leon Paternoster » How-to

Good web copy is boring

Leon — Wed, 05 May 2010 13:30:54 +0000

One of the most difficult things about writing web copy on a day to day basis is taking some text from a colleague and reforming it into an often brief missive.

Where have my lovely adjectives gone? is what they’re thinking but not saying. Most people are very polite and will save their disapproval for another time (or person. But I digress).

Untrained web writers often make these mistakes:

they assume that not having much to say about their product or service means it somehow lacks gravitas, substance &c.
they think words can mask the fact there’s not much content
they think that writing unadorned by adjectives is dull
they think that short, simple, active sentences are dull
they think that their adjectives enhance the description of their product or service; that they help paint a picture
they think bullet points, bolded keywords and short, bitty paragraphs look ugly

The problem with adjective–laden writing is that readers couldn’t care less whether your product is innovative and new because they haven’t come across a product that is unoriginal or dated in the last 10 years of browsing the web. These types of adjectives have less than zero meaning.

Screenshot of The MSPA annual conference web page: lots of text about Istanbul but who's speaking and what will I learn?

Readers want to know how the product you’re offering will help them, so a quick summary of its benefits will suffice. Structure this is in a way that helps them scan your text, paint pictures with, erm, pictures, and you’re pretty much there.

On paper (or screen) it may seem boring, and a million miles from the original author’s conception of their product, but your readers will appreciate it. Conversions really do increase after copy is stripped down to communicate a clear message.

Getting the boring message across

Ben Locker explains how clients don’t value simple copy. I try and demonstrate its purpose to colleagues by:

involving them in the content writing process by showing them drafts and explaining why I’ve made certain decisions
sitting them in on some simple, low–fi user testing. It doesn’t have to be related to whatever it is they’re interested in; witnessing how impatient real people are in real web situations is often an eye opener
getting them to perform a fact finding task using a real site which uses overly complicated copy (note their frustration)

The key is getting clients or colleagues to see with the user’s (or customer’s) eyes. It’s not easy, but it can help build trust and make future work a lot easier.

Adventures in HTML5. Part one: Using HTML5 now

Leon — Thu, 07 Jan 2010 22:03:19 +0000

There’s no real reason I’m aware of for not using an HTML5 DOCTYPE and HTML5 tags (with the exception of audio and video, which can be fixed). So that means the first line of any HTML document should be:

Which is reason enough to start using HTML5. But it also means that instead of structuring pages with:


... 

...

You can use:


... 

... 
... 
...


Which is very exciting (and radically different from the last seven or so table–free years of markup). At last we can structure documents with real tags. There will be less 
s in the world, which is a good thing.
Browser support
All modern browsers interpret HTML5 tags and allow CSS to style aside, header etc., and you can force Internet Explorer to join the party with a small snippet of javascript. I hotlink to some Google Code–hosted javascript by adding the following to the head section of HTML pages:

(Note the lack of a script type. That’s one of the many great things about HTML5: It’s stripped out lots of (X)HTML verbosity, which makes it a lot more friendly.)
Which means the following browsers and user agents don’t interpret HTML5:

Internet Explorer with javascript turned off
Screen readers

Which isn’t a problem because one audience is going to be absolutely tiny (is there any reason to browse in IE with javascript turned off?) and the other will simply ignore the HTML5 tags (another great feature of HTML5 is the graceful degradation. Browsers adopt the standard at different rates, but most of the time the fall back option is perfectly acceptable).
Most HTML5–specific tags are currently implemented by (ab)using the virtually meaningless div (div groups bits of content arbitrarily; it doesn’t indicate why these bits of content have been grouped). As screen readers do nothing with divs it makes no difference if we use header or article instead of div id="header" or div id="content". And once screen readers start to understand HTML5 users will begin to benefit from more meaningful documents. For example, screen readers could separate navigation from content by looking at the markup contained between nav tags.
Caveat
As ever, all is not completely simple. The problem HTML5 poses to screen readers is not the introduction of a new set of tags, but in the way it handles h1-h6. In previous HTML specs, a document could only consist of 1-6 discrete headings it made sense to only use one top level heading because it would mark up the document’s title, and documents normally one have one title. So your document would use h2s, h3s et al to head other pieces of content.
In HTML5 each node can have its own hierarchy of headings (so each header, footer, article and aside can have an h1), although it doesn’t have to (HTML5 is a good friend because it’s so flexible) Looking at our traditionally marked-up page, it would be structured along the lines of:

Site title
... 

... 
... Document title

Sidebar section title

Whereas our HTML5 page can be structured like this:

... Site title
... 

... 
... Article title
... 
... 

... Aside section title

Which is logical, but means that screen readers (which use the traditional method) just see a bunch of first level headings, which corrupts the structure of the document.
It’s difficult to suggest a way round this. HTML5 is our flexible friend, so you can continue to use a strict h1-h6 structure, but it strikes me as illogical, considering the new DOM structure which allows us to have document level footers and footers within articles.
So are you using HTML5 on a day to day basis?
Or is it still too experimental for real client work?



Controlling excerpts and content length in WordPress
Leon — Sun, 05 Apr 2009 07:14:50 +0000
Apologies for the less than pithy title…
WordPress is a little inflexible when it comes to displaying post excerpts. If you use the_excerpt, WordPress will dutifully display your excerpt or, if there isn’t one, the first 55 words from your content.
It’d be good if this function included a parameter to limit content length by a specified number of words. Perhaps it will in future versions. In the meantime, here’s how I go about it:
First I determine whether a post has an excerpt or not by checking whether the excerpt field in the database is empty. If it’s not empty, WordPress will go ahead and display the excerpt. If the excerpt is empty, I tell WordPress to display a specified number of words (10 in this example) from the content by using the the_content_rss function:
post_excerpt != "" ) {

the_excerpt();

}

else {

the_content_rss('', FALSE, '', 10);

}

?>
Although this may seem (and be) a rather esoteric technique, I’ve found two uses for it. The first was when I developed a theme for a client that generated a banner from the excerpt. The client had around 400 posts in his blog that didn’t have excerpts, so I needed to limit the banner size.
You can also modify the code to display all of a post’s content if there is no excerpt. This is useful if you’re using Twitter Tools to pull tweets into your blog, but you want to display excerpts from your regular posts.
Well, I found it useful.



Styling WordPress posts according to their mood
Leon — Sat, 04 Apr 2009 21:14:05 +0000
Well, it’s been a long time since the last post. Combination of reasons: busy at work work, some client work and the wife getting a promotion and more work work work. We’re working class, us.
There is, of course, the great God Twitter devouring my creative juices, or rather diverting them into 140 character missives. I love Twitter for many reasons: it’s a sort of whispering underground, an ever–flowing communication stream (of effluence, sometimes, but still…)
There’s another Twitter–influenced post (and site overhaul) in the offing, but in the meantime, there have been two WordPress problems and solutions that I’ve been working on recently. I’ll share the first with you in this post, namely:
Changing page styling by adding an ID to the body tag
I’m in the process of overhauling my personal site and one thing I’m looking at is styling index and single pages according to the mood of the post that’s being displayed.
The easiest way to do this is to add an ID to the page’s body tag. As the body tag is the daddy of all other tags (HTML is grandpa, but we leave him well alone), prefixing CSS declarations with body#id_name will override any previous declarations.
Let’s say I fancy a gothic feel to my page and want to override my default h2 setting. I’d add the following below my original h2 declaration:
body#gothic h2 {color: red; font-size: 72px; font-family: garamond, baskerville, times, georgia, serif;} /* gothic styling! */


The problem is getting WordPress to spit out  in the HTML. Custom fields provide the answer:
Adding a custom mood field to WordPress - note: don't use spaces
Now I have a bit of text I can use as an ID, I need to get wordpress to insert it into the relevant file (which can be any template file). First, I begin my loop and grab the text from the database:


ID, 'mood', true); ?>
Then I add it to my body tag:

When WordPress gets round to rendering the page, it’ll spit out:

A pretty simple process (and not limited to gothic styling, but I’m guessing you’d figured that out). The only odd thing is starting your loop before the body tag: but that has zero effect on anything really. I’ve created a page that shows the technique in action (view the CSS to see how the override works).
NB: If you’re running a site with lots of traffic and bandwidth is an issue you need to beware of a proliferating stylesheet. You’ll have a default set of declarations (so you don’t have to style every post separately) and each ‘mood’ will have its own set. On the other hand, if (like me) you’re low on fancy imagery, you’re operating efficiently anyway.



Fancy transparencies with rgba
Leon — Fri, 06 Mar 2009 14:17:40 +0000
Transparency is not something I’ve used much in the past, probably because it traditionally involves messing around with images (which is not really my thing: I’m a textual type).
But CSS does allow authors to apply transparency to textual components, and I’ve recently discovered the rgba value. I like rgba because it doesn’t use any browser specific syntax, and it’s very logical.

See an example of rgba in action
Download the zipped HTML, CSS and image files

What’s rgba?
Like the rgb value, three numbers are used to reference the red, green and blue elements of any given colour. rgba accepts an additonal value (the a, or alpha value) which determines how transparent the colour is on a scale of 0-1 (1 being opaque). So a black, half transparent colour would be set with rgba(0,0,0,0.5).
This is not a picture of me
This value can be applied to any selector. Combined with the :hover pseudo class, authors can create some pretty effects without messing around with actual images.
How my example works
It’s basically a huge link with a background image. The default background color is normal, opaque yellow (hex FFD100), but the a:hover background value has been set to rgba(259,209,0,0.5) (i.e. the same yellow with 50% transparency). The additional text only changes to black when it’s hovered over: the default state is yellow.
Unfortunately, only Firefox and Safari accept the rgba value. You can make other browsers degrade gracefully by setting a traditional background colour  value  above the rgba value. Unsurprisingly, IE makes a pig’s ear of it by trying to do something, and failing. I therefore had to use a separate IE style sheet to get it working properly: overkill, perhaps, but it’s the only way I could get it to work.
What could you use it for?
Erm, I’m not sure. Surprise images aren’t great from a usability point of view, and it can be quite annoying accidentally making images appear as you mouse across the page. I quite like the idea of a blog front page where titles are displayed in this way. When the reader hovers over the title the image reveals itself, perhaps along with a summary of the post. I’d love to hear of any ideas you have, or any examples of it in the real world.



Horizontal navbars: CSS/HTML how-to
Leon — Tue, 23 Dec 2008 09:23:38 +0000
Here’s how I’ve been implementing horizontal navbars (note: only tested in FF3 and IE7 at this moment):
The problem
We want a navbar that:

is horizontal
shows the reader where in the site they are
indicates where the reader is about to go by changing the style of a hovered–over link
doesn’t use any unnecessary divs

See a demo of my horizontal navbar.
Horizontal navbar
The code
Our HTML couldn’t be cleaner and simpler—no meaningless divs, just semantic classes for the ul and the selected link:


	Home
	About
	Journal
	Portfolio


And the CSS:
ul.nav {
	height: 2em;
	text-transform: lowercase;
	font-variant: small-caps;
	letter-spacing: 0.1em;
	margin-bottom: 1.5em;
	font-family: lucida grande, liberation sans serif, sans-serif;
	background-color: #efefef;
	color: #333;
}

ul.nav li {
	list-style-type: none;
             float:left;
}

ul.nav li a {
	float: left;
	width: 10em;
	text-align: center;
	line-height: 2em;
	background-color: #efefef;
	color: #333;
	text-decoration: none;
	border-right: 0.0625em solid #333;
}

ul.nav li a:hover, ul.nav li.current {
	float: left;
	width: 10em;
	text-align: center;
	line-height: 2em;
	background-color: #ffd100;
	color: #333;
	text-decoration: none;
	border-right: 0.0625em solid #333;
}
You can, of course, play around with the colours and fonts.
How it works
The real magic is in the height and line-height properties: as long as the ul height is the same as the li line-height we can ensure that the borders that separate the nav links match the height of the background bar.
Have a very merry Christmas!



Paragraphs on the web: a typographical guide
Leon — Sat, 11 Oct 2008 12:11:59 +0000
With thanks to Stefan Vervoort and his article on paragraphs, which gave me the idea for this article.
What’s a paragraph?
It seems a simple question, but as with so many fundamental questions giving a concise answer can be tricky.
Well, a paragraph isn’t a sign or a clue as to your content in the same way that headings are. Paragraphs are your content: the flow of ideas and the development of your argument.
Which means that you owe your readers respect when it comes to setting your paragraphs; readability is absolutely paramount, especially when you’re dealing in lots of text — when writing a blog, for example.
An example of an indented paragraph from an old text
Making paragraphs readable in 5 steps
We need to think about 5 things when we set paragraphs on the web, all of which can be controlled using CSS:

Font choice and size
Colour
White space: this includes line-height, line width, margins, letter-spacing and word-spacing
Alignment
Boundaries, indents, outdents and versals


Font choice and size
I’ll talk about the effect different fonts create in a future article. What I’m interested in here is legibility. Of the web safe fonts, Times looks cramped at ‘normal’ font sizes, and is only worth using in headings. Monospace fonts such as Courier and Lucida Console denote code and are therefore generally inappropriate for body copy (unless you’re making a lo–contrast statement).
Traditionally, serif fonts (such as Georgia and Times) were seen as conducive to print reading while sans serif fonts (such as Arial, Helvetica and Lucida) were seen as appropriate for the screen. Either is fine, but it is worth bearing in mind what fonts work at what size. Verdana was specifically designed to be used at small sizes, so it is a sensible choice at, say, 10 pixels. Georgia looks pale and indistinct at 12 pixels and below, but up it to 16 pixels and it looks great.
Of course, we don’t want to inflict small fonts on our readers, regardless of their age (so just because your readers are all hawk–eyed young designers who prefer to look at neatly aligned blocks of text rather than messy, real text, it doesn’t mean you can get away with 8 pixel Helvetica).
I would suggest a minimum font size of 14 pixels for paragraphs. I generally use 16 pixels. Of course, we should be allowing readers to select their own size by using relative sizing units. This is what I use on this blog:

body {
font-size: 100%;
}

p       {
font-size: 1em;
font-family: helvetica, arial, nimbus sans, sans serif;
}

Colour
We need to consider contrast and glare when selecting colours for our paragraphs. Regardless of your reader’s eyesight, every reader will appreciate distinct text that doesn’t give them a migraine. Some choices are obviously poor, but you can be sure by running some objective checks. I use the Colour Contrast Analyser extension for Firefox. Of course, some of this is just personal preference: white/near white on black will pass any contrast test, but it is not, in my opinion, conducive to reading long swathes of text.
Here’s the CSS I use:

body {
color: #444;
background-color: #fff;
}

White space
White (or negative) space need not, of course, be white. It is the space both around and within paragraphs, and can help your reader keep his or her place within the text, while not having to worry about accidentally straying into adjacent content.
I’ve written pretty extensively on line height before; suffice to say that it’s worth changing the browser default setting of 120% of the paragraph font size. Anything between 140% and 170% is good, although bigger font sizes don’t require as much line height as smaller.
CSS allows some fine tuning of the white space between letters and words. Applying letter spacing to headings can often provide some interesting effects, but it’s rare to see either property applied to paragraphs. These settings have become so conventional that any change has a marked effect upon a page, as you can see at the Contrast.ie blog. Interestingly, additional letter-spacing has been applied to the body selector: it creates a bold, confident effect, which perhaps links to the firm’s own image. It’s a very original approach that would require a lot of care to implement well.
CSS also allows us to control the space between and around paragraphs. In some print material, a new paragraph is marked by an indent, but on the screen the convention is to insert a space between paragraphs (although some sites attempt to introduce a ‘bookish’ variation, which unfortunately makes reading from a screen difficult. It’s good to see that The New Yorker has taken my advice and inserted line breaks between paragraphs. If it ups the font size and changes the font to Georgia it’ll be there!) It is logical to make the space between paragraphs the equivalent of a single line, as this maintains the vertical rhythm of the text on the page.
Ensuring that there is space around a paragraph is a matter of overall page design and element placement. One good way to ensure that this happens is to keep sidebar lists to a reasonable length, while making the content part of your page the widest element on the screen. Of course, it is also necessary to ensure that the width of your paragraphs (also known as the measure) is neither too long (so the eye loses its place within a line of text) nor too short (so that the eye has to jump up and down the page too often). The optimum measure is around 10-15 words.
There’s quite a lot to bear in mind when setting paragraphs and white space. This is my typical CSS:

body {
width: 57em; /* probably 912px */
font-size: 100%;
line-height: 1.5em; /* this ensures everything has the same line-height */
}

p {
width: 30em; /* measure therefore 10-15 words, width over half the body width */
font-size: 1em;
margin-bottom: 1.5em; /* same as document leading */
}

If you are thinking of using a smaller font size for paragraphs (say 0.875em) then you’ll need to resize the bottom margin, so as to maintain the vertical rhythm set in your body selector. It needs a calculator, but it’s quite simple: simply divide the line height by the element font size. So if we have a body line height of 1.5em and a font size of 0.875em, then the sum is 1.5/0.875, or p {margin-bottom: 1.714em;}
Alignment
This is easy. Browsers don’t justify text very well, so you’re best off using flush left, ragged right alignment. This is what browsers default to, so it doesn’t need to be set. If you must use justified paragraphs, the CSS is simple: text-align: justify;. In my experience, serifs justify better than sans serifs and the wider the measure the better.
Boundaries, indents, outdents and versals
Jon Tan has written a wonderful article on achieving some fancy effects when setting paragraphs. What I want to concentrate on here is how we can implement these largely unexplored areas.
CSS offers us a range of pseudo–selectors with which to alter the way in which the opening line or letter of a paragraph (or any element) is presented:
:first-letter allows us to style the first letter of a paragraph, while :first-line allows us to target the (you’ve guessed it) first line. So, you could use something like:

p:first-letter {
font-weight: bold;
font-size: 1.5em;
}

which would make the first letter of every paragraph bolder and bigger. We obviously need a way in which to target specific paragraphs. There are 2 possible approaches:

Apply first letter or first line styling to paragraphs that have been given a particular class. We could target an intro paragraph class with p.intro:first-letter {font-weight: bold; font-size: 1.5em;}, and leave our other paragraphs alone.
Sometimes we can’t target paragraphs that have been assigned a class. For example, when we simply want to target the first line of a blog article. The way round this is to use adjacent selectors. So if we have wrapped our article in an id entitled #article and we knew that the first paragraph always followed an h2 or an img preceded by an h2, then #article h2 + p:first-line, #article h2 + img + p:first-line {font-variant: small-caps;} will make sure that only the first paragraph is targetted.


This is quite complicated CSS, so let’s give a complete example. Let’s say you want to make the first letter of every blog article 3em bold and the first line small-caps. Here’s what you’d do:

HTML:

Artcile title
Paragraphs are lovely.  Beautiful.  And I want you to appreciate their beauty.
The thing about them, though, is that they take a bit of thought.


CSS:
#article h2 + p:first-letter {
font-size: 3em;
font-weight: bold;
line-height: 1em;
}

#article h2 + p:first-line {
font-variant: small-caps;
}


The use of these pseudo-selectors opens up a wide range of possibilities for styling paragraphs. Jon Tan’s article goes some way in exploring them: the rest will be down to some experimentation.

Conclusions
I’ve provided an example of some reasonably fancy paragraphing. Feel free to peruse the HTML and CSS.
As you can see, there’s quite a lot to think about when setting paragraphs on the web. As ever, CSS offers a concise, simple and easy–to–understand method for implementing our ideas. What do you think? How do you go about setting paragraphs?



Image replacement: problems when words are pictures (part 1)
Leon — Sun, 17 Aug 2008 11:47:30 +0000
Image replacement is used when a designer wants to use non-web safe fonts. Part 1 of this article looks at the disadvantages of replacing marked-up text with images.
When it comes to designing websites, designers can choose from the following fonts (and this ignores users with a Linux variant installed on their PC):

Times
Helvetica/Arial
Verdana
Georgia
Trebuchet
Lucida

Of course, this can prove limiting, especially when a designer comes from a print background, where font choice is limited only by the designer’s ability to purchase new fonts. Fonts can express the author’s personality, structure information and aid readabilty.
So designers have a choice:

Accept the situation and carry on with the 6 fonts listed above, or;
Replace text with images of text.

Problems with image replacement
The font's garamond italic - but an image of words is meaningless to screen readers

Workload
Instead of simply wrapping headings in h1–h6 tags designers have to create them using imaging software. Even if this is automated, the process of entering the text into an application, copying the resultant markup tag and pasting it into an HTML document is relatively laborious. Using the SIFR method requires even more work.
The heading text can’t be copied
Let’s say I want to copy an article from a website, paste it into a word-processing document and format it for printing. This is simple when copying from an HTML document with plain textual headings. On the other hand, if images have replaced text, I couldn’t reformat the heading: in fact, if background images have been used I wouldn’t have any headings to edit at all.
Images cause accessibility issues
Without visual cues such as bolding and colour, screen readers rely on the structure of a document to derive meaning from it. As an image is not a heading it has an inappropriarte meaning to a screen reader. The Firefox screen reader emulator extension Fangs demonstrates this quite clearly.
Let’s take this simple example of a heading marked up using a standard h1 tag:

Text should be text, not pictures

This is what Fangs outputs:

Page has one heading and no links An example of a heading dash Internet Explorer Heading level one Text should be text, not pictures


Heading list: Text should be text, not pictures: 1

Let’s replace the h1 tag with an image:



This is what Fangs outputs (i.e. what a screen reader would say):

An example of an image used as a heading dash Internet Explorer Graphic This is the top level heading of this document

The headings list is empty
Google won’t like you
Search engines approach HTML documents in the same way as screen readers; they use structure to derive meaning. In order to ascertain what a document is about (and its subsequent appearance in search query listings), Google will look at the page’s title and h tags and weight them accordingly. Alt tags are useful as they will tell Google what meaning an image is conveying, but a heading occupies a higher level within a document’s hierarchy.

Designers therefore use several methods to overcome these problems. I’ll discuss these in Part 2 of this article.
If you liked this article, you might also be interested in 5 web design sins from the experts.



Writing great articles: anatomy of a BBC news story
Leon — Wed, 13 Aug 2008 11:04:41 +0000
I refer specifically to a news story about US swimmer Michael Phelps. Not all of the techniques apply to all forms of web writing, but many do, and most can be adapted in some way to make articles more readable.
BBC News story layout
What the BBC does so well:
The article takes up most of the screen
The BBC news website underwent a recent redesign. Unlike the BBC home page’s redesign, this was an unqualified success. The page uses a 6 column grid, 5 of which are dedicated to the article itself – which means the reader’s attention is fixed firmly on the story.
Emphasis and colour aren’t overdone
The headline is clearly indicated by a simple change in font and font size
Headings are indicated by a larger font size and a slightly different font face (24 pixel Arial as opposed to the 13 pixel Verdana used for body copy). These simple typographical alterations serve to indicate the purpose of the heading without distracting from a large quanitity of content: the designers chose not to use colour or bolding. Similarly, links are a conventional blue, making their purpose immeadiately clear. Using blue allows the BBC to avoid underlines: lots of underlined links can distract the reader from the content.
Reading is comfortable
The article’s copy occupies 3 of the page’s 6 columns, which results in a measure of 10-15 words. The leading is set to 140% of the paragraph font size, which is 14 pixels. These settings ensure the reader’s eye isn’t stretched across the page or up and down lines in order to locate their position within the text.
The heading tells you what the story is about in 5 words
No humour, punning or alliteration – just 5 words that tell you who, where and what.
The article is interactive
The story includes video
The first element readers encounter after the headline isn’t a paragraph; it’s a video, with an enticing play button placed slap bang in the middle of it. This is not a passive text – readers are encouraged to do things rather than absorb large swathes of text. Similarly, readers are offered a wide range of links to click and explore, and another video further down the text.
Links are contextual
The links are relevant to the story content
More contextual links, this time to other news providers
A BBC logo placed top left provides the only universal link on the page – everything else is related to the current story, encouraging the reader to follow a narrative through the site. Even the left–hand sidebar alters according to the page’s content, acting as a sort of vertical breadcrumb. The right–hand sidebar offers a wide range of links related directly to the story; firstly, a list of BBC headlines (again, all informative and less than 5 words long), secondly a list of external sites and lastly links to related stories from other news providers.
The use of contextual links further aids the interactivity of the site by offering readers choices related to what they are currently reading, rather than a universal, unrelated links list. This makes perfect sense; for example, readers are unlikely to follow a link to the BBC Proms season from this page.
The article uses a standfirst
A standfirst is the first, summative sentence of a story. Convention dictates that it is bolded, which attracts the reader’s eye. It serves as a polite summary of the story, which allows him or her to decide whether to continue reading the text. It is usually found in tabloid newspapers, and the BBC story follows several other conventions of tabloid writing.
Short paragraphs, complex sentences
Most of the paragraphs in the story consist of just 1 sentence, never more than 2. Again, this serves to break the text up and thereby make reading easier. More discursive articles will require more than 1 sentence per paragraph, but keeping paragraphs short is an excellent convention, even if it means using some complex sentence structures.
Pull quotes
An example of a pull quote
A pull quote is a quote that is literally pulled from the main body of the text. It is often, but doesn’t have to be, from a person involved in the story. Its purpose is manifold: it provides both ‘human interest’ and typographical variation — in the BBC story it has a different background colour from the main body copy and employs a simple graphic. The BBC enhances the pull quote in this article by making it a link to a message board, once again making the story as interactive as possible, and adding a feeling of inclusion.
Critcism
Criticisms are minor, but I would perhaps use a conventional, horizontal breadcrumb to help users locate themselves within the BBC’s website as a whole. I’d also emphasise keywords in order to further aid readers through large blocks of text. Finally, I’d up the font size to 16 pixels in order to make the type even more readable.
Summary
The BBC doesn’t use ornamentation to display its content; instead, a thougtful layout, logical typography and attention to sensible writing conventions allow the excellent content to entertain and inform.
If you liked this post, you might want to read about 6 newspaper writing techniques for the web.



When CSS works beautifully
Leon — Mon, 04 Aug 2008 23:57:31 +0000
There are times when CSS is so elegant and logical that you smile. Take this example:
.Pingback .commentmetadata li a:before {
        content: '(This is a pingback or a trackback) 2014 ';
        font-weight: bold;
        color: #444;
}

And it works — it prepends styled content to links that reside in lists that are descended from two parents (the content has grandparents, in effect).
Not in IE, of course.
Sidenote: HTML entities can be added to CSS–generated content, but only using hexadecimal values.