| Day 2: (More) Advanced HTML [prev] | Home | [next] Days 4-5: Project Management |
This is a summary write-up of material and concepts covered in Day 3 of the Spiders at Work Web Camp. On day 3, we talked about multimedia.
Multimedia is a term that usually refers to image, sound and video formats for the presentation of content. It usually stands in contrast to text-only, which refers to plain (and sometimes formatted) text. Much of the buzz on the internet concerns the use of multimedia for websites; many people are able to comprehend multimedia content more readily than text-only format. Use of multimedia on the web can be at once very rewarding and very challenging for authors; misuse of multimedia content can render a web page inaccessible and useless. It's important to have a grip on the basics before you begin authoring.
In this section, we will explore images, sound and video separately.
We're all familiar with images, and we were introduced to the <img> tag yesterday which allows images to be inserted into a
web page. We explored the syntax of the tag, but now it's time to take a
deeper look at the use of images and the issues they raise.
Images can enhance a web page in many ways. At the most fundamental level, images "spice up" web pages by giving the eye something to hang on to; most people comprehend and absorb images faster than they read text, so a well-designed web page that uses images can convey information extremely efficiently. Skillful use of images can make web pages very attractive and aesthetically pleasing (although some of us greybeards still like the aesthetic of plain text, but we're slowly dying out, so don't worry about us). Furthermore, images can be used to present "look-and-feel" themes that aid users in recognizing and navigating your site; logos and icons are powerful conveyors of meaning.
Like all good things, images come at a price, and their overuse can quickly sour a page or a whole site. These are some of the problems that can result from image use:
For reasons we'll explain below, images are much larger than plain text in terms of file size and transmission size. This means that every image you use on a page slows down the speed at which the page will become visible to your audience. Don't rely on your readers to be willing to wait for graphics-heavy pages to download; many people are still using slow modems for their internet connections.
Although this is less of a problem than it used to be, it's still important to be aware of the wide range of systems out there in use that may have difficulty with your images' size, resolution, color range, or storage format - any incompatibilities of which may render your image in a manner ranging from slightly off to absolutely unrecognizable. We'll discuss this below.
It's easy to give in to the temptation, once you get rolling, of using images for everything. It seems to be a stage web authors go through, and it's easy to recognize pages done by authors in that stage: pages crammed solidly with images, background images and wallpaper, animated icons and so forth. If it were possible to step from a tranquil meadow directly into a blaring Las Vegas strip on a Friday night, it would create much the same impression as a graphics-heavy page where the author is enjoying spraying graphics and glitz everywhere. Moderation in all things, remember.
That said, however, most people (authors and readers alike) consider the use of images to be essential on modern web pages, for good reasons:
Eye fatigue is something to take seriously. Text-heavy pages can become tiring to readers. For all of the reasons that images work in print, they also work on the web.
Images help to convey meaning, which we now know works its way into our brains in many different ways. Especially so-called "visual thinkers" find images an essential tool for comprehension, but most people experience the immediacy of image absorbtion as a satisfying way to enhance their understanding of a written piece.
Well-planned sites use images with themes throughout, such as familiar images for logos, buttons and navigation tools; this is essential to developing the intangible "look-and-feel" of a successful site. Pages designed with consistency help comprehension, and images can be a big part of this.
Let's move forward and look at what images are.
At their most fundamental level, images may be thought of as grids, like a sheet of graph paper, with each small box filled in with one color. The choices available for colors depend on something called the bit depth of the image; the greater the bit depth, the greater the range of available colors. Black and white images are said to have a bit depth of 1 pixel: each pixel can be either on or off. Photographic images often have bit depths of 32 bits, where each pixel has a range of 4,294,967,296 available colors; that's a heavy box of crayons, to be sure.
In some image formats, "transparent" is also an option for a color, meaning the boxes marked as transparent will allow color to "soak through" from the image or colors below it.
All images, regardless of their storage type, are rendered as grids when displayed on web pages, for the simple reason that most computer screens and printed pages both also use this technique when it comes to displaying and printing. (The alternative method, known as "vectoring," is generally used for more scientific purposes and is not discussed here.)
To illustrate, we're going to take a small, simple image, and zoom in several steps. This is my nephew munching his first Zwieback toast a couple of weekends ago. We'll zoom in on (one of) those glorious baby blues.
| 1x | 2x | 4x | 8x |
|---|---|---|---|
|
|
|
|
Note that although the first image has smooth photographic tones, as we zoom in, the image gets "blockier" and it's easier to see the individual boxes, or pixels (which stands for "picture elements"). It's similar in some ways to looking at a photograph under a magnifying glass, in that the limits of the resolution become apparant (although the zoom-in effect is somewhat different for traditional photograph printing processes).
The standard resolution for computer screens ranges between 72 and 96 dots per inch (dpi). Modern printers tend to have resolutions between 300 and 1200 dpi, meaning print quality is usually much smoother than screen quality (although a printed image will only have as much detail as is stored in its file format; more on this below).
To get a sense of how much space images take up, we need to do a little math. If you are math-phobic, you can gloss over this section with this piece of information: images are much bigger in terms of storage requirements (and this translates directly into download speed for your readers) than text. What follows is an explanation of why this is the case.
Most human beings these days count in base 10 - probably because we have ten fingers (although the ancient Babylonians counted in base 60, and other bases have been used). This means that we have 10 digits in our number system: 0, 1, 2, 3, 4, 5, 6, 7, 8 and 9. When we count, and we run out of digits, we add a column representing our counting base in exponential increments, and start over. In other words, when our "ones" counter reaches 9, we reset it to 0, and increment the next column over. This is a little easier to see if we use "leading zeroes," which we typically omit when writing numbers, as in the following examples:
| Value | 1000's | 100's | 10's | 1's |
|---|---|---|---|---|
| 208 | 0 | 2 | 0 | 8 |
| 209 | 0 | 2 | 0 | 9 |
| 210 | 0 | 2 | 1 | 0 |
Computers think in base 2, however. This means the only digits available are 0 and 1, and then it rolls over. If we count from 1 to 8 in base 2, it looks like this:
| Value | 8's | 4's | 2's | 1's |
|---|---|---|---|---|
| 1 | 0 | 0 | 0 | 1 |
| 2 | 0 | 0 | 1 | 0 |
| 3 | 0 | 0 | 1 | 1 |
| 4 | 0 | 1 | 0 | 0 |
| 5 | 0 | 1 | 0 | 1 |
| 6 | 0 | 1 | 1 | 0 |
| 7 | 0 | 1 | 1 | 1 |
| 8 | 1 | 0 | 0 | 0 |
Last bit of computer jargon: each column in base 2 is called a bit. The basic storage unit for computers is a byte, which is 8 bits. This means that each byte can store a value from 0 to 255; 0 is 00000000; 255 is 11111111 (1 + 2 + 4 + 8 + 16 + 32 + 64 + 128, the values of each column).
In an uncompressed, "raw" format, each pixel of an image needs to be stored. The color of a pixel is expressed with a numeric value; in a black and white image, 1 is white and 0 is black. If an image measures 100 pixels high and 100 pixels wide, then there are 100 x 100 = 10,000 pixels in the image, each storing a value of 0 or 1.
If the image is black and white, then there are only two possible colors, and one bit is sufficient to store the data for one pixel. This means that eight pixels can be stored in a byte (remember, eight bits to a byte). So, we can divide our total number of pixels (10,000) by the number of pixels we can store in a byte (8) to get our image size in bytes: 1,250.
These days, 1,250 bytes is a considered tiny tiny amount of data, trivial to fling around the internet even for users with slow connections. However, it is easy to see that image sizes multiply exponentially. Take a 1000 by 1000 image, instead of 100 by 100, and we suddenly have 1,000,000 pixels instead of 10,000. Now the image requires 125,000 bytes to store, which is getting heavier.
And, of course, you're probably going to use color in your images, and this makes the situation worse. Let's take our original 100x100 image, but instead of black and white, we add colors. If we allow the use of 256 colors, then it is no longer possible to store a pixel (whose color value will now range from 0 to 255, instead of just 0 or 1) in a single bit. In fact, we need a whole byte to store it. All of a sudden, our image is eight times bigger. We divide the number of pixels (10,000) by the number of pixels we can store in each byte (1) to get, um, 10,000. Suddenly our image - without changing the size, just the color depth - has grown from 1,250 bytes to 10,000 bytes. Our 1000 by 1000 image would require 1,000,000 bytes now (approximately one megabyte).
Furthermore, depending on your needs, 256 colors might not be enough. For cartoons or simple graphs and charts, it might be adequate, but for rendering photographic images and gradients with much finer ranges of color, 256 colors will look grainy. 16-bit color allows for 65,536 possible color values, but going through the math again shows that 16-bit images are twice the storage size of 8-bit (256-color) images of the same dimensions. Furthermore, some people say that even 16-bit color can appear grainy, and that 32-bit color is really need for realistic photographic images. Now we're up to 32 bits -- 4 bytes -- for each pixel, and our images are starting to get very large very quickly.
To illustrate this a bit more vividly, let's revisit my nephew. The size of this image is 200 pixels by 150 pixels, so there are 30,000 pixels in the image. We'll look at it in four color depths: 32, 8, 4, and 1. Notice how the image changes as we drop the color depth, both in quality and storage size.
| 32 bit | 8 bit | 4 bit | 1 bit | |
|---|---|---|---|---|
| Image |  |
 |
 |
 |
