Mike Simmons continues his introduction to web site design for musicians with a more detailed look at the most important HTML tags, and explains how, when and in what form to use graphics on your site. This is the second article in a six‑part series.
Last month we looked at some of the generalities of web site design, and I explained that web pages are constructed by means of something called Hypertext Mark‑up Language (HTML). HTML essentially consists of 'tags' — instructions enclosed in angled brackets within a text document — which tell the browser how a variety of components (text, pictures, and so on) should be displayed. I suggested that although using a piece of authoring software makes web construction a good deal easier, a little knowledge of HTML can be very useful when it comes to troubleshooting or adapting an already existing page.
I also made it clear that while HTML pages have much in common with the sort of documents produced by word processors or desktop publishing packages, there are also important differences. Not the least of these is that though we may have a very clear idea of what we want our web pages to look like, there is no way of guaranteeing that what we want is what other people viewing the site will see: the way in which a web page appears on their screen will be highly dependent on which system they are using and how it is set up. This isn't to suggest that we need to abandon any thoughts of design and aesthetics but, rather, that we need to retain an awareness of this flexibility from the very beginning if our ideas are ever to reach fruition.
Though it might not be apparent to the visitor to a site, every web page is made up of two discrete components — the Header, which is contained within <HEAD> tags, and the Body, which is, not surprisingly, contained within <BODY> tags. The entire page is contained with <HTML> tags — a declaration to the browser that it should treat the contents of the page as HTML.
Consider the following example:
This is the body — the only part of the text that will actually show up on the page.
If you type this out, save it as a text file (it doesn't matter whether the tags are upper or lower case, nor whether you put spaces or carriage returns between them), and then open it in a browser you'll see exactly how it will look.
The header section of a page can contain a variety of information about the page itself, but very little of the text that appears there will be displayed by a browser. The exception to this — and the only text there is in ouexample header — is that text written between the title tags will appear on the title bar of the window displayed by the browser. It's not essential to provide a title for the page, but it generally looks rather more professional, and informative, than the 'Untitled' message that the browser will display if you don't! Other data which may be stored in the head section includes various 'META' tags which, amongst other things, provide information for search engines, thus making your site more likely to attract the attention of the casual inquirer. We'll come back to the META tags, but not this month. Let's get back to the example.
It's unlikely that you'll ever be confronted by anything quite as dull as the body section we've got here, but it still makes the point — for something to appear on your page, you must include it within the body tags. By the way, you'll notice that the second tag in every pair of tags contains a forward slash — this is standard practice, and tells the browser when a particular attribute should be switched off (so to say that something is 'within the body tags' means that it comes between the <BODY> and the </BODY> tags).
It would be quite possible to fill the body section of your page with nothing but text, but it might not look very attractive if you did, and you might find that your visitors didn't stay for very long. One of the things that's made the web what it is today is the facility to add pictures, and that's what we'll look at now.
Links are what makes the web what it is. They link your pages together and, equally important, they link your site to those of other people.
The following piece of HTML...
...Will add a picture (in this case, one called aber2.JPG) to your page. It's perhaps worth being a little more precise in our terminology here, because it won't really add the picture to the page at all, it will simply appear to do so. In order for someone else to see that page as you want them to, they'll need both the file with the HTML code that says <IMG SRC="aber2.JPG">, and the graphic file called aber2.JPG as well — and both will need to be in the same relative position as they are on your own hard drive (see the 'Good Housekeeping' box).
Provided the person viewing the page has a browser that supports graphics, and they haven't turned this facility off, the relevant graphics files will be downloaded and displayed automatically when they view your web page. It would be nice to say that all you need to know is <IMG SRC="filename"> and there's nothing else to it, but sadly this is not the case. We also need to consider how we want the picture to be displayed, how we want it to relate to the text that's also on the page and, most importantly, we also need to consider just how long it will take for the picture to download onto the user's system.
Whatever anybody else may tell you, when it comes to adding pictures to your web site, size really doematter. Though they certainly brighten up a page, pictures also slow down the speed with which that page will load into the browser — and the larger the file size for each picture, the slower things will become. It makes sense then, to make sure that your graphic files are as small as they possibly can be.
If you have access to Adobe's Photoshop or a similar piece of software then you'll have little difficulty here (see the example screenshot on the left). Failing this, there is a wide variety of shareware programs (Graphic Convertor for the Mac and Graphic Workshop for Windows spring to mind) which will fit the bill. Alternatively, the software that comes with most scanners will generally let you save in a wide variety of formats. If you want to transfer pictures on to your web site from prints, drawings or other 'hard‑copy' media, you'll need access to a scanner (though some photographic shops will scan material for you — at a cost!). You don't need an elaborate scanner to get the kind of picture quality required for presentation on a web site, but if you're going to buy one to do other jobs, such as designing your own CD artwork, then it's best to spend a little more on a model that can scan at a resolution of 600dpi (dots per inch) or better. If you're only interested in creating web pictures, then £100 or less may buy you a perfectly serviceable model, but for more serious use, expect to pay upwards of £150.
Whether you're producing illustrations with a graphics program or scanning in your own photographs, just make sure that the quality is as good as it can be, but no better than it need be. There's little point in producing a picture at 300dpi, for example, when most monitors are only capable of displaying a resolution of between 72 and 90dpi. Similarly, your picture may well look at its best when displayed in a format that stores millions of colours — but just how much worse would it look in a 256‑colour palette, which would make for a far smaller file? And what about black and white, which would make it much smaller still?
Two file formatsGIF and JPEG, are the standards used for web graphics (and hence supported by most browsers), and choosing the right one to store your images is also important in keeping file sizes to a minimum, since each uses different compression systems optimised for different types of image. GIF is best for line art or anything else where there are fairly large blocks of a single colour, whereas JPEG is often a better format for more complex images such as photographs. On my own site I use JPEGs for the album covers and various other photographs dotted about, reserving GIFs for various headings I've saved as graphics files and a few other sundries. If you're not sure which is best for a particular image, save the file as a GIF and see what it looks like and how big the file is. Then compare it with the same image saved as a JPEG.
Once you've decided on your file type you may, depending on your graphics package, be able to reduce the size of your file even more. JPEGs can be saved at different levels of compression; the greater the level of compression, the more degraded the image is likely to become. However, it can take a keen eye to notice on a computer screen what would be startlingly obvious on a printed page. Similarly, the size of GIFs can be minimised by reducing the number of colours in the palette used to reproduce them. There's nothing wrong with a bit of trial and error here as long as you remember the one golden rule — if it looks good enough on a monitor then it's probably good enough. (Oh, and the other one — do all that tinkering on a copy of the graphics file rather than the original. Some of it is irreversible, so if you haven't got a copy to fall back on you may well be stuck!)
It's worth mentioning that there are a number of pieces of software which will help to optimise your images for the web, the inestimable Fireworks probably being the most popular. If you really want to reduce the size of your graphics files to an absolute minimum then this is the software for you, but it's not cheap and you may want to see how well you can do on your own before making such an investment. The only real price you'll pay for doing this is paid in time. Just remember though, a picture may well be worth a thousand words, but however small you make it, it'll still take an awful lot longer to load!
Once your graphic file is as small as it can be then you can bring it onto your page with that IMG SRC tag. There are, however, a few more things to think about. Consider the following piece of HTML:
<IMG SRC="lleyn2.jpg" WIDTH="365" HEIGHT="244" ALT="cottage">
First you'll see that the file 'lleyn2.jpg' is called onto the page, in just the same way that we called up 'aber2.JPG' in our previous example, but now the size of the image is also specified. By doing this we tell the user's browser what to expect, and so allow it to display the page rather more quickly. The measurements are in pixels and, if you are using authoring software, the data is likely to be inserted automatically. If you're coding by hand then you should be able to get the dimensions from your graphics package. In point of fact we could make the image much smaller, or bigger, than its normal size simply by altering those figures but, as we shall see, doing this is not without its implications.
So what about that ALT "cottage"? It's worth bearing in mind that not every browser displays pictures, and that not every user of more modern browsers chooses to have that option switched on. The ALT text is what is displayed in place of the image while it is loading, or instead of the image if the browser has not been configured to show them. It is also what is read out by text‑to‑speech software on browsers used by the visually impaired. In addition, some browsers will display the ALT text as a 'tool tip' if the cursor is held over the displayed image.
One further piece of HTML: try inserting an image into a page and then typing in some ordinary text. View what you've done in a browser and you'll see the picture displayed first with the text beneath it. But what if you want the text beside the image? Insert an "Align" command as follows:
<IMG SRC="lleyn2.jpg" WIDTH="365" HEIGHT="244" ALIGN="left" ALT="cottage">
And now you'll see the text running all the way down beside the image. I'll leave you to guess what happens if you try ALIGN="right"!
Links are what makes the web what it is. They link your pages together and, equally importantly, they link your site to those of other people. The simplest way to make a link is to make part of the text a link point — thus clicking on the phrase 'My Best Chum' could take us to a page entitled 'My Best Chum', while clicking on the words 'Home Page' could take us back to the home page. Creating such a link is a very straightforward process in any authoring package, and generally involves highlighting the word or words, clicking on some sort of 'make link' icon, and then steering through the file menus to select the file you want to link to. The HTML for our example above, however, would be:
<A HREF="chum.HTML">My Best Chum</A>.
The text that forms the link ('My Best Chum', in this case), need not be related to the name of the actual linked file (simply called 'Chum.HTML' in this example, perhaps in order to comply with the ISP's server's naming requirements). In this example, the link would take the user to the start of the linked page when clicked. It is, however, perfectly possible to create a link that takes the browser to a specific section of a page — either a different page, as in the above example, or a different section within the same page. With web pages that contain a lot of organised text, such as FAQ (Frequently Asked Questions) pages, for instance, it's common practice to have an index at the start of the page that consists of a set of links to other sections of the same page — so the person viewing the page can either scroll down the page to reach a particular section, or jump to it directly from the index.
Creating a link to a specific part of a web page is slightly more complicated, in that you need to put another tag at the place in the page you want to link to. So, supposing we wanted to link from our first page to a specific point in the 'My Best Chum' page, we would need to 'name' that point by inserting a tag like this:
In order to link to this named tag within the 'My Best Chum' page, we would then use the following tag (with appropriate text in the middle):
<A HREF="Chum.HTML#School">My Chum's Schooldays</A>
If we were linking from within the same page — for example, in an index such as I described above — we could leave out the filename:
<A HREF="#School">My Chum's Schooldays</A>
It's also possible to use images as links, but if you're going to do this it's best to keep the images small, because the link won't work until the image has finished loading. One way round this is to have two links on the page, one which uses a word, the other which uses an image. I've used this technique on my own site. As I've already mentioned, part of my home page shows a picture of each of the album covers, and each of these images acts as a link that takes the browser to the page relating to that album. Underneath the picture is the title of the album, however, and this has also been linked to the page.
Using an image as a link is also employed in a system called 'thumbnails', where a very small image is used as a link to a much larger version of the same picture. In this way, those who want access to the full‑sized version can get it, but those who don't only have to wait for the thumbnail to load.
A word of warning here, however. As we have seen, it's possible to determine the size of an image on a web page simply by specifying its width and height when we bring it onto the page. So, if we have called up an image with a piece of HTML like:
<IMG SRC="lleyn2.jpg" WIDTH="365" HEIGHT="244">
...it would be possible to produce a much smaller image with something like:
<IMG SRC="lleyn2.jpg" WIDTH="183" HEIGHT="122">
But this would only be a smaller image, not a smaller file size, and would consequently take just as long to load as if it were displayed full size. The only way to create a thumbnail is via your graphics package, which will let you reduce the actual file size and then save it under another name. You would then have two versions of the same picture, one much smaller than the other, and could use the former as a link to the latter.
A third way in which you can establish links — and one that I wouldn't even think of without some sort of authoring package — is by creating a Client Side Image Map. This sounds a little complex but basically involves identifying particular 'hot spots' within an image that serve as links to other pages. As with other graphic links, it makes a lot of sense to supply a second set of (text) links for the user with the slow modem.
One sort of link that's perhaps worth special mention is the email link. If you want your site visitors to send you an email then it's easy enough to insert a piece of text on your page that says something like 'why not email me?' The HTML that would turn the word 'email' into a link that would call up an email page ready addressed to you is simply:
why not <A HREF="mailto:firstname.lastname@example.org">email </A>me?
Where, of course, you'd replace my email address with yours! As always, you're dependent on your visitor and their browser here. If they're using a browser that doesn't support e‑mail, or if they haven't configured the preference pages, then they can click for all they are worth, but nothing will happen!
One thing that every site should have plenty of is links back to the home page. Ideally, they should be in the same position on every page, and they should look the same. Don't turn your site into a mystery tour (unless that's your actual intention) because you want to hold your visitor's attention. If you provide an eccentric navigation system that's difficult to follow your visitors are likely to become frustrated and vote with their feet. Or, at least, their mouse!
So far I've only talked about links within your own site, but equally important — and straightforward — are links to other peoples'. Typing the following into your page:
click <A HREF="www.musicmtn.demon.co.uk">here</A>
...would simply display the words 'click here' in a browser window, with the word 'click' highlighted. Clicking on the word 'here', however, would lead someone straight to my web site. (Please feel free to do this, I need all the help I can get!)
A couple of things are worth considering when you're making links to other people sites. Except in specific circumstances it's wisest to only makes links to the home page of another site and, once you've done so, it's only courtesy (and good sense) to inform the site owners of the fact — they may well make a link back to your site if you do. Making a link to a page deep within someone else's site (www.musicmtn.demon.co.uk/tsnaps/..., for example) means that you'll have a dead link on your site the moment they make any changes that affects the navigation to that page on theirs.
A common feature of all the links that you create is that you're able to make some decisions about what will will happen when your visitor clicks on them.
<A HREF="chum.HTML" TARGET="_self">My Best Chum</A>
...will open that "My Best Chum" page in place of the current page — this is probably what you'll want while visitors are navigating around your site, and is how most browsers will respond if they are given no target information. This, on the other hand:
<A HREF="chum.HTML" TARGET="_blank">My Best Chum</A>
...will open the 'My Best Chum' page in a new window in the browser, leaving the existing page still oen in the window behind it. The advantage of this is that the user is more likely to return to the first page — a point worth considering when you're setting up links to other people's sites.
It might also be worth considering exactly what rationale you'll use for creating links to other sites. It's your site after all, and there's nothing stopping you creating links to 'my favourite football team', 'my favourite film', 'my favourite hamburger joint' and so on ad infinitum. It's just worth wondering how many people actually follow those links, and why they should want to follow them. Think about why they visit your site and what would have attracted them to it. Then think about links that relate to that attraction. My first couple of albums, for example, relate to the Lleyn Peninsula of North Wales. On the pages relating to those albums I've established as many links to sites devoted to North Wales as I can find. On the page for my most recent album Compositions of Stone (shameless plug) I've presented links to a variety of excellent sites dedicated to Standing Stones, Stone Circles and Alignments of Stone — and so it goes on.
Next month, we'll be looking at ways in which you can get greater control over text and images and start making the whole site rather more attractive. Until then, this is the time to start building — but don't forget to keep things in the right folders!
When you've completed your site (or at least got it in a good enough state to publish it as a first edition) you'll beam it up to your ISP's server. Until then you'll be building the site on your own computer. The more work you do, the more files you'll accumulate — one for every page, one for every picture, one for every sound file, and so on. If you're a methodical kind of person you'll immediately start by creating a series of folders for each type of file. Alternatively, you may have them strewn all over your desktop, intending to tidy them up later. The moment you do tidy them up you'll be in for a bit of a surprise, because every link you make will have been broken! Let's look at that <IMG SRC="aber2.JPG"> again. Besides anything else, it tells us that the image file is in the same folder/directory as the page file.
Alternatively, <IMG SRC="pictures/aber2.JPG"> would tell us that the image file is in a folder called 'pictures', which is in the same folder as the page file. Part of the HTML is a path, telling the browser where to find the picture. If you move that picture into another folder then it simply won't be able to find the file. However, provided you make sure the path to the file is always correct, it won't matter if you continue to edit the file, nor does it matter if you replace it with another file of the same name. What this means is that if you start off with a series of folders before you start constructing your site you're likely to avoid a lot of extra work later on.
Some authoring programs manage the whole site for you and won't let you make this kind of mistake. Others will, however — and I speak from experience! It's probably worth mentioning at this point that all your file names must consist of no more than eight letters (plus extender). For Mac users — and PC users whose operating systems have finally caught up with Macs — this can come as something as a shock, but the ISP's server may well not recognise a file with a name like 'My First Album Cover', however sensible that name might seem to you.