O what a tangled web we weave

Citation

Ellis, B. (1999), "O what a tangled web we weave", Microelectronics International, Vol. 16 No. 1. https://doi.org/10.1108/mi.1999.21816aaa.002

O what a tangled web we weave

O what a tangled web we weave

Even today, with the Internet well established, it is astonishing how many Web sites are user-unfriendly. Ideally, every page should load within a few seconds. In the developed nations, we often forget that the bandwidth of "Internauts" in developing countries may be quite limited. It is therefore logical that, if you want an international audience, you should do everything within your power to ensure that pages within your site are as small as possible.

As a rough rule of thumb, with reasonably good telephone line modem connections at 28.8kbs, every kilobyte of data takes an average of one second to download, including establishing and reestablishing the connections. With poor connections, as are common in some countries, or when the net is very busy, it may average twice, thrice or more as long.

The logical corollary is that, if your home page totals 100kb, nobody will wait a minute-and-a-half or more while it downloads. If the visitors cannot see where they want to go within a few seconds, they will go elsewhere: this may mean to the competitors if you have a commercial site or it may mean they will give up trying altogether. Large home pages are therefore a disservice to the owners.

Here are a few hints to help yourselves and your visitors (if you yourself are not responsible for your company's site but feel that there may be relevance in this list, pass it on to the company Webmaster or design bureau, please):

• •

  Above all, keep the home page as simple and graphics-free as possible: this is the one which may determine whether someone will stay on your site or not.

• •

  Try to keep all pages as simple as possible with few sub-files, minimal graphics and no frames.

• •

  If you feel the need to have a very graphics-intensive site, offer an alternative no-frames, no-graphics sub-site, with just the essential text.

• •

  If you do use frames, and the viewer's browser does not support frames, do not tell him simply to get a better browser; he will not see anything you have written; shunt him immediately to a no-frames sub-site. Better still, offer those with the capability of a frames-compatible browser to browse within the no-frames site. Many prefer it as being faster.

• •

  If you must have a heavy graphics file in a page (i.e. more than 10kb), put in a small thumbnail image which the viewer can click on to see the large version, if he wishes to. Ideally, tell the viewer how big the file will be ("Click on this thumbnail to see all the details of our gizmo [85kb]").

• •

  Some pages have too much text. If you have a page with more than 30 or 40kb of text, see whether you can split it up into a number of sub-pages. Warn navigators if a page is necessarily large (>35kb total) within the menu or hyperlink.

• •

  Filter out irrelevant or repetitive graphics.

• •

  Steer away from unnecessary "gadgets" which require lengthy scripts or other non-HTML devices. These are often useless in terms of information, except to slow down, quite unnecessarily, the viewing of the site. You can be too clever, by half!

• •

  Never include a hit counter or other device which requires automatic on line access to a third party site.

• •

  Do not include large files as backgrounds.

• •

  Make sure that you restrict the colour scales to a minimum: you can reduce the size of many GIF and JPG graphics by using 256 colour palettes (or even 16) without the quality noticeably suffering ­ do not be afraid of experimenting.

• •

  Ensure that your GIF and JPG images have a resolution not higher than 75 dots per inch. Your visitors will rarely gain any benefit with a higher resolution. Rescale your images to exactly the size you want them to appear before saving the graphics files: do not resize them on the Web page.

• •

  Do not include sound or, worse, video files within your ordinary pages. If you need to embed them, use thumbnails with appropriate warnings to activate them on a separate page.

• •

  If you use some sophisticated WYSIWYG Web-page editors, check that there is not a heavy overhead of unnecessary repetitions. For example, some of them may repeat all the details of fonts, font sizes, colour and so on at the start of every paragraph of body text, even though nothing has changed. Delete all that is superfluous, including the </p> tags.

• •

  If you use editors that offer the use of server extensions (e.g. Microsoft FrontPage) be aware of the important overheads that some of the more sophisticated features impose.

• •

  Check that your pages look as you intend with several different browsers: the fancy feature that costs you an extra 5kb of file space may not work the same with Microsoft Internet Explorer 4.01 as it does with Netscape Communicator 4.5 and different again with Netscape Navigator 2.01.

• •

  Do not use status line scrolling: this is rarely impressive, it is more distracting and annoying as the movement is frequently irregular.

• •

  Above all, Netscape Communicator has a very useful tool (Microsoft Internet Explorer does not seem to have an equivalent) which will tell you what the overheads on any page are. Right-click on any page or frame and select View (Frame) Info. You will see a split window. In the top half, you will see every file that is called on that page. In the bottom half, you will see all the basic details of the main page file, including the size ("Content Length"). By clicking down all the files in the top half, you can add up the total of the files used in that particular page.

• •

  Finally, and by no means least, make sure your server has sufficient bandwidth to meet the demand, whether it is in-house or through a service provider. It is no use whatsoever using your own server if you cannot connect directly into the Internet backbone through a good optical link, if you expect more than one visitor at a time. There is nothing more frustrating for your precious client to see that the page he is wanting to look at is downloading at 28 bits per second when he knows full well that his connection is capable of speeds a thousand times faster or more. This happens only too often and, believe me, it is a very false economy if you lose customers. (This problem also occurs with third party service providers which offer free or low-cost hosting, especially to popular ­ read here XXX ­ sites: avoid them like the plague!) Related to this but, unfortunately, less easy to deal with other than complain, is the problem of national bandwidth. Some countries, especially those with a nationalised or monopolised telecommunications system, have the bandwidth between their subscribers and the Internet backbone which limits the speed of transfers, especially at peak periods. This can slow down downloading horrendously. The only advice I have for frustrated visitors is to try again in off-peak periods (I find that, in Europe, the best time is between about 0400 and 0600 hours GMT when all good Europeans and Americans should be doing better things than bunging up the Internet with their traffic!).

I do not claim that any of the numerous sites I have designed meet all these tenets (do what I say, not what I do!), but I do try to keep them in mind, within the limits of the practical. For example, "my" site at http://www.protonique.com is, by no means, perfect (the cobbler's children go unshod), but it is not as bad as many. For example, the home page is less than 6kb altogether and offers the choice of going to the rest of the site in either graphics or non-graphics form. The graphics sub-Web home page is possibly among the most heavily graphics-intensive page on the site, with an image of the globe at 7,596 bytes and 12 graphics menu-buttons at about 350 bytes each, but the total is about 37kb, which I admit is very hefty. On the other hand, the text-only sub-Web home page, which offers exactly the same information, menus etc. is only 8kb, so I can argue that visitors can choose if the connection is poor or their patience is running out.

At this stage, dear reader, you may be asking what kind of fly has bitten Brian? Well, I will let you into a little secret. For those of you who are my assiduous fans (both of you), you may remember that the very first of these columns was devoted to the IMAPS Web site, at that time under the ISHM URL. Of course, life being what it is, the ISHM Web site was replaced by the IMAPS one before it appeared in print. I will not say that this was a conspiracy to make me look like a nitwit. Anyway, you will perhaps remember that I complained about the long downloading times of some of the pages, so I thought I would have another look to see whether, under its new banner, it had improved (Figure 1). I am sorry to report that it has gone down the drain, even further, in trumps. Believe it or not, on three separate occasions when examining this site at http://www.imaps.org it took me between three and five minutes to fully download the home page, in two frames, totalling ­ wait for it ­ 166kb, through their impossibly slow server, sometimes running at under 100 bps. And what did this home page show for it? A washed out background image consisting of a collage of an oval-framed giant panda (I thought it was a football at first), a sailing boat and a mission-style church on a sky-blue fond. Alone, this was 44kb. At first glance, this seemed totally irrelevant to microelectronics until I saw the light: the next International Systems Packaging Symposium, in January, will be held in San Diego. Bad enough, it reduced the legibility of the blue text superimposed over the blue background. Worse, the left hand part of the screen was devoted to a small menu frame. The globe at the top, alone, took up some 50-odd kb and each of the buttons required a 5kb download, even though this was ten times more than necessary (they were drafted at about three times natural size and saved in a 24 bit colour format). Altogether, I am sure that this home page could be reduced to about 1/3 of its current aggregate file size without losing a jot of information or pizzazz. It requires just a little bit of thought. Many of the other pages were similarly wasteful or badly designed.

Figure 1IMAPS home page

Now, I am going to give away a little secret that most visitors to the site would not guess or find out. Instead of going to their home page, type in http://www.imaps.org/noframe.html as the URL. It gives exactly the same information as the home page for a total of less than 40kb (less than one-quarter of their "real" home page) and over one-third of this is an advertisement for Microsoft Internet Explorer (14.6kb)! Furthermore, you can link in to any of the child pages from there at a faster download time. It is really worth it, believe me. There is one caveat: use the "Back" button of the browser to return to this page, because pressing any "Home Page" button will take you straight back to the heavily frames-intensive and graphics-intensive pages. Of course, if your browser allows you to switch off viewing frames, you can automatically achieve the same results.

I would seriously suggest the IMAPS Webmaster may care to consider working through his site with the above list of bullets in mind. If he cares to e-mail me, I'll even help him to improve the site and make it faster and more user-friendly, should he get stuck. I make no apology for what may seem as a harsh criticism because I believe it is in the interests of IMAPS to buckle down to a better image.

Oh! I nearly forgot! The contents of the site! As I recollect it, not a great deal has altered since I reviewed it in 1997, other than the contemporary material of forthcoming events and suchlike, of course. It is difficult to know what a cross betweena trade organisation and a learned society should put on a Web site. Perhaps a little less on the organisational side and a little more technical information such as technical press releases or even articles may attract more visitors, but this is perhaps purely personal. I was a little astonished to read through the list of corporate members: indeed impressive but the astonishing thing is they all seem to have a hyperlink to their respective Web sites ­ surely a Web site is not a prerequisite for membership, is it? Anyway, I'll select some of these at random for future issues of this commentary: Webmasters, to your keyboards!

*	Site appearance*
*	Site content ***

Sites mentioned:http://www.protonique.comhttp://www.imaps.orghttp://www.imaps.org/noframe.html

Brian EllisMosfiloti, Cypruse-mail: mi-comment@protonique.com