| Size in bytes | 120,000 | 30,000 | 15,000 | 2,750 |
Our rather unpleasant-looking black and white image is 2,750 bytes, which isn't too painful on download times, but is it much use? The 4-bit image isn't much better. At 8 bits, and 30,000 bytes, we're doing better, although the image quality still isn't great. 30,000 bytes is going to take about 20 seconds to download on a 28k modem. Our nice 32-bit image, at 120,000 bytes, will take over a minute -- just for a single image. Imagine a web page with five or six of these, and you see that even a modest web page using half-decent images would be almost useless for modem users.
Fortunately, math comes to our rescue once again, in the form of compression.
They say a picture is worth a thousand words. Would a thousand words suffice to describe my nephew?
Perhaps a poet could take a crack at it and come up with something that would approach doing the job:
The first Zwieback toast
Licked and squeezed repeatedly
Applied to the face.
That doesn't quite capture it, does it? Still, we could make a more concerted go of it. How about an easier one? Can this picture be described in a thousand words?
Yes, it can. In fact, it can be described very precisely in far less than that:
A 200 by 100 white image.
This image contains 20,000 white pixels. Even in black and white, it requires 2,500 bytes to store, and if it were 32-bit color, it would require 80,000 bytes. But the description above is much simpler and far more compact. With that simple description, the image could be recreated far more efficiently than it can be stored.
Compression is the science of giving mathematical descriptions of images that are as compact and concise as it's possible to be. Because, as we saw above, uncompressed images can be almost uselessly large, compression is very important. More efficient compression is the holy grail of a hardworking bunch of experts who design graphic file formats; the less space it takes to describe an image, the more efficiently they can be moved around, like on the internet. This translates directly into faster download times and zippier web pages, which is one of the prime directives of any good web author.
There are two general categories of compression: lossy and lossless. Lossy compression is compression that accepts some degradation of the original image as a tradeoff for increased compression ability; lossless compression preserves the original image exactly but may not compress quite as far.
The good news is, most image formats in use on the web are compressed automatically. As you might suspect, there are different sorts of compression algorithms adapted for different tasks, and each image format uses a different sort of compression. Knowing which format is best for your images is an important part of using images on your pages.
We're going to look at the three major formats used for images on the web: JPEG, GIF and PNG.
JPEG (designed by and named for the Joint Photographic Expert Group) is the image format most commonly used for photograph-quality images. Why pontificate on its use and purpose when the JPEG FAQ puts it so concisely?
JPEG is designed for compressing either full-color or gray-scale images of natural, real-world scenes. It works well on photographs, naturalistic artwork, and similar material; not so well on lettering, simple cartoons, or line drawings. JPEG handles only still images, but there is a related standard called MPEG for motion pictures.
JPEG is "lossy," meaning that the decompressed image isn't quite the same as the one you started with. (There are lossless image compression algorithms, but JPEG achieves much greater compression than is possible with lossless methods.) JPEG is designed to exploit known limitations of the human eye, notably the fact that small color changes are perceived less accurately than small changes in brightness.
Pretty advanced compression happening in there. Another neat thing about the JPEG format is that you can set the quality level yourself when you save a JPEG image, on a scale from 0 to 100. Lower quality levels increase the compression rates, making the images' file sizes smaller. There is also, of course, a dropoff in quality.
Here is my nephew again, in JPEG format and this time with JPEG quality ratings of 75, 50, 25 and 0.
| 100 | 75 | 50 | 25 | |
|---|---|---|---|---|
| Image | |
 |
 |
 |
