Principles of friendly web pages
This is the first of a series of pages that present the basic principles of using HTML to create a user-friendly web site. This page is the introduction to the series and defines the principles to be discussed.
Principles of friendly web pages
Making it Best Viewed With Any Browser
Making it Lynx and WannaBe Friendly
Let iCab smile (Macintosh only)
Pay attention to loading times
Don’t expect to get the layout perfect
Don’t assume the user has a huge monitor
Don’t use blinking text, marquees
or distracting images
Don’t describe your site as under construction
Take care in using New!
labels
The structure of an
HTML
document
Refinements: using additional features
Further refinements: improving accessibility
Trouble-shooting: why doesn’t it come out as expected?
Preliminary note. I original wrote these pages in about 1997, and would certainly write many things differently if I were starting from nothing today. The principles haven’t changed since then, but the web itself has changed enormously (not necessarily for the better), and these pages have not yet had the thorough revision that they probably need.
The title of this guide deliberately uses the word friendly
in two ways. It is intended to be
friendly to its readers in the sense that its aim is to present the minimum of
HTML
needed for preparing a page, without going into more detail than necessary. It also sets out to
describe
HTML
that is friendly to its eventual users, which means creating pages that are
intelligible to the maximum number of users, without requiring them to install particular
browsers or use particular kinds of hardware. In other words this guide is intended as a small
contribution to the Best Used with Any Browser campaign.
It is not enough to write in
HTML; one must have something to say
(Y. L.
Peretz)
The guiding principle before creating any web page should be that it needs to have
some content, in other words it needs to provide something that someone somewhere
is going to find useful or interesting. What the writer actually wrote was It is not
enough to write in Yiddish, one must have something to say
. However, I don’t read a
lot of Yiddish and I do read a lot of pages prepared in
HTML; even if I avoid web sites
that previous visits have suggested to contain nothing of interest I still sometimes
find pages that make me wonder what their author was trying to convey to visitors.
Most people do not visit particular web pages in order to admire their brilliant design,
but because they are interested in the information that they contain. For
the academic web user, the possibility of finding useful information provides the only
real reason for surfing the web. If you don’t agree with this analysis then the rest of
this guide is unlikely to be of interest to you.
The time will probably come when you will want to use more advanced features of HTML than are to be found in this guide. A complete list of all the elements available in HTML requires several pages of a textbook, without allowing any space to describe what they mean or how to use them. Yet most of them are rarely used, whereas a relatively small number are used constantly. This guide deals with this relatively small number, i.e. the part of HTML that you need to know before you can begin. With these you can create a perfectly acceptable web page, and you may never need any more. Some of the most widely read pages on the web, such as many of those carrying news group postings, use even fewer elements than those described here, and is doesn’t seem to affect their popularity. Their readers are more interested in their content than in their design. If you do need more, there are abundant sources of more complete information about HTML.
Do you want your pages to be intelligible to the overwhelming majority of people who access them, or just a minority? Do you care whether or not blind or partially sighted people using speech synthesizers will be able to make sense of your pages? The answers may seem obvious, but you may also think that nearly everyone uses the same system as you do for browsing the web and so if your pages look adequate on your screen they will look adequate for the overwhelming majority of users, so why worry.
The essential point is that
there are a lot more different browsers out there than most users realize, and no
one of them accounts for an overwhelming proportion of users. Put somewhat differently,
by no means all people use a browser that is even capable of interpreting the more
fancy features of web pages, and nowhere near all of these users actually allow their
browsers to interpret them: many users disable the automatic loading of images; many disable Java
and Javascript, and so
on. 75% is an optimistic estimate of the proportion
of users able to appreciate the finer points of web design. Slapping the faces of just 1% of
users by sticking a This page looks best if viewed with Internet Explorer 5.0 or higher
icon on
it would be rude and unnecessary enough (Translation: Get yourself a decent browser
if you want to look at my page; otherwise forget it
); slapping the faces of at least 25%
is stupid and counter-productive as well.
None of this means you should not use images to brighten up your pages. It just means that you should take reasonable care to ensure that the images don’t take over the page so completely that it is completely unintelligible to people who see (or hear) only the text. More practically, it means that you should always provide every image with a text alternative to be displayed on browsers that do not display the image itself.
If you ever see a web page bearing the Best Viewed With Any Browser message it means that its author subscribes to the principles set out in the previous section, that the objective of creating a web page is to make its content available to anyone who cares to look at it, without turning away users who don’t use a particular browser. Apart from not demanding a particular browser, a web page designed in accordance with these principles should not expect particular hardware either: not everyone has a fast Ethernet connection; not everyone has a 23-inch monitor capable of displaying a 1800 pixel wide image. Within the limits of what is possible you should examine one’s own pages not only with your own preferred browser, but with others as well. As an absolute minimum you should check new pages with recent versions of both Internet Explorer and Mozilla, but it’s a good idea to supplement these with browsers such as iCab, Opera and Netscape, as well as text-only browsers such as Lynx and WannaBe.
Making a web page friendly to Lynx and WannaBe is not quite the same as saying that it is Best Viewed With Any Browser, as it is more limited. Lynx and WannaBe are text-only browsers with no capacity for displaying images. Lynx has been widely used in the Unix and PC worlds for a long time, but is much less common on the Macintosh. Although WannaBe is still in development it is already a very stable and fast text-only browser for the Macintosh, and admirably fills the gap left by the feeble support for Lynx on the Macintosh.
Some people use these browsers from choice, as a way of
processing web pages much faster than a fully featured browser can do, but others
do so from necessity as they have hardware that is incapable of displaying images
or because they are blind and can only use the textual content of a page. For all these
users, making a page friendly to text-only browsers mainly means including in it some text to
replace
the missing images. Another aspect is not telling users to
Click here
: this instruction assumes the user is navigating with a mouse and selecting
links by clicking the mouse button over the highlighted link. Not everyone uses a mouse
and blind users will not know where here
is.
Although the most popular browsers are quite tolerant of HTML errors, in the sense that they will often display what you intend even if that is not actually what your HTML specifies, this is not really a good thing. First of all, code with errors is at best ambiguous, so if it is interpreted the way you want that just means that a good guess has been made, but if you make readers guess your intentions you cannot be surprised if they sometimes guess wrongly. Second, you have no grounds to complain if the browser you use is updated in such a way that the new version no longer interprets a piece of incorrect HTML in the same way as the version you used for testing it. Third, and most important, you cannot control the browsers that your visitors use, and anyone who uses a browser that expects correct HTML may not be able to read your page if it contains HTML errors.
All of this suggests that you should use a validation service to check the correctness of your HTML. At the end of this page there is an icon like the one at the beginning of this section, which indicates that the page has been checked by the validation service of the World Wide Web Consortium. This is not the only HTML checker that it exists, but it has the advantage of belonging to the organization that defines HTML standards in the first place, so there is a good chance that the information that it supplies is correct. (At least one validation service that I have tried flags HTML like the <a name="w3"></a> at the beginning of this section as an error because it contains no text or image between the opening <a> tag and the closing </a> tag. However, this is not an error.)
If you develop your pages on a Macintosh it’s a good idea to adopt iCab as your standard browser, especially for looking at your own pages. Although this is not (yet!) one of the best known browsers it has a major advantage for the HTML author, namely that it tells you immediately whether it considers your HTML to be valid, thereby saving a trip to the W3C validator. If it does, you will see the smiling icon shown on the left above, for example (I hope) if you look at this page with iCab. Nearly all pages you visit, however, will produce one of the other two icons: the unhappy one in the middle if iCab identifies definitely invalid HTML, or the neutral one on the right if there are no actual errors but some warnings are needed. When I have checked, iCab usually agrees with the W3C validator about what is valid and what is not, and on the rare occasions where they disagree a case can usually be made for arguing that iCab’s interpretation is the correct one.
Unfortunately iCab’s development over the past two years has been painfully slow, and I have been tempted to remove the preceding paragraph until version 3 appears, which will, all its users hope, show some of the urgently needed revision.
Not everyone has a high speed Ethernet link to the net, and even if they did the time
required to load an image-laden page from across the ocean would still often cause
the user to lose interest before it arrived. There are several ways of minimizing the
danger that the user will press the STOP button and request a different page before
yours has arrived:
A web browser is not a word-processor; still less is it a page-layout program coupled to a high-resolution printer. It is impossible to design a web page so that it will look exactly the way you want, regardless of the browser and hardware that are being used to view it. Even if the user has the same browser as you installed on the same model of computer connected to the same type of monitor there is no reason to expect the page to look the same because users can set their preferred fonts to override whatever may be expected by the author, they can choose their preferred colours for links, and so on.
It follows that devoting a large amount of effort getting the appearance of a page
just right
is largely a waste of time. Even if you succeed for your preferred browser
on a particular computer there is no certainty that the next version of the browser
will not interpret some tags differently and change greatly the appearance. Consider the following
example (which was prepared in 1997, so the browsers it compares are no longer widely used,
but no matter: the principles have not changed):
The black and grey portions are enlarged from screen shots of the different ways
that three different browsers interpret exactly the same
HTML
code on the same
computer (the blue parts are annotations added by hand afterwards). The bottom
line shows what one particular user (me) considers to be the ideal way of presenting
the two fragments. Notice that none of the three browsers manages to place an italic
word symmetrically between the roman words on either side, and none of them manages
to place a subscript snugly next to the symbol it qualifies. Notice also that what was then the most recent
(and state-of-the-art
, if you like that sort of thing) of the three browsers did the
worst job of it. Perhaps most important, notice the huge difference between two
different versions of the same browser. This means that even if you went to a great deal
of trouble getting your pages to look just right
with Netscape 4.0 there was no guarantee
that they won’t look quite different now that Internet Explorer has become the most popular browser.
There are two incidental comments to make about this example. The first is that Km is a symbol used quite often in biochemistry, but the point has wider relevance, because similar symbols are needed in many sciences, i.e. symbols that consist of a letter in italics with a subscript that is not in italics. The other is that the example was worked out when Netscape 4 was rapidly becoming the most popular browser, and if I were doing it now I should doubtless give more emphasis to Internet Explorer. Updating the example now would miss much of the point, however, which is not that Netscape Navigator 4.0 did a bad job of rendering HTML (true though that may be), but that no browser, either now or in the foreseeable future, renders a web page in a precisely definable way.
Your own tests of the example used here may look quite different, and indeed the
same comparison made with a TrueType font on a PC
rather than a Postscript font on
a Macintosh showed Netscape 4.0 is a less unfavourable light. Nonetheless, it was not
a deliberately unfair comparison, in the sense that it involved the font and computer
that I habitually used at the time, and I only made it because I was trying to understand the huge
change (for the worse!) in the appearance of certain pages that I noticed after I upgraded
from Netscape
3 to Netscape 4. For completeness, the code used to generate the page from which the
enlargements were made was as follows:
<p>An example of some normal text with a word in
<i>italics</I> and another in <b>bold</B> within it.
Notice how the word in <i>italics</I> is shifted with
respect to the rest of the text. Now examine an italic
symbol with a roman subscript: <i>K</I><SUB>m</SUB>.
(In the original
HTML
there is <b>no space</B> between
the <i>K</I> and the <SUB>m</SUB>).
and your browser renders it like this on your computer (don’t be surprised if it looks quite
different from all of the three examples illustrated above):
An example of some normal text with a word in italics and another in bold within it. Notice how the word in italics is shifted with respect to the rest of the text. Now examine an italic symbol with a roman subscript: Km. (In the original HTML there is no space between the K and the m).
Not everyone has a 23 inch monitor, and even people who do don’t necessarily want
to fill it completely with your 23 inch image. If you plan your page to look acceptable
at a width of about 550 pixels it will be acceptable for most users, but better still don’t assume
any standard width at all. Some will claim that allowing users to look at pages at whatever sizes
suit them inhibits the design of a professional looking site. Personally I’m not too interested in
designing such a site, but in any case easy resizing is not incompatible with a the look
of a commercial site.
marqueesor distracting images
Back in 1997, I thought that there were few things more irritating to the user than blinking text, and no good reasons for using it. I still think there is no good reason for using it, but now one sees other monstrosities that are even worse. You will not find any information in this guide about how to make text blink, or move, or how to do distracting things with images.
under construction
Many web pages are decorated with little images like road-works signs,
declaring that the site in question is under construction
. These images are
more irritating than anything else, but are made even more objectionable by
the fact that the claim they make is rarely true. Most pages that bear them
remain exactly the same for months or even years on end (if you look
carefully you will often find some additional information such as Last
update: 17 September 2000
on pages that are claimed to be under
construction
). By contrast, pages that are actively maintained by their
authors are changing constantly and are thus permanently under construction,
but such pages rarely carry under construction
notices. It follows that
the notice usually means exactly the opposite of what it says and denotes
a site whose author lost interest in it half-way through preparing it.
New!labels
Many web pages are likewise decorated with little banners declaring that particular entries are
NEW!
. These labels are less irritating than
under construction
signs, because they are
sometimes true and may even be useful. However, they need to be used with care. If you really
maintain your site, weeding out obsolete information immediately and adding new information with
reasonable frequency, then it may be helpful to your readers to indicate which entries are new. You
cannot decide this when you first open your web site, because you don’t know at that stage how
efficient you are going to be, but if it has been in existence for a few months and you have kept
it continuously up to date and believe you will go on doing so, then by all means add
NEW!
labels. Each such label, however, should have a lifetime of no more than a few weeks.
If you maintain a page that regular visitors come back to every few days, then the lifetime should be much shorter, even as little as a day or two.
Numerous programs are now available that in principle take the work
out of creating a web page as they operate more or less like word processors
and don’t require you to work directly with the
HTML
code that they generate.
These programs fulfil a function, but most web authors continue to prefer to
write their own
HTML, for several reasons: