Lemur zaprasza
Do I Really Need All the Bells and Whistles? Animation GIF 89a Animation Shockwave Video Sound Actual Content Just Plain Sound The Use of Java ActiveX Virtual Reality Modeling Language (VRML) Hybrid Applications. Tricks of the Trade Summary – 18 – Bells and Whistles 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. Do I Really Need All the Bells and Whistles? 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. Animation 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. 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." 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 89a Animation 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 ," for more general information on this format. Shockwave 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. 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 . If you are a multimedia developer, you'll find plenty of information on adapting and creating WWW/Shockwave applications. Note We check all plug-in dependent applications through the BDWBWI (Better Damned Well Be Worth It) protocol. If you are expecting viewers to download and install a plug-in, then return to your page to download a large file, you'd better be sure that you're providing them with something that's worth the wait! Video 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. Sound 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. Actual Content 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 (). 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. 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. Just Plain Sound 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. The Use of Java 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, . (See Figure 18.5.) ActiveX 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 . Virtual Reality Modeling Language (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. . 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. 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. Tricks of the Trade 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.
|