| File size in bytes | 33,062 | 14,656 | 13,401 | 12,511 |
Note especially the dropoff in size and quality between 100 quality and 75 quality. It's hard to tell the difference visually between 100 and 75, but the file size drops by more than half. Note also that the dropoffs in visual quality from 75 to 50 and 25 are much more noticable, but the file size savings are negligible. For this reason, most people consider the 75 to 50 range good thumbnails for images destined for the web.
GIF (Graphics Interchange Format, created by CompuServe) is another very popular format for web-based images. It is a lossless format that does particularly well with images that have narrow color ranges, such as computer-generated diagrams, charts, line drawings, and so forth. It is an 8-bit storage format; this means that a maximum of 256 colors can be used in a GIF image. This makes it unsuitable for photographic images such as JPEG is good with. However, for things like web page buttons, simple logos, and related images, it is far better than JPEG.
Below we compare the look and file size of the 75-quality JPEG image of my nephew, and the same image stored as a GIF:
| 75-quality JPEG | GIF | |
|---|---|---|
| Image | |
|
| File size in bytes | 14,656 | 20,918 |
No surprise: the JPEG looks much better, and it's smaller, too. However, if we examine the brilliant graphic we used in the day 2 writeup, which has a much narrower color range, let's see how the two formats do:
| 75-quality JPEG | GIF | |
|---|---|---|
| Image |  |
 |
