
- •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

162 WHO: Riding the Project Life Cycle: We Never Forget a Phase
The presentation and revision process can go several rounds, demanding your tact as well as your expertise. You must be able to respond positively to client requests and return with a solution that demonstrates your responsiveness, without jeopardizing the end product.
Receive design approval
The great day arrives! The client has signed off (well, except for one more teeny tiny change). Now you gear up to begin translating your concept into reality. This phase is known as development.
Development
In the development phase, web designers work with other team members to translate site concepts into functional web pages. While you design additional graphic elements, create Style Sheets, and possibly code web page templates in HTML and JavaScript, producers will be marking up dozens, hundreds, or thousands of pages, and developers will be working to make the entire site far more functional than HTML alone allows.
Up until now, you’ve felt pretty certain about the way the site would shape up. After all, the front page and selected sub-pages have been designed and approved. Now, you must take the elements of all those pages and apply them to every single page of the site. Sometimes you do all this work; sometimes assistants or colleagues pitch in; and sometimes the work is carried out by the equivalent of production artists, whose work you may supervise. What is important in this phase is to maintain consistency.
Is the navigational menu on the right-hand side in all existing comps? Then it should remain there as new pages are designed, unless there is an overwhelmingly important reason to move it. (“It doesn’t fit on this page” is not a legitimate rationale; it merely means you must work harder and rethink that page. Sometimes it means you must rethink the entire site.) The consistent location of navigational elements provides a vital pathfinder for visitors. Imagine trying to find your way in a strange city where the street signs kept changing color or location. No city would be that cruel or foolish. Neither should any website. (Flip back to Chapter 3, “Where Am I? Navigation & Interface,” for more on this subject.)

Taking Your Talent to the Web |
163 |
Client-branding elements also must be treated with consistency from page to page. There are technological reasons for this, as well as psychological ones.
Psychologically, if the logo is always 32 x 32 pixels and always at the top left, visitors expect to see it there on all pages. Such consistency reassures visitors that they are still in the same “place” on the Web. After all, the Web is a fluid and limitless medium, and the client’s site is just a drop in that vast ocean. Consistent branding orients web users; inconsistent branding disorients them. Love your audience and provide the markers they need to know where they are (and your clients will think you’re doing it for them).
Technologically, once a graphic element is cached in the visitor’s browser, it need not be downloaded again. Because most visitors use slow dialup modems, the less downloading, the faster the site and the better the user experience. Thus, if the same 32 x 32 image appears on every page, there is no need for additional downloads, and each page of the site will appear that much faster. (Refer to the discussion in Chapter 2, “Designing for the Medium,” regarding bandwidth and caching if you’ve forgotten how this works or why it matters.)
During the development phase, you’ll do things such as:
■Create all color comps
■Communicate functionality
■Work with templates
We provide tips and pointers in the following sections.
Create all color comps
As you have seen, the design phase demanded the creation of selected color comps. During development, one or more web designers will create color comps for all pages. Depending on client expectations, the design team also may show these comps to the client for approval.

164 WHO: Riding the Project Life Cycle: We Never Forget a Phase
As the team creates each color comp, technicians or junior designers will cut it apart in Adobe ImageReady or Photoshop 6, Macromedia Fireworks, or another similar software program. This process converts the color comp into component elements, and these are finally assembled into a working web page built with HTML and other web languages or with a What You See Is What You Get (WYSIWYG) web layout program, such as Dreamweaver. This is not the only way to create web pages, nor (in our opinion) is it necessarily the best way. It is the primary technique used in most shops, however, and every web designer should master the process.
Communicate functionality
Refer to the previous discussion on rollovers or image swapping, as it can be called. In some web firms, the web designer will code those image swaps in JavaScript. In other firms, the web designer merely articulates a desired effect (complete with Photoshop comps), and a developer or web technician writes the necessary code.
Functionality can include CGI and Java (for forms, e-commerce, message boards, and chat functions), JavaScript (for special interactive visual effects as well as less glamorous browser detection, plug-in detection, forms validation, and so on), plug-in technologies (Flash, QuickTime, or RealVideo), and beyond.
The communication travels both ways. At times the technologist will explain intentions or limitations to the web designer; at other times the web designer calls the shots. Web designers are not expected to know Java programming or MySQL. Many web designers do not even work in Flash. What’s expected is that you know enough about these formats and languages to work with those who specialize in them, articulating your vision or responding to the direction of others.
By the way, we despise the word “functionality” even more than we hate phrases such as B2B or B2C. Alas, it seems to be the best word for the job. Former English majors, check your emotions at the door. This business has more buzzwords than a venture capitalist convention.

Taking Your Talent to the Web |
165 |
Work with templates
In some cases, sites change very little over time. More commonly, the site you design functions as a placeholder or shell for ever-changing content. Sometimes this changing content is managed by the web agency. If the client updates infrequently, you can simply write new HTML and create new images to accommodate occasional changes like these. More often, your clients will update their own sites, with mixed results. (We’ll be whining about that later in the book.)
Today, content is often changed dynamically, by means of various backend technologies. In such cases, you are not so much designing pages as you are templates—visual and markup placeholders in which content will be updated by means of a publishing system or in response to dynamic database technology. The work is essentially the same as “traditional” web design but involves special considerations that will be articulated by the technologists on the team. (See Chapter 12 for more.)
Design for easy maintenance
In the best of all possible worlds, the web design team retains control over the site as it evolves over the months and years. Control is usually accompanied by a retainer fee, which is negotiated at the very beginning of the process. In reality, more and more clients assume control over the site when it is delivered.
Designers and coders should always create highly structured and welldocumented work, so that they can easily go back to it and update it without hunting for missing files, debugging errant file references, and so on (or so that their clients, upon assuming control of the site, can perform these tasks without damaging the site).
Upon finishing the site, you’ll accompany it with a style guide and documentation. These will be much easier to create if the site’s file structure and naming conventions make sense to begin with.