The focus on this book is textual content and images; however, here are some rough guidelines for working with audio and video. See the book’s companion Web site for recommended reading about audio and video.
Audio Content
Audio content destined for the Web should be prepared in MP3 for- mat; while MP3 is a proprietary fi le format, it is also widely used in all sorts of desktop and portable digital audio players.
Preparing MP3 audio fi les is a complex matter, but here are some basic settings that you should use: output your fi les as 8-bit stereo sound.
Perhaps the most important setting on MP3 fi les is their bit rate; for voice applications, 64 kilobits per second (kbs) will provide adequate sound quality, although 128 kbs often sounds noticeably better. How- ever, the higher the bit rate, the larger the sound fi le.
Be sure also to record and prepare your MP3 audio at a 44.1 kHz sample rate, simply because that sample rate is supported by Flash and other players, and there are no savings in fi le size with MP3s when you lower the sample rate. For a technical but all-in-one discussion of this, see http://www.blogarithms.com/index.php/mp3secrets/ . Video Content
Video content is the most complicated material to prepare for the Web.
In addition to shooting and editing your video, it is essential that sound syncs with motion. For most purposes, posting video on YouTube is an ideal solution (Chapter 18 lists other, similar sites for video hosting).
First, the videos are stored and transferred from YouTube’s servers, not
CREATING WEB CONTENT 31 yours. This keeps you from expending large amounts of bandwidth, or the amount of data your server can serve at any one time, on your own server. YouTube also does a generally outstanding job of behind-the- scenes compression and resizing of video, though be sure to consult their documentation on making and posting videos. 4 Finally, maintain- ing a YouTube account is yet another way to establish your presence on the Web. Because YouTube allows you to set up a profi le that can in- clude a link to your Web site, you may be able to attract YouTube users to your site.
The only problem with YouTube is that the code it provides for em- bedding videos on your Web site does not adhere to Web standards.
(See Chapter 18’s discussion of JavaScript and the SWFObject 2.0, which addresses this issue.) For testing purposes, though, there is noth- ing wrong with cutting and pasting the YouTube code. You can swap it out with the JavaScript-based solution before your site goes live, or as a future improvement.
NEXT STEPS
The work of writing and designing your pages depends on the real con- tent of your site. Now that you have some idea of how to prepare for the Web the content you should be gathering and writing, it’s time to look at what a Web page is, the history of how pages have been made, and why standards for Web writing and design are so important.
NOTES
1 . Lorem ipsum, http://www.lipsum.com/
2 . Google Web Search Help, “Getting Started: About Google Images,”
http://www.google.com/support/websearch/bin/answer.py?answer=112512 3 . PDFCreator, http://sourceforge.net/projects/pdfcreator/
4 . YouTube.com, “Making and Optimizing Your Videos,” http://www.you tube.com/t/howto_makevideo
C H A P T E R 4
Standards-Based Web Pages
So far we’ve looked at reasons for writing on the Web and a few approaches to reading the Web with a designer/writer mindset. In Chapter 3 we covered some of the basics of creating and gathering content for your site.
This chapter covers the guiding principles behind well-built pages to deliver your content according to Web standards. Web standards are guidelines issued by the World Wide Web Consortium (W3C), an inter national organization of people associated with technology com- panies and universities. Its aim is to make the use of Web languages and protocols uniform across different user agents (UAs), a fancy phrase for Web browsers and other devices that access the Web.
Now, the idea of “standards” may seem contradictory to an activity as creative as Web design. If everyone is to follow Web standards, is there any room for creativity?
The answer, of course, is “Yes.” In fact, not only do Web standards not stifl e creativity, they actually encourage it. Think for a moment about some of the standards that people have come to rely on. You can buy any kind of electronic device you want—a blender, a television set, a guitar amplifi er—and not have to worry that its plug won’t work in the socket where you live. That one standard frees you to make mojitos or milkshakes, watch trash TV or high-brow documentaries, and play blues or heavy metal.
The design of electrical sockets is standardized, just as are the threads for light bulb fi xtures, traffi c signals and signage, and the USB connec- tors on computers. We also have standardized weights and measures, standards for television and radio signals, and even some standards for
34 HOW TO DESIGN AND WRITE WEB PAGES TODAY
spoken and written language: This is a standard sentence. Standard this sentence is not (unless Yoda you are).
If you had to install a different kind of electrical outlet for every de- vice you own, learn different traffi c-signal patterns from city to city, or learn to speak a different language for each individual human in your neighborhood, you’d probably be a hermit who’d never leave the soli- tary, candlelit comforts of home.
WHAT YOU WON’T LEARN IN THIS BOOK
Here is a brief list of Web design practices that you won’t learn in this book.
These are practices as outdated as the belief that the sun revolves around Earth; run, don’t walk, away from anyone who suggests any of the following:
• HTML tables to design pages. Used for their intended, structural purpose, HTML tables are good for one thing: marking up tabular data. Tables for lay- out present signifi cant accessibility issues and make a page harder to re- purpose or redesign later. Instead of HTML tables, use CSS layout techniques (see Chapter 17).
• Frames and framesets. Another accessibility nightmare, frames are arti- facts from an era before Web servers could easily include content shared over multiple pages. Instead of frames, use server-side includes (see Chapter 21).
• Invisible GIF image spacers. Often used in tandem with HTML tables, invis- ible GIF spacers are the chewing gum and chicken wire of shoddy Web design.
Instead of image spacers, use CSS layout techniques (see Chapter 17).
• “Save As HTML . . .” in a word processor. Just because the option is there doesn’t mean it should be used. Word processors are great for their intended purpose of word processing, but they are as appropriate for building Web pages as chainsaws are for fi xing eyeglasses.
• Adobe Flash for site design. Treat Flash like a chef treats an extremely hot chili pepper: used in moderation in the right dishes for the right people, it adds layers of excitement and complexity. But always give people the option to omit it, and never allow the Flash chili pepper to be eaten by itself (see Chapter 18).
For a crash course in these and other problem practices on the Web, visit http://www.webpagesthatsuck.com/ .
STANDARDS-BASED WEB PAGES 35