| File size in bytes | 2,977 | 546 |
Again, no question about the winner. The GIF image is sharp and lossless, and about 1/6 the size of the JPEG. Furthermore, the JPEG is somewhat distorted, if you look at it closely; the colors have been altered, and there's some clear loss of detail.
There's an important note about the GIF format: its encryption method, LZW, is patented and owned by Unisys Corporation, which recently decided to start charging for its use (after it had been widely used for many years). This has led many people to stop using the format in protest and switch to a newer format, PNG, which was developed in response to the GIF patent problem. Read on.
The new kid on the block of image formats is PNG, for "Portable Network Graphics". PNG was developed as an alternative to GIF that would surpass it in some ways and stay in the public domain. It seems to be a superior format, but older browsers can't display PNG images, so you must weigh the needs of your audience against your concern over the GIF licensing issues. Some people continue to use GIFs and trust that Unisys won't come after them; others are jumping ship to the new platform. PNG is now an official w3 recommendation.
PNG gets around two big limitations of GIF: the patent issue, and the bit-depth restrictions. PNG can store images in up to 48-bit color, even more than JPEG. When comparing 8-bit images, PNG is even a little more efficient than GIF.
Note: The following examples use real PNG images. If you do not see them, then your browser does not support PNG and it's time to upgrade. However, since this site is written in XHTML, you should be using a bleeding-edge browser for best results anyway, right?
GIF vs PNG:
| GIF | PNG | |
|---|---|---|
| Image | |
 |
| File size in bytes | 546 | 402 |
The GIF and PNG images are identical; the PNG image is also about 1/3 smaller and free of licensing issues. Of course, if you can't see it, it isn't much use, but most recent browsers (and all future browsers) handle PNG just fine.
JPEG vs PNG
Although, as we see below, PNG can also handle photographic images just fine, its compression isn't really ideal for the format:
| 75-quality JPEG | PNG | |
|---|---|---|
| Image | |
 |
