The User Experience in Text

We put so much effort into the pictures, graphics, layout, and the buttons and other objects in our web designs, that it can be all too easy to overlook the simple text content, and how it is displayed. The user experience can be affected, for better or worse, by apparently quite minor aspects of text layout.

The particular factor I am thinking of right now is the number of words on a line. Most of us are already quite familiar with the fact that overly long lines of text - as, for instance, lines allowed to spread right across the full width of a modern desktop screen - can be quite wearisome to read.

At the opposite end of the scale, however, it is also possible to have lines that are too short, with too few words per line. This also makes reading long portions of text quite a tedious exercise. Yet there are many web sites out there showing exactly this problem. Particularly on small screens, even for supposedly Responsive sites, and especially when the user is using text zoom.

An Example

Consider, for instance, the following passage of text, taken from Treasure Island:

He was a very silent man by custom. All day he hung round the cove or upon the cliffs with a brass telescope; all evening he sat in a corner of the parlour next the fire and drank rum and water very strong. Mostly he would not speak when spoken to, only look up sudden and fierce and blow through his nose like a fog-horn; and we and the people who came about our house soon learned to let him be. Every day when he came back from his stroll he would ask if any seafaring men had gone by along the road. At first we thought it was the want of company of his own kind that made him ask this question, but at last we began to see he was desirous to avoid them. When a seaman did put up at the Admiral Benbow (as now and then some did, making by the coast road for Bristol) he would look in at him through the curtained door before he entered the parlour; and he was always sure to be as silent as a mouse when any such was present.

Here the text is nicely readable. It is displayed with an average of 10 - 12 words per line (using a fixed 30em width). But now look at the next portion from the same passage, but shown in a very narrow column allowing only 2 or 3 words per line. You will likely find it quite annoying, having to drop to the next line so frequently.

You may well have found yourself paying so much attention to dropping down to find the start of the next line, that you got less of the sense of the words than you did with the first passage.

It is clear that we need longer lines to make the reading experience pleasanter and less tedious. It doesn't matter so much for single sentences of just a line or two, though even they can lose their import if split too oddly. But such overly short lines certainly impede the experience if the users are expected to read large portions of text.

In this example we also see another problem - an unusually long word in such a narrow column can actually be too long for the space available (ok, I cheated, I joined "silver fourpennies" into one word purely to demonstrate the problem, but there are many real words longer than that). Very long words are liable to overflow their container into the next column.

So we must ensure lines of text are not too short. My personal view is that seven words per line is about the very minimum to have for any long piece of text.

Accessible User Experience

However, even when we think we have made the text wide enough initially, if we consider accessibility, and what poor-sighted people do in their browsers to make the text readable, we realise that the problem may not actually have been solved.

Such users may well be using the "Zoom Text Only" option available in most browsers. The advantage to the user of this option, as opposed to simply zooming the whole page is, of course, that the entire page remains within the window boundaries without having to scroll back and forth with scroll bars. For responsively developed pages it does not matter, but responsive design is still relatively new and the vast majority of web sites are still non-responsive. So many people prefer to use this browser option wherever possible.

Unfortunately, at larger text sizes, a line of 6 words in normal text size suddenly becomes just 2 or 3 words on being enlarged. So if we decide that the minimum umber of words per line should be 6 or 7, we had better actually allow for 10 - 12 words in the default medium font size, to allow for larger text sizes to still stay above 6 words per line.

It is therefore important to

• a) consider what happens to text, at different amounts of zoom, in narrow columns or containers and design for it beforehand
• b) when testing our pages, do extra tests using a large text-only zoom setting

W3C require that pages should cope with zooming up to 200%, so that is the text-only zoom setting we should use in testing, paying special attention to any narrow lines or passages of text.

And Containers

Another facet of text design is that, if we specify a width and/or height for a container that holds text, consider specifying it in em units, not px units. This will ensure the container adjusts to the size of text zoom in use, becoming larger if the user is using a larger size of text.

It means that a particular line of text will hold the same number of words (i.e. wrap the line at the same point in each line) regardless of the size of text in use. View the boxes round my Treasure Island examples above, at different sizes of text-only zoom in your browser, and you will see this is true.

This may not always be necessary, or even possible, of course; sometimes we can let the text re-wrap according to text size. But using em units is absolutely mandatory if both width and height are specified to make a fixed size container; otherwise the text will overflow the bottom of the container at large text sizes - a sight quite often seen, and very ugly it is too when it happens. Poor-sighted users should be treated better than that!

Text Headings

Another, related problem becomes apparent when we have long headings in narrow columns. The larger font of a heading may break it up into three or four lines of just one or two words each, even while the ordinary text underneath has a sensible words per line average. However, where the breaks occur can make quite a difference between the heading looking good, and being readily understood, or looking somewhat strange and not so easy to comprehend.

It is a matter of good looks, and an indefinable sense of what looks meaningful, as opposed to what looks ugly and somewhat jumbled. It's the difference that makes for good or bad user experience. Compare these two headings:

Both contain the same words, but only the first heading looks good. The second one has a meaningless "a" hanging off the end of the first line; it not only looks a bit strange, it also fails to continue the flow of meaning of the heading. The first example manages that flow better; ending the first line with "a book by" immediately tells the user, "Oh yes, I'm about to learn who wrote this book Treasure Island". So even as they are dropping their gaze to look for the second line, they already know they are looking for a person's name.

Consideration of this factor of both looks and meaning will help us to ensure our headings split across lines in sensible places. We might even decide to reword the heading in such a way that it looks good however it is split.

And What About Responsive Pages?

A few weeks ago (on 3 Aug) I made a post in this blog, "Accessible Responsiveness", about media queries in responsive pages. There I mentioned the possible problems that can arise when the media query breakpoint is specified in the usual px units that most tutorials encourage.

If we carefully set the breakpoint to avoid columns of text becoming narrower than, say, 6 or 7 words per line on average, our careful work is immediately undone if the user is running in a high text-only zoom. It is the same problem described above - a line of 5 or 6 words in standard text size becoming just 2 or 3 words at 200% zoom.

For those of you who haven't seen that post (or were doing something more useful at the time!) the solution I mentioned in that post is quite simple. Just set media query breakpoints in em units rather than pixels. Problem solved.

Fixing the Text Size

And finally, there are far too many web sites created where the size of text has been fixed in the CSS, for instance using font-size: medium. Sadly some frameworks, such as Bootstrap, are bad for this, but many hand coded sites are written that way as well.

The problem with doing this is that some browsers cannot then zoom the text size. Internet Explorer is the main culprit, of course (at least up to v11; it remains to be seen if future versions will change that). It has the unfortunate trait of obeying the developer too literally when they specify a fixed text size. It won't, then, allow text-only zoom at all! Other browsers, such as Firefox, are more rational, and will override the developer's fixed size when the user has specified a text-only zoom.

Unfortunately IE is still the most popular browser be virtue of being bundled with the Windows operating system. It's easy to say people with poor eyesight should obtain another browser, but many ordinary people don't know how, and have got attached to using IE by the time they find out. Giving the user a good experience means doing it for the tools they have, not forcing them to go and get another tool before they can see our work!

Conclusion

They say a picture is worth a thousand words, but if we have to write the thousand words we must give attention to how we display them!

References:

• The passage from Treasusre Island was copied from the online version at Project Gutenberg