| 6 |
Run Ragged |
You care about typography, right? Do you care about words and how they look, read, and are understood? If you pick up a book or magazine, you notice the moment something is out of place: an orphan, rivers within paragraphs of justified prose, or caps masquerading as small caps. So why, I ask you, is your stance any different on the web?
We’re told time and time again that as a person who makes websites we have to get comfortable with our lack of control. On the web, this is a feature, not a bug. But that doesn’t mean we have to lower our standards, or not strive for the same amount of typographic craft of our print-based cousins. We shouldn’t leave good typesetting at the door because we can’t control the line length.
When I typeset books, I’d spend hours manipulating the text to create a pleasurable flow from line to line. A key aspect of this is manicuring the right rag — the vertical line of words on ranged-left text. Maximising the space available, but ensuring there are no line breaks or orphaned words that disrupt the flow of reading. Setting a right rag relies on a bunch of guidelines — or as I was first taught to call them, violations!
Violation 1. Never break a line immediately following a preposition
Prepositions are important, frequently used words in English. They link nouns, pronouns and other words together in a sentence. And links should not be broken if you can help it. Ending a line on a preposition breaks the join from one word to another and forces the reader to work harder joining two words over two lines.
For example:
The container is for the butter
The preposition here is for and shows the relationship between the butter and the container. If this were typeset on a line and the line break was after the word for, then the reader would have to carry that through to the next line. The sentence would not flow.
There are lots of prepositions in English – about 150 – but only 70 or so in use.
Violation 2. Never break a line immediately following a dash
A dash — either an em-dash or en-dash — can be used as a pause in the reading, or as used here, a point at which you introduce something that is not within the flow of the sentence. Like an aside. Ending with a pause on the end of the line would have the same effect as ending on a preposition. It disrupts the flow of reading.
Violation 3. No small words at the end of a line
Don’t end a line with small words. Most of these will actually be covered by violation №1. But there will be exceptions. My general rule of thumb here is not to leave words of two or three letters at the end of a line.
Violation 4. Hyphenation
In print, hyphens are used at the end of lines to join words broken over a line break. Mostly, this is used in justified body text, and no doubt you will be used to seeing it in newspapers or novels. A good rule of thumb is to not allow more than two consecutive lines to end with a hyphen.
On the web, of course, we can use the CSS hyphens property. It’s reasonably supported with the exception of Chrome. Of course, it works best when combined with justified text to retain the neat right margin.
Violation 5. Don’t break emphasised phrases of three or fewer words
If you have a few words emphasised, for example:
He calls this problem definition escalation
…then try not to break the line among them. It’s important the reader reads through all the words as a group.
How do we do all of that on the web?
All of those guidelines are relatively easy to implement in print. But what about the web? Where content is poured into a template from a CMS? Well, there are things we can do. Meet your new friend, the non-breaking space, or as you may know them: .
The guidelines above are all based on one decision for the typesetter: when should the line break?
We can simply run through a body of text and add the based on these sets of questions:
Are there any prepositions in the text? If so, add a after them.
Are there any dashes? If so, add a after them.
Are there any words of fewer than three characters that you haven’t already added spaces to? If so, add a after them.
Are there any emphasised groups of words either two or three words long? If so, add a in between them.
For a short piece of text, this isn’t a big problem. But for longer bodies of text, this is a bit arduous. Also, as I said, lots of websites use a CMS and just dump the text into a template. What then? We can’t expect our content creators to manually manicure a right rag based on these guidelines. In this instance, we really need things to be automatic.
There isn’t any reason why we can’t just pass the question of when to break the line straight to the browser by way of a script which compares the text against a set of rules. In plain English, this script could be to scan the text for:
Prepositions. If found, add after them.
Dashes. If found, add after them.
Words fewer than three characters long that aren’t prepositions. If found, add after them.
Emphasised phrases of up to three words in length. If found, add between all of the words.
And there we have it.
A note on fluidity
An important consideration of this script is that it doesn’t scan the text to see what is at the end of a line. It just looks for prepositions, dashes, words fewer than three characters long, and emphasised words within paragraphs and applies the accordingly regardless of where the thing lives. This is because in a fluid layout a word might appear in the beginning, middle or the end of a line depending on the width of the browser. And we want it to behave in the right way when it does find itself at the end.
See it in action!
My friend and colleague, Nathan Ford, has written a small JavaScript called Ragadjust that does all of this automatically. The script loops through a webpage, compares the text against the conditions, and then inserts in the places that violate the conditions above.
You can get the script from GitHub and see it in action on my own website.
Some caveats
As my friend Jon Tan says, “There are no rules in typography, just good or bad decisions”, and typesetting the right rag is no different.
The guidelines for the violations above are useful for justified text, too. But we need to be careful here. Too stringent adherence to these violations could lead to ugly gaps in our words — called rivers — as the browser forces justification.
The violation regarding short words at the end of sentences is useful for longer line lengths, or measures, of text. When the measure gets shorter, maybe five or six words, then we need to be more forgiving as to what wraps to the next line and what doesn’t. In fact, you can see this happening on my site where I’ve not included a check on the size of the browser window (purposefully, for this demo, of course. Ahem).
This article is about applying these guidelines to English. Some of them will, no doubt, cross over to other languages quite well. But for those languages, like German for instance, where longer words tend to be in more frequent use, then some of the rules may result in a poor right rag.
Marginal gains
In 2007, I spoke with Richard Rutter at SXSW on web typography. In that talk, Richard and I made a point that good typographic design — on the web, in print; anywhere, in fact — relies on small, measurable improvements across an entire body of work. From heading hierarchy to your grid system, every little bit helps. In and of themselves, these little things don’t really mean that much. You may well have read this article, shrugged your shoulders and thought, “Huh. So what?” But these little things, when added up, make a difference. A difference between good typographic design and great typographic design.
Appendix
Preposition whitelist
aboard
about
above
across
after
against
along
amid
among
anti
around
as
at
before
behind
below
beneath
beside
besides
between
beyond
but
by
concerning
considering
despite
down
during
except
excepting
excluding
following
for
from
in
inside
into
like
minus
near
of
off
on
onto
opposite
outside
over
past
per
plus
regarding
round
save
since
than
through
to
toward
towards
under
underneath
unlike
until
up
upon
versus
via
with
within
without |
2013 |
Mark Boulton |
markboulton |
2013-12-24T00:00:00+00:00 |
https://24ways.org/2013/run-ragged/ |
design |
| 102 |
Art Directing with Looking Room |
Using photographic composition techniques to start to art direct on the template-driven web.
Think back to last night. There you are, settled down in front of the TV, watching your favourite soap opera, with nice hot cup of tea in hand. Did you notice – whilst engrossed in the latest love-triangle – that the cameraman has worked very hard to support your eye’s natural movement on-screen? He’s carefully framed individual shots to create balance.
Think back to last week. There you were, sat with your mates watching the big match. Did you notice that the cameraman frames the shot to go with the direction of play? A player moving right will always be framed so that he is on the far left, with plenty of ‘room’ to run into.
Both of these cameramen use a technique called Looking Room, sometimes called Lead Room. Looking Room is the space between the subject (be it a football, or a face), and the edge of the screen. Specifically, Looking Room is the negative space on the side the subject is looking or moving. The great thing is, it’s not just limited to photography, film or television; we can use it in web design too.
Basic Framing
Before we get into Looking Room, and how it applies to web, we need to have a look at some basics of photographic composition.
Many web sites use imagery, or photographs, to enhance the content. But even with professionally shot photographs, without a basic understanding of framing or composition, you can damage how the image is perceived.
A simple, easy way to make photographs more interesting is to fill the frame.
Take this rather mundane photograph of a horse:
A typical point and click affair. But, we can work with this.
By closely cropping, and filling the frame, we can instantly change the mood of the shot.
I’ve also added Looking Room on the right of the horse. This is space that the horse would be walking into. It gives the photograph movement.
Subject, Space, and Movement
Generally speaking, a portrait photograph will have a subject and space around them. Visual interest in portrait photography can come from movement; how the eye moves around the shot. To get the eye moving, the photographer modifies the space around the subject.
Look at this portrait:
The photography has framed the subject on the right, allowing for whitespace, or Looking Room, in the direction the subject is looking. The framing of the subject (1), with the space to the left (2) – the Looking Room – creates movement, shown by the arrow (3).
Note the subject is not framed centrally (shown by the lighter dotted line).
If the photographer had framed the subject with equal space either side, the resulting composition is static, like our horse.
If the photographer framed the subject way over on the left, as she is looking that way, the resulting whitespace on the right leads a very uncomfortable composition.
The root of this discomfort is what the framing is telling our eye to do. The subject, looking to the left, suggests to us that we should do the same. However, the Looking Room on the right is telling our eye to occupy this space. The result is a confusing back and forth.
How Looking Room applies to the web
We can apply the same theory to laying out a web page or application. Taking the three same elements – Subject, Space, and resulting Movement – we can guide a user’s eye to the elements we need to. As designers, or content editors, framing photographs correctly can have a subtle but important effect on how a page is visually scanned. Take this example:
The BBC homepage uses great photography as a way of promoting content. Here, they have cropped the main photograph to guide the user’s eye into the content.
By applying the same theory, the designer or content editor has applied considerable Looking Room (2) to the photograph to create balance with the overall page design, but also to create movement of the user’s eye toward the content (1)
If the image was flipped horizontally. The Looking Room is now on the right. The subject of the photograph is looking off the page, drawing the user’s eye away from the content. Once again, this results in a confusing back and forth as your eye fights its way over to the left of the page.
A little bit of Art Direction
Art Direction can be described as the act or process of managing the visual presentation of content. Art Direction is difficult to do on the web, because content and presentation are, more often than not, separated. But where there are images, and when we know the templates that those images will populate, we can go a little way to bridging the gap between content and presentation.
By understanding the value of framing and Looking Room, and the fact that it extends beyond just a good looking photograph, we can start to see photography playing more of an integral role in the communication of content.
We won’t just be populating templates. We’ll be art directing.
Photo credits:
Portrait by Carsten Tolkmit
Horse by Mike Pedroncelli |
2008 |
Mark Boulton |
markboulton |
2008-12-05T00:00:00+00:00 |
https://24ways.org/2008/art-directing-with-looking-room/ |
design |
| 148 |
Typesetting Tables |
Tables have suffered in recent years on the web. They were used for laying out web pages. Then, following the Web Standards movement, they’ve been renamed by the populous as `data tables’ to ensure that we all know what they’re for. There have been some great tutorials for the designing tables using CSS for presentation and focussing on the semantics in the displaying of data in the correct way. However, typesetting tables is a subtle craft that has hardly had a mention.
Table design can often end up being a technical exercise. What data do we need to display? Where is the data coming from and what form will it take? When was the last time your heard someone talk about lining numerals? Or designing to the reading direction?
Tables are not read like sentences
When a reader looks at, and tries to understand, tabular data, they’re doing a bunch of things at the same time.
Generally, they’re task based; they’re looking for something.
They are reading horizontally AND vertically
Reading a table is not like reading a paragraph in a novel, and therefore shouldn’t be typeset in the same way. Designing tables is information design, it’s functional typography—it’s not a time for eye candy.
Typesetting tables
Typesetting great looking tables is largely an exercise in restraint. Minimal interference with the legibility of the table should be in the forefront of any designers mind.
When I’m designing tables I apply some simple rules:
Plenty of negative space
Use the right typeface
Go easy on the background tones, unless you’re giving reading direction visual emphasis
Design to the reading direction
By way of explanation, here are those rules as applied to the following badly typeset table.
Your default table
This table is a mess. There is no consideration for the person trying to read it. Everything is too tight. The typeface is wrong. It’s flat. A grim table indeed.
Let’s see what we can do about that.
Plenty of negative space
The badly typeset table has been set with default padding. There has been little consideration for the ascenders and descenders in the type interfering with the many horizontal rules.
The first thing we do is remove most of the lines, or rules. You don’t need them – the data in the rows forms its own visual rules. Now, with most of the rules removed, the ones that remain mean something; they are indicating some kind of hierarchy to the help the reader understand what the different table elements mean – in this case the column headings.
Now we need to give the columns and rows more negative space. Note the framing of the column headings. I’m giving them more room at the bottom. This negative space is active—it’s empty for a reason. The extra air in here also gives more hierarchy to the column headings.
Use the right typeface
The default table is set in a serif typeface. This isn’t ideal for a couple of reasons. This serif typeface has a standard set of text numerals. These dip below the baseline and are designed for using figures within text, not on their own. What you need to use is a typeface with lining numerals. These align to the baseline and are more legible when used for tables.
Sans serif typefaces generally have lining numerals. They are also arguably more legible when used in tables.
Go easy on the background tones, unless you’re giving reading direction visual emphasis
We’ve all seen background tones on tables. They have their use, but my feeling is that use should be functional and not decorative.
If you have a table that is long, but only a few columns wide, then alternate row shading isn’t that useful for showing the different lines of data. It’s a common misconception that alternate row shading is to increase legibility on long tables. That’s not the case. Shaded rows are to aid horizontal reading across multiple table columns. On wide tables they are incredibly useful for helping the reader find what they want.
Background tone can also be used to give emphasis to the reading direction. If we want to emphasis a column, that can be given a background tone.
Hierarchy
As I said earlier, people may be reading a table vertically, and horizontally in order to find what they want. Sometimes, especially if the table is complex, we need to give them a helping hand.
Visually emphasising the hierarchy in tables can help the reader scan the data. Column headings are particularly important. Column headings are often what a reader will go to first, so we need to help them understand that the column headings are different to the stuff beneath them, and we also need to give them more visual importance. We can do this by making them bold, giving them ample negative space, or by including a thick rule above them. We can also give the row titles the same level of emphasis.
In addition to background tones, you can give emphasis to reading direction by typesetting those elements in bold. You shouldn’t use italics—with sans serif typefaces the difference is too subtle.
So, there you have it. A couple of simple guidelines to make your tables cleaner and more readable. |
2007 |
Mark Boulton |
markboulton |
2007-12-07T00:00:00+00:00 |
https://24ways.org/2007/typesetting-tables/ |
design |
| 183 |
Designing For The Switch |
For a long time on the web, we’ve been typographically spoilt. Yes, you heard me correctly. Think about it: our computers come with web fonts already installed; fonts that have been designed specifically to work well online and at small size; and fonts that we can be sure other people have too.
Yes, we’ve been spoilt. We don’t need to think about using Verdana, Arial, Georgia or Cambria.
Yet, for a long time now, designers have felt we needed more. We want to choose whatever typeface we feel necessary for our designs. We did bad things along the way in pursuit of this goal such as images for text. Smart people dreamt up tools to help us such as sIFR, or Cufón. Only fairly recently, @font-face is supported in most browsers. The floodgates are opening. It really is the dawn of a new typographic era on the web. And we must tread carefully.
The New Typesetters
Many years ago, before the advent of desktop publishing, if you wanted words set in a particular typeface, you had to go to a Typesetter. A Typesetter, or Compositor, as they were sometimes called, was a person whose job it was to take the written word (in the form of a document or manuscript) and ‘set’ the type in the desired typeface. The designer would chose what typeface they wanted – and all the ligatures, underlines, italics and whatnot – and then scribble all over the manuscript so the typesetter could set the correct type.
Then along came Desktop Publishing and every Tom, Dick and Harry could choose type on their computer and an entire link in the typographic chain was removed within just a few years. Well, that’s progress I guess. That was until six months ago when Typesetting was reborn on the web in the guise of a font service: Typekit.
Typekit – and services like Typekit such as Typotheque, Kernest and the upcoming Fontdeck – are typesetting services for the web. You supply them with your content, in the form of a webpage, and they provide you with some JavaScript to render that webpage in the typeface you’ve specified simply by adding the font name in your CSS file.
Thanks to services like these, font foundries are now talking to create licensing structures to allow us to embed fonts into our web pages legally – which has always been a sticking point in the past. So, finally, us designers can get what we want: whatever typeface we want on the web.
Yes, but… there are hurdles. One of which is the subject of this article.
The differences between Web Fonts and other fonts
Web fonts are different to normal fonts. They differ in a whole bunch of ways, from loose letter spacing to larger x-heights. But perhaps the most notable practical difference is file size. Let’s take a look at one of Typekit’s latest additions from the FontFont library, Meta.
Meta Roman weighs in at 42 KB. This is a fairly typical file size for a single weight of a good font. Now, let’s have a look at Verdana. Verdana is 186 KB. For one weight. The four weight family for Verdana weighs in at 686 KB. Four weights for half a megabyte!? Why so huge?
Well, Verdana has a lot of information packed into its 186 KB. It has the largest hinting data table of any typeface (the information carried by a font that tells it how to align itself to the pixels on your screen). As it has been shipped with Microsoft products since 1996, it has had time to grow to support many, many languages. Along with its cousin, Georgia (283 KB), Verdana was a new breed of typeface. And it’s grown fat.
If really serious web typography takes off – and by that I mean typefaces specifically designed for the screen – then we’re going to see more fonts increase in file size as the font files include more data. So, if you’re embedding a font weighing in at 100 KB, what happens?
The Flash of Unstyled Text
We all remember the Flash of Unstyled Content bug on Internet Explorer, right? That annoying bug that caused a momentary flash of unstyled HTML page. Well, the same thing can happen with embedding fonts using @font-face. An effect called The Flash of Unstyled Text (FOUT), first coined by Paul Irish. Personally, I prefer to call it the Flash of UnTypeset Text (still FOUT), as the text is styled, just not with what you want.
If you embed a typeface in your CSS, then the browser will download that typeface. Typically, browsers differ in the way they handle this procedure.
Firefox and Opera will render the text using the next font in your font stack until the first (embedded) font is loaded. It will then switch to the embedded font.
Webkit takes the approach that you asked for that font so it will wait until it’s completely loaded before showing it you.
In Opera and Firefox, you get a FOUT. In Webkit, you don’t. You wait.
Hang on there. Didn’t I say that good web fonts weigh in considerably more than ‘normal’ fonts? And whilst the browser is downloading the font, the user gets what to look at? Some pictures, background colours and whatever else isn’t HTML? I believe Webkit’s handling of font embedding – as deliberate as it is – is damaging to the practice of font embedding. Why? Well, we can design to a switch in typeface (as jarring as that is for the user), but we can’t design to blank space.
Let’s have a closer look at how we can design to FOUT.
More considered font stacks
We all know that font stacks in CSS are there for when a user doesn’t have a font; the browser will jump to the next one in the stack. Adding embedded fonts into the font stack means that because of FOUT (in gecko and Opera), the user can see a switch, and depending on their connection that switch could happen well into any reading that the user may be doing.
The practicalities of this are that a user could be reading and be towards the end of a line when the paragraph they are reading changes shape. The word they were digesting suddenly changes to three lines down. It’s the online equivalent of someone turning the page for you when you least expect it. So, how can we think about our font stacks slightly differently so we can minimise the switch?
Two years ago, Richard Rutter wrote on this very site about increasing our font stacks. By increasing the font stacks (by using his handy matrix) we can begin to experiment with different typefaces. However, when we embed a typeface, we must look very carefully at the typefaces in the font stack and the relationship between them. Because, previously, the user would not see a switch from one typeface to another, they’d just get either one or the other. Not both. With FOUT, the user sees two typefaces.
By carefully looking at the characteristics of the typefaces you choose, you can minimise the typographic ‘distance’ between the type down the stack. In doing so, you minimise the jarring effect of the switch.
Let’s take a look at an example of how to go about this.
Micro Typography to build better font stacks
Let’s say I want to use a recent edition to Typekit – Meta Serif Book – as my embedded font. My font stack would start like this:
font-family: 'Meta Serif Bold';
Where do you go from here? Well, first, familiarise yourself with Richard’s Font Matrix so you get an idea of what fonts are available for different people. Then start by looking closely at the characters of the embedded font and then compare them to different fonts from the matrix.
When I do this, I’m looking to match type characteristics such as x-height, contrast (the thickness and thinness of strokes), the stress (the angle of contrast) and the shape of the serifs (if the typeface has any).
Using just these simple comparative metrics means you can get to a ‘best fit’ reasonably quickly. And remember, you’re not after an ideal match. You’re after a match that means the switch is less painful for the reader, but also a typeface that carries similar characteristics so your design doesn’t change too much.
Building upon my choice of embedded font, I can quickly build up a stack by comparing letters.
This then creates my ‘best fit’ stack.
This translates to the CSS as:
font-family: 'Meta Serif Bold', 'Lucida Bright', Cambria, Georgia, serif
Following this process, and ending up with considered font stacks, means that we can design to the Flash of UnTypeset Content and ensure that our readers don’t get a diminished experience. |
2009 |
Mark Boulton |
markboulton |
2009-12-16T00:00:00+00:00 |
https://24ways.org/2009/designing-for-the-switch/ |
design |