- •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
156 WHO: Riding the Project Life Cycle: We Never Forget a Phase
How does the database work? Your developers know. Meet with them separately and then bring one or more to the next client meeting.
The possibilities are endless—when you first enter the room. After several successful analysis meetings, the possibilities should have focused into a set of meaningful and achievable goals. If you’re still talking in generalities after two or three meetings, you’re not doing your job. If you’re talking in generalities after four or five meetings, the client is not serious. Timelines with cash consequences can sober up most clients. Have an attractive, friendly project manager explain to the client the additional costs incurred as his indecisiveness causes deadlines to shift.
Design
The design phase is a simple word for a heck of a lot of activity. The process nearly always unfolds something like this:
■Brainstorm and problem solve with your team.
■Translate needs into solutions.
■Sell ideas to the client.
■Identify color comps to be developed.
■Create color comps and proof of concept.
■Present color comps and proof of concept.
■Revise and repeat as necessary.
■Receive design approval.
Brainstorm and problem solve
As soon as your team has a clear understanding of the client’s business problems, goals, constraints, and requirements, you can begin brainstorming solutions on your own, in partnership with other web designers, and in meetings with developers, producers, and information architects.
Taking Your Talent to the Web |
157 |
A project manager will join the team if she has not already done so. Make her your best friend. While you conceive grand notions or are daydreaming in Adobe Illustrator, she will be keeping track of and documenting schedules, deadlines, goals, and progress. We wouldn’t last a minute in her job. Nor would most “creative” folks. Respect her for doing what you would pay not to do.
Methods of brainstorming vary. Some groups like to shout out ideas, writing everything down on a whiteboard. Others like to go off in small groups and then reassemble to critique each other’s ideas. Sometimes you sit in the corner and type out ideas. Sometimes you draw on a traditional sketchpad. Some agencies dictate how the process should work; others let you
figure it out for yourself.
Translate needs into solutions
The web designer and other team members will collectively come up with a number of solutions, which will then be narrowed down by group consensus, creative director fiat, or both. These solutions may be articulated internally through any combination of rough design sketches, internal Photoshop comps, written documents, or wireframes (functional visual storyboards showing the proposed site elements in relation to each other, but not in any way indicating how they will eventually look and feel).
To present these ideas to the client, you can once again use any of the following:
■Rough design sketches
■User interface documents
■Creative briefs
■Pencil sketches
■Wireframes
■Color comps
158 WHO: Riding the Project Life Cycle: We Never Forget a Phase
Sell ideas to the client
Using any or all of the tools just listed, the team presents their projected solutions to the client, answering questions, justifying decisions and methods, and discussing alternatives. As part of this discussion and “selling” process, the designer should be able to:
■Articulate technology limitations. Explain why the team supports a particular solution and avoid committing to alternatives that won’t work.
■Articulate design considerations and decisions. As in a traditional design project, explain the rationale behind various creative decisions.
Articulating the limitations of technology and the needs of users can be tricky. The web designer must be familiar with technological issues involved in web development to be able to explain why the team supports a particular solution and to prevent impossible agreements and commitments.
Impossible agreements occur when the client asks for something that cannot be done, cannot be done within the budget and time frame, or just plain should not be done—and an inexperienced web designer or project manager commits the company to fulfilling that unreasonable or impossible expectation. Don’t laugh. Plenty of web design teams have met their doom by committing to solutions that are technologically or graphically inappropriate, more costly than they’re worth, impossible to deliver within the given time frame, or simply deeply stupid.
We were once asked to design the interface for a sophisticated, multi-user business software program that ran in a web browser. Essentially, the product was an intranet site with advanced functions rivaling that of expensive proprietary software. Though a sales force had lined up dozens of large corporate buyers, the developers were unable to deliver the product because its scope kept shifting as the executive in charge came up with one “neat idea” after another that he insisted on incorporating into the product. The design team and sales force sat on their hands while the developers burned out trying to fulfill constantly shifting objectives.
Taking Your Talent to the Web |
159 |
The executive then decided that the seemingly undeliverable product would sell better if users could visually customize it to their liking. He asked that a series of “skins” be developed, and the project manager added this requirement to the mountain of unattained goals. The last we heard, the product was still in development.
This kind of foolishness most often takes place in-house, where egos run unchecked and projects can drag on forever without obvious financial con- sequences—because those who do the work are on the company payroll anyway. But it also can creep into traditional client-vendor relationships if project managers accept impossible agreements.
That’s the worst-case scenario. The only-slightly-better scenario is that your company will somehow fulfill the impossible agreement only to watch the client fail because everyone shook hands over a really bad idea. The client may want his e-commerce site visitors to enter personal data and create a unique user account before even seeing what he has to offer. He may request this at the last minute, and the web agency may manage to fulfill the request on time and within the budget. But nobody will use the site, and the client could bad-mouth the agency rather than admit his own folly, thus harming your business for years to come.
Even if the client has only good things to say about you, you don’t want your clients to fail, and you don’t want the press to associate your agency with widescreen, Technicolor flops. It will take all your expertise at client negotiation to avoid the Titanic effect (also known as the Boo.com effect). But it’s better to face conflict than to knowingly deliver bad work.
The best-case scenario, of course, is to come up with and sell workable solutions that offer real value to the audience your client wishes to reach.
How Not to Do It
“Because I know what I’m doing, and you’re a pathetic marketing flack who wouldn’t know a good idea if it bit him on the thigh.”