modulus blog

Google vice-president of search product and user experience, Marissa Mayer made an interesting observation recently, when speaking of on-line newspapers:

I can go to various newspapers and when you scroll down to the bottom, what do you do next? There were related stories and related videos but those were up on the top. So now the most committed user – the one that reads through the entire piece – is now looking at the bottom of the page with nothing to do.

It is well worth while looking at each of your web pages with the specific aim of ensuring that there is something engaging to reward your most committed site visitors, at the end of each article, at the bottom of each page. This is especially true for longer articles or pages.

When specifying text size in HTML markup by way of the font-size attribute in CSS, the units used can be either absolute or relative. Absolute units (such as pixels) mean that the website designer retains more control over the appearance of the page, but that requests from web browsers for larger or smaller sizes will be ignored. When relative sizes are used (such as ems or percentages) some additional testing is needed to ensure that the page does not become illegible or jumbled at large and small point sizes, but the degree of convenience offered to those whose vision is less than 100% is, in my opinion, well worth the extra five minutes of testing. Furthermore, relative sizing allows for both automatic and manual adjustment of the font size on devices such as mobile ‘phones.

I visited 40 randomly-selected websites and checked each for compliance with requests from the web browser to increase or decrease the text size (note that this is not the “zoom” function present in some browsers, it should affect text only. The results are as follows:

“Full” means that all text on the site resizes as requested by the browser, and that the end result is still legible.

“Partial” compliance means that while much of the text might resize as requested, some of it does not (or the site becomes illegible due to text overlaps); the most common symptom here is menu text which stays at the same fixed size.

“None” means that, apart from some minor and accidental spacing changes, none of the text responds to requests for size changes.

In Internet terms, a “captcha” is a “Completely Automated Public Turing test to tell Computers and Humans Apart”, i.e. one of those images which requires you to replicate the text in order to pass to some next step, such as submitting a comment. The idea of captchas is not without its problems; for the disabled it can be a complete barrier to site access. Even for people without disabilities, entering some random alpha-numeric characters which have been deliberately distorted can be difficult.

Here are five examples of captchas which I consider to be quite difficult to get right:

Over-simplification of captchas can mean that they can potentially be solved by computers. However, in the vast majority of cases the “treasure” protected by a captcha is not of sufficient worth to bother trying to break the security by OCR or artificial intelligence techniques. Indeed, for the vast majority of sites using a captcha, the enemy is a simple-minded spambot.

One approach I’m trialling at the moment is to use text that is not composed of random alpha-numeric characters, but is a valid English word, randomly selected from a largish subset of English words. We want a set of words of moderate length (say 6-9 characters) and which are reasonably familiar to most readers. We can, for example, use the names of vegetables; these names are reasonably familiar to most site visitors, tend to be about the right length and, consequently, a human site visitor has a much higher chance of typing in the right text in repsonse to a word like “spinach”, whilst very little advantage is conferred to the simple-minded spambot by the fact that the word is a familiar English word. The use of real words decreases confusion between the letters “l”, “i” and “1″, as we
know that “spinach” is spelled with an “i”, not a “1″ or “l”.

Here is what I’m trialling at the moment:

This approach does reduce security and could be broken by a sophisticated program which combined image processing capability with dictionary lookup, but that doesn’t really concern me, as I am not using captchas to protect anything more valuable than the right to leave a comment in a guestbook or send an email.

introduction

The way in which people read text has been extensively studied since the 19th century, yet when one looks for definitive information on choosing an appropriate line-length for a website for optimum legibility, a wide range of conclusions is found. Recent experiments have shown that on-screen reading speed increases with longer line lengths (testing in the range 35 – 95 characters per line). Other experiments have shown that line length had little effect on readability, but that readability was substantially affected by the size of the surrounding white-space margins, with large margins substantially enhancing readability. Another recent experiment showed that margins slow reading speed, but increase comprehension. These studies are not necessarily conflicting; taken together they indicate that line length itself is not as key as might have been thought, but providing adequate white-space margins (which, coincidentally, will somewhat decrease line length) is important to comprehension, which is even more important to a commercial website than reading speed.

My local newspaper (The Age) uses a principal layout comprising eight columns, each only 45 mm. wide, which results in 28 – 34 characters per line – so short that, in combination with the fact that the text is justified, about 15% of lines end in a hyphen.

Unlike a newspaper or magazine, which has a set size combined with a set font and font size, the website visitor has a high degree of control over properly-designed websites and can change the overall size, text size, font size and even font family. This degree of flexibility more or less rules out hyphenation of text, which, in contrast with newspapers and magazines means that very narrow columns work less well.

Justification (i.e. where inter-word padding is inserted to make all lines equal in measured length) is the rule rather than the exception in books, magazines and newspapers, but the exception rather than the rule on websites. Justification looks much better when combined with hyphenation, and is therefore less appropriate for websites. In addition, only a limited range of browsers support justification.

techniques

The simplest and cleanest way to ensure that you have adequate white-space margins around text is to set the margins directly in CSS e.g.
margin-left: 15%;
margin-right: 15%
etc.

Note that it is preferable to set these margins as percentages of the available width (rather than absolute values) so that they adjust appropriately when the page is resized. Most websites will, however, be more complex in their layout and we must also bear in mind that “white-space” is not necessarily unoccupied.

Setting CSS to justify text (text-align: justify;) or to right-justify text (text-align: right;) works with Mozilla Firefox 2.0.0.13 and its cousin Netscape Navigator 8.0.4. With Internet Explorer 6.0.28
or Opera 9.27, these justifications can be made to work, but the inheritance mechanism in their CSS implementations is not correct and so each element that is to be justified (other than the default ‘left’) has to have the justification specifically set i.e.
body {text-align: justify;}
may not be sufficient, you may need, for example,
body {text-align: justify;}
td {text-align: justify;}
to reliably achieve the justification.

This article is an extract from the “Saffron Book” (Good Practice for Commercial Website Design) available for on-line purchase at e-books.