| File size in bytes | 14,656 | 64,929 |
It's comparable in quality, but over four times bigger. So don't use PNG for photographs, stick with JPEG. Give PNG a good look for replacing GIF, though - eventually, it'll happen because it's a better format and it's free of the Unisys licensing issues.
OK, so we've seen the major image formats used for web pages and internet use. Now: how do we come up with images?
Your basic choices are to create them yourself, or get them from someone else. If you have some artistic talent, nothing beats original work. If you're less talented (like this author), you might see what other sources are out there.
Most people dabble in creating images by hand whether they have talent or not. This is usually done with the use of various sorts of graphics creation and manipulation programs. Many of these are commercial (and some are very expensive); others are free (many, but not all, of these are less powerful than the commercial ones).
It is far beyond the scope of this document to give tutorials in the various programs that are out there. The best bet is to hit a search engine (my favorite at present is Google) and look for, say, "Photoshop tutorial", which will give you a list of results (like this) that you can pick through on your own.
Simple buttons and icons can often be created with inexpensive to free paint programs that come with the major operating systems, like Paint for Windows or xpaint for Linux (although if you're using Linux, you're probably wanting the Gimp, a free and often-superior competitor to Photoshop). Mac users might want to check out GraphicConverter, an inexpensive shareware program with a startling range of features.
The internet is a huge source of images and multimedia files. Essentially, you use someone else's images. There are libraries and collections of free images out there, but like with other forms of intellectual property, you shouldn't just go grabbing images that you like without making sure it's explicitly OK. If in doubt, a polite email to the site maintainer is standard etiquette. Many people will let you use their images with just a simple credit or web link in return.
Consider what form of compensation you might want if people were using your hand-crafted images.
As you might expect, there's a huge demand for free images on the internet, and the marketers have risen to meet the demand. Searches for "free images" in the major search engines tend to bring back results weighted towards clipart cleainghouses crammed with commercials and banner ads that link to each other (they're probably all the same place anyway), but make it very hard to actually get to the content. For situations like this, I prefer the Yahoo pages for graphics; they've gone through the pain of filtering out the better sites.
Scanners, once a luxury item in the computer world, have become very cheap. US$150 will get you a fine scanner that can handle 1200 dpi images; I've seen scanners going as cheap as $10 in promotions at big electronics chains (really). Once slow, clunky and expensive, scanners are a great way to bring images into your computer.
They do a particularly good job with photographs; scanning cartoons and line art will often bring in unwanted gradations of color, so some cleaning up is often necessary. If you have some skill in drawing by hand that doesn't translate well to mousing around a paint program, scanners can be a real blessing.
The basic steps to using a scanner are:
Affordable digital cameras started coming onto the scene in 1998, although they were available in the mid-1990's. Today they remain more of a luxury item overall than scanners, but there is a wide range of price and quality, and they have many advantages over scanners: mobility, lack of physical media, and speed of data import.
Older digital cameras used a serial-line interface to the computer that was slow and often difficult to configure; modern digital cameras generally use USB, a more recent type of connection used for everything from keyboards and mice to Zip drives and scanners. USB is easier to work with and is significantly faster than serial.
As of late 2000, digital cameras could be broken down into three categories based on their image resolution: 1, 2, and 3 megapixel. The 3-megapixel cameras are generally in the US$800-$1000 range as of this writing; other models scale down with resolution and features.
Low-end digital cameras can be found in the $200 range; while they may have maximum resolutions of 640x480, that can be fine for images for the web. If you want to print with good quality, you're going to get tiny images because scaling an image to 600 dpi (from the 72dpi most cameras shoot at) means dividing both dimensions by about 9, so a 9 inch wide screen shot would print at about 1 inch wide at high quality. The more pixels the camera has, the larger images you can print.
The general rule of thumb is: for simple web graphics, anything up to a 1-megapixel camera is fine. For high-quality printing at up to 8 x 10 inches, 3 megapixels is where you want to start. 2-megapixel cameras can do up to about 5x7 at near-photo quality.
I found the Steve's Digicams website helpful when shopping for my digital camera. (No, it's not me, it's another Steve.)
Here, in summary, are the main points to keep in mind when authoring and thinking about images.
The general rule of thumb is: JPEG for photographic material, including digital captures and scans. You might also find yourself using JPEG with computer-generating images that are too rich in color shades for GIF and you don't want to use PNG. GIF or PNG are better for line art, icons, and computer-generated graphics without photographic color ranges.
Many people prefer the new PNG format over the older GIF format because of the licensing issues with the Unisys patent. PNG support in browsers is rapidly spreading, but some older browsers cannot display PNG graphics, so some people are still holding back. Of course, new standards only advance if people use them, so we have to step over the line at some point...
This is far less of an issue than it used to be; when color monitors first began hitting the shelves, many of them had very limited color ranges, as did some of the first graphic cards in computers that drove these monitors. Any computer or monitor purchased since around 1994 can probably handle up to 16-bit color just fine, and most can do 24 bit or 32 bit.
Be aware that there are slight variations in gamma between monitors and even operating systems. If you need very precise color control, you will need to restrict yourself to a 216-color palette of "safe" colors that will show reliably on pretty much all systems. This page has more information.
Remember that you must not only be concerned with the sizes of the individual images on your page, but with the sum total of ALL of the images on your page. Users don't like to wait long times for images to download. A good rule of thumb is to try to keep the total size of your pages, including text, images, and other embededded media, under 80k (80,000 bytes) if at all possible. If your pages are too graphics-heavy, modem users are going to have a hard time and may not stay around to see your site.
Finally, remember that visually disabled users may not see your pictures at all. Your design should be able to withstand the lack of images; use ALT attributes for all of your images and be sure that descriptions are available for visually disabled users. Don't embed meaning in images that can't be reached in some other way.
Much more information on designing for users with disabilities may be found at the Bobby home page and the Web Accessibility Initiative. If you are receiving federal funding for your work, you may be required to reach level AA accessibility ratings at the WAI, which will have a large impact on your use of images.
Text and images are both integral parts of the HTML language
specification. Once we get into sound, we have left the domain of HTML;
there is no <sound> tag in HTML.
Sound files are used and treated in much the same way that image files are, with the exception that since there's no sound tag, you are more limited in what you can do with sound on a web page. Sound also differs from images in that the user's browser determines how the sound is handled; the user may have their browser configured to pass sound files to an external application to play, or it may be configured to play the sound itself if it is capable, or it may not be able to handle the sound at all, in which case it won't play.
To see how your browser is configured to handle sound, try this link and see what happens.
If it plays, then your browser is configured to handle sound natively. If you see a "save as" dialog box, or a box prompting you for what to do with "ralph.wav", then your browser doesn't know what to do with the sound file and is asking you how to handle it.
It's important to realize that some of your users will inevitably run into the same problem, and you will need to provide instructions to them on how to configure their browsers. For this reason alone, some people shy away from using sound on web pages.
There are methods for making sounds play automatically in the background when a web page loads, but I'm not going to tell you how to do that. It's obnoxious. It's also disruptive when your users are using shared or laboratory computers. It's a great way to annoy people and drive them away from your site.
Apple Computer's QuickTime plug-in is one of the standard plug-ins that most browsers are or should be equipped with. It can be configured to handle most common sound and video formats. Once it's installed on a user's machine, sounds will be opened with a small dedicated player with the familiar "movie frame" controls for play, pause, stop, and a draggable slider:
Depending on the plug-in's configuration, the sound may open in the browser's current window, or a new browser window, or a player's application window.
The HTML4 <object> tag was designed to accomodate the
placement of objects like sounds (and video) in web pages, but
unfortunately it is so poorly implemented in most browsers that it can't be
used reliably at present. The non-standard <embed> tag
sometimes works in more recent browsers, but it will break any validation
efforts you undertake since it's not a real HTML tag. It also won't work
in earlier browsers.
(Is anybody else sick of this yet?)
The safest way to handle a .wav sound file on a page is to upload it just like an image file, and then link to it the same way you would link to another page:
<a href="mysound.wav">Play the sound</a>
The user's browser will then handle the sound with whatever method it is configured to use.
I have not seen many sites that rely heavily on audio due to the difficulty of controlling it reliably across different browsers, versions and platforms. Regardless, here are some of the more commonly-used sound formats:
The .wav format is probably the most common sound file format. Mac, Windows and Linux systems can all play .wav files. They aren't terribly efficient in terms of compression, but they have the huge advantage of portability.
AIFF (Audio Interchange File Format) is another widely-used format created by Apple Computer for the storage of high-quality music data. The QuickTime player handles it as well as .wav (and other formats). It is not as universal as .wav but common enough that you might encounter it.
If you haven't heard of MP3 by now, you must be avoiding the media. MP3 stands for "MPEG Layer 3" and is a method of storing high-quality audio with very high compression rates. It has received a lot of attention over the past year in association with Napster, in that people are taking their CDs and "ripping" the tracks to mp3 format, which compresses them to files about one-tenth of their original size with hardly any dropoff in quality. For the first time, high-quality music files became small enough to trade online - legally or illegally.
RealAudio is one example of what is called streaming media. The difference between streaming media and non-streaming media is that streaming media is designed to play as it is received in a steady stream, rather than waiting for the entire file to download before play begins. When it works, it has the effect of reducing download time because the computer isn't sitting idle during the download; it starts playing as soon as there's enough there and continues playing as the download continues.
I say "when it works" because it often doesn't, especially on packet-switched networks like the internet that are prone to unexpected congestion. Even at very high connection speeds, I have always had uneven results with Real and other streaming formats, which causes annoying pauses and interruptions. With the current architecture of the internet, there isn't much that can be done. When the network is clear and traffic is flowing smoothly, performance can be good. When there's congestion or lag, it can be unacceptable.
If you wish to provide RealAudio streaming audio, you must purchase the RealAudio server software and have a server to run it off of. This can be extremely expensive - the base price is about US$2000 for the software, and the server fees will vary widely based on whether you own your own server or lease space on someone else's. You can provide raw files without running a server, and it will be up to the user's browser to do the streaming work, but its effectiveness will depend on the web server load and the state of the network congestion between the user and the server.
In summary, here are some specific recommendations to make when considering the use of sound on your web pages.
It's obnoxious and people will hate you. I will, anyway.
If you're linking to sound files, be sure to indicate in the text, or with a small graphic, or both, that a sound file is the destination of the link. It's helpful to indicate the file size in parenthesis, too, so users can decide whether they want to download the sound file to hear it.
Not all users have their browsers properly configured for sound, so a brief page explaining what they need to hear your sounds (with convenient links to it near the sound-related areas of your pages) will help users who want to hear your sounds, but aren't sure how.
If your sounds are of speech, or have speech in them, provide text transcripts so that people who cannot play or hear the sound have an alternative channel to get the information.
And so we come at last to video - the tastiest morsel of the multimedia smorgasbord.
Tastiest because video conveys the richest concentration of information of all of the media types. Moving images, sound, and the additional intangibles of video that are greated than the sum of individual stills - body language, facial expressions, and the buildup of visual context.
This richess comes at a heavy price, however: VIDEO FILES ARE VERY LARGE. Generally, any video over about ten seconds is measured in megabytes, and the better quality the video, the faster the increase in size.
If compression of images is difficult, compression of video is especially difficult because it must be synchronized with sound. Uncompressed video - imagine a long series of uncompressed images and uncompressed sound - is unbelievably large, and a huge amount of research has gone into the development of compression engines that make video manageable. Still, for all intents and purposes, video is not yet practical as a primary content type on the internet. It can only be compressed so far before it loses enough quality that it becomes more of a distraction than a benefit, and the analog modem lines still in widespread use all over the world make all but extremely short video segments just too expensive in download time to make up a significant part of any website's content.
Most websites that provide video are targeting users with higher-bandwidth connections, such as DSL, cable, or direct T1/T3 backbones such as those found at larger businesses and universities. If this is your target audience, that's fine, but be aware that it's going to be at least a few more years before widespread, affordable high-bandwidth connections are available, particularly outside of the large urban centers.
The other cost of using video, obviously, is production. As video cameras get cheaper and digital video gets more accessible, these costs come down for amateur productions, but the production of quality video still involves skilled personnel - camerapeople, anchors, voiceovers, editors, sound crew, and so forth.
This isn't to say there isn't value in a low-budget video production; there certainly can be, and if carefully planned, video can be a rich addition to a website's content. Unless you're specifically planning to serve only high-bandwidth users, however, you must keep the needs of your low-bandwidth users in mind when deciding how much video to use and for what purpose.
A rule of thumb when considering low-bandwidth users (and by low-bandwidth, we mean 28.8 kpbs modems, which are still an upper limit for a significant proportion of users - in fact, the worldwide average will be substantially lower than that, particularly in developing nations) is this: every minute of video will take between twenty minutes and one hour to download, depending on the frame size and the compression quality.
Like with sound files above, there is no facility for video in HTML. There
is no <video> tag for video content. Once again, then,
it is up to the browser to be configured to handle video, and the burden of
doing this rests on the user. Apple's
QuickTime plug-in
does a fine job with most common video formats, but it must be installed
before video can be viewed.
The same problems with the <object> tag and the <embed> pseudo-tag exist as discussed in the section on Sound
above: the <object> tag is the correct and valid way to
embed video in a page with HTML, but it doesn't work in any but the most
cutting edge browsers as of late 2000. The invalid <embed> pseudo-tag works more reliably in recent browsers but still fails in
older ones, plus it makes it impossible to validate your pages.
The cleanest way to handle video if you are concerned with validation is to link to the video file in the same manner we used for the sound file above. A nice touch is to use a still image from the video as the link to the video file; this will give users some context when the video begins playing. It is also polite to make it clear to the user that clicking the image will cause a video to download, and give some indication of its file size, as in the following example:
 |
