|
|
Communicate—don't decorate. This is the hallmark of commercial art, and even interactive art should heed this wisdom.
There are certainly reasons for using the latest whiz-bang features on a site. If you are presenting the site just for entertainment and brand recognition (like Pepsi), if you are trying to set your site apart from your competition's, or if your
company image can be enhanced by the use of bells and whistles, by all means, consider their use.
There is, of course, a caveat: Bells and whistles annoy many people. We've talked with many folks who have very strong opinions about the use of features like Shockwave. As you know, many people turn plain old graphics off on their browsers. You can
probably imagine how they feel about huge multimedia files.
In short, no. Having an extremely accessorized site may increase traffic (exponentially), but the prevailing wisdom on the subject seems to point to one fact: Hits do not mean sales. If sales are the main goal of your site (as opposed to mindshare),
and you are keeping an eye on time and/or expense, you will probably keep your bells and whistles to a minimum (but don't forget that graphics on the Web were once considered frivolous).
Having a clearly navigable, attractive, and informative site will give people a good impression of your company. Having a few special features may help put you ahead of your competition (all other things being equal). Overloading your site with bells
and whistles, just for the sake of having them, will make you look cheesy.
Think of it this way: Have you ever seen a car that was way too accessorized? Did you think "Wow, that guy has class?" or was it more like "Jeez, what a goofball! Maybe he's a pimp." If you do choose to employ bells and whistles, do
so tastefully. In many cases, your best bet may be to let people know if they are about to enter a feature-rich site, and to give them an alternative.
This is not to say that you should be aiming at producing plain, generic sites. What you should be doing, on a constant basis, is balancing bandwidth with communication value. You want to make the best presentation possible, and you want to do so using
the least bandwidth. This is true even when you know that your site will be viewed by an audience with full T1 access—bandwidth is still a consideration.
So, what you should be thinking about is what communication value each component in your site will have, and whether it's worth the expense of bandwidth. Many authors try to keep each page under 40K total (HTML, graphics and any other files). This is a
difficult goal, and we don't necessarily adhere to it ourselves, but we always use it as a benchmark. When there comes a time to make a decision about including a component that will push our page size past this mark, we ask ourselves (and our client)
whether this component is worth it. Sometimes it is, and sometimes it ain't.
There are several ways to add animation to your site. Server push, client pull, applets (Java, ActiveX, and so on), embedded Shockwave, and GIF89a animation all provide movement on the screen. Each do so in a different way, and with different effects
on the browser.
Server push and client pull generally reload images, one on top of the next, in order to achieve an "animation" of sorts. This is a real bandwidth hog, and the effect can be pretty untrustworthy (especially using low-speed connections). You
will rarely see this on the Web anymore, not because of any specific fatal flaw, but because it was never well-hyped, and because of bandwidth issues.
A good example of server push animation is on the Armani Exchange Summer '96 site. The opening screen (Figure 18.1) simply shows two people bundled up for winter.
Figure 18.1. The opening screen on the Armani Exchange Summer '96 site.
After a series of slides (pages), in which the couple disrobes, the final slide (Figure 18.2) shows the logo and tagline, "Summer is here."
Figure 18.2. The final screen of the Summer '96 site.
It's a very cute use of this type of animation, though it's also very slow. The difference between server push and client pull is implied by the name. Server push sends the information (generally via a CGI script) without request, and the connection to
the server stays open until the server is finished. Client pull requests each transfer individually (usually with the META/refresh tag), and generally necessitates the reopening of the connection each time a new page is loaded.
Client pull is generally the easiest to set up, as it requires only the addition of a tag in the <HEAD> of an HTML document. For example, adding the line <META HTTP-EQUIV="Refresh" CONTENT="10;
URL=http://domain.com/feed2.htm"> will cause the page feed2.htm to load after 10 seconds. This page could have another "Refresh" command that would load a third page, and so on.
For the most part, client pull and server push types of animation can be replaced through the use of GIF89a animations, which have several distinct advantages.
GIF animation is probably the best way to introduce animation to your pages. Both Netscape and Microsoft have expressed that they will support GIF animation in all future browsers, it requires no plug-ins, it is relatively small, and some nice effects
can be achieved by its use.
The main advantages to GIF89a animations are that they are completely portable, do not require an open connection (like server push), and can work offline (unlike any connection-dependent animations). The down side is that they require a special tool
to make (unless you want to get into the code yourself). Of course, we've included that tool on the CD-ROM (is there no end to our forethought and generosity?). Read the Quick and Dirty Guide at the end of this chapter for step-by-step instructions for
creating GIF89a animations. Also refer to Chapter 12, "Working with Graphics," for more general information on this format.
Macromedia (see Figure 18.3) is the developer of the two major multimedia presentation applications on the market: Director and Authorware. Shockwave is a way to package movies and interactive applications from these programs.
Figure 18.3. Macromedia's home page.
Macromedia Shockwave for Director and Shockwave for Authorware are, without question, excellent interactive multimedia platforms. Unfortunately, the proprietary nature of Shockwave, and the need to download plug-ins, makes it pretty unappealing for
commercial use. Additionally, these are big files, and though the newest Shockwave for Authorware is supposed to stream (which means that you can view and interact with it while the file is downloading), there is still an issue of bandwidth.
For more information on Macromedia products, visit www.macromedia.com. If you are a multimedia developer, you'll find plenty of information on adapting and creating WWW/Shockwave applications.
Everyone wants their $3,000+ computer to look like a $200 television. While you can link to (and even embed) AVI, QuickTime and other video formats within your HTML pages, the files themselves are generally huge, of poor quality, and limited to 320x240
pixels. Although the technology for streaming video (video that is presented as it loads) is being improved constantly, the price for setting up the equipment and server required to run this type of application can be extraordinary, and the quality is
questionable. These are the reasons why you don't see many video files on the WWW—yet.
MPEG (a proprietary algorithm-based compression, like JPEG) may soon change this, as MPEG allows for very aggressive compression, full-screen presentation, and high-quality sound and video. MPEG1 is often described as having similar quality to VHS
video (again, the TV thing), while it's big brother, MPEG2, has mastering digital quality.
Our advice on the use of video is to use MPEG (once it is fully supported). The WWW really isn't a proper vehicle for huge files, and current video formats require bandwidth beyond reason. MPEG encoders and decoders are constantly being improved upon,
and your best bet is to continue to search the Net for up-to-date information.
Adding sound to your pages is more difficult than you might expect. While you can always link to a sound file (of any type), this doesn't really present a very good effect. Your viewers will need to download the entire file before they can hear
it—this isn't exactly what you think of when you want multimedia. Luckily, there are more and more options becoming available for sound.
If you want your page's sound to have actual content—which is to say you want more than just noise—you will want to go with a streaming application. A streaming application does not require a complete file download, but instead allows the
viewer (listener) to hear a file as it downloads. One of the most exciting sound streaming applications is RealAudio (www.realaudio.com). RealAudio has such an aggressive compression, and such an effective packet handling
protocol, you can actually have a live feed. Visit the National Public Radio site off of the RealAudio home page (Figure 18.4) for an example.
Figure 18.4. The RealAudio home page.
Generally, the slower the access speed, the poorer the sound quality (because the sound file must be more highly compressed). On a 14.4 connection, RealAudio sounds like an AM radio that is not quite on the station. You can still make out the words,
but it's not exactly great sound.
If you are considering adding a vocal sound file (such as a speech) to your site, RealAudio seems to be the best option. It will require vendor software for the server, encoding software for the designer, and decoding plug-ins for the viewers. Visit
the RealAudio site for more information.
If you are simply looking to create a background sound for your pages, you can avoid specialized server/client software in at least two ways. Microsoft Internet Explorer and the newest version of Spry Mosaic allow for the use of a "background
sound" (in the body tag: bgsound="sound.wav") within the code. The sound file will download, and then loop as many times as is specified or until the viewer leaves the page. This is, by far, the easiest way to apply sound to your page, and
we anticipate that it may be included on other browsers very soon.
The second way to add sound is to use a Java applet. As with all things Java, using an applet for sound is not quite ready for prime time. The sound quality we've experienced on Java-enabled sites is comparable to that of old video games and
low-quality MIDI players. Take heed, though, as this will likely change.
Java was developed to be a platform-independent programming language. This is to say that it was designed to work under everything from UNIX, to MAC, to Windows. It's best to think of Java as a set of instructions for writing code. Upon loading the
applet, your computer writes its own platform-specific code based on the applet, using what is called a runtime module.
The idea behind Java was that a single, small, powerful language that could be used by all platforms would find a perfect application on the Net. Unfortunately, despite the high investment made by many companies, and despite Sun Microsystems' efforts
to keep the language pure, there is an almost constant battle being waged over how Java will be used.
Many of the people developing Java applets have found shortcomings in its application. This is to be expected from an entirely new language, as growing pains are par for the course. Unfortunately, some of these developers have bastardized the language
to make it work with their specific applications (reducing its cross-platform compatibility and compromising security,among other things).
As we've alluded to before, we don't feel that Java's time has come quite yet. We do believe that the future of the Web may be paved (at least partially) with Java, but we can't quite see that future. There are simply too many problems to overcome, and
too few good uses at this time.
This said, there is no doubt that Java is now available, and that there are clean, reliable applications where Java can be useful in presenting your message. Just the use of scrolling text may, in some cases, help you get your point across. In cases
like this, by all means use Java. Sun offers a full development kit as well as instructions at its Web site, http://java.sun.com/. (See Figure 18.5.)
Figure 18.5. Sun Microsystem's Java development site.
Microsoft didn't really jump on the Java bandwagon—it's more like they were dragged kicking and screaming. As an alternative, Microsoft developed ActiveX controls, which can be embedded into HTML to control a variety of objects (including Java).
ActiveX has several unique functions as a controller. One of the coolest is that it automatically downloads any specific software needed to run an object, and allows for digital authentication of these applications. In other words, the code contains
the URL of the application (what would be a plug-in on Netscape), goes and gets this app, checks that the file has been digitally signed, and then presents you the verification (because applications can contain nasty things such as viruses, you wouldn't
want them to download directly without knowing what might happen).
While ActiveX is clearly powerful, cross-platform, and compatible with many languages, the fact that Microsoft IE is the only browser currently supporting ActiveX (Figure 18.6), and that IE only represents about 8 percent of the market, seems to make a
case for taking a "wait and see" attitude. For information on ActiveX, check out the Microsoft site at www.microsoft.com.
Figure 18.6. Microsoft's ActiveX control with VRML.
VRML is, without doubt, the coolest bell or whistle in the works. Virtual Reality is a 3-D modeled "space" generated by the computer that enables the viewer to change perspectives and view objects as if they were "walking" through
this space. You can see behind objects by "walking" around to the back. You can move closer and farther, look up and down, left and right. You can even interact with others in this virtual space.
Virtual reality may one day be the preferred method of GUI (Graphic Use Interface). This is to say that you may one day interface with your computer via virtual reality—not only for entertainment and interaction, but for more mundane tasks as
well. You want to open a file? Go to the file cabinet, open the drawer, and grab the file. Want to delete something? Crush it with your fist, or shoot it with a flame-thrower (it just doesn't get much cooler than that).
TV and films have pushed the idea that you'll be able to slip on a suit, put on some goggles, and "exist" within this virtual world. While this future is now residing as scattered components in many different labs (one place is working on a
suit, another is developing goggles, and so on), it's certainly not outside the bounds of technology to believe that we will see consumer-priced virtual reality systems within the next few years.
As it stands now, virtual reality is pretty experimental, and VRML (the proposed standard for virtual reality on the Net) is a pale comparison to what we can soon hope for. The truth is, however, that VRML will probably be a big part of the Web within
the next couple of years, and commercial designers should keep on top of the technology.
VRML applications currently enable you to "walk" through "worlds" that contain fairly simple shapes (called primitives) and give you navigational control for moving and viewing (like Intel's VRML in Figure 18.7). You can even create
your own model (called an Avatar) to represent yourself as you move about a world. This model can be downloaded by others in the same world, so that they can see and even interact with you. This is kind of neat, but there really isn't much commercial
application for it yet.
Figure 18.7. Intel's sample of VRML.
As with other cool things, it's the bandwidth bug that brings VRML to a crawl. Add to this the fact that the VRML standard is being pulled in every direction by proprietary concerns, and the conclusion is that VRML is not ready for prime time. Our
advice: Wait for the dust to settle.
Hybrid applications provide the best solution for the bandwidth problem. A hybrid application is an application that contains most of its information on a local memory drive (like a CD-ROM), and uses data transfer only for updates. In this way,
users can enjoy rich content and interactivity with only a minimal use of bandwidth.
DOOM was a great early example of a hybrid application. This 3-D shoot-em-up game allowed multiple users to play over a network (such as the Internet), without the need to transfer more than the minimum information. Each user's system had the entire
game in memory, and all that needed to be transferred were the position and actions of the players. Compare this to current VRML worlds, where everything must be downloaded to each user's system, and you can imagine how much bandwidth can be saved.
Hybrid applications don't necessarily fit into this book, and it's certainly way beyond our scope to design a hybrid app, but you should know of their existence and rapid development. If you are developing a marketing CD-ROM catalog, for instance, and
you want it to be updatable via the WWW (like downloading current pricing, or linking out to ordering), you are creating a hybrid application.
While hybrid applications may go against the "open" nature of the WWW ( by requiring more than just a browser and plug-ins), they may provide the most realistic quick fix to the bandwidth problems faced by media developers. Keep an eye out,
as this may be a big part of the future.
Here's what it comes down to: How much are you (or your clients) willing to pay for features that will only be seen or used by a small percentage of the market?
If a good Web site may take 100 hours to create, and a feature-rich Web site may take 1000 hours, you need to justify that 900 percent increase. If you'll be gaining 10 or more times the sales, or mindshare, or whatever is your goal with the
feature-rich site, it's worth the expense (of time or money). Realistically, however, you probably won't be looking at this type of increase.
Clients will often say something like "we want Java." At which point we have to explain to them that Java is a programming language, not a feature. We then ask them what they want to accomplish with a Java application. Some people actually
have a use for Java (such as some kind of interactivity), but 99 times out of 100, all the people want is animation.
As a commercial designer, you are looking to provide a good investment, and a good investment is rated by its returns. Your job is to provide the most effective Web site possible, under the constraints of time, money, technology, and bandwidth. The
trick of the trade is to honestly assess the possible features of a site against their role in the site's overall effectiveness.
You don't have to be a downer, and just go in dashing everyone's dreams of an awe-inspiring site. What you should do is sit down with the client (or by yourself) and realistically examine your options. If option X will cost $Y, and will only be
viewable by Z percent of the WWW community, is it a good expense? In some cases it will be, and in others it will not. You have to put these things in perspective—this is called being a professional.
In our opinion, GIF89a animation is unparalleled in function and simplicity. It adds motion to your page, requires comparatively little bandwidth, and gives a nice effect. Furthermore, these animations require no plug-ins, and either are or will be
implemented in the major browsers. When asked to develop animation, GIF89a is almost always our first choice.
So, let's get animated! To continue our exciting generic streak, we've opted to use a 3-D-rendered globe for our example. We've used Asymetrix 3D-FX for our rendering engine, using a globe model supplied with the software. (Hey, we said 30 minutes.)
An animation requires several frames (images) to be used in succession. To do this, we create an animation path for the model (in this case, a spinning motion), and generate snapshots for each frame (Figure 18.8).
Figure 18.8. Rendering 3-D frames.
Note
Most 3-D tools enable you to create animations automatically, using a variety of formats. We've found, however, that the compression and dithering these formats provide are inferior to static bitmaps. This is why we take a series of bitmap snapshots, rather than relying on animation tools.
For this globe, we decided to create a 16-frame rotation. This means that it requires 16 different GIFs to create the effect. The number of frames in an animation will affect the size of the final GIF file. In our sample, we used 16 files which, as
individual GIFs, would be approximately 4K each. The resulting animation GIF is under 50K, which means that the size of the GIF animation is not equal to the cumulative size of all of the frames (64K).
Notice that we named the individual frames alphabetically (A,B,C) rather than numerically (1,2,3). This is to help us keep track of the sequence. If you are using more than 9 frames, you may want to name them as we've done, since a computer will put
the number 10 before number 2 (1,10,11,12,2,3,4,). Most applications list files in alphabetical order.
Now that we have our frames (Figure 18.9), we can put them together with the GIF Construction Set (on the CD-ROM). This is a great tool, and we're not nearly using it to its potential in this example. Please note that you do not have to replace the
entire GIF in each frame—only the area that you wish to change. The construction set will enable you to place smaller files over the top of larger ones. In this case, however, the entire image changes as the globe turns (though we could have cut the
size down a little be reducing the white space).
Figure 18.9. Individual animation frames.
You'll notice in Figure 18.10 that we are adding commands within the construction set. LOOP does what it implies—once the GIF has reached the end, it starts over again. The CONTROL lines enable you to set the timing of the animation (how long each
frame will stay on screen before the next loads), as well as how each frame will load in relation to the last. You may need to play with the CONTROL lines quite a bit to get the desired effect for each individual animation.
Figure 18.10. Constructing a GIF animation.
As you add each image, the construction set asks what palette you want applied. Here again, you will want to play around to see what gives the best effect. More often than not, you'll probably opt for the Use local palette selection.
Once you have created your animation GIF, you can simply place it as you would any other image. You can also resize the image within the code. In this way, one animation can be used for many applications within a site without the need for reloading. In
creating a page to display our sample GIF animation, we've used the GIF twice at full size, and four more times as bullets. The effect is a lot of motion on the page (which you'll just have to imagine).
Here's the code we used:
<HTML> <BODY BGCOLOR="#FFFFFF"> <IMG SRC="zglobe.gif" HEIGHT=75 WIDTH=100 ALIGN=LEFT> <IMG SRC="zglobe.gif" HEIGHT=75 WIDTH=100 ALIGN=RIGHT> <center> <h1>Welcome to the World!</h1> </center><P><br><br><br> <HR> <h2><DD>Places to Visit:<P> <IMG SRC="zglobe.gif" HEIGHT=25 WIDTH=33 ALIGN=LEFT>Forests<P> <IMG SRC="zglobe.gif" HEIGHT=25 WIDTH=33 ALIGN=LEFT>Oceans<P> <IMG SRC="zglobe.gif" HEIGHT=25 WIDTH=33 ALIGN=LEFT>Deserts<P> <IMG SRC="zglobe.gif" HEIGHT=25 WIDTH=33 ALIGN=LEFT>Mountains<P></h2> </BODY> </HTML>
Figure 18.11 shows you the result.
Figure 18.11. Our sample animation page.
You'll notice that the browser's STOP button remains active (red) even though the document is loaded. When we first started using GIF animation, we received complaints that our pages weren't fully loading. This is not the case. Since most animations
are set to LOOP, the browser is constantly reloading the image—but it's doing so from local memory. Even if you go offline, the image will continue to LOOP. Luckily, people have now become accustomed to this.
Note
Browsers that are not capable of displaying GIF animations will only display a static "snapshot" of your GIF (as will most bitmap manipulation applications). This snapshot will generally be the first or the last frame in your animation, so make sure these frames look good on their own. Viewers using older browsers won't know what they're missing, which is preferable to them feeling like they're missing out.
And there you have it! Even with the rendering, this took less than 30 minutes (though we must admit, we've done this before).
If you're not lucky enough to have 3-D rendering software, don't despair. A simple animation can be created using any graphics program, including Paint Shop Pro on your CD-ROM. For instance, you can create a simple animation by simply opening a graphic
in PSP and lightening the image, little by little, using the Adjust Brightness tool and saving the image each time as a different GIF file (Figure 18.12).
Figure 18.12. A fade-in or fade-out animation's frames.
When put together in the GIF Construction Set (Figure 18.13), this can create a fade-in or fade-out animation (depending on the order you place the GIF files in the animation). We created a fade-in animation in 10 minutes using this technique. Though
this type of animation is very simple to create, the effects can be amazing. For instance, this fade-in animation (when timed correctly by editing the control) can make the graphic seem to appear out of thin air—or to slowly disappear.
Figure 18.13. Creating a fade-in animation.
See, it's easy—just use your imagination! Animation is just a series of slides. If you can make the slides, you can build the animation.
Yes, we may have been a big downer throughout this chapter. You may have had grand ideas that we shot right out of the water—which is not really our intention. Our intention was to give you our honest opinions on the use of bells and
whistles. You see, as Web developers (yes, you included), we are often inundated with software companies pushing their newest feature that will "revolutionize the Web."
We are not saying these companies are bad or lying (in fact the Web would not be what it is today without them). Far from it. They are producing a product that they believe in and we have the utmost respect for that. Our point is to bring all of this
down to earth, and to give a more conservative view of things than that offered by sales hype.
In this chapter we have discussed
Keep an eye on the development of these technologies, and begin learning how to use them. Don't rule them out, just keep the issues we have discussed in mind. We've said it before, but that won't stop us from saying it again:
Communicate—don't decorate. Design by this philosophy and you'll be just fine.
Are you ready to get yourself up and running?
