- •Taking Your Talent to the Web
- •Introduction
- •1 Splash Screen
- •Meet the Medium
- •Expanding Horizons
- •Working the Net…Without a Net
- •Smash Your Altars
- •Breath Mint? Or Candy Mint?
- •Where’s the Map?
- •Mars and Venus
- •Web Physics: Action and Interaction
- •Different Purposes, Different Methodologies
- •Web Agnosticism
- •Point #1: The Web Is Platform-Agnostic
- •Point #2: The Web Is Device-Independent
- •The 18-Month Pregnancy
- •Chocolatey Web Goodness
- •’Tis a Gift to Be Simple
- •Democracy, What a Concept
- •Instant Karma
- •The Whole World in Your Hands
- •Just Do It: The Web as Human Activity
- •The Viewer Rules
- •Multimedia: All Talking! All Dancing!
- •The Server Knows
- •It’s the Bandwidth, Stupid
- •Web Pages Have No Secrets
- •The Web Is for Everyone!
- •Swap text and code for images
- •Prune redundancy
- •Cache as Cache Can
- •Much Ado About 5K
- •Screening Room
- •Liquid Design
- •Color My Web
- •Thousands Weep
- •Gamma Gamma Hey!
- •Typography
- •The 97% Solution
- •Points of Distinction
- •Year 2000—Browsers to the Rescue
- •Touch Factor
- •Appropriate Graphic Design
- •User Knowledge
- •What Color Is Your Concept?
- •Business as (Cruel and) Usual
- •The Rise of the Interface Department
- •Form and Function
- •Copycats and Pseudo-Scientists
- •Chaos and Clarity
- •A Design Koan: Interfaces Are a Means too Often Mistaken for an End
- •Universal Body Copy and Other Fictions
- •Interface as Architecture
- •Ten (Okay, Three) Points of Light
- •Be Easily Learned
- •Remain Consistent
- •Continually Provide Feedback
- •GUI, GUI, Chewy, Chewy
- •It’s the Browser, Stupid
- •Clarity Begins at Home (Page)
- •I Think Icon, I Think Icon
- •Structural Labels: Folding the Director’s Chair
- •The Soul of Brevity
- •Hypertext or Hapless Text
- •Scrolling and Clicking Along
- •Stock Options (Providing Alternatives)
- •The So-Called Rule of Five
- •Highlights and Breadcrumbs
- •Consistent Placement
- •Brand That Sucker!
- •Why We Mentioned These Things
- •The year web standards broke, 1
- •The year web standards broke, 2
- •The year web standards broke, 3
- •The year the bubble burst
- •5 The Obligatory Glossary
- •Web Lingo
- •Extranet
- •HTML
- •Hypertext, hyperlinks, and links
- •Internet
- •Intranet
- •JavaScript, ECMAScript, CSS, XML, XHTML, DOM
- •Web page
- •Website
- •Additional terminology
- •Web developer/programmer
- •Project manager
- •Systems administrator (sysadmin) and network administrator (netadmin)
- •Web technician
- •Your Role in the Web
- •Look and feel
- •Business-to-business
- •Business-to-consumer
- •Solve Communication Problems
- •Brand identity
- •Restrictions of the Medium
- •Technology
- •Works with team members
- •Visually and emotionally engaging
- •Easy to navigate
- •Compatible with visitors’ needs
- •Accessible to a wide variety of web browsers and other devices
- •Can You Handle It?
- •What Is the Life Cycle?
- •Why Have a Method?
- •We Never Forget a Phase
- •Analysis (or “Talking to the Client”)
- •The early phase
- •Design
- •Brainstorm and problem solve
- •Translate needs into solutions
- •Sell ideas to the client
- •Identify color comps
- •Create color comps/proof of concept
- •Present color comps and proof of concept
- •Receive design approval
- •Development
- •Create all color comps
- •Communicate functionality
- •Work with templates
- •Design for easy maintenance
- •Testing
- •Deployment
- •The updating game
- •Create and provide documentation and style guides
- •Provide client training
- •Learn about your client’s methods
- •Work the Process
- •Code Wars
- •Table Talk
- •XHTML Marks the Spot
- •Minding Your <p>’s and q’s
- •Looking Ahead
- •Getting Started
- •View Source
- •A Netscape Bonus
- •The Mother of All View Source Tricks
- •Doin’ it in Netscape
- •Doin’ it in Internet Explorer
- •Absolutely Speaking, It’s All Relative
- •What Is Good Markup?
- •What Is Sensible Markup?
- •HTML as a Design Tool
- •The Frames of Hazard
- •Please Frame Safely
- •Framing Your Art
- •<META> <META> Hiney Ho!
- •Search Me
- •Take a (Re)Load Off
- •WYSIWYG, My Aunt Moira’s Left Foot
- •Code of Dishonor
- •WYS Is Not Necessarily WYG
- •Publish That Sucker!
- •HTMHell
- •9 Visual Tools
- •Photoshop Basics: An Overview
- •Comp Preparation
- •Dealing with Color Palettes
- •Exporting to Web-Friendly Formats
- •Gamma Compensation
- •Preparing Typography
- •Slicing and Dicing
- •Rollovers (Image Swapping)
- •GIF Animation
- •Create Seamless Background Patterns (Tiles)
- •Color My Web: Romancing the Cube
- •Dither Me This
- •Death of the Web-Safe Color Palette?
- •A Hex on Both Your Houses
- •Was Blind, but Now I See
- •From Theory to Practice
- •Format This: GIFs, JPEGs, and Such
- •Loves logos, typography, and long walks in the woods
- •GIFs in Photoshop
- •JPEG, the Other White Meat
- •Optimizing GIFs and JPEGs
- •Expanding on Compression
- •Make your JPEGS smaller
- •Combining sharp and blurry
- •Animated GIFs
- •Creating Animations in ImageReady
- •Typography
- •The ABCs of Web Type
- •Anti-Aliasing
- •Specifying Anti-Aliasing for Type
- •General tips
- •General Hints on Type
- •The Sans of Time
- •Space Patrol
- •Lest We Fail to Repeat Ourselves
- •Accessibility, Thy Name Is Text
- •Slicing and Dicing
- •Thinking Semantically
- •Tag Soup and Crackers
- •CSS to the Rescue…Sort of
- •Separation of Style from Content
- •CSS Advantages: Short Term
- •CSS Advantages: Long Term
- •Compatibility Problems: An Overview
- •Working with Style Sheets
- •Types of Style Sheets
- •External style sheets
- •Embedding a style sheet
- •Adding styles inline
- •Fear of Style Sheets: CSS and Layout
- •Fear of Style Sheets: CSS and Typography
- •Promise and performance
- •Font Size Challenges
- •Points of contention
- •Point of no return: browsers of the year 2000
- •Absolute size keywords
- •Relative keywords
- •Length units
- •Percentage units
- •Looking Forward
- •11 The Joy of JavaScript
- •What Is This Thing Called JavaScript?
- •The Web Before JavaScript
- •JavaScript, Yesterday and Today
- •Sounds Great, but I’m an Artist. Do I Really Have to Learn This Stuff?
- •Educating Rita About JavaScript
- •Don’t Panic!
- •JavaScript Basics for Web Designers
- •The Dreaded Text Rollover
- •The Event Handler Horizon
- •Status Quo
- •A Cautionary Note
- •Kids, Try This at Home
- •The Not-So-Fine Print
- •The Ever-Popular Image Rollover
- •A Rollover Script from Project Cool
- •Windows on the World
- •Get Your <HEAD> Together
- •Avoiding the Heartbreak of Linkitis
- •Browser Compensation
- •JavaScript to the Rescue!
- •Location, location, location
- •Watching the Detection
- •Going Global with JavaScript
- •Learning More
- •12 Beyond Text/Pictures
- •You Can Never Be Too Rich Media
- •Server-Side Stuff
- •Where were you in ‘82?
- •Indiana Jones and the template of doom
- •Serving the project
- •Doing More
- •Mini-Case Study: Waferbaby.com
- •Any Size Kid Can Play
- •Take a Walk on the Server Side
- •Are You Being Served?
- •Advantages of SSI
- •Disadvantages of SSI
- •Cookin’ with Java
- •Ghost in the Virtual Machine
- •Java Woes
- •Java Woes: The Politically Correct Version
- •Java Joys
- •Rich Media: Exploding the “Page”
- •Virtual Reality Modeling Language (VRML)
- •SVG and SMIL
- •SMIL (through your fear and sorrow)
- •Romancing the logo
- •Sounds dandy, but will it work?
- •Promises, Promises
- •Turn on, Tune in, Plug-in
- •A Hideous Breach of Reality
- •The ubiquity of plug-ins
- •The Impossible Lightness of Plug-ins
- •Plug-ins Most Likely to Succeed
- •Making It Work: Providing Options
- •The “Automagic Redirect”
- •The iron-plated sound console from Hell
- •The Trouble with Plug-ins
- •If Plug-ins Run Free
- •Parting Sermon
- •13 Never Can Say Goodbye
- •Separation Anxiety
- •A List Apart
- •Astounding Websites
- •The Babble List
- •Dreamless
- •Evolt
- •Redcricket
- •Webdesign-l
- •When All Else Fails
- •Design, Programming, Content
- •The Big Kahunas
- •Beauty and Inspiration
- •Index
46 WHY: Designing for the Medium: Web Pages Have No Secrets
So let us repeat: There is never enough bandwidth. Therefore, the best web design is that which conserves bandwidth.
Good web designers are constantly performing digital sleight of hand to conserve bandwidth. By contrast, beginning web slingers with a background in design will typically create a comp in Adobe Photoshop, cut it apart in Adobe ImageReady, and use Macromedia Dreamweaver or Adobe GoLive to put it together again as a working web page. The page may look divine, but it’s almost guaranteed to hog bandwidth.
So how do we conserve bandwidth?
Swap text and code for images
For one thing, we conserve bandwidth by using HTML text instead of typographic images wherever we can. As mentioned earlier, images must be downloaded, decoded, and expanded in the browser —and that takes time. Text may be downloaded in a fraction of the time. HTML is text-based and is thus a bandwidth-friendly technology. ImageReady is a great tool, but don’t expect it to make all your decisions for you. If you use ImageReady or Macromedia Fireworks to generate the pieces of a web page, be prepared to replace some of those pieces with bandwidth-friendly HTML.
Trim those image files
We also conserve bandwidth by reducing the file size of our images when exporting them (saving them in web-friendly formats) from Photoshop. All designers know that file sizes diminish as resolution decreases. A 1200ppi (pixels-per-inch) image takes up more megabytes than the same image at 72ppi. On the Web, all images are rendered at 72ppi, but that is only the beginning. Later in this chapter, we’ll discuss techniques for squeezing high quality out of small image files, and (again) replacing images with HTML even when you use a tool like ImageReady to automate part of the process.
Do more with less
Slicing a large image into a dozen pieces may reduce the bandwidth required by each piece, but there is a trade-off. As the server responds to one image request after another, the cumulative bandwidth used might be higher than needed to serve a smaller number of larger images. Each design requires you to experiment with these trade-offs.
Taking Your Talent to the Web |
47 |
Prune redundancy
Another technique to conserve bandwidth is to remove redundancy from HTML code. If you’re unfamiliar with HTML, you can scan Chapter 8 for a quick overview. But even if you don’t, the following example will probably make sense to you. If not, just nod along and come back later.
In traditional web design, we use HTML tables to position text and images on the page. HTML tables are just like tables in a spreadsheet, except that the borders are usually turned off (border=”0”) to hide the underlying technology from viewers. By default, elements in a table cell are left-aligned unless the programmer has specified otherwise by typing something like <td align=”center”> or <td align=”right”>. Therefore, in an HTML layout, it is unnecessary to type:
<td align=”left”>
In our code, when:
<td>
Will suffice. Now, <align=”left”> does not eat much bandwidth on its own, but multiplied thousands of times throughout a site, that kind of unnecessary markup adds up to a significant waste of bandwidth per visitor. If the site wastes 10K of bandwidth on each visitor, and one million visitors access the site each week, the waste of bandwidth is multiplied to an astounding 10 gigabytes per week, and visitors may experience a decline in the overall responsiveness of the web server.
Strange as it seems, we can even conserve bandwidth by minimizing white space in our HTML documents. Users never see these documents unless they are utilizing View Source, and technically, the amount of white space makes no difference in the rendering of the site. For example, this HTML snippet:
<div align=”Center”> <form>
<input
type=”button” style=”font-size: 12px; font-family: geneva, arial, sans-serif; backgroundcolor: #ff6600; color: #ffffff;”
value=”Previous Reports”
48 WHY: Designing for the Medium: Web Pages Have No Secrets
onClick=”window.location=’com0800a.html’;” onMouseOver=”window.status=’More of same.’; return true;” onMouseOut=”window.status=’’;return true;”>
</form>
</div>
<p> <br> </p>
Is functionally identical to this HTML snippet:
<div align=”Center”><form><input type=”button” style=”font-size: 12px; font-family: geneva, arial, sans-serif; background-color: #ff6600; color: #ffffff;” value=”Previous Reports” onClick=”window.location=’com0800a.html’;” onMouseOver=”window.status =’More of same.’; return true;” onMouseOut=”window.status=’’;return true;”></form> </div><p> <br></p>
Note that this technique cannot be applied to the entire web page. If you mess with the white space and line breaks in JavaScript, you can generate scripting errors that cause pages to fail. It is only safe to delete the extra white space in the HTML portion of each document. HTML does not care whether the white space is there or not. But extra white space adds to the character count, which in turn, beefs up the document’s overall weight. An HTML document with plenty of white space can weigh in at 11K, while an identical document without white space may be as little as 9K. Certainly, 2K is a negligible amount of bandwidth, but multiplied by a million users a week as per the previous example, it once again becomes significant.
Before you rush off and start deleting all the white space from your HTML
files, bear in mind that white space helps the eye make sense of the code. Because a site that never changes is a site that soon loses its traffic, you will frequently find yourself reopening documents you created months before to update the content and design. Just as often, a coworker will have to open and revise a document you created, or you’ll be editing one of theirs. Moreover, web design is becoming more and more collaborative, which means more and more documents change hands throughout the process. For this reason, most web designers leave plenty of white space in their documents—along with a trail of comments which help the designer or her successors make sense of the markup.