Click the image to the left to view the video of
the spider escaping into the woods. File type: .avi video File size: 11mb Movie length: 1 minute Download time (28k): about 1 hour |
The HTML for the above example reads:
<table><tr><td><a href="http://130.91.108.76/~slinberg/freedom.avi"><img src="freedom.jpg" alt="video still" /></a></td><td style="text-align: left">Click the image to the left to view the video of the spider escaping into the woods.<br /><br />File type:<strong>.avi video</strong><br />File size:<strong>11mb</strong><br />Movie length:<strong>1 minute</strong><br />Download time (28k):<strong>about 1 hour</strong></td></tr></table>
Apple's QuickTime format is one of the most widely used video formats out there. It is compatible with Macintosh and Windows, and Apple makes free players and plugins for both platforms.
Brought to you by the fine folks who created JPEG compression, MPEG is the motion-picture version of JPEG. Nearly all of the video players in the Mac and Windows world play MPEG just fine.
Created by Microsoft, this is probably the most widespread video format on the Windows side. There are actually many different flavors of .avi, and Intel makes software drivers needed to view them; some have been ported to Macintosh and other platforms, but others have not.
Windows Media is another Microsoft format aimed at a wider target than PCs; they seek to expand to video and sound-playing appliances. Still in active development, the dust hasn't quite settled regarding stable players on various platforms. Not often encountered in web-based media, but could become a bigger player if Microsoft continues to create players on a wide range of platforms.
The video extension of what used to be called Real Audio is now Real Media; a streaming video format delivered by Real Networks. The same issues with streaming audio apply to streaming video, with the addition that since a lot more data is being moved, the potential for interruptions due to network congestion is higher.
Here are some specific recommendations to make when considering the use of video on your web pages.
As with sound, textual and visual cues that clicking something will cause a video to download and play is absolutely essential to users. Video downloads are such a big event that you don't want users to trigger them by accident.
It's especially important to list the file type along with the size because some people might recognize a file type as something they may not be able to play after they download it. If I'm a Mac user and I see an .avi video link, I'm going to be cautious about risking the download because it might not play. If it's a .mov or an .mpeg, I'll probably go ahead.
A rough rule of thumb when determining download times is that a user on a 28.8 modem can download, under perfect conditions, about 10 megabytes per hour. Six minutes per megabyte. A 56k modem user can grab 15 or 16 megabytes per hour if everything is super smooth; DSL and cable modem users are roughly in the one to three megabytes per minute range, sometimes faster.
This isn't just for the visually disabled; it's for people who won't or can't download your videos. Don't hide your secrets in them; provide a path around by giving a rich transcript. Remember to transcribe not just dialog and spoken words, but visuals as well, like a camera sweep across a skyline.
Same as for sound. Give your users instructions for setting up their browsers and accessing your content.
This concludes the day 3 summary, and the method-oriented instruction of the camp. The last segment in this write-up of the camp is the days 4-5 writeup, which covers the project management aspects of building and maintaining a website.
Copyright (c) 2000-2001 Steve Linberg, Silicon Goblin Technologies. All rights reserved.
