250 HTML and Web Design Secrets 0764568450, 9780764568459

* This value-priced guide by one of the Top 25 Most Influential Women on the Web delivers 250 solutions, workarounds, ti

270 56 8MB

English Pages 433 Year 2004

Report DMCA / Copyright

DOWNLOAD PDF FILE

Recommend Papers

250 HTML and Web Design Secrets
 0764568450, 9780764568459

  • 0 0 0
  • Like this paper and download? You can publish your own PDF file online for free in a few minutes! Sign Up
File loading please wait...
Citation preview

250 HTML and Web Design Secrets

250 HTML and Web Design Secrets Molly E. Holzschlag

Wiley Publishing, Inc.

Published by Wiley Publishing, Inc., 10475 Crosspoint Boulevard, Indianapolis, IN 46256, www.wiley.com c 2004 by Wiley Publishing, Inc., Indianapolis, Indiana Copyright  Published simultaneously in Canada eISBN: 0-7645-7708-5 Manufactured in the United States of America 10 9 8 7 6 5 4 3 2 1 No part of this publication may be reproduced, stored in a retrieval system or transmitted in any form or by any means, electronic, mechanical, photocopying, recording, scanning, or otherwise, except as permitted under Sections 107 or 108 of the 1976 United States Copyright Act, without either the prior written permission of the Publisher, or authorization through payment of the appropriate per-copy fee to the Copyright Clearance Center, 222 Rosewood Drive, Danvers, MA 01923, (978) 750-8400, fax (978) 646-8600. Requests to the Publisher for permission should be addressed to the Legal Department, Wiley Publishing, Inc., 10475 Crosspoint Blvd., Indianapolis, IN 46256, (317) 572-3447, fax (317) 572-4447, e-mail: [email protected]. Limit of Liability/Disclaimer of Warranty: The publisher and the author make no representations or warranties with respect to the accuracy or completeness of the contents of this work and specifically disclaim all warranties, including without limitation warranties of fitness for a particular purpose. No warranty may be created or extended by sales or promotional materials. The advice and strategies contained herein may not be suitable for every situation. This work is sold with the understanding that the publisher is not engaged in rendering legal, accounting, or other professional services. If professional assistance is required, the services of a competent professional person should be sought. Neither the publisher nor the author shall be liable for damages arising herefrom. The fact that an organization or Web site is referred to in this work as a citation and/or a potential source of further information does not mean that the author or the publisher endorses the information the organization or Web site may provide or recommendations it may make. Further, readers should be aware that Internet Web sites listed in this work may have changed or disappeared between when this work was written and when it is read. For general information on our other products and services or to obtain technical support, please contact our Customer Care Department within the U.S. at (800) 762-2974, outside the U.S. at (317) 572-3993 or fax (317) 572-4002. Wiley also publishes its books in a variety of electronic formats. Some content that appears in print may not be available in electronic books. Library of Congress Cataloging-in-Publication Data Trademarks: Wiley and related trade dress are registered trademarks of Wiley Publishing, Inc., in the United States and other countries, and may not be used without written permission. All other trademarks are the property of their respective owners. Wiley Publishing, Inc., is not associated with any product or vendor mentioned in this book.

About the Author In the world of Web design and development, Molly E. Holzschlag is one of the most vibrant and influential people around. With over 30 Web development book titles to her credit, Molly is also a noted columnist, speaker, and educator. As a Steering Committee Member of the Web Standards Project (WaSP), Molly works along with a group of other dedicated Web developers and designers to promote open standards for the Web. She serves as an advisor and spokeswoman for the World Organization of Webmasters. Molly speaks regularly at conferences in addition to teaching and developing curriculum for a number of colleges and universities, including the University of Arizona, University of Phoenix, New School University, and Pima Community College. Many recognize Molly from her column, “Integrated Design,” which appeared in the much-missed Web Techniques Magazine for three years, and from sister publication Webreview.com, where Molly served as Executive Editor for a year during the best of the San Francisco dot.com era. Molly has been honored as one of the Top 25 Most Influential Women on the Web. For more information about Molly, drop by at www.molly.com/.

Credits Acquisitions Editor Katie Mohr Development Editor Marcia Ellett Technical Editor Ethan Marcotte Production Editor Pamela Hanley Copy Editor TechBooks Editorial Manager Mary Beth Wakefield

Vice President and Executive Group Publisher Richard Swadley Vice President and Executive Publisher Robert Ipsen Vice President and Publisher Joseph B. Wikert Executive Editorial Director Mary Bednarek Project Coordinator TechBooks Proofreading and Indexing TechBooks Production Services

To Bill Cullifer for his unflagging enthusiasm for the Internet, desire to uplift and educate, and for his friendship

Contents Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xvii Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xix

Part I: Tools, Planning, and Content . . . . . . . . . . . . . . . . . . . . . . . . . . 1 Chapter 1: Setting up a Master Toolbox . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 Web Browsers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 Choosing a Code Editor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 File Management with FTP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 Telnet and SSH . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 Validation Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 PNH Toolbar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 Sidebar Reference Panels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 Bitmap Image Programs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 Vector Image Programs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 Web Animation Utilities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 Screen Capture Utilities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 Rename Utilities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 Tag Strippers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 HTML Tidy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 Compression Utilities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 Audio and Video Players . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 Plug-Ins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 SVG and SMIL Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 Software for Security and Safety . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 Collaborative Communication Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

Chapter 2: Managing Your Web Project . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 The Challenge of Web Project Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Toward Consistent Organizational Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Creating Industry-Wide Standards for Web Project Management . . . . . . . . . . . . . . Fixing Disparities in Problem-solving Approaches . . . . . . . . . . . . . . . . . . . . . . . . . . . Selecting the Project Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Defining the Budget . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Identifying Goals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Determining the Stakeholders . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Determining Market Needs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Identifying Roles and Responsibilities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Creating a Project Workflow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Listing Creative Tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Clarifying Technical Tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Defining Administrative Tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

36 36 37 37 38 39 39 40 41 41 43 44 44 44

⽧ x

Contents

⽧⽧⽧

Listing Marketing Tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Addressing Quality Assurance Concerns . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Setting Milestones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Getting Signoff Throughout the Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Encouraging Collaboration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Managing Scope Creep . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

45 45 46 46 47 48 49

Chapter 3: Architecting Your Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51 What Is Information Architecture? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Sites Big and Small, New and Old . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Organic Growth and the Web . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Performing a Content Audit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Determining Hierarchies of Content . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Defining Technical Infrastructure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Determining Naming Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Site Mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Understanding Wireframing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Developing Prototypes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Creating User Pathways . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Creating Archive Systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Considering Frequency of Updates and Redesigns . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Setting Site-Wide Standards . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Developing a Site-Wide Style Guide . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

52 52 52 53 54 56 57 59 60 61 62 63 64 65 65 66

Chapter 4: Making Sites Usable and Persuasive . . . . . . . . . . . . . . . . . . . . . . . 67 Create Consistent Branding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Determining Primary Navigation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Secondary Navigation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Grouping Navigation by Like Items . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Iconography and Language Use . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Managing External Links . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Direct Access to Site Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Placement of Critical Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Consistent Placement of Elements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Drop-Down Menus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Pop-Up Windows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Consider Tabbed Navigation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Provide Orientation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Date and Time Formats . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Cost-Controlled Usability Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

68 69 71 72 74 77 81 83 84 84 85 87 88 89 90 91

Chapter 5: Creating and Managing Fantastic Content . . . . . . . . . . . . . . . . . 93 Finding Your Voice . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94 Clarifying Site Purpose . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95 Text and the Computer Screen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96 Writing Effective Paragraphs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99 Varying Pace . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100

⽧⽧⽧

Contents

⽧ xi

Removing Extraneous Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Using Tables to Organize Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Using Lists to Simplify Ideas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Using Headers Meaningfully . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Applying Style Standards . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Avoiding Problem Grammar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Understand Copyright! . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Extending Copyright with Creative Commons . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Protecting Intellectual Property with Trademarks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . The Role of Patents on the Web . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . What Is Digital Rights Management? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Exploring Content Management Systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

102 102 104 105 106 107 107 108 109 110 110 111 112

Part II: HTML, XHTML, CSS, and Accessibility . . . . . . . . . . . . . 113 Chapter 6: Crafting Pages with HTML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115 Is HTML Easy? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . HTML is a Markup Language . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Face the Changes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Document Conformance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Author to the Specification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Validate the Document . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Create a Markup Style and Stick to It . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Understand Document Types and Language Versions . . . . . . . . . . . . . . . . . . . . . . . . . Use DOCTYPEs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . HTML is Root . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Use and Appropriately . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Always Use . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Manage Character Sets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Author Documents Structurally . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Use Lists to Enhance Structure and Readability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . and versus and . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Know your Document Tree . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Elements, Tags, and Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Intrinsic Events . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Special Characters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Limit Color Names to Standard Colors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Avoid the font Element . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Avoid the center Element . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Avoid All Deprecated, Obsolete, and Proprietary Elements and Attributes . . . . . . . Use Elements as They Were Intended . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Restrict Use of Tables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Restrict Use of Frames . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Validate, Validate, Validate! . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

116 116 116 117 117 118 118 119 122 123 124 125 125 127 128 130 131 133 134 135 136 136 138 138 139 140 141 141 142

Chapter 7: Moving Ahead with XHTML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143 About XHTML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144 History . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144

⽧ xii

Contents

⽧⽧⽧

Goals of XHTML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . XHTML Versions and DTDs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . So Is XHTML Better? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Choose a DTD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Avoid the XML Declaration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Use Correct XHTML DOCTYPEs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Add the Namespace to Root . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Implementing Style in XHTML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Adding Scripts in XHTML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . XHTML and Case Sensitivity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Quotation of Attribute Values in XHTML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Managing Nonempty Elements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Terminating Empty Elements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Managing Minimized Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Entities and XHTML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . alt Attribute Required . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Understand Well-Formedness . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Proper Nesting of Lists . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . DOCTYPE Switching . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Enclose Inline Elements in Blocks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . name Becomes id . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . The target Attribute is Unavailable in Anchor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

144 145 147 147 148 149 150 151 152 153 154 155 155 156 156 157 158 159 162 163 164 165 165

Chapter 8: Style Tips for Type and Design . . . . . . . . . . . . . . . . . . . . . . . . . . . 167 Learning CSS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . When to Use Linked Style . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . When to Use Embedded Style . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . When to Use Inline Styles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Importing Style . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Understand the Cascade . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Work with Inheritance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Be Aware of Specificity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Creating Multiple Link Styles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Link Effects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . CSS Borders and Border Styles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Gaining Space with Padding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Understanding Type Sizing Options in CSS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Type Effects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Styling Lists with CSS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Using Lists for Vertical Navigation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Using Lists for Horizontal Navigation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Spice Up Forms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Add Visual Effects to Data Tables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Using Background Graphics in CSS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Image Replacement Techniques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . CSS-Based Text Mouseovers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Text and Image Mouseovers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Dynamic CSS Menus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Rounded Tabs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Sliding Doors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Cool Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

168 168 169 170 170 171 171 173 174 177 179 181 182 182 186 188 190 191 193 195 196 198 201 202 205 205 207 207

⽧⽧⽧

Contents

⽧ xiii

Chapter 9: Laying Out Pages with CSS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 209 CSS Layout Basics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Two-Column Layout, Positioned Left Navigation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Float-Based Layout . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Nested Float . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Three-Column Layout . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Vertical Centering in CSS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Ordering DIVs for Backward Compatibility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . @import for Graceful Degradation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . CSS Hacking Strategies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . The Box Model Hack . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . The High Pass Filter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . The Mid Pass Filter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . IE 5.0 Windows Band Pass Filter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . IE 5.5 Windows Band Pass Filter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Opera Hacks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Understanding CSS Media Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Alternate Style Sheet for Print . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Alternate Style Sheet for Small-screen Media . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Alternate Style Sheet for Projection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . CSS Best Practices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

210 211 212 214 218 220 226 227 228 230 231 232 232 233 233 234 235 236 237 237 241

Chapter 10: Adding Accessibility Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . 243 What is Web Accessibility? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . The Advent of Accessibility Challenges . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Accessibility and Law . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Accessibility and You . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Describing Visual and Aural Content . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Providing Alternate Content . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . They’re NOT alt “Tags!” . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Use the title Attribute in Links . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Using the abbr Element for Abbreviations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Using the acronym Element for Acronyms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Understand the accesskey Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Index Link and Form Controls Using tabindex . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Group Form Selections with select and optgroup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Add fieldset and legend to Forms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Using the label Element with Forms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Summarize and Caption Data Tables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Consider Using Skip Links . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Making Frames Accessible . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Testing with Accessibility Validators . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Testing with Lynx . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Testing with Screen Reader Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

244 244 246 247 247 247 249 249 251 252 254 255 256 258 259 260 263 265 266 267 267 268

Part III: Designing Sites for Long-Term Success . . . . . . . . . . 269 Chapter 11: Sophisticated Visual Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 271 Visual Design and Site Intent . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272

⽧ xiv

Contents

⽧⽧⽧

Defining and Maintaining Your Brand . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . GIFs and JPEGs: Still Your Secret Graphic Weapon . . . . . . . . . . . . . . . . . . . . . . . . . . . Refinding the Lost Promise of PNG . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . GIF Animation Do’s and Don’ts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Image Maps: To Use or Not to Use . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Make the Most Out of Text-Based Type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Combine Graphics and Markup for Effective Typography . . . . . . . . . . . . . . . . . . . . . . What Is White Space and Why Do I Care? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . The Importance of Proximity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . There’s No Such Thing as Web-Safe Color . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Making the Most Out of Web Color . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . The Symbolic Meaning of Shapes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . The Psychology of Color . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Color and Culture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Color and Gender . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Color Tips . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Exploring Scalable Vector Graphics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

272 273 276 278 278 279 280 280 282 284 285 287 287 288 290 290 291 292

Chapter 12: Spicing It Up with Dynamic Content . . . . . . . . . . . . . . . . . . . . . 293 All about Scripting and Rich Media . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . JavaScript, ECMAScript, and DOM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Using Rich Media . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Providing the Current Date . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Doing Popups Properly . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Randomize Images and Text . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Open a New Window Without target . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Check for Plug-Ins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Text Size Switching . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Style Sheet Switching for Visual Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Dynamic Menu Systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Forms Validation with JavaScript . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . The Trouble with applet, object, and embed . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Adding Flash and Complying with Standards . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Adding Audio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Adding Video . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . About Digital Storytelling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

294 294 296 297 298 301 307 309 310 315 317 319 320 322 323 324 326 327

Chapter 13: Keeping Sites Fresh and Engaging . . . . . . . . . . . . . . . . . . . . . . . 329 Use Personalization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Offer Useful Information and Applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Provide Random or Frequently Changed Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Add a Weblog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Consider Weblog Commenting Systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Offer Site Registration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Consider Cookies to Track Usage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . The Power of Polls . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Add Discussion Groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Use Web-based Chat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Refresh Your Page Style Regularly . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

330 332 334 335 337 338 340 341 343 343 346

⽧⽧⽧

Contents

⽧ xv

Style Sheet Switching for Customization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Add Search Technology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Aggregate Content . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

347 349 349 351

Chapter 14: Improving Site Ranking and Managing . . . . . . . . . . . . . . . . . . 353 About Web Site Marketing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Now Focus Is on Structure and Content . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Avoid Unscrupulous Marketing Techniques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Targeting Keywords for meta Elements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Writing Effective meta Descriptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Using Targeted Words in Headers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Using Keywords in Text . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Keeping URLs Short and Relevant . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Solicit Reciprocal Links . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Consider Affiliate Programs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Use Opt-In E-mail Newsletters to Drive Traffic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Run Regular and Seasonal Promotions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Learn More About Web Ads . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Add Sponsored Links . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Search Engine Submission . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Don’t Forget Offline Promotions! . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

354 354 355 356 357 358 359 360 361 361 363 364 365 366 367 368 368

Chapter 15: Dealing with Growth and Redesigns . . . . . . . . . . . . . . . . . . . . 369 The Importance of Server Logs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Develop a Regular Assessment Cycle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Ensure Scalability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Manage Content Growth . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . When to Redesign . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Map Redesign Projects and Timelines Carefully . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Express Upcoming Changes to Audience Members . . . . . . . . . . . . . . . . . . . . . . . . . . . Re-Evaluate Long-Term Goals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

370 372 373 374 374 375 376 377 378

Part IV: Appendixes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 379 Appendix A: Demystifying Service Provision . . . . . . . . . . . . . . . . . . . . . . . . . 381 Appendix B: Overview of Application and Database Technology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 387 Appendix C: Helpful Reading, Web Sites, and Resources . . . . . . . . . . . . . 393 Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 399

Acknowledgments This was my first book with Wiley Publishing, and I’mhappy to say it was a delightful experience. Katie Mohr is a most awesome acquisitions editor. Marcia Ellett always had a steady, calm eye as my development editor. My thanks also to the entire editorial team who helped make this book possible. It’s a fairly regular convention that computer book authors get to pick their technical editors. It’s also a fairly regular convention that there’s limited budget for TEs, but Ethan Marcotte (www.sidesh0w.com/) kept me on the straight and narrow with his technical edits and endless good cheer. From Waterside Productions, my agent David Fugate is always my shimmering knight in armor. For providing technical support, research, comments, and resources directly affecting this book, my thanks go in no specific order to Stephanie Troeth, Dunstan Orchard, Matthew Mullenweg, Eric A. Meyer, Tantek ¸Celik, Porter Glendinning, Dori Smith. At large: AdaptivePath, Boxes and Arrows, Digital Web Magazine, the entire blogging community, and, of course, to all my readers who keep me inspired and happy as a computer book author—no easy task.

Introduction Web design has come a long way in just over a decade. The concerns facing anyone working on Web sites are so complex and changing so rapidly that it’s downright overwhelming. From a consumer perspective, Web designs and redesigns can be very expensive. The goal of this book is to provide you with all the top-flight information you need to know to get up to speed with the best practices and standards being used by today’s practical but progressive Web sites such as ESPN and Wired News. We all need help to improve workflow, develop rich designs that can be accessed by numerous browsers and alternative devices such as cell phones and PDAs, create sites that meet legal concerns regarding content and accessibility, managing sites for the long term, and improve the financial bottom line by significantly reducing bandwidth and increasing revenue. Most likely you are a person who is working on public or private Web sites and is somewhat experienced with HTML and Web graphic design and are interested in ramping up to the next level of expertise. If you’re like me, you want to make your life easier by streamlining the design process and management, and increasing awareness and promotion of the sites you design and develop. Your primary job might not even be that of a Web designer—perhaps you are a scientist, librarian, documentation specialist, promotions specialist, educator, or serving in the armed forces. The people working on Web sites at this point in history come from a very wide range of backgrounds and professions, and we come from all parts of the globe. Some readers will be avid hobbyists, too, using the Web as a means for self-expression via Weblogs, social networks, and special interest groups. 250 HTML and Web Design Secrets looks into the detailed work required to create successful Web sites and provides extremely up-to-date approaches to dealing with an array of challenges that the creation of Web sites presents. Technologies and topics covered include tools, project management, information architecture, usability, content development and management, HTML, XHTML, and CSS, graphics and multimedia for the Web, accessibility, best uses of dynamic content and rich media, keeping content fresh, improving site ranking and promotions, and managing redesigns.

Using This Book Focusing on theory, standards, and rigid practices is, in a word, dry. 250 HTML and Web Design Secrets takes a fresh and fun approach, providing insider techniques that will help designers get the information they need. Instead of teaching individual languages or technologies, the lessons here are broken down into specific “secrets” that will help you immediately improve your current sites; help you build new sites that are visually exciting, extremely portable, and cross-platform compatible; help you manage redesigns; and take your sites from the past into a successful future. Another unique quality of the “Secrets” format of this book is that while it’s written to be read from start to finish, it can also be used as a quick reference when you’re facing a specific problem. The book consists of 15 chapters broken into three parts: “Tools, Planning, and Content;” “HTML, XHTML, CSS and Accessibility;” and “Designing Sites for Long-Term Success.” There are also three appendices to help you get more resources for Web site service provision, application, and database technologies, and references of a wide range of helpful Web sites, articles, books, and organizations that can help you constantly challenge and improve your skills beyond the scope of this book.

Part I

Tools, Planning, and Content Chapter 1: Setting Up a Master Toolbox Chapter 2: Managing Your Web Project Chapter 3: Architecting Your Information Chapter 4: Making Sites Usable and Persuasive Chapter 5: Creating and Managing Fantastic Content

Chapter

Setting up a Master Toolbox

1

⽧⽧⽧⽧⽧⽧⽧⽧⽧⽧⽧⽧⽧⽧⽧⽧⽧⽧⽧⽧⽧⽧⽧⽧⽧⽧⽧

Secrets in This Chapter #1: #2: #3: #4: #5: #6: #7: #8: #9: #10: #11: #12: #13: #14: #15: #16: #17: #18: #19: #20:

Web Browsers . . . . . . . . . . . . . . . Choosing a Code Editor . . . . . . . . . File Management with FTP . . . . . . . Telnet and SSH . . . . . . . . . . . . . . Validation Tools . . . . . . . . . . . . . . PNH Toolbar . . . . . . . . . . . . . . . Sidebar Reference Panels . . . . . . . . Bitmap Image Programs . . . . . . . . . Vector Image Programs . . . . . . . . . Web Animation Utilities . . . . . . . . . Screen Capture Utilities . . . . . . . . . Rename Utilities . . . . . . . . . . . . . Tag Strippers . . . . . . . . . . . . . . . HTML Tidy . . . . . . . . . . . . . . . . Compression Utilities . . . . . . . . . . Audio and Video Players . . . . . . . . . Plug-Ins . . . . . . . . . . . . . . . . . . SVG and SMIL Support . . . . . . . . . Software for Security and Safety . . . . Collaborative Communication Software

. . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . .

⽧⽧⽧⽧⽧⽧⽧⽧⽧⽧⽧⽧⽧⽧⽧⽧⽧⽧⽧⽧⽧⽧⽧⽧⽧⽧⽧

. . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . .

. 5 . 8 11 12 14 16 17 17 21 22 24 25 26 26 27 29 29 30 30 32

⽧ 4

Part I: Tools, Planning, and Content

⽧⽧⽧

W

hy start a book on Web design secrets with tools? Shouldn’t that be something left for an appendix, perhaps? After all, you want to get right down to the nitty-gritty, and I appreciate that. As any working Web designer knows, the master designer really needs very few tools at hand to create the ultimate Web design toolbox. A great designer can make do with a text editor, a Web browser, an imaging software program, and an FTP client. So why all the fuss? Well, for one thing, in today’s busy, mobile world, most Web designers’ work requires a range of specialty tools to help make life easier. This chapter comes first because I have an agenda. My goal is to celebrate the ideologies of the Web itself: open standards, cross-platform interoperability, accessibility, and portability. So while you’ll find plenty of familiar commercial tools in this chapter, what you’ll also find is a range of alternatives that are designed under open source licenses and that are available across platforms. In today’s economic environment, many professional programs can cost significant money, making a comprehensive toolbox seem at first glance to be costprohibitive. Yet the Web is filled with alternative software that is either distributed under GNU open source licensing, as freeware, or as low-cost shareware. While typically the open source tools were in use on UNIX and related open source platforms such as the many variants of Linux, there have been many recent ports to Windows and Mac OS X. As a result, a world of free or very low-cost tools has opened up to the Web designer. This chapter points you to those resources wherever available. GNU licensing refers to licenses distributed under the GNU project, which first emerged as an alternative to UNIX systems, resulting in the now very popular Linux program, and related operating systems. The GNU project is part of the Free Software Foundation, whose mission is to preserve and promote free software. More information on this important alternative form of software distribution can be found at www.gnu.org/.

note

The tools in this chapter help you to do the following: ⽧ ⽧ ⽧ ⽧ ⽧ ⽧ ⽧ ⽧ ⽧ ⽧

Author markup and CSS with ease Create great Web graphics Validate pages Test sites in a range of Web browsers Draw in vector-based environments Use bitmap imaging tools for Web graphic production Design animations Use plug-ins for video and audio Convert and clean up documents Compress documents

While this chapter won’t tell you how to use these tools, it will tell you which utilities you might want to consider adding to your toolbox; give guidance as to which tools are considered most useful and sophisticated, and provide resources

⽧⽧⽧

Chapter 1: Setting up a Master Toolbox

⽧ 5

as to where you can find the tools in question. You’re sure to find something new and helpful to add to your kit.

⽧ ⽧ ⽧

Secret #1: Web Browsers AOL has closed Netscape’s doors, and Microsoft has announced that no more standalone Internet Explorer (IE) versions will be produced and is waiting instead for the Longhorn Operating System, which includes an integrated browser. New browsers have been entering the market with somewhat daunting regularity— Apple Safari has fast become popular among many Mac users, and Mozilla Firefox is attracting users who want a lean but sophisticated Web browser. Opera continues to improve quietly, and Mozilla continues to develop its capabilities, now under the auspices of a nonprofit agency, The Mozilla Foundation, whose goal is to “preserve choice and innovation’’on the Internet. Browsers are clearly political. It’s very difficult to write about Web browsers at this time because they are in such a state of flux, and historically have been in a state of flux. Web browsers have been a number one concern for designers. The Web browser is the primary piece of software used by the designer and the site visitor to access Web pages. As a result, the ways in which browsers interpret (or don’t interpret) the languages and techniques we use to design our pages can cause significant frustration for both the designers and site visitors.

Figure 1-1: As of this writing, Internet Explorer 6.0 for Windows is felt to be the most used browser.

⽧ 6

Part I: Tools, Planning, and Content

⽧⽧⽧

What can you do to navigate these difficult waters? The secret boils down to having a twofold approach. ⽧ ⽧

Select the browser you want to use for development Have a range of browsers to emulate your client’s needs

Fortunately, there are ways of determining which browsers you’ll want to have for testing. One way is from general statistics, which show you that at this time, IE 6.0 is considered to be the most used browser on earth (see Figure 1-1). You can also look at your own server logs, which tell you the browsers visiting the sites in question (see Figure 1-2).

Figure 1-2: Browser usage from Molly.Com, Inc. shows me which browsers are being used to access my Web pages. While you should always use statistics as a determining factor in how you will design and test a given site, you will want some specific browser in your toolbox no matter what (refer to Table 1-1). Ideally, you’ll also have more than one platform to work on—at the very least a version of Windows and Macintosh operating systems. However, this is not entirely necessary, and I provide some helpful tips here if you don’t have the luxury of more than one available testing machine.

Table 1-1: Web Browser Toolbox Browser and Version

Platform

Reason Needed

IE 6.0

Windows

Considered the most commonly used browser

IE 5.5

Windows

Common browser, specific bugs in CSS support that require testing

⽧⽧⽧

Chapter 1: Setting up a Master Toolbox

⽧ 7

Browser and Version

Platform

Reason Needed

IE 5.01

Windows

Still in widespread use; has bugs, and should be used in testing

Netscape 4.7

Windows

Problematic browser because of partial CSS support. Despite the fact that it’s over four years old, this browser remains on many institutional systems due to security and application concerns

Mozilla

Windows, Macintosh, Linux, and others

Sophisticated browser with excellent standards support, cross-platform consistency, and an excellent browser for development

Opera

Windows, Macintosh, Linux, and others

Good browser for CSS testing; OperaShow is an excellent CSS-projection feature not found in other browsers. The Macintosh version has not been advanced as far as other versions

IE 5.0

Macintosh

Popular browser used by many Macintosh users, especially those on operating systems earlier than OSX

Safari

Macintosh

Sophisticated browser from Apple, of growing interest within the Macintosh community, but only available for OSX and above. Is the default browser on all new Apple computers

Lynx

Windows, Macintosh, VMS, UNIX

Text-only browser helpful in testing for accessibility purposes

note

You can now run more than one version of IE on a given machine. This was only recently made public when a bug was found in the developer upgrade to IE 6.0. See www.skyzyx.com/archives/000094.php for more information. For a pay-per-view testing service, see www.browsercam.com/, which allows you to see your work on a variety of browsers and platforms you might not have for a reasonable fee. You can see how your site looks in the current version of Safari at www.danvine.com/icapture/, and to see how your site will look in the Konqueror browser, visit http://kcapture .eadz.co.nz/.

My personal favorite browser in which to develop sites is Mozilla (see Figure 1-3). The reason is because there are a number of tools both within it and available for it so it becomes an ideal working environment (you can get similar functionality

⽧ 8

Part I: Tools, Planning, and Content

⽧⽧⽧

Figure 1-3: The Mozilla Web browser is an extremely flexible, useful browser with special features for designers and developers. with Netscape 7.0 and Mozilla Firefox). What’s more, it’s available for every conceivable platform, is open source, and constantly improving.

⽧ ⽧ ⽧

Secret #2: Choosing a Code Editor There are three primary categories of editors you can use to write HTML, XHTML, XML, CSS, and JavaScript (as well as any other ASCII-based languages). ⽧





ASCII text editors. These editors have very few features beyond word-wrap and save, but if you know your code, they can be excellent for quick fixes or even full jobs. Commercial code editors. These editors are ASCII editors with power tools, such as wizards, to help you add images. They are my personal favorite for most of the work I do with HTML, XHTML, and CSS. Commercial visual editing packages. These are full-service Web design software applications that include some means for the designer to work visually without worrying about the code being generated.

Table 1-2 shows some of the primary products within each category type along with platform and features. So how do you make the best choice? The secret is to have at least one of each type available. You’ll find yourself using a combination of tools for most jobs. My dream team editing toolboxes are as follows.

⽧⽧⽧

Chapter 1: Setting up a Master Toolbox

Table 1-2: Popular Code Editor Features Editor

Editor Type and Platform

⽧ 9

Features/Availability

vi

ASCII text editor for UNIX, OS X, Linux, VMS

Native to most UNIX systems; free

Emacs

ASCII text editor for UNIX, Linux, OS X, VMS and even Windows

Open-source, www.gnu.org/ software/emacs/emacs.html.

Notepad

ASCII text editor for Windows

Native to Windows systems; free

SimpleText

ASCII text editor for Macintosh (pre OS X)

Native to Macintosh prior to OS X; free

TextEdit

ASCII text editor for OS X

Native to OS X; free

Homesite

Windows-based HTML editor with support for a number of ASCII-based languages

Very popular with many professional designers on the Windows platform. Fee-based, but there’s a 30-day full trial version to try before you buy, www .macromedia.com/software/ homesite/

BBEdit

Macintosh-based HTML editor with support for numerous ASCII-based languages

Very popular with many professionals on the Mac platform. Fee-based, but with a try-before-you-buy demo, www. barebones.com/products/ bbedit/index.shtml

Adobe GoLive CS

Visual editor for Macintosh and Windows

Popular with some professionals; has improved greatly but still generates some problematic and proprietary markup. Fee-based, free demo

Macromedia Dreamweaver MX 2004

Visual editor for Macintosh and Windows

Popular with many Web design professionals, has very good standards support and integrates well with application technologies such as ColdFusion, JSP, and so forth. Fee-based, free demo

Microsoft FrontPage 2003

Visual editor for Windows

In widespread use due to the proliferation of Office in many organizations. Biggest appeal is its ease of use for nondesigners. Has some nice features including good support for CSS, but is typically not recommended for the Web design professional unless he or she is also educated in markup and CSS

⽧ 10

Part I: Tools, Planning, and Content

⽧⽧⽧

For Windows: ⽧ ⽧ ⽧

Notepad (see Figure 1-4) Homesite (see Figure 1-5) Macromedia Dreamweaver MX 2004 (see Figure 1-6)

Figure 1-4: Editing a page in notepad.

Figure 1-5: Using Homesite, a more robust editor.

⽧⽧⽧

Chapter 1: Setting up a Master Toolbox

⽧ 11

Figure 1-6: Working on the same document in design mode of Dreamweaver MX 2004. For Macintosh: ⽧ ⽧ ⽧

SimpleText (or TextEdit on OS X) BBEdit Macromedia Dreamweaver MX 2004

However, just because these are my favorite combinations doesn’t mean they’ll be yours. The best thing you can do is download the free trials and work with a range of tools before making any decisions.

tip

There are many more editors than I’ve named here. You can do broader-range searches at your favorite search engine to ensure that you’ll find those editors most appropriate to your needs.

⽧ ⽧ ⽧

Secret #3: File Management with FTP File Transfer Protocol (FTP) is one of a variety of protocols that run on the Internet. An FTP client allows you to transfer any kind of file from a local computer to a remote server, and depending upon the capabilities of the client you’re using, perform important functions such as changing file permissions.

There are many FTP clients—even Web browsers and mechanisms within OS can act as FTP clients. But for full features, most folks turn to a handful of respected and flexible FTP software. Table 1-3 provides details.

⽧ 12

Part I: Tools, Planning, and Content

⽧⽧⽧

Table 1-3: Popular FTP Clients and Features Client

Platform

Features/Availability

WS FTP

Windows

Full-featured file transfer program, customizable, inexpensive

CuteFTP

Windows

Popular, full-featured FTP, inexpensive

FTPClient

Macintosh

Transmit

Macintosh

Fetch

Macintosh

Unlike browsers or code editors, you only need one FTP client on hand (see Figure 1-7).

Figure 1-7: Use WS FTP (classic view) for a wide range of transfer and file management needs. Many HTML and visual editors have FTP features built right in. However, even with those features, because most Web designers work using a variety of tools, having a standalone FTP client in your toolbox is a definite plus.

⽧ ⽧ ⽧

Secret #4: Telnet and SSH Like FTP, Telnet is an Internet protocol. Its function is to allow you to have linebased entry to a remote server so that you can perform remote functions from your local machine with ease. Telnet is available natively on most operating systems. For example, if you select Start ➪ Run and type telnet into the textbox in Windows,

⽧⽧⽧

Chapter 1: Setting up a Master Toolbox

⽧ 13

you’ll get a Telnet console. Telnet clients provide additional features that can be very useful too, so it’s often good to have at least one on hand.

Secure Shell (SSH) is a form of Telnet that includes increased security features. Nowadays, most well-run Web servers will prefer you to use Telnet with SSH enabled. Many standalone Telnet clients now integrate SSH into their feature lists, and many operating systems, including Mac OS X and Windows 95, 98, 2000, and XP, have some form of Telnet built into the system. Table 1-4 describes the top three Telnet/SSH clients and related features.

Table 1-4: Telnet and SSH Clients Telnet/SSH Client

Platform

Features/Availability

PuTTY

Windows, all versions

Free and downloadable from www.chiark.greenend.org.uk/ ∼sgtatham/putty/

NiftyTelnet

Macintosh, pre OS X

Freeware, available at http://asg.web.cmu.edu/andrew2/ dist/niftytelnet.html

OpenSSH

Linux and related platforms

Freeware, www.openssh.com/. OpenSSH is also the SSH technology built into Mac OS X

Figure 1-8: Configuring PuTTY on Windows 2000 to perform an SSH login to a remote Web server.

⽧ 14

Part I: Tools, Planning, and Content

⽧⽧⽧

You’ll only need one Telnet/SSH client in your toolbox, so take advantage of what’s either built in to your operating system or to one of these excellent freeware utilities. Figure 1-8 shows me using PuTTy to log in to a remote Web server and perform tasks.

⽧ ⽧ ⽧

Secret #5: Validation Tools Validating markup, CSS, and accessibility is becoming more and more important for professional Web designers. A variety of online validators can be helpful, but there are also standalone and add-in products for existing programs. Table 1-5 describes some of the popular validation tools available to you. Figure 1-9 shows a page being validated by the CSE HTML Pro standalone validator.

Table 1-5: Validation Tools for Markup, CSS, and Accessibility Validation Tool

Platform and Usage

Availability

W3C HTML and XHTML Validation

Online service. You can add by URL or by upload

http://validator.w3.org/

W3C CSS Validation

Online service. Validate by URI, paste into text area or upload. A standalone version is available

http://jigsaw.w3.org/css-validator/

CSE HTML Validator Pro

A professional standalone for Windows that validates XHTML, HTML, CSS, and Accessibility. Very powerful, highly recommended

www.htmlvalidator.com/

Bobby

Offers both online and standalone validation for accessibility

Standalone:www.watchfire.com/products/ desktop/bobby/default.aspx Online: http://bobby.watchfire.com/bobby/html/ en/index.jsp

Cynthia Says

Online validator

www.cynthiasays.com/

Lift

Multiple plug-in, standalone, and online accessibility and usability validation

www.usablenet.com/products services/ products services.html

Macromedia Dreamweaver MX, MX 2004

Built-in HTML, XHTML validation

Good validation if preferences are set up properly. Can be integrated with the Lift validation tool for Macromedia for accessibility and usability

⽧⽧⽧

Chapter 1: Setting up a Master Toolbox

⽧ 15

Validation Tool

Platform and Usage

Availability

Adobe GoLive

Built-in validation for HTML and XHTML

Good validation, but nothing for CSS or accessibility

FrontPage 2003

No internal validation

Can be used with the Lift validation tool for Microsoft FrontPage for accessibility and usability

Figure 1-9: Validating a page with CSE HTML Pro.

Of course, as with other tools mentioned in this chapter, these are popular and comprehensive tools. A range of additional tools perform these or similar processes; they are available for multiple platforms and offered as freeware, shareware, and commercial licensing. Again, the secret is to find the best validation services for your needs and stick to them.

caution

Accessibility validation is an especially difficult issue because it’s recommended that you use multiple validators. In addition, accessibility validators don’t measure visual issues, so you have to use them just as you would a grammar checking utility—rely on a balance of the validator feedback and your own knowledge. Markup and CSS validators are more specific because they test against the specifications for the defined languages in question.

⽧ 16

Part I: Tools, Planning, and Content

⽧⽧⽧

⽧ ⽧ ⽧

Secret #6: PNH Toolbar Till this point, you’ve read about tools that are broad in scope. The PNH toolbar is a very specific utility that I’ve found absolutely invaluable as part of my Web design toolbox. The PNH toolbar is completely free, available across platforms, and can be installed in Netscape 7.0+, Mozilla 1.0+, and Mozilla Firefox Web browsers instantly. Once installed, you can use its reference links and fantastic utilities while you’re developing pages. Some of the PNH toolbar features include the following: ⽧ ⽧ ⽧

⽧ ⽧ ⽧

Instant access to W3C reference materials Page testing where any open document can be run through HTML, CSS, Accessibility, and other validation tools in a background tab Allows you to disable styles on a given page, add an external style sheet to any page open within the browser, outline block elements, outline replaced elements, outline table cells, turn off images, and resize your browser window to custom as well as conventional sizes View form and cookie details View source Access additional Mozilla and related tools instantly

Figure 1-10 shows me turning on the table cells of a table-based page.

Figure 1-10: Using the PNH toolbar to view the table structure of an HTML page.

⽧⽧⽧

Chapter 1: Setting up a Master Toolbox

⽧ 17

Download the PNH toolbar from http://placenamehere.com/ pnhtoolbar/.

note

⽧ ⽧ ⽧

Secret #7: Sidebar Reference Panels Netscape 7 and Mozilla contain a sidebar panel (F9). This panel has a range of utilities, such as search, with which the browsers ship, but there are also additional sidebar panels that individuals have created. Some of these panels are extremely valuable for Web designers to have as they offer immediate, in-browser access to aspects of design. Sidebar panels of immediate relevance to Web designers include the following: ⽧ ⽧ ⽧ ⽧ ⽧

CSS 2 and CSS 2.1 sidebar reference panels (available in French, too) HTML 4.01 sidebar reference panel Document Object Model 2 (DOM 2) sidebar reference panel (also available in French) JavaScript sidebar reference panels and guides (multiple versions) XSLT 1.0 (Extensible Style Language with Transformations) sidebar reference panel

Each of these panels is available completely free and install instantly. Once in place, the panels act as references by both the information they contain within them and the fact that references are linked to the specifications they represent. If I’m working on a site using CSS 2, and I want to know how to use a certain property, I simply open the CSS 2 side panel (shown in Figure 1-11), find the property in question, and click the reference. My browser then takes me directly to the topic within the specification (see Figure 1-12). Currently, sidebar panels can be downloaded from the Netscape DevEdge site, http://devedge.netscape.com/toolbox/sidebars/. It’s unknown at this time whether AOL will continue to host that site indefinitely. If you cannot resolve the site, visit the Web Standards Project, www.webstandards.org/, which has committed to ensuring the location of these panels will always be made available.

tip

Side panels are quite easy to make for anyone with HTML skills, so if you are interested in creating helpful tools and utilities, you might want to read more about how to make side panels at http://devedge.netscape.com/ viewsource/2002/sidebar/.

⽧ ⽧ ⽧

Secret #8: Bitmap Image Programs Bitmap graphics are the primary form of graphics on the Web, and having a program that creates and optimizes them is essential. Bitmap graphics, also referred to as raster graphics, are graphics where the image is made up of tiny boxes of color, known as pixels. Pixel-based graphics typically can be compressed very well, but

⽧ 18

Part I: Tools, Planning, and Content

⽧⽧⽧

Figure 1-11: The CSS 2 side panel, close-view.

Figure 1-12: The CSS panel with the specification open in the browser window.

⽧⽧⽧

Chapter 1: Setting up a Master Toolbox

⽧ 19

do not scale well because data becomes lost as you attempt to enlarge a pixel-based image.

note

Many bitmap-based imaging programs, such as Photoshop, do contain some support for vector-based graphics, which you’ll read about in the next secret. Still, they are primarily used for the creation of raster graphics.

One thing that’s no secret is how ubiquitous Photoshop is for Windows and Macintosh users. And while every professional Web designer should really be familiar with and use Photoshop (shown in Figure 1-13), some other bitmap imaging programs also enjoy fairly widespread use.

Figure 1-13: Working on a client site in Photoshop. For Macintosh and Windows, Macromedia Fireworks (shown in Figure 1-14) is a very popular bitmap imaging program, and JASC’s Paint Shop Pro has a certain cult-like following among Windows-based Web design enthusiasts. Corel offers a complete drawing program with its Draw suite, but its use seems very limited among people working on the Web. A surprise for bitmap imaging needs is The Gimp. The Gimp stands for “GNU Image Manipulation Program’’ and is an open source bitmap drawing software program that works on UNIX and related systems, as well as having versions for the Macintosh and Windows (see Figure 1-15). The Linux and Windows versions of Gimp are freely distributed. You can also run Gimp under OSX for free, although the MacGimp version runs around $20 to download (a far cry from the hundreds to even thousands of dollars other bitmapping programs will cost you).

⽧ 20

Part I: Tools, Planning, and Content

⽧⽧⽧

Figure 1-14: Fireworks is extremely popular for bitmap production.

Figure 1-15: Designing graphics using The Gimp, a freely distributed open-source imaging program.

⽧⽧⽧

note

Chapter 1: Setting up a Master Toolbox

⽧ 21

For information on Adobe Photoshop, please visitwww.adobe.com/. Macromedia Fireworks can be found at www.macromedia.com/. Corel products are showcased at www.corel.com/, and JASC’s Paint Shop Pro is available at www.jasc.com/. The Gimp for UNIX and Windows can be found at www.gimp.org/, and The Gimp for Mac OS X is at www.macgimp.org/.

⽧ ⽧ ⽧

Secret #9: Vector Image Programs For those of you who create logos, refine type, and enjoy drawing, the two most common drawing programs are Adobe Illustrator and Macromedia Freehand (shown in Figure 1-16). Vector-based images differ from bitmap graphics in that they contain the mathematical information necessary to allow them to be scaled without loss of quality. They are extremely useful for creating curves and shapes. Of course, you will need to rasterize your final work by converting it to bitmap formats, such as GIF or JPEG, if you’re going to use your illustration on the Web, but you can achieve far more complex drawing tasks in a vector-based program.

Figure 1-16: Drawing geometric shapes in Macromedia Freehand. As with bitmap programs, there are a few shareware and open source gems that shouldn’tbe overlooked, especially for those on a limited budget, who have lighterweight needs for vector drawing.

⽧ 22

Part I: Tools, Planning, and Content

⽧⽧⽧

Two such bitmap programs are: ⽧



Mayura Draw is a shareware vector drawing program for Windows, at $39.00 per license. Used mostly by scientists and engineers for technical illustrations, Mayura Draw can be an invaluable and inexpensive tool in your design toolbox (see Figure 1-17). Sketch is a freely distributed open source drawing program for Linux, with a Windows port version called “Skencil.’’

Figure 1-17: Using Mayura Draw for vector-based design.

tip

Web designers and developers using Linux platform and open source software for designing graphics should check out LinuxArtist.Org, at www.linuxartist.org/2d.php. For additional free vector drawing software resources, see http:// bourbon.usc.edu:8001/tgif/vector.html.

⽧ ⽧ ⽧

Secret #10: Web Animation Utilities Outside of animation for advertising, GIF animations have somewhat fallen out of favor for use on professional Web sites—except for those instances where very subtle effects are desired. Of course, much of this has to do with the proliferation of Macromedia Flash (which has also influenced Web advertising). Nevertheless, GIF animations are sill desired in some cases, so make sure you have one on hand.

⽧⽧⽧

Chapter 1: Setting up a Master Toolbox

⽧ 23

As with all software and utilities, some of the available Web animation utilities are commercial, and some are completely free. Table 1-6 provides a variety of popular options from which to choose.

Table 1-6: Popular Web Animation Utilities Software

Platform and Usage

Availability

Ulead Gif Animator

Windows; very popular with many designers

Commercial, low-cost product with 30-day demo, www.ulead .com/ga/runme.htm

GIF Construction Set

One of the oldest GIF animators around for Windows

Low-cost shareware, www.mindworkshop.com/ alchemy/gifcon.html

GIF Builder

Very popular for Mac OS 9 and earlier

Low-cost shareware, www.mac.org/graphics/ gifbuilder/

GIF Builder for OS X

Mac OS X (will run on Mac OS 8 and above)

Freeware, www.macupdate.com/info .php/id/235

GIF Merge

Linux and related platforms

http://the-labs.com/ GIFMerge/

The majority of Web designers, however, tend to use Adobe ImageReady for animations. ImageReady (shown in Figure 1-18) ships with Photoshop and is available for Windows and Macintosh.

Figure 1-18: Creating a GIF animation in Adobe ImageReady.

⽧ 24

Part I: Tools, Planning, and Content

⽧⽧⽧

⽧ ⽧ ⽧

Secret #11: Screen Capture Utilities By far, some of the most helpful utilities I’ve ever used are those that assist with screen capturing. Such utilities are invaluable when creating Web site portfolios, sharing mockups with co-workers and colleagues, and so on. While screen captures can be done with almost any imaging program, such as Photoshop, screen capture utilities let you hone in on specific portions of the screen and capture menus, dialogs, and toolbars with ease. This can be very helpful and save a lot of time—instead of cropping full-screen images, you can instantly get what you need and, in most cases, output it to numerous useful file formats. Many excellent screen-capture utilities are available for all platforms, but the three most reportedly beloved are as follows: ⽧





For Windows, SnagIt by TechSmith is an amazing utility that I find myself using almost daily. You can find this low-cost shareware at www.techsmith.com/products/snagit/. Find low-cost shareware ScreenShot Pro, for Mac and Mac OS X at www.code-line.com/software/screenshotpro.html. OSX is packaged with two screen-capture utilities, one within the operating system itself, and the other a feature called Grab. For Linux, the KDE desktop environment has screen shot utilities built in (www.kde.org/), and The Gimp, discussed in the bitmap imaging section earlier, does a great job with screen captures.

Figure 1-19 shows me preparing to capture a screen using SnagIt.

Figure 1-19: Working with SnagIt to create screen shots.

⽧⽧⽧

Chapter 1: Setting up a Master Toolbox

⽧ ⽧ ⽧

⽧ 25

Secret #12: Rename Utilities For the many Web designers working on a Windows platform, easy ways to rename numerous files locally can be problematic. Let’ssay you want to take a directory full of files with the suffix .html, retain the files’ unique prefixes, and change the suffix globally to .php. To do this directly on an open-source operating system from the command line is very simple, but for Windows and Macintosh (except if you use the command line in OS X) you need a rename utility to perform the task effectively.

For Windows and Mac OS X, a low-cost, shareware program that’ll help you perform rename tasks on your local machine is “A Better File Rename.’’Not only does it do the job, but the company that makes the product, PublicSpace, also has a special Web master program allowing you to link to the company and get the software free. Or, if you run a site where you can place their ad banner, you can get more than one product free. Figure 1-20 shows a rename process using A Better File Rename.

Figure 1-20: Working with A Better File Rename to batch rename files locally.

note

To download A Better File Rename, see www.publicspace.net/ ABetterFinderRename/. For the Web master program, visit www.publicspace.net/ webmasters/index.html.

⽧ 26

Part I: Tools, Planning, and Content

⽧⽧⽧

⽧ ⽧ ⽧

Secret #13: Tag Strippers Another important utility that you’ll want to have is an HTML tag stripper. Utilities of this type let you take an HTML or related Web document and strip all the code out of it, leaving you with just the text. In some cases, commercial Web design software contains such utilities. Examples include Macintosh BBEdit (mentioned in the previous “Code Editor’’ section), Homesite, and ColdFusion Studio. In the case of Dreamweaver for both Macintosh and Windows, you can add an extension such as Tag Stripper, (www.massimocorner.com/dw/commands/tag_stripper.mxp), which will do the trick for you. Check your favorite editor for this feature. Even if you have features of this nature within your main software, you still might want to have a lightweight, fast, standalone stripper available. What’s more, tag strippers tend to offer more advanced features anyway, such as maintaining logical formatting of text, converting tables into tab-delimited format, and changing HTML entities to proper text characters. Table 1-7 shows a variety of helpful, lowcost tag strippers.

Table 1-7: Helpful Tag Stripper Software Software

Platform and Usage

Availability

Detagger

Windows

Low-cost shareware, www.jafsoft .com/detagger/

HTTC – HTML to Text Converter

Windows, Linux

Free under GNU license, www. franksworld.net/httc/

Html2text

Linux; command line in English and German

Open source freeware, http:// userpage.fu-berlin.de/ ∼mbayer/tools/ html2text.html

HTML Markdown

Macintosh Classic

Low-cost shareware, www. printerport.com/klephacks/ markdowndocs.html

Figure 1-21 shows me stripping an HTML page using Detagger.

⽧ ⽧ ⽧

Secret #14: HTML Tidy Just as a handy tag stripper gets rid of tags, conversion software such as HTML Tidy can be really useful. Not only does Tidy convert text to HTML, but it also converts HTML to XHTML or to XML. It also validates your markup and fixes additional markup problems. A very sophisticated tool, it’s available for every platform and is freely distributed via http://tidy.sourceforge.net/.

⽧⽧⽧

Chapter 1: Setting up a Master Toolbox

⽧ 27

Figure 1-21: Using Detagger to remove HTML tags.

tip

HTML Tidy is built into a wide range of shareware code editors and utilities. Be sure to check the sourceforge Web site for additional resources.

In Figure 1-22, I’m using TidyGUI, a simple GUI interface to Tidy, to clean a document.

⽧ ⽧ ⽧

Secret #15: Compression Utilities Compression utilities are one of the most critical tools you’ll need. And, with today’s more efficient compression, not only are you able to compress files for more efficient e-mail, FTP, Web site downloads and storage, but you can extract them easily, too. One of the biggest issues in compression is cross-platform compatibility. In the past, most UNIX and related operating systems used certain compression formats, Macintosh used others, and Windows still others. Sending files back and forth or making them available in compressed formats on Web sites always means making sure you’ve got software capable of cross-platform compression and extraction. For Windows, the most widely used package for this is WinZip (www.winzip .com/), a low-cost shareware utility that creates and extracts a wide number of compression formats that are used across platforms (see Figure 1-23).

⽧ 28

Part I: Tools, Planning, and Content

⽧⽧⽧

Figure 1-22: Tidy literally “tidies up” your documents.

Figure 1-23: Creating a zip format for downloadable media files. For Macintosh, a commonly used package is StuffIt, which is also available for Windows and Linux. It’s an excellent commercial choice—it’s low-cost, cross-platform compatible, and easy to use. You can find it at www.stuffit.com/. For a good graphical interface that provides multicompression, multiextraction on Linux, gnochive is available for free at http://gnochive.sourceforge.net/.

⽧⽧⽧

Chapter 1: Setting up a Master Toolbox

⽧ ⽧ ⽧

⽧ 29

Secret #16: Audio and Video Players Audio players are necessary for Web designers who are both working with audio and video as well as visiting Web sites where forms of audio and video are in use. At this point, many audio players are also video players, as you’ll see.

Many players are available these days. Table 1-8 provides a best-of-breed and most popular list.

Table 1-8: Popular Audio Players Software

Platform and Features

Availability

RealPlayer

Windows, Mac, Plug-in for Linux. Support for all common audio and video formats with emphasis on Real streaming media and SMIL formats

Free and pay versions available at www.real.com/

Apple QuickTime

Windows, Mac. Support for all common audio and video formats with an emphasis on the QuickTime format

Free and pay versions available at http://quicktime .apple.com/

Microsoft Windows Media Player

Windows, Mac. Popular media player capable of supporting almost all audio and video formats, emphasis on Windows Media file format

Available with Windows Operating Systems and the IE Web browser and for download, at www .microsoft.com/ windows/windowsmedia/

WinAmp

Windows. Very popular media player with support for most media types

Free and pay versions available at www.winamp.com/

note

An emerging alternative for multimedia is Ogg Vorbis, a project that is fully open, nonproprietary, patent and royalty free, available at www.xiph.org/ ogg/vorbis/.

⽧ ⽧ ⽧

Secret #17: Plug-Ins For a number of technologies, it’s helpful to have plug-ins already installed in your browsers. This helps you avoid having to download plug-ins for commonly used tasks.

⽧ 30

Part I: Tools, Planning, and Content

note

For Real and QuickTime plug-ins, see the player pages available in the preceding Audio and Video Player section.

⽧⽧⽧

The most ubiquitous plug-in is for Flash. You can download the Flash plug-in at www.macromedia.com/software/flashplayer/. You’ll also want the Shockwave plug-in, found at www.macromedia.com/software/shockwaveplayer/. Another very important plug-in is Java. This product establishes a connection between your Web browser and Java platform products. It’s available at http://java.sun.com/products/plugin/. The Acrobat plug-in is invaluable for Web designers. It allows you to download Portable Document Format (PDF) files directly to your Web browser; find it at www.adobe.com/products/acrobat/readstep2.html.

⽧ ⽧ ⽧

Secret #18: SVG and SMIL Support While not prevalent, Scalable Vector Graphics (SVG) and Synchronized Multimedia Integration Language (SMIL) are two open-standards technologies geared at aspects of imaging and multimedia. Because of growing interest in these technologies, you will want to have some resources at hand should you decide to work with either. To study and work with SVG and SMIL, you need the following (free) support items: ⽧ ⽧ ⽧

Adobe offers an SVG viewer for Windows and Macintosh at www.adobe .com/svg/viewer/install/main.html. Corel has an SVG viewer for Windows at www.smartgraphics.com/ Viewer_prod_info.shtml. RealPlayer offers the best support for SMIL at www.real.com/ realoneplayer.htm.

⽧ ⽧ ⽧

Secret #19: Software for Security and Safety While the majority of security concerns in Web design and development lie on the server side of things, protecting your local computer(s) is an essential aspect of being a professional Web master. The reasons are many and include the protection of your intellectual property (IP) to limit or eliminate the possibility of spreading viruses or worms in networks, software, Word documents, and e-mail; and to prevent the proliferation of spyware, adware, and other malicious browser-oriented concerns that can be spread via browsers and peer-to-peer communication systems. To do a good job of protecting any local machine, you’ll want: ⽧

Up-to-date antivirus software

⽧⽧⽧

⽧ ⽧

Chapter 1: Setting up a Master Toolbox

⽧ 31

Firewall software (many firewall features are being built into operating systems, but they aren’t always considered as safe as additional products) Adware protection

You should also always make sure to perform routine upgrades to your operating system and add patches when they are available. Table 1-9 lists helpful security and safety software.

Table 1-9: Helpful Security and Safety Software Software

Platform and Features

Availability

McAfee Software

Variety of commercial packages for antivirus, firewall, and additional protection for Windows

Commercial standalone and subscription products available at www.mcafee.com/

Norton Software

Variety of commercial packages for antivirus, firewall, and additional protection for Windows and Macintosh

Commercial standalone and subscription products available at www.norton.com/

Sophos

Antivirus software for multiple platforms

Commercial standalone software, available at www.sophos.com/

Vexira Anti Virus

Antivirus software for Windows and Linux

Commercial software, available at www.centralcommand.com/

Zone Alarm Firewall

Firewall software for Windows

Free and fee-based options, available at www.zonelabs.com/

Brick House

Firewall software for Macintosh OS X

Low-cost shareware, available at http://personalpages.tds .net/∼brian_hill/ brickhouse.html

Firestarter

Firewall software for Linux and related systems

Freeware, available at http:// firestarter.sourceforge .net/index.php

Spybot

Windows removal system for spyware and related problems

Free (donations at your discretion), available at www.safernetworking.org/

AdAware

Windows removal system for spyware and related concerns

Highly recommended, free and pro versions available at www .lavasoftusa.com/

Internet Cleanup

Macintosh removal system for spyware and related issues

Commercial product, low-cost, available at www.aladdinsys .com/mac/cleanup/ index.html

Mac Scan

Macintosh removal system for spyware and related issues

Free, and available at http:// macscan.securemac.com/

⽧ 32

Part I: Tools, Planning, and Content

⽧⽧⽧

Windows platforms are the most vulnerable to viruses and spyware. Macintosh is less so, especially OS X, but there are still some concerns with the Macintosh platform. Linux platforms suffer very few problems, if any, with viruses, spyware, and adware, because experienced users spot malicious code, and Linux and related platforms are very, very security-conscious to begin with.

note

Figure 1-24 shows me using AdAware to scan my local drives for adware, spyware, and other malicious software.

Figure 1-24: Creating a zip format for downloadable media files.

⽧ ⽧ ⽧

Secret #20: Collaborative Communication Software You know that instant messaging (IM) can be totally counterproductive to workflow. On the other hand, for those Web designers and developers working collaboratively from different locales—possibly even around the world—there’s nothing like IM to make life easy. There are four primary IM clients: ⽧ ⽧ ⽧ ⽧

AOL Instant messenger (AIM) can be downloaded at www.aim.com/ (for Windows, Mac, or Linux). MSN Messenger is downloadable from http://messenger.msn.com/ (for Windows and Mac). Yahoo! Messenger can be downloaded from http://messenger.yahoo .com/ (for Windows, Mac, UNIX and UNIX-related systems). ICQ is available from www.icq.com/ (for Windows and Mac).

All of them are free, and all entertain some level of popularity. The problem is that they are all proprietary and don’t work with each other (with the exception of AIM and ICQ, as both are owned by AOL)—meaning that if your collaborator pal in

⽧⽧⽧

Chapter 1: Setting up a Master Toolbox

⽧ 33

Moscow uses AIM and you use MSN, you’re not going to be able to chat if you’re using the proprietary clients. Fortunately, there are alternative clients available that transcend the proprietary silliness and do so in impressive ways, as shown in Table 1-10.

Table 1-10: Cross-Service Collaboration Software Software

Platform and Features

Availability

Trillian

Windows. Supports AIM, MSN, Yahoo!, ICQ, IRC, has e-mail support, chat, plug-ins can extend the software to incorporate Winamp audio, RSS newsfeeds. Very popular and very useful software

Free, pro version available for a donation at www.trillian.cc/

Fire

Mac OS X. Supports all of the primary popular protocols

Free, at http://fire .sourceforge.net/.

Jabber

All platforms. Suite of open-protocol services and applications for nonproprietary messaging

Free, at www.jabber.org/

Gaim

Linux and Windows. Supports AIM, MSN, Yahoo!, ICQ, and other protocols

Free, at http://gaim .sourceforge.net/

I use Trillian for all my IM contacts, additional e-mail accounts, and RSS newsfeeds.

Summary The master Web designer must have a range of helpful tools on hand, and doing a complete audit of your software will help you figure out what you need. Of course, depending upon your work environment, there are tools here that you might never use, but being aware of them is empowering. And, while the cost of tools can really add up, once you’vegot the perfect toolbox in place, maintenance and upgrades are going to be less problematic and costly. The biggest secret when it comes to tools is finding a balance between what’s out there and what you like to work with. After all, it’s you, not the tool, that’s responsible for creating awesome Web sites.

Chapter

Managing Your Web Project

2

⽧⽧⽧⽧⽧⽧⽧⽧⽧⽧⽧⽧⽧⽧⽧⽧⽧⽧⽧⽧⽧⽧⽧⽧⽧⽧⽧

Secrets in This Chapter #21: #22: #23: #24: #25: #26: #27: #28: #29: #30: #31: #32: #33: #34: #35: #36:

Selecting the Project Manager . . . . . . Defining the Budget . . . . . . . . . . . . Identifying Goals . . . . . . . . . . . . . . Determining the Stakeholders . . . . . . . Determining Market Needs . . . . . . . . Identifying Roles and Responsibilities . . Creating a Project Workflow . . . . . . . . Listing Creative Tasks . . . . . . . . . . . Clarifying Technical Tasks . . . . . . . . . Defining Administrative Tasks . . . . . . Listing Marketing Tasks . . . . . . . . . . Addressing Quality Assurance Concerns Setting Milestones . . . . . . . . . . . . . Getting Signoff Throughout the Process . Encouraging Collaboration . . . . . . . . Managing Scope Creep . . . . . . . . . .

. . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . .

⽧⽧⽧⽧⽧⽧⽧⽧⽧⽧⽧⽧⽧⽧⽧⽧⽧⽧⽧⽧⽧⽧⽧⽧⽧⽧⽧

. . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . .

38 39 39 40 41 41 43 44 44 44 45 45 46 46 47 48

⽧ 36

Part I: Tools, Planning, and Content

⽧⽧⽧

W

ith an expert toolbox in place, the next step is to define the scope of the project and put a process in place to manage it effectively. This is a step that many Web designers miss or don’t put a lot of emphasis on. However, it is critical not only for a client or company’s Return On Investment (ROI) to have sites developed and managed in a timely, accurate fashion, but proper planning and management is also essential for the long-term vision and desired outcome of the project. The secrets in this section help you organize and manage your projects with greater efficiency. You’ll learn to do the following: ⽧ ⽧ ⽧ ⽧ ⽧ ⽧ ⽧

Define your team. Identify the best project manager. Work to improve collaboration between team members. Learn as much about the client, project stakeholders, and audience as possible. Work within a budget. Create a project workflow. Manage time and quality assurance of your project.

The Challenge of Web Project Management Project management is an art and soft science that has had hundreds—if not thousands—of years to emerge. The process—whether it be for huge industrial construction projects, humanitarian endeavors, or even the day-to-day management and workflow of a fast-food restaurant—of managing a given task from fruition through to completion has been undertaken hundreds of millions of times. So why does managing Web projects seem to be particularly challenging? There are unique difficulties in terms of how various personalities interact within Web teams. Some of the problems can be narrowed down into three main issues: ⽧ ⽧ ⽧

There is no specific structure when it comes to Web teams. There is no industry-wide standard for Web project management. There are disparities in the way various members of a given team think.

Toward Consistent Organizational Structure In the early days of the Web, it appeared that the individual Web designer could address most site needs. There was no call at that time for complex database integration or e-commerce. In fact, most of the technologies now used to manage those complicated tasks didn’t even begin to emerge until 1995. Prior to 1995, most Web sites were small and relatively easy to maintain by one person. But once the Web hit the desktops of consumers, a dramatic shift occurred. Sites needed a lot more to run securely, effectively, and required updating and managing more frequently. This took more hands, and it’s where the concept of Web teams really emerged.

⽧⽧⽧

Chapter 2: Managing Your Web Project

⽧ 37

The economic shakeups in recent years forced a lot of design firms to close completely, or to reduce staff significantly. This has resulted in great differences in how Web projects are dealt with in various companies, government agencies, and education environments. As with many issues in Web design, there is no real “onesize-fits-all” model, and the likelihood is that there won’t ever be, at least not in our lifetimes. So how do you manage? The secret is to find the sweet spot in the individual project circumstances.

Creating Industry-Wide Standards for Web Project Management Another challenge is that currently no industry-wide standards exist for Web project management. While some techniques have emerged over the years, such as Rapid Application Development (RAD), Rational Unified Process (RUP), and the concept of Extreme Programming—a means of fast-cycling software projects— the fact is these techniques exist in the programming sector, and while they may be used for Web-related applications development or database integration, they are rarely applied to the overall Web development and design processes themselves. In fact, there are very few standards for the business side of Web design, and it’s only been through convention, past experience, and drawing from other models that any form of consistent management practices have emerged. This is not to say that there aren’t emerging books and resources available to help those who are given the job of managing a Web project. This chapter provides as many resources for you as possible, but the reality is that as a Web project manager, you must be a very resourceful individual capable of setting project standards and guidelines appropriate for the team and/or project at hand.

Fixing Disparities in Problem-solving Approaches A widely discussed topic in managing Web projects is the disparity in personality and subject matter expertise. All of us have, at one time or another, been party to such personality differences within our fields. The programmer often thinks in abstract but linear chunks of information, whereas a designer might only focus on the visual and creative feel of a project. Marketing departments have their own lingo, as do the financial folks. In Web teams, you end up with not only disparate points of view, but also differences in language use and expression. While ideally all people working on the Web would at some point be exposed to effective communication skills (often referred to as soft skills in the corporate world), the reality is that most people focus their energies on what pays the bills and what interests them specifically, without a lot of encouragement to be more integrated in their thinking and language. This is not a fault, but it does point to the fact that no educational or professional standards have emerged just yet for those of us in the field. As a result, most of what you pick up you learn by the bootstrap method, from colleagues and friends, and on your own via books and Web sites. As a result, effectively communicating across the subfields within the industry becomes a significant challenge. When working on team-driven projects, this challenge can surface into real problems. A great project manager can solve this by effectively identifying roles, responsibilities, and goals, and organizing the project in such a way that respects the diverse

⽧ 38

Part I: Tools, Planning, and Content

⽧⽧⽧

nature of individuals within a team, while also getting that team to work in tandem toward a common, clear goal.

⽧ ⽧ ⽧

Secret #21: Selecting the Project Manager The job of the project manager is a tough one. He or she has to perform such complex tasks as the following. ⽧ ⽧ ⽧ ⽧ ⽧ ⽧ ⽧ ⽧

Organizing and defining roles of team members Defining audience, company, and client needs Finding symbiosis between those often divergent needs Creating the overall project workflow plan Ensuring the workflow is followed and any problems are dealt with efficiently Determining and staying within the project budget Coordinating communications between all parties involved with the project Keeping the peace

From a knowledge standpoint, project managers should have a minimum of some knowledge regarding every topic that the project will touch. Does this mean that the project manager has to know how to set up and maintain a Web server? Not necessarily, but understanding the broad issues and jargon involved should be part of his or her knowledge base.

Figure 2-1: The project manager is the hub of any project.

⽧⽧⽧

Chapter 2: Managing Your Web Project

⽧ 39

In terms of skills, the most important one a project manager can have is the skill of effective communication. The project manager is the hub in the wheel—all spokes are joined at the hub. It is the project manager’s job to keep the wheel rolling along (see Figure 2-1). For a wide range of information about project management, check out The Project Management Institute, a nonprofit member organization serving project managers, at www.pmi.org/.

tip

The United Kingdom has a range of active resources for project managers, including the Association for Project Management (APM), www.apm.org.uk/. Additional international associations can be found at the International Project Management Association (IPMA), www.ipma.ch/.

⽧ ⽧ ⽧

Secret #22: Defining the Budget No matter what a project’s scope is or the number of individuals involved with its life cycle, budget is going to play an enormous role in how the project is run. Effective budgetary administration of a project means the following: ⽧ ⽧ ⽧ ⽧

Gaining a full understanding of the project’s scope Budgeting for human resources according to real cost Purchasing hardware, software, or related items falls within the project budget Restricting spending on unnecessary steps

Of course, “time is money” so a critical aspect of effective budget management is effective use of time.

note

A wide range of tools is available to help project managers manage time, delegate responsibilities, and otherwise take care of the business of management. Visit www.business.com/directory/management/ operations-management/project-management/software/ for more information about helpful budget and project management-related software.

⽧ ⽧ ⽧

Secret #23: Identifying Goals If the topic of this secret seems rather basic, let me assure you that while not difficult, it is the most often overlooked or rushed-through part of the planning process. It’s also the primary reason that projects wind up with problems.

⽧ 40

Part I: Tools, Planning, and Content

⽧⽧⽧

Specific goals must be defined prior to any project. They include the following: ⽧ ⽧



Client goals. These goals are those that the client hopes to achieve. Audience needs. Perhaps the most overlooked issue within an overlooked issue, the audience must be taken into consideration at all steps of the project. Site intent. This is the reason the site is being developed in the first place. Interestingly, many people don’t really realize why they’re creating Web sites, and many failures come about from having an unclear idea of what the site is intended for.

While many planning software packages can help you identify some of these critical issues, nothing beats a pen and paper. Sit down and make lists, as detailed as possible, of each of these goal areas.

⽧ ⽧ ⽧

Secret #24: Determining the Stakeholders In the corporate world, the term stakeholder has taken on some interesting connotations. Originally a term used to describe the individual who would hold the prize during betting, the word now tends to refer to anyone within an organization who holds power. In terms of a Web project, a stakeholder would be anyone who makes final decisions. One of the greatest challenges in today’s Web design is to sort out who really has power in any given situation. A major secret to successful Web project management means figuring out exactly who is holding the power within the organization in terms of final decision making. Typically, this is a job the project manager should undertake, although anyone providing administrative assistance can help work it out. In analyzing the circumstances, you might very well find that there are numerous stakeholders. Some general guidelines for clarifying stakeholders follow: ⽧



⽧ ⽧

tip

Always determine who has the last word. This person should go on top of your hierarchy and should always be the final go-to person if problems arise. Determine secondary stakeholders. These are the individuals who will make decisions for specific portions of a project, such as the Marketing Manager, IT Manager, or Art Director. It’s helpful if you can make notes about the type of relationship they have with the primary stakeholder—good relationships between a secondary and primary stakeholder can in fact be used to the project manager’s advantage should disputes arise during the project. Try to get agreement ahead of a project that the primary stakeholder (or someone he or she designates) will have the final word in any dispute. Consider drawing up a hierarchy so the chain of command is clearly understood. While identifying the key decision makers is a very important step toward success, how you interact with them is just as important. Clarifying roles makes this process somewhat easier, but certainly in many cases relationships are challenged.

⽧⽧⽧

Chapter 2: Managing Your Web Project

⽧ 41

Consider appointing a moderator at the early stage of any project whose role is solely to help moderate disputes should they arise. This person would be someone other than the project manager who can moderate disputes between the project manager and stakeholders.

If significant problems exist within your organization, some kind of external moderation via a third party might be necessary if disputes cannot be settled.

⽧ ⽧ ⽧

Secret #25: Determining Market Needs Once you’ve got an idea of the project, the basic needs of the client, site intent, and audience, it’s time to determine whether the market will bear out a site of the nature you’re trying to develop. This is specific to public Web sites, but even private intranets may be improved by asking similar questions. The goals of determining market needs include the following: ⽧ ⽧ ⽧ ⽧ ⽧

Understanding the market size for the product or service, which you’ll be representing Preparing to manage any economic or other challenging factors within the market in question Knowing the market players and examining their methods for success or stumbling blocks Identifying potential competitors for long-range tracking Identifying potential collaborators for long-term, mutually beneficial relationships

At this stage of the game, it’s very helpful for the project manager to sit down and do serious research to answer the following questions: ⽧ ⽧ ⽧ ⽧

Who are the existing market players? How are they using their sites effectively (or not)? Who is their targeted demographic and is it different from the one defined by this project? Is there any current measure of customer satisfaction?

Of course, the real work comes in once you’ve got this information. By studying market players, economics, demographics, and current satisfaction levels, you will be best able to position your project effectively in the current market.

⽧ ⽧ ⽧

Secret #26: Identifying Roles and Responsibilities The next step is to identify your team. Have a decent idea of who you have and what they are capable of doing. Even if you are working solo, identifying your role and what aspects of the project you are fully confident that you can be responsible for, helps you determine aspects of the projects for which you’ll require outsourcing.

⽧ 42

Part I: Tools, Planning, and Content

⽧⽧⽧

Getting this information organized early on in the game is essential to a project’s success. For both group and individual projects, use the checklist sample shown in Table 2-1 as a guideline for auditing and organizing your role and responsibilities for a project.

Table 2-1: Sample Chart for Web Team Roles and Responsibilities Individual

Skills

Project Role

Jackie

HTML, CSS, scripting, document management, information architecture, some project management

Markup and CSS coordinator

Lee

Visual design, Web graphic production

Visual rendering of site design, graphic design and production for site

Jerry

Application developer

Provide solutions for server-side interactivity

Kelly

Database developer

Develop necessary database and integrate with site

Max

IT systems administration, security

Set up, run, and maintain Web servers and other technical components

Nicky

Information architect

Design site infrastructure and long-term growth management plan

Sal

Usability and Accessibility specialist

Ensure site is usable and accessible

Terry

Marketing, brand specialist

Oversee the way the site is integrated into the company’s larger-scale marketing scheme

Tony

Administrative, organizational, workflow management

Administrator

After the team players are identified, a better idea of who is responsible for what emerges. During your evaluation exercise, you might wish to include any secondary interests of individuals. For example, the IT guy might be a fantastic artist and capable of offering some ideas to the benefit of the team. Ideally, teams work in an integrated fashion, although some experts feel that individuals should only be responsible for their particular depth field.

note

At this point, many experts recommend profiling personalities within the team and associating individuals with such profiles as: ⽧ ⽧ ⽧ ⽧

Ego-oriented Results-oriented Relationship-oriented Detail-oriented

⽧⽧⽧

Chapter 2: Managing Your Web Project

⽧ 43

Profiling is said to help categorize personalities within a group and therefore facilitate managing disparate points of view and language use. However, profiling of this nature can also pigeonhole people and limit them to their primary skills without acknowledging that they might have multiple talents to bring to the table.

⽧ ⽧ ⽧

Secret #27: Creating a Project Workflow Okay, your team is in place, you know who the stakeholders are, and you understand the general goals of your project and the constraints of your budget. It’s time to put a workflow in place. Even though project management is as old as the hills, that doesn’t mean anyone has come up with the perfect workflow recipe. A lot of information has to be gathered first, including defining specific tasks. However, for this secret the emphasis is on understanding the overarching event cycle. While there are many models for project workflow, the general flow may be helpful for you to get an overview of how all of the secrets in this chapter can aid you in achieving your goals. Table 2-2 shows a general project life cycle and which tasks are associated with each aspect of the project.

Table 2-2: Project Workflow Example Workflow Phase

Associated Tasks

Pre-production

Company and client agree to project, project manager is appointed, management team is appointed, stakeholders are identified, budget and market needs are understood

Task Identification

Tasks are exhaustively examined by the project team, and team members are associated with the tasks

Production

Content is gathered. The project manager oversees team members in all the aspects of the project: Web graphic design, HTML, and other coding, Web programming, content management, and editoria.

Quality Assurance

This important phase places the project under scrutiny. Testing of Web pages, usability, accessibility, multibrowser and platform tests, and other assurances of quality are challenged and, where necessary, repaired

Launch

During launch, the project goes live and marketing and related maintenance tasks ensue

Post-production

Any upgrades, maintenance, and marketing tasks are performed. Many project managers recommend a post mortem of sorts at this phase of the project, inviting all project members to get together and review the project: what worked, what failed, and how can we learn from our experiences?

⽧ 44

Part I: Tools, Planning, and Content

⽧⽧⽧

⽧ ⽧ ⽧

Secret #28: Listing Creative Tasks In order to flesh out the workflow plan, separating out tasks by type will enable assignments to be made in an organized fashion. Clarifying the creative tasks for a given project includes identifying all the design and brand-related tasks. Examples of creative tasks include: ⽧ ⽧ ⽧

Content. What is the voice of the site? How will content be arranged, written, and presented? Design. How will the site look and feel? Which company colors, logos, and other identifiers need to be collected and produced? Multimedia. Will the site require multimedia? If so, which technologies will be used?

Project managers can work with their design team member(s) to come up with a comprehensive list of creative tasks appropriate to your project’s needs.

⽧ ⽧ ⽧

Secret #29: Clarifying Technical Tasks Along with creative tasks, technical tasks must be defined and slotted into the scope of the project. Technical tasks include the following: ⽧ ⽧ ⽧ ⽧

Identification of any client-side markup and scripting needs (HTML, XHTML, CSS, and JavaScript) Determination of whether application languages will be required, and if so, which language and platform Discovery of whether database functionality is required for this project, and if so, what kind of database is optimal Server administration (will the server be purchased, co-located, or hosted with an ISP?) Sometimes client-side markup is managed by the design department or by another team member entirely. Paying special attention to intra-team politics is especially important here, because this is where clashes between designers and technologists most commonly occur.

note

⽧ ⽧ ⽧

Secret #30: Defining Administrative Tasks There are numerous administrative tasks, mostly overseen by the project manager, although he or she should feel free to delegate where sensible. Administrative tasks include the following: ⽧

Researching and defining the project in clear terms

⽧⽧⽧

⽧ ⽧ ⽧ ⽧ ⽧ ⽧

Chapter 2: Managing Your Web Project

⽧ 45

Budgeting the project Defining team members and tasks Overseeing completion of tasks within the context of the project workflow Managing client concerns and needs Ensuring resources are available Managing project timeframes and dealing with potential slip-ups

⽧ ⽧ ⽧

Secret #31: Listing Marketing Tasks Another area where potential issues arise in team dynamics is in marketing. The goals of marketing and the goals of creating an excellent product are sometimes at odds with one another. Defining the tasks before setting project milestones can help shake these issues loose early on in the project process and may well assist the project manager in preventing delays due to warring factions of the team. Marketing tasks can consist of the following: ⽧ ⽧

⽧ ⽧

Analysis of demographic Research of best marketing options for product or service (ad-based marketing, ranking on search engines, cross-promotional events, and reciprocal links on collaborative sites) Organization of press events, including writing and delivery of press releases, and preparation and scheduling of any special events for launch Long-term evaluation of market needs, including scheduling of follow-ups past the site’s launch and post production, as needed

⽧ ⽧ ⽧

Secret #32: Addressing Quality Assurance Concerns Once a site enters the production phase and everyone is happily at work, attention shifts to managing your project effectively by putting quality assurance (QA) and testing phases in place. If a project manager fails to identify quality assurance issues early in the project and is unable to schedule them accordingly, significant workflow issues can ensue. Some of the issues examined during the QA phase include the following: ⽧ ⽧ ⽧ ⽧ ⽧ ⽧ ⽧

Validation of markup and CSS Testing of all programming features Load-bearing tests (especially if the site is expected to be very heavily trafficked) Multibrowser and platform testing Accessibility testing Usability testing Editorial review of all content

You measure QA differently depending upon the project, its scope, and its contents. For example, if the site is required to be Section 508-compliant, you must be prepared to test for that compliancy, or time can be lost. Similarly, testing for

⽧ 46

Part I: Tools, Planning, and Content

⽧⽧⽧

usability must be assessed, and the methods by which you’re going to test will make a huge difference in how the project proceeds. If you’re outsourcing to a usability lab, for example, preparing for possible delays within the initial workflow milestones is a helpful way to avoid project slippage. Many project managers are suggesting that QA be comprised of a separate team that works along with the primary team throughout the project’s production phase. This is thought to reduce errors during the production process and shave time off of the QA process itself as a result. I’ve definitely seen this work in very collaborative environments, but with those teams that might be less comfortable with the idea that someone is constantly looking over their shoulder during production, the idea should be introduced diplomatically, if at all.

tip

⽧ ⽧ ⽧

Secret #33: Setting Milestones Once you’ve got all your research in order, your tasks defined, and your team is chomping at the bit to go, it’s time to make the schedule and set specific by-date and project-percentage milestones. Remember the following three points: ⽧ ⽧ ⽧

tip

You have to set milestones! Not doing so at the outset could cause catastrophic problems that become unmanageable later on. Pad the time. Figure out a probability for the length of each phase and add at least one-fifth of that time to the schedule. Always be willing to change them. If you see a slip coming, try to readjust the schedule without having to affect the bottom line.

Many experts say that the key to effective scope management is keeping extremely detailed and accurate records of time. Every team must do this independently, and the project manager will gather that information and input it into the workflow management software, constantly analyzing where the project is, how far it needs to go, and whether that precious 100 percent date will be met. For more information on productivity software for project managers, see www.project-management-software.org/.

⽧ ⽧ ⽧

Secret #34: Getting Signoff Throughout the Process Signoff in this case can refer to any number of steps within the project, but usually has to do with administrative (budget, team structure), technical (use of a specific technology), or creative (approval of design). The effective project manager will, at this point, have added very specific milestones according to the needs of the project to the master schedule that include getting stakeholder signoff more than once throughout a project process.

⽧⽧⽧

Chapter 2: Managing Your Web Project

⽧ 47

In a hierarchical stakeholder model such as that described earlier, this likely means getting secondary stakeholder signoff for part of the project, and primary stakeholder signoff at least a few times during the process. If you’re having difficulty getting signoff from a stakeholder, remember that time and money are always deal makers or breakers. Show the stakeholder how you are saving time or money, or the worst case scenario: let them know that without signoff, the project could be delayed or cause budget problems.

tip

⽧ ⽧ ⽧

Secret #35: Encouraging Collaboration As mentioned earlier, some experts believe that encouraging collaboration isn’t a very good idea. The argument is this: If disparate personalities are allowed to collaborate, it will take far more time to reach the goal. While this is often true, and your unique project situations will dictate how much or how little collaborative efforts can be built-in to the project, the highly effective project manager should easily be able to include brainstorming sessions in the project timeline. Without collaboration, a wide range of problems can occur. It’s essential to figure out a good strategy for encouraging effective, collaborative meetings. Some tips for running effective collaborative meetings include the following: ⽧ ⽧ ⽧

⽧ ⽧

tip

Set a specific goal for the meeting, such as “By the end of this meeting, we’ll determine which browsers the Web site must support.” Make sure everyone gets an agenda prior to the meeting, outlining the topics, goals, and start and end times. Ask attendees to prepare for the meeting in advance. The designer could be asked to provide mockups of how the site will look in a variety of Web browsers; the server administrator could be asked to collect log data showing browsers using a current (or similar) project site; and the marketing person could bring in demographic information of the current and projected site visitor base. Allot time for each individual to discuss his or her materials, for open discussion, and for closing the meeting. Always walk away from a meeting with a specific action/results item, such as “Team determined that backward compatibility with Netscape 4.x browsers is not relevant to our audience. However, since it is simple enough to at least provide readable content to these users, we will incorporate those practices into the project.”

Perhaps the wisest advice I’ve ever heard regarding meetings is this: If you don’t need a meeting, don’t have one. This means that project managers need to not only write effective schedules, but also be flexible enough to decide when a meeting is needed—or not needed as the case may be.

To manage a team efficiently (even if you’re a “solo” Web designer using outside resources), helping everyone on your team get involved with a given project and

⽧ 48

Part I: Tools, Planning, and Content

⽧⽧⽧

to feel a personal relationship with the success of a project helps the individual to be at his or her best, which in turn results in a better project. If you do decide to encourage collaboration, it’sessential to work those brainstorming meetings into the project workflow, and for the project manager to take a strong but diplomatic approach. You can find some very helpful resources online to aid you in organizing and running meetings more effectively (see Figure 2-2 for one example).

Figure 2-2: Want some help managing meetings effectively? See EffectiveMeetings.com.

⽧ ⽧ ⽧

Secret #36: Managing Scope Creep Scope creep is the slipping of your project from the schedule that you built. If you have to, you’ll add time to the project, but this is always, always a last resort. Of course, scope creep occurs frequently, even with very good managers and teams at the helm. Extreme Programming, also known as XP, is a project management process in the programming world that has been especially created for riskoriented projects. For more information on XP, see www.extremeprogramming.org/.

note

So what do you do if you see dates slipping away? Sit down and reevaluate. ⽧

Isolate the problem(s).

⽧⽧⽧

⽧ ⽧ ⽧

Chapter 2: Managing Your Web Project

⽧ 49

Work with relevant team members to get a hold of the problem in a timely and sensible fashion without sacrificing important tasks. Consider adding resources (human or technical) if you believe doing so will assist the scope creep rather than adding concerns. If a situation becomes seemingly unmanageable, consider bringing in an external manager or moderator to help solve problems.

There are still so many emerging factors in Web design and development that it’s hard to identify risks within Web projects. The best project managers do everything within their knowledge and skill base to prevent scope creep, but the cost of quality must always be measured against the time and money factors, too.

tip

Care for your team members! One of the best ways to avoid scope creep is to avoid burning out your teams. Taking everyone out of the office and doing fun activities can lighten up the emotional load and actually assist in more productive team members, and in turn, result in a better quality project.

Summary Project management has been around since the beginning of human time. How we found food, learned to cook it, preserve it, and eventually farm, sell, and broker it provides a perfect metaphor: People naturally figure out needs and create organizational structures to go with those needs. Web project management is still in a nascent form, largely due to the issues raised at the beginning of this chapter. However, with a little of that natural instinct and a lot of looking at other projects—both Web and otherwise—the savvy project manager or project team member will be able to find helpful and even innovative ways to deal with the unique management concerns today’sWeb professional must face.

Chapter

Architecting Your Information

3

⽧⽧⽧⽧⽧⽧⽧⽧⽧⽧⽧⽧⽧⽧⽧⽧⽧⽧⽧⽧⽧⽧⽧⽧⽧⽧⽧

Secrets in This Chapter #37: #38: #39: #40: #41: #42: #43: #44: #45: #46: #47: #48:

Performing a Content Audit . . . . . . . . . . . . . Determining Hierarchies of Content . . . . . . . . Defining Technical Infrastructure . . . . . . . . . . Determining Naming Conventions . . . . . . . . . Site Mapping . . . . . . . . . . . . . . . . . . . . . Understanding Wireframing . . . . . . . . . . . . Developing Prototypes . . . . . . . . . . . . . . . . Creating User Pathways . . . . . . . . . . . . . . . Creating Archive Systems . . . . . . . . . . . . . . Considering Frequency of Updates and Redesigns Setting Site-Wide Standards . . . . . . . . . . . . . Developing a Site-Wide Style Guide . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

⽧⽧⽧⽧⽧⽧⽧⽧⽧⽧⽧⽧⽧⽧⽧⽧⽧⽧⽧⽧⽧⽧⽧⽧⽧⽧⽧

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

53 54 56 57 59 60 61 62 63 64 65 65

⽧ 52

Part I: Tools, Planning, and Content

⽧⽧⽧

H

ow information is designed both from a conceptual and technical standpoint immediately impacts the short- and long-term evolution of a site. Understanding what information is available, how to structure it in such a way that makes sense both to the end-user and the behind-the-scenes interrelationship of other documents within the Web site, and managing growth effectively can be extremely helpful in avoiding problems down the road.

What Is Information Architecture? Long before the Web, the act of organizing and architecting information was in place. Richard Saul Wurman, author of over 80 books including the acclaimed Information Anxiety about making information understandable, coined the term “unformation architecture’’ in 1976, even though the profession really emerged and matured after people began to struggle with managing information on the Web. While the exact definition of the term is still being debated, most will agree that information architecture is the process of identifying, organizing, and structuring site content. By my way of thinking, this has to extend to the technical implementation of site infrastructure needs. A strong infrastructure means a stable, clean-running, underlying technology, which enables designers to create navigation and interface designs that are useful and relevant to both the information and the needs of the user. People working in this field, which is called “IA’’by inside professionals, are referred to as Information Architects.

note

As with many individual topics within Web design and development, IA concepts overlap with other topics. So, some of the topics in this chapter are relevant within all three practices. A good example of this is wireframing and prototyping—both techniques are part of designing for usability as well as appearing within the IA umbrella. Another example would be that the creation of persuasive navigation could fit under either heading. Finally, the creation of style guides may fall to the information designer, the visual designer, the project manager, or the usability specialist.

Sites Big and Small, New and Old Because the architecture of a Web site so critically influences its interface, IA has taken a very important place in the Web site design process. Web designers working alone are becoming aware of how important organization is to a smooth process. Designers often come face-to-face with the difficult considerations that must be made during the architecting of a site as the technical and design issues are worked out. IA is not just for large-scale sites or sites that are being redesigned, either—the principles within the field apply equally as much to the small business Web site as they do a major bookseller.

Organic Growth and the Web Currently, many Web sites are suffering from organic growth syndrome—an outgrowth of the innovative yet often haphazard way by which Web sites have been built over the past years.

⽧⽧⽧

Chapter 3: Architecting Your Information

⽧ 53

IA for the Web has emerged as a powerful approach to these concerns, and within this special study area are tremendously helpful secrets to empower Web designers as they develop the information and infrastructure on their sites.

⽧ ⽧ ⽧

Secret #37: Performing a Content Audit All of us have gone to the grocery store and come out having spent more time and money than we originally intended. If I’m preparing to cook a big meal or stocking the house with needed items, it’s infinitely more practical to audit those items I have and make a list of what I actually need. Then, I know precisely which items I’ll want at the grocery and be able to navigate its aisles and lines in less time, stick to a predefined budget, and forget fewer—if any—items than had I not taken the time to audit and plan my errand. Before any actual architecting of information can begin, a complete audit of content must be performed. This is true of brand new as well as established Web sites. In either case, an audit provides the architects with a real view of what elements they work with. Goals of a content audit include the following: ⽧ ⽧ ⽧ ⽧ ⽧

Identify the strengths and weaknesses within the content and infrastructure of the existing or planned site Discover problems with current architecture and site performance Organize content into logical groups Prepare content for examination and implementation of content hierarchies and management Gain real information regarding the scope of the project at hand

As you read in Chapter 2, the project manager is often responsible for organizing his or her team and coordinating site production-related activities, including content audits. If you are working alone, the content audit should be performed at some point immediately after the information-gathering period. Content audits are important not only to the large-scale project, but smaller sites, too. Both team and solo designers and developers need to know what information is being managed.

note

Activities typical to the content audit process include the following: ⽧ ⽧



Thorough review of all existing content. In this step, all content for the Web site is organized and charted in preparation of evaluation. Evaluation of all content. During the evaluation step, the gathered content is evaluated for its integrity. Unnecessary or duplicate content is often removed after an evaluation, helping to streamline the process of the site’s architecture. Sorting of content by relevancy. An excellent way of improving the organization of content is to group like items, just as you’ll find in a well-organized grocery. All the soups are arranged together, as are the juices, and cleaning supplies. Certainly, this sorting of like items in real-world situations is not accidental—it is, in fact, a form of IA applied to the real, rather than virtual world.

⽧ 54

tip

Part I: Tools, Planning, and Content

⽧⽧⽧

If you are working in a team environment, it can be very helpful to delegate the evaluation and sorting of content as it relates to a given department. For example, the Web graphics on an existing site are likely to be managed by the team’s designers or document authors, and they may well have a better idea of what they have and what they need. Then, the designated IA project manager or design team member can review and audit the information more readily.

Table 3-1 shows a simple example of a content audit in the relevancy phase for a fictitious shoe company, “Meyer Shoes.’’ In this case, the audit is looking at graphics and Web-related documents for its current catalog offering.

Table 3-1: Content Audit (By Relevancy) for Fictitious Project “Meyer Shoes” Men’s Shoes

Women’s Shoes

Children’s Shoes

20 thumbnail graphics of all men’s styles for 2004

45 thumbnail graphics for all women’s shoe styles for 2004

12 thumbnail graphics for children’s styles for 2004. Missing 3 thumbnail images

20 full-size graphics for catalog detail pages

40 full-size graphics. Missing several styles

15 full-size graphics covering all children styles for 2004

20 HTML documents with complete descriptions of all 2004 styles

No HTML documents for the catalog available at this time

5 of 15 children’s shoe styles are ready; project manager expects the remainder to be completed within one week

The relevancy, or categorization, of the information into three separate categories, Men’s, Women’s, and Children’s shoes, helps streamline the audit process. By breaking it down into categories of relevance, you can quickly see what’s complete and where missing items appear. The breakdown of content into categories becomes a critical part of the information’s technical structure. Instead of having a single image section for all shoes, for example, the infrastructure of the site can now be managed by category, making it easier from a maintenance and upgrade perspective as well as forming the basis for a much more reasonable, usable front end. Content audits are extremely beneficial for a number of reasons. The two most immediate are that audits result in identifying problem areas and a roadmap emerges as a guide to moving ahead with content repair, replacement, and management.

⽧ ⽧ ⽧

Secret #38: Determining Hierarchies of Content Hierarchies are the basis of much of our world—from governments and organizations, to the structure within computer programming—hierarchies are frameworks for organization.

⽧⽧⽧

note

Chapter 3: Architecting Your Information

⽧ 55

When dealing with information for the Web and how it will be architected, understanding hierarchies is a basic requirement. Understanding that hierarchies should be crafted and built as specifically to the categorization of content as possible is critical, too.

A hierarchy has a root, and the root appears at the top of the hierarchy. It is from there, not from the farthest leaf, that you measure the system. Each branch is specialized, and becomes increasingly more specialized as you follow the branch system. In Secret #1, you reviewed a simple relevancy example, which, if mapped out, displays a very clear hierarchy, such as that shown in Figure 3-1.

Figure 3-1: A simple hierarchy built from category relevance. In this case, Meyer Shoes is the root of the hierarchy, with the branches consisting of the three categories defined earlier, Women’sshoes, Men’sshoes, and Children’s shoes, comprising the top level of the hierarchy. To make a simple site structure from this hierarchy, you’d end up with a Home Page and three main sections for the site.

Figure 3-2: A more explicit hierarchy based on further breakdown of content.

⽧ 56

Part I: Tools, Planning, and Content

⽧⽧⽧

Realistically, as you study your audited content and accurately categorize it, you will get more and more explicit with your hierarchy determination. Depending on the size of your site, you will determine hierarchies within hierarchies, as shown in Figure 3-2.

tip

How explicit your hierarchies become should relate directly to the amount of content you have. The smaller the Web site, the easier it is to manage by keeping it simple. If you are working with a very large amount of content, the content hierarchy is going to be far more explicit.

Web sites that have a hierarchy with many top-level categories but not a lot of explicit hierarchy structure beneath those categories are referred to as shallow. Those with fewer top-level categories but deeper content are referred to as deep. Table 3-2 provides a comparison of the two.

Table 3-2: Comparing Hierarchy Options for Web Sites Shallow Hierarchy

Deep Hierarchy

2–5 tiers

Up to 9 tiers

Contains root (home page) and top-tier categories, few or no lower tiers

Contains root, top-tier, and at least one or more additional tiers within the structure

Experts recommend that sites with a smaller content base, such as a small business Web site or personal site (see Figure 3-3), use shallow hierarchies.

Figure 3-3: Smaller sites work well with a shallow hierarchy. Deep hierarchies are applicable to those sites where large amounts of content are being managed and archived, such as news, portal, and commerce sites (see Figure 3-4).

⽧ ⽧ ⽧

Secret #39: Defining Technical Infrastructure Interestingly, not all information architects are involved in the creation of the technical infrastructure. This infrastructure is the system of folders and files on the server. Quite often, the individual or group managing the server puts together the infrastructure. Divorcing the site structure from the overall IA process can result in many problems, the “organic growth syndrome’’issue being an excellent example.

⽧⽧⽧

Chapter 3: Architecting Your Information

⽧ 57

Figure 3-4: A deep hierarchy is effective for larger Web sites. While it is impossible to envision what a successful Web site will look like in one year, or ten years, it is possible to build a technical infrastructure that reflects the content while leaving room for growth. That’swhy I think ensuring that the content hierarchy process and the technical infrastructure process are closely integrated— with the designer or team members working on infrastructure only after a complete audit and content hierarchy has been designed. Some of the compelling reasons an effective architecture based on content is necessary include the following: ⽧ ⽧ ⽧ ⽧ ⽧

Information on the server will be organized in direct response to the real, existing data about content categories. Images and other media can be organized by category and type. It provides better control over URL length. It brings far more awareness of exactly where specific types of data should be stored on the server. Better organization provides more flexibility in making the content hierarchy wider and deeper should the need arise, preventing or minimizing out-of-control growth.

If you take the simple Meyer’s Shoes content hierarchy and work on a directory structure based on the three categories defined earlier, you’d end up with a technical structure somewhat like that found in Figure 3-5.

⽧ ⽧ ⽧

Secret #40:

Determining Naming Conventions

I’ve read a lot of material geared toward educating Web designers and developers about naming conventions and, unfortunately, this topic is often glossed over. “Create file and directory names that make sense to you’’is written more times in

⽧ 58

Part I: Tools, Planning, and Content

⽧⽧⽧

Figure 3-5: Technical architecture model for sample Web site. the literature than I can count, and while the thought is fundamentally correct, it’s incomplete. Yes, your directory and filenames should make sense to you, but they should also make sense to your users as well as any other developers and designers working on the site. The reasons for this have mostly to do with usability and how users experience and interact with Web sites. There are also practical considerations such as case, use of characters, and length of resulting URLs. Here’s a list of guidelines to help you determine good naming conventions for your technical architecture: ⽧





Use short, clear terms. Naming the Meyer Shoe site directory structure with men, women, and children, respectively, keeps things very clear, and helps your visitors to orient themselves within a site. This is also true of document and image filenames. A good rule of thumb is to ensure that all names should be ten characters or less (preferably less). Use lower case. Some Web servers are case-sensitive. As a result, you need to be sure your paths are consistent. I recommend choosing lower case for directory and filenames in all instances. Avoid reserved (also known as “special’’)characters. A number of characters are reserved for specialty use when configuring servers and their behavior and working with protocols specific to the Web. While you can conceivably use any character in a filename that you want, to avoid problems, it’s best to steer clear of any of these characters in your filenames (see Table 3-3 for more detail).

⽧⽧⽧

Chapter 3: Architecting Your Information

Table 3-3: Characters and their Use in Naming Conventions

⽧ 59

Character

Use

Space

Never

|

Avoid

&

Avoid

*

Avoid

%

Avoid



Can be used for directory naming on properly configured servers



Freely

-

Freely

You will see some of these characters, especially the ampersand and percent sign, appear in URLs generated by server-side applications. This is acceptable. The point here is to have you avoid using these symbols in your actual directory and filenames.

note

Another interesting point is that while you can use the dash (-) and underscore ( ) freely within directory and filenames, a lot of controversy has been generated over this seemingly innocuous issue. The tendency is for most technical people to prefer an underscore, but in this case, it really is a personal choice. My recommendation is to choose one or the other and stick with it consistently. If you imagine the resulting URL for the Children’s running shoe page, it’s www.sitename.com/childrens/running/. Not too long, yet very intuitive.

⽧ ⽧ ⽧

Secret #41: Site Mapping Creating site maps is the physical mapping of your site’s contents. Site maps may be generated throughout a project’s life cycle. They provide a powerful tool for all team members to gain an aerial view of the Web site.

A site map is also referred to as the blueprint of a Web site.

note

Site maps can contain a variety of information, including the following: ⽧ ⽧ ⽧ ⽧

Visual representation of site pages Hierarchical representation of the site in a flow-chart style Notations regarding links between pages Notations regarding external links

⽧ 60

Part I: Tools, Planning, and Content

⽧⽧⽧

The larger a site, the more complicated its map. Therefore, it’s extremely warning important that it be mapped correctly and updated frequently during the project life cycle. Typically, mapping the site is done using mapping tools. Many commercial Web projects help keep track of your content and generate a subsequent site map. Figure 3-6 shows a map of my Web site as displayed in Dreamweaver MX 2004.

Figure 3-6: Site mapping in Macromedia Dreamweaver.

⽧ ⽧ ⽧

Secret #42:

Understanding Wireframing

In his book Information Anxiety2, Richard Saul Wurman (mentioned earlier as the man who coined the term IA and is considered its “father’’ by many) claims that there are two parts to a given problem. He defines these as being the “ what’’and the “how.’’ Wireframing addresses the what portion rather than the how. In the process of wireframing, the site’s content and hierarchies are “framed’’ in a series of documents (the wireframes) that actually reflect the physical makeup of your documents. Bear in mind that these documents are far more focused on the structural than the visual, and for good reason. This is the step that comes before prototyping the site. You’re not looking for information such as which colors will be used for the navigation links (that’s considered a “how’’). You’re looking for what the navigation consists of (that’s a “ what’’).

⽧⽧⽧

Chapter 3: Architecting Your Information

⽧ 61

Information typically dealt with in the wireframing process includes the following: ⽧ ⽧ ⽧ ⽧

Clarifying section names and how they’ll be represented on the site Detailing primary navigation Defining secondary navigation where needed Providing a basic layout sketch for known content

Wireframe documents can be created in a number of ways. Some designers sketch their wireframes, and others use HTML and related tools, such as Dreamweaver. Many designers who wireframe their sites use charting or drawing programs such as Visio, Photoshop, or Illustrator.

note

In the case of Meyer Shoes, the wireframe pages would reflect the general layout scheme, navigation schemes, and planned content areas. You’ll find an excellent article, “HTML Wireframes and Prototypes: All Gain and No Pain” by Julie Stanford at www.boxesandarrows.com/ archives/html-wireframes-and-prototypes-all-gainand-no-pain.php.

tip

⽧ ⽧ ⽧

Secret #43:

Developing Prototypes

While similar to wireframing, the prototype portion of an architectural process is applying the “how’’ to the “ what’’ of a wireframe. In the wireframe process, your goal is to find the somewhat intangible place between concept and fruition—the piece that fits between the actual structure and the visual representation. A prototype, unlike the wireframe, seeks to define aspects of the site such as its visual appearance. Prototypes are flat, noninteractive graphical mockups of a page’s layout. Prototyping is important because of the following: ⽧ ⽧ ⽧

Prototypes can be shared with the full team and the client for input and modification prior to production. Prototyping allows you to see the visual counterparts of the structural relationships you’ve created. A prototype can prepare your site for early usability testing (see Chapter 4, “Making Sites Usable and Persuasive’’).

Most experienced designers understand that in order to make prototyping costeffective, not all pages of a site are prototyped. If I were prototyping the Meyer Shoes site, I would prototype the following documents only: ⽧ ⽧ ⽧

Home page Top-tier page Product page

⽧ 62

Part I: Tools, Planning, and Content

⽧⽧⽧

This way, changes can be implemented promptly prior to actually producing all pages of the site. The only exception to this streamlined approach would be if the actual top-tier pages were significantly different than each other in some way.

tip

Getting sign-off from stakeholders on a completed prototype is not only wise, but should be considered imperative. It is from this point forward that heavy production on the site ensues. Be sure you are designing to an approved prototype.

⽧ ⽧ ⽧

Secret #44:

Creating User Pathways

Take a close look at this book. Look at the front cover. Find any teasers that get you to open the book? Look at the back cover—any information there to help you as a reader to get to the information you actually want? Flip through the book; what catches your eye? Now examine the Table of Contents, and check out the Index. All of these aspects of a technically-oriented book are what’s referred to as the flip factor. Books are architected in very specific way to provide you, the reader, with various paths you can take to get to information. In terms of a Web site’s “flip factor,’’ auditing, wireframing, and prototyping all lead us to the shaping of our site’s architecture and, ultimately, the site’s usability and content design. We’re creating the interface between a site’s technical backend and its welcoming front-end. If a book, which is a mostly linear medium, can benefit from user pathways, so can a Web site. What’smore, because different types of people use navigation schemes and site entry points in different ways, creating a variety of pathways to information is a necessity.

note

Not all Web site visitors will enter your site via the home page. Depending upon your visitor’s personality, he or she might use different or even unusual steps to get from one place to another within the site.

The experienced Web designer and developer will right away notice the crossover between IA and usability at this point in the process. How users will navigate your site is a major part of usability and user interface design (see Chapter 4). Despite the crossover in application, putting the implementation of user pathways into the IA process lays down the opportunity for usability testing to begin very early in the process. To figure out how a user might trailblaze his or her way through your site, you must figure out the scenario: Which user is attempting to achieve what? For example, a buyer goes to the Meyer Shoe site with the goal of buying a pair of women’s shoes. How the buyer gets to the right place to take that action is another matter. She may go to the site via its home page and follow the options from that point. Or, as a returning customer, she may have the women’s shoes main page bookmarked. Another scenario could be that she originally bought a pair of running shoes for her ten-year-old nephew, and has the children’s section bookmarked. If she starts on the main children’s shoe page, how does she get to women’s shoes? It’s your job to help the buyer by first figuring out who is visiting your site and under what range of potential circumstances.

⽧⽧⽧

Chapter 3: Architecting Your Information

⽧ 63

Begin by listing all the various tasks an individual might perform at your site, such as the following: ⽧ ⽧ ⽧ ⽧

Sign up for a new diet plan Research new minivans Go shopping for home electronics Check bank account balances

Study potential user scenarios in relation to these tasks, and then list the potential pathways that can be used to complete those tasks. In their excellent book, Web ReDesign: Workflow that Works, workflow experts Kelly Goto and Emily Cotler say that there are two predominant types of user pathways.

note

A functional pathway is a pathway that results in having to use functional and programmatic aspects of the site, such as shopping carts, logins, and complex searches. A nonfunctional pathway is one that is not dependent upon technical requirements, rather its goals are related to information such as looking at the company’s principals, looking up phone numbers, and so on. In all cases, knowing the goal of the individual is imperative to making sure they get to the function or feature they require. With many small Web sites, the user pathway process shouldn’t take very long. However, if you are working on a very large Web site, the process can be time consuming. Project managers should keep a close eye on this part of the project— it’s a very necessary step and, as mentioned, helps get usability testing started far earlier in the process. If it’s taking too long, focus more on functional pathways first, because nonfunctional pathways are usually easier to construct.

⽧ ⽧ ⽧

Secret #45:

Creating Archive Systems

A commonly overlooked area of architecture is how to design archive systems. The challenge with archives comes about when you’re creating date-related content that you want to keep available for site visitors, but will roll off of the top-level hierarchy at some point. Managing the means by which this content is published means a world of difference when it comes to the site visitor being able to find that content. While not a specific step within the IA process, the need to create effective archives is becoming increasingly clear as Web sites grow in scope. Archive systems are most relevant to the following: ⽧ ⽧ ⽧ ⽧

Large-scale public Web sites Intranet sites for industry, government, research, and education News sites Personal Weblog sites (some of these sites are becoming enormous!)

⽧ 64

Part I: Tools, Planning, and Content

⽧⽧⽧

The main issues in creating archive systems are as follows: ⽧ ⽧ ⽧

Understanding your content Categorizing content accordingly Structuring the directories and documents in such a way that they can be permanently stored and retrieved

If you’rethinking “Hey! I did all this when auditing my content,’’you’recorrect. The big difference is figuring out how to make a given document permanent. Changing a URL or filename is a major issue, so you don’t want to do that if you can avoid it. The best way to do this is to know while going in, which documents will require archiving and permanently house them by date, category, and topic.

tip

The best thing you can do to ensure long-term structure for archives is to determine which documents will be archived, and leave them in that location forever.

These days, archives are managed by a content management system (CMS). CMSs are an extremely hot topic these days, mostly due to the fact that they are very often extremely expensive and difficult to implement. What’s more, any good CMS will allow you to import existing information into its format, so if you aren’t using a CMS with archiving for a given project, consider building your own archiving structure and then worrying about the technology later.

note

Having a search feature on all pages is a tip you’re going to read quite often in this book. If you have a very large site, you can provide additional user pathways to detailed content such as archives via advanced searches that allow the site visitor to search using date, keyword, content, and topic filters.

⽧ ⽧ ⽧

Secret #46:

Considering Frequency of Updates and Redesigns

Another issue that sneaks into the long-term concerns of a site’s architecture is how frequently the information is going to be updated and the site freshened up. This relates to IA because it is during the IA process that you can determine areas of potential technical growth of the site for the long term, allowing designers to tap into technologies such as server-side includes, application and database technologies, and other document and function-related processes without having to redesign the infrastructure.

note

Always anticipate that a Web site will grow or be redesigned. If you don’t build your architecture without some organized awareness of what might potentially emerge, you are at a serious disadvantage later on, when growth does occur and redesign is imminent.

Along with helping to create a scalable architecture, ensuring that you make plans to update and redesign the site early on allows you to anticipate with improved accuracy what kind of growth your document base is going to expect. This means you’ll be able to architect your site to allow for scalability.

⽧⽧⽧

Chapter 3: Architecting Your Information

⽧ ⽧ ⽧

⽧ 65

Secret #47: Setting Site-Wide Standards As I mentioned earlier, it may be up to someone other than the IA to set and document the standards being used. However, it can also fall into their jurisdiction because the IA should at this point have a deep understanding of how the site and its interface work. Whether managed by your IA team, design team, or content team, it is always helpful to set site-wide standards. These are the various production guidelines that the entire team will follow as it works through the production concerns of the site. Setting these standards can be the job of the lead designer, the project manager, or can be done by a full team. If you are working in a team environment, getting feedback from all team members for site standards will help you avoid leaving important information out.

tip

Some of the concerns for which you should study your site and create a standard include the following: ⽧ ⽧ ⽧ ⽧ ⽧ ⽧ ⽧ ⽧ ⽧ ⽧ ⽧

tip

Code Code commenting Colors Directory structures File naming conventions Graphic formats Maintenance list Accessibility guidelines Content guidelines Team members and roles Policies Project managers should encourage site-wide standards early on, and check on all relevant site standards during the Quality Assurance (QA) phase.

⽧ ⽧ ⽧

Secret #48:

Developing a Site-Wide Style Guide

The style guide gathers up all the various standards you’ve created for your site and places them in a single guide so that all members of a team can access the information and ensure that all the guidelines are followed. Whenever a team member has a concern, he or she can check the guide before asking questions, saving everyone time. Style guides typically reflect all the information found after the development of site-wide standards. During their redesign of the New York Public Library, Jeffrey Zeldman and Carrie Bickner co-created an excellent style guide for coding standards (see Figure 3-7).

⽧ 66

Part I: Tools, Planning, and Content

⽧⽧⽧

Figure 3-7: The online style guide for the New York public library. The NYPL Style Guide, at www.nypl.org/styleguide/, is extremely straightforward and provides a starting-point guideline for those interested in developing a practical style guide.

tip

I’ve found it especially helpful to publish the guides in multiple formats: PDF, Web, and print. This makes the guide widely available to everyone no matter where they are.

Summary How information is managed can be a very challenging process. There is no doubt that the redesigns and upgrades for many Web sites have proven the need for intelligent IA going into a project. In deconstructing these sites, many of which suffer from organic growth problems—inconsistent naming, poorly organized archives, navigation systems that are limited because they were designed to reflect a more simple architecture—we become very aware that IA is as essential to the site development process as graphic design or HTML. As we begin applying IA methods, we also begin to grasp the way the various fields within the Web profession are layered and interwoven. Good project management and planning are integral to a smooth project, good IA is essential to bridge the technical and presentational aspects of a Web site, and IA inevitably is a portion of usability and content design—two of the topics you’ll be delving into more deeply in the following chapters.

Chapter

Making Sites Usable and Persuasive

4

⽧⽧⽧⽧⽧⽧⽧⽧⽧⽧⽧⽧⽧⽧⽧⽧⽧⽧⽧⽧⽧⽧⽧⽧⽧⽧⽧

Secrets in This Chapter #49: #50: #51: #52: #53: #54: #55: #56: #57: #58: #59: #60: #61: #62: #63:

Create Consistent Branding . . . . . Determining Primary Navigation . . Secondary Navigation . . . . . . . . Grouping Navigation by Like Items Iconography and Language Use . . Managing External Links . . . . . . Direct Access to Site Features . . . . Placement of Critical Information . Consistent Placement of Elements . Drop-Down Menus . . . . . . . . . . Pop-Up Windows . . . . . . . . . . . Consider Tabbed Navigation . . . . Provide Orientation . . . . . . . . . . Date and Time Formats . . . . . . . Cost-Controlled Usability Testing . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

⽧⽧⽧⽧⽧⽧⽧⽧⽧⽧⽧⽧⽧⽧⽧⽧⽧⽧⽧⽧⽧⽧⽧⽧⽧⽧⽧

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

68 69 71 72 74 77 81 83 84 84 85 87 88 89 90

⽧ 68

Part I: Tools, Planning, and Content

⽧⽧⽧

S

triking a balance between usability recommendations, practical experience, and usability testing is an accurate factor in making choices when it comes to usability practices and user experience. This chapter offers some tried-and-true wisdom of usability as it applies to common Web site features to help you find that middle ground. Although this chapter is not a comprehensive usability tutorial, it can provide you some of the best secrets to ensuring your site is both usable and persuasive for its intended audience.

⽧ ⽧ ⽧

Secret #49:

Create Consistent Branding

When you think of branding, you might think of logos, colors, taglines, and names relating to a given product, company, or service. Although branding encompasses those elements, true branding is a far more powerful and subtle issue than you might expect. Successful branding is about creating an emotional relationship between an individual and the representative company or product. This means that good branding creates a response in people—whether a tagline makes us feel comfortable, or a logo makes us feel energetic, or a color scheme makes us calm—these responses are the desired results of effective branding. Branding can be achieved using a variety of techniques. Contemporary marketing theory breaks down branding into two types: ⽧



Direct Experience. In direct experience branding, the emotional relationship is one-to-one. If you have a great burger at Ye Olde Burger Shoppe, the satisfying results of that meal relate emotionally to the product and brand. Indirect Messaging. The indirect method uses slogans, sponsored events, and promotions to connect people to product brands. The key to successful indirect messaging is repetition, usually in the form of TV and magazine ads, and billboards.

Web sites can benefit from both forms of marketing (Figure 4-1), although Web sites themselves are almost always going to be a direct experience for people these days. You go to a site for a reason—to read a Weblog, purchase copies of a favorite author’s books, and so forth. You interact with the site, and your experience there creates the emotional one-to-one feeling found within direct experience marketing. When creating a lasting relationship between an end user and a product, company, organization, or service, Web designers need to plan the direct experience to have a specific emotional result. For example, my bank’s Web site provides excellent service, useful management tools, and provides me with an emotional sense of security. This kind of bonding between a site’svisitor and a product can be accomplished using a range of specific usability techniques—many described throughout this chapter. But we can also draw from indirect messaging techniques to enhance our goals. All of the following things can work on the indirect level by providing repetitive images: ⽧ ⽧

Using consistent placement for logos from page to page Using consistent color and graphic styles

⽧⽧⽧

Chapter 4: Making Sites Usable and Persuasive

⽧ 69

Figure 4-1: Ads on Web sites are considered indirect messaging, but the actual Web site itself is a direct experience. ⽧ ⽧

Typography Iconography

Combining an effective direct experience and consistent statement of brand will help you to bond your site visitors to your site, creating lasting, rewarding relationships.

⽧ ⽧ ⽧

Secret #50: Determining Primary Navigation A primary navigation scheme is the main navigation for your site. It may be the only navigation you have, or you could combine it with other navigation, depending upon the scope and requirements of the site. At the heart of any Web site’s usability lies its navigation. How you evolve your navigation schemes will depend upon a lot of the work you’ve done in planning and architecting the site. But it is vitally important to make sure you really hone in on the primary features and functions of your site, reducing the number of options and placing them in an order that is logical. An example of logical ordering might be as follows: 1. 2. 3. 4. 5.

Home Books Video Audio Contact

⽧ 70

Part I: Tools, Planning, and Content

⽧⽧⽧

Whereas illogical ordering might be the following: 1. 2. 3. 4. 5.

Video Contact Audio Home Books

Looks pretty simple, right? Well, that’s the point. You know what it’s like to do certain tasks, such as driving a car. We’ve repeated such actions over and over in our lives, so the acts of accelerating, braking, signaling a turn, and so on have become a part of us. We’renot actively thinking out each step; it’sbecome automatic and easy. Navigation should be that for a visitor. Some readers may be familiar with Steve Krug’s aptly named book Don’t Make Me Think!. The entire idea that site visitors should not have to work out complex tasks just makes sense. Figure 4-2 shows Designtopia, a site with a common-sense approach to navigation.

Figure 4-2: Designtopia offers extremely simple, persistent, and obvious navigation on all of its pages, making the experience of navigating the site a no-brainer. Using the information you gather when wireframing, prototyping, and mapping your site, primary navigation schemes emerge quite readily. And when it comes to any navigation scheme, one thing is certain: Simple is always better.

tip

You can also think of navigation as a form of indirect messaging. Always keep primary navigation in the same location, using the same visual styles, throughout your site.

⽧⽧⽧

Chapter 4: Making Sites Usable and Persuasive

⽧ ⽧ ⽧

⽧ 71

Secret #51: Secondary Navigation Secondary navigation assists users in drilling down further into the hierarchical structure of your site. Secondary navigation should be reserved for detail—the primary navigation remains dominant and consistent in its placement throughout a site. Forms of secondary navigation include the following: ⽧

Alternative text links. This technique is a very common practice of including text links on those pages where image-based navigation is in use. This helps with the accessibility of the site (see Figure 4-3).

Figure 4-3: Alternative text links provided on Lynda.com. This technique is in widespread use as optional navigation. ⽧

Drop-down menus. These are menus for quick access to specific areas of a site (see Figure 4-4).

Figure 4-4: Drop-down menus are a popular means of adding quick access to site sections. ⽧

Section submenus. Larger sites often have submenus for individual sections (see Figure 4-5).

⽧ 72

Part I: Tools, Planning, and Content

⽧⽧⽧

Figure 4-5: Primary navigation with a section submenu on the Adaptive Path Web site provides a classic example of secondary navigation. The most important secret when designing secondary navigation is to make sure it doesn’t conflict with the primary scheme. It should appear in a different location, whether below or to the side of the primary navigation, and it should appear only when necessary. Figure 4-6 shows a prototype page with “zones.’’ Notice how primary and secondary navigation are in distinctly different zones.

Figure 4-6: Mapping potential navigation zones on a prototype page.

note

Secondary navigation should be distinctive in its visual design, yet not so much so as to call more attention to it than the primary.

⽧ ⽧ ⽧

Secret #52: Grouping Navigation by Like Items While working with your information architecture, you’ll find that as you begin to develop navigation schemes, you’ll be listing out specific areas of a site. It’s very

⽧⽧⽧

Chapter 4: Making Sites Usable and Persuasive

⽧ 73

helpful to take such a list and then group like items, combining them to reduce the number of options and the need for the site visitor to think much about where things might be located. Here’s a list of potential Web site navigation items for a portal site: ⽧ ⽧ ⽧ ⽧ ⽧ ⽧ ⽧ ⽧ ⽧ ⽧ ⽧ ⽧ ⽧ ⽧ ⽧

Quote Horoscope Technology Sports Fortune Weather World Nutrition Business Poll Fitness TV listings Movie listings Lottery Travel

When you have the list of items complete, sit down and try to identify like groups. Right off the bat here, I see two primary groups. The first is News: ⽧ ⽧ ⽧ ⽧ ⽧ ⽧

World Sports Weather World Business Technology

The other group could be Activities: ⽧ ⽧ ⽧ ⽧ ⽧ ⽧ ⽧ ⽧ ⽧ ⽧

Quote Horoscope Fortune Poll Fitness Nutrition TV listings Movie listings Lottery Travel

Upon closer examination, activities can be broken up into activities and entertainment. Activities would be related to the site itself: ⽧ ⽧ ⽧ ⽧ ⽧

Quote Horoscope Fortune Lottery Poll

⽧ 74

Part I: Tools, Planning, and Content

⽧⽧⽧

The entertainment category would include the following: ⽧ ⽧ ⽧ ⽧ ⽧

TV listings Moving listings Fitness Nutrition Travel

At this point, we have three top navigation areas: News, Activities, and Entertainment. Depending upon the site’s needs and structure, you can break things down even further. The point is for you to organize, merge, and combine topics in effective logical groups so the site visitor doesn’t have to.

⽧ ⽧ ⽧

Secret #53: Iconography and Language Use The use of icons (iconography) in navigation was a popular technique long before we began studying navigation for the Web. Navigation is, of course, a part of any user interface—whether it be software programs such as Word, kiosks, CD-ROMs, or Web sites. Iconography typically relies on metaphor. Metaphor is the symbolic representation of an object or idea. That representation defines some likeness between the symbol and its related object or idea. Familiar uses of metaphor in iconography include the following: ⽧ ⽧ ⽧ ⽧ ⽧

An envelope to represent e-mail A shopping bag or stack of wrapped boxes to represent shopping A stock ticker to represent finances A pencil to represent articles A briefcase to represent job and work

If you think about these examples carefully, you’ll see that they are very clear in their relationship. This is referred to as a concrete metaphor. The symbol is very literal (see Figure 4-7). These icons were designed specifically to assist foreign students whose first language might not be English in finding services online such as e-mail, weather information, medical information, prescription refills, and assistance.

note

c Chris The icons in Figure 4-7 and the Web site screen shot in 4-9 are  Silverman, and used here with permission. Please see Chris’s site, www.csideaworks.com/, for some great iconographic design and inspiration.

Another type of metaphor in iconography is referred to as abstract. An abstract metaphor can be a literal image that is abstractly related to the corresponding object or idea. More commonly, abstract metaphors are created symbols that have no specific meaning until related to the object or idea in question. The designer makes the suggestion between the icon’s design and the related idea—with abstract metaphors, the meaning is not literal (see an example in Figure 4-8).

⽧⽧⽧

Chapter 4: Making Sites Usable and Persuasive

⽧ 75

Figure 4-7: Concrete iconography from designer Christopher Silverman.

Figure 4-8: Can you find the navigation? It’s the circles with shapes along the bottom of this design. Abstract iconography is based on the designer’s conceptual response to the ideas being expressed.

⽧ 76

Part I: Tools, Planning, and Content

⽧⽧⽧

Generally, if you’re trying to make your site very usable, very concise, and are encouraging the “Don’t Make Me Think’’ideology, the designer should stick to concrete metaphor in iconography. Of course, your content and audience will shape your design decisions. For example, abstract iconography might work well on a Web site featuring the works of abstract artists. Only your research and planning will help you determine if abstract metaphor is a reasonable choice for your navigation icons. Of course, many designers never choose to use iconography because language is sufficient. Simply styling the text or creating images using words to suggest navigation options is a completely legitimate way to go. And now, with the many ways we can use CSS for style navigation, we don’t even need to use JavaScript to toggle images for creative effects.

cross ref

For more information on using CSS for style navigation, refer to Chapter 8.

Consider the following guidelines when using text for navigation: ⽧ ⽧



Keep text options short and concise. Instead of “Visit Other Weblogs,’’ you would use “Other Weblogs,’’or even just “Weblogs.’’ Avoid jargon or location-related terminology where possible. This is especially true in those situations where you are trying to reach a broad audience that might not always speak the language in which your site is authored. Stick to convention. Everyone knows what “Contact’’and “About’’means, but they might have to think twice about the words “Where’’and “What’’ being used to represent the same thing.

Figure 4-9: Combining iconography with text for clarity in the primary navigation.

⽧⽧⽧

Chapter 4: Making Sites Usable and Persuasive

⽧ 77

Of course, there’s a happy medium here. Many designers combine iconography with text. If you’re after clear communication, combining the word “e-mail’’ with your envelope icon does the trick (see Figure 4-9). If you want to create a more abstract design but still assist with clear navigation, you can use the abstract icons along with the literal text.

note

For more information about clarifying language usage for better comprehension and accessibility, please see Chapter 10.

⽧ ⽧ ⽧

Secret #54: Managing External Links It’s no secret that the longer you keep a person on your site, the more of an emotional relationship you can develop between what your site represents and that individual.

This is true of all types of Web sites, including Weblogs, commerce sites, and portals. Commerce sites are especially concerned with this issue, because while you’ll visit your favorite Weblog to enjoy the content, you might never be back to the “Baby Stuff’’ Web site again, yet you can be sure they hope you’ll be buying your friend’s baby shower gifts there. So, managing external links becomes very important in those situations where keeping a person on the site up through the desired outcome of their visit is mission-critical. Typically, this means avoiding any external links in content close to the top of the page. Keep links short and relevant. You can even write the surrounding content of links in such a way to make them more—or less—attractive for your visitors to follow. Here’s an example of a link (see Figure 4-10) I’d probably follow: Finding the popular and controversial ``Heya Charlie Brown'' movie hasn't been easy. But I've found the last link on earth for the upbeat little flick. Get it now!

And here’s a link (see Figure 4-11) I might skip: That Heya Charlie Brown thing really got out of hand.

In the preceding figure, it’s not only the lack of enthusiasm in the voice of the content, but also the placement of the link. Had it been placed around “Heya Charlie Brown,’’it would likely be more noticeable. There are more problems than just these concerning links and Web site usability. Table 4-1 describes some of those problems and provides suggestions for managing links more efficiently.

note

You can find more information on link validators and link validation services at www.business.com/directory/internet and online/site management/link monitors/.

⽧ 78

Part I: Tools, Planning, and Content

⽧⽧⽧

Figure 4-10: A persuasive link.

Figure 4-11: The content isn’t enthusiastic, and the link falls in an odd spot. I probably would not follow this link.

⽧⽧⽧

Chapter 4: Making Sites Usable and Persuasive

Table 4-1: Link-Related Problems in Usability

⽧ 79

Problem

Suggestions and Solutions

Link has incorrect URI

This common problem may not have anything to do with the way you originally managed your external links. Sites go away, or move files, and servers go down. Or, you might have simply mistyped the URL. The best way to find these problems is to run your site through link-checking software. You can do this with many products, including Web development products such as Dreamweaver. A number of online services also provide regular link checking and reports (see resources note following this table)

Link has no URI

This happens to me quite often as a result of adding link markup with no URI because I’m using it as a placeholder. It can also happen for the same reasons mentioned for incorrect URI listings. If you are creating placeholder links, use some kind of consistent dummy text, and then use your editor to find those dummy links when you’re ready to add the URLs. You may also use any of the link-checker products as a means of finding missing links

Link text not visible inline

Links in text are often difficult for readers to discern, particularly if the link colors are close to the text colors. The proper technique for colorizing text is a much-debated issue. Some purists, such as Jakob Nielsen, who authored the seminal book Designing Web Usability and is one of the leading pundits in the field, believe that link colors should remain the conventional browser default colors, but most designers don’t agree. No matter which track you decide to take, it’s important that there is some discerning feature about your inline text links, such as ensuring the link colors contrast effectively with the text, making them easier to identify

Too many links in a page

When the rise of the portal site came about some years back, I was pretty flummoxed about what to tell Web designers about how to manage links for portal sites. Portal sites tend to be all about linking elsewhere, but with so many links on a page, how do we know where to go first? There’s no guidance. In recent years, Weblogs are becoming portals in a sense, offering far more links on a page than home pages of the past (Figure 4-12 shows a Weblog example). The best solution to the issue of having many links is to first assess what really needs to be there and remove what doesn’t. Then, organize your links into effective groups. This will help your users a great deal continued

⽧ 80

Part I: Tools, Planning, and Content

⽧⽧⽧

Table 4-1: (continued) Problem

Suggestions and Solutions

Link is to a non-HTML document

You will often have cause to offer users download links to non-HTML document formats such as PDF files, Word documents, Excel spreadsheets, audio and video files, and so on. Because not all browsers support non-HTML document formats either with or without plug-ins, if you are offering the file specifically for download, be sure to note what type of file it is and how large it is (as shown in Figure 4-13). You may also want to offer any plug-ins on your site so your audiences are prepared

Link text is very long

I’m sure you’ve seen link text that is a paragraph long. When I see long passages that are linked, I assume the person doing the markup made a mistake! Typically, links should be at least one word and up to as many as six or seven, but not more. Usually three to five words, clearly written, are sufficient

Figure 4-12: Weblogs are becoming link farms. The best solution is proper organization, as seen here on the right-side link options of designer Doug Bowman’s Stopdesign Web site.

⽧⽧⽧

Chapter 4: Making Sites Usable and Persuasive

⽧ 81

Figure 4-13: If you’re offering downloads to non-HTML file formats, describe to your audience what they’re downloading, which format it’s in, and how large the file size is.

⽧ ⽧ ⽧

Secret #55: Direct Access to Site Features What’s the most important reason people come to your site? If you don’t know, you need to find out—because making sure you get your visitors from their point of entry to the feature they want is a prime directive. Notice that I wrote “from their point of entry.’’ That’s because not everyone will come to your site via the home page. So even if your home page has immediate access to the fabulous online game you’re famous for, what happens if someone comes in via your discussion board page? You’ve not only got to have direct access to the critical features on your site, but you’ve got to make that access consistent (it looks and behaves the same way) and persistent (it exists in the same location on each page) throughout the site, as well. The Web Standards Project (WaSP) has been struggling with an issue that exemplifies this problem quite well. As of this writing, one of WaSP’s primary goals is to offer designers and developers standards-related references and resources. We call this the LEARN group, which has access from the top level of our navigation (see Figure 4-14). Yet, when you click on the learn link, you get an expanded menu with a variety of options (as shown in Figure 4-15). I personally feel this menu is extremely confusing, because the options do not guide me to any specific place. I have to really think to figure out where the information I want might be. And what’s the difference between “reference’’ and “resources’’ anyway? A visitor could easily

⽧ 82

Part I: Tools, Planning, and Content

⽧⽧⽧

Figure 4-14: The learn section is clearly demarcated at the top level, fourth option down from the top.

Figure 4-15: The “learn” submenu is unclear and, as a result, places site features too far from the individual.

⽧⽧⽧

Chapter 4: Making Sites Usable and Persuasive

⽧ 83

click one and end up in the wrong place. In addition, if a visitor came in at one of these lower pages, he or she might be even more confused. Back up for a second and think about all the logical things we’vebeen discussing— the need for planning, understanding audience, keeping things orderly and clear— they do help. And it’snot that the WaSP design team didn’tdo those things. But you can see that, at this time, the WaSP Web site does not provide true direct access to one of the most important features it wants to make available for site visitors. I’m not exactly sure if it brings comfort or concern to you to know that some of the most respected Web designers and developers couldn’t quite nail the information architecture and usability of a Web site—especially one in a state of transition—but it does exemplify that these techniques are still being worked out and that these challenges are keeping all of us on our toes. Fortunately, WaSP is re-examining its goals and design, which often is the best any of us can do—create, study the problems, and improve.

⽧ ⽧ ⽧

Secret #56: Placement of Critical Information In the newspaper industry, headlines are said to run “above the fold.’’This means that the critical news is placed above the fold of the paper, so that it’s the first thing people see. While the concept of “fold’’is really nonexistent in Web design, the idea that critical information needs to be placed at or toward the top of a page remains a good thought (see Figure 4-16).

Figure 4-16: Critical elements should be placed high up on a page.

⽧ 84

Part I: Tools, Planning, and Content

⽧⽧⽧

Despite the fact that a new Mozilla project had just been released, the primary information on this page is about Mozilla’s hallmark product, the Mozilla Web browser. Therefore, it holds first position on the page.

⽧ ⽧ ⽧

Secret #57: Consistent Placement of Elements Another very significant issue in terms of successful user interface design is the consistency of page elements, both in terms of visual placement of logos and navigation, and of their style.

More than likely, you’ve visited a Web site where you started to dig in, and ended up on a page within that site that had no consistency in the placement of elements or the design as you moved from page to page. The problem is less pervasive than it used to be—particularly as awareness of usability concerns in design grows. When working on the placement of elements, include the following: ⽧

⽧ ⽧



note

Logos. Typically, a logo will be persistently placed in one spot throughout the site. A common technique is to make the logo larger on the home page and somewhat smaller on subsequent pages, but in all cases the location should be the same. Navigation. As already discussed, the consistent placement of navigation is a critical aspect of successful, usable design. Link to Home. All pages of your site should have a persistent link (or links) to the home page. It’s conventional to link the logo graphic to the home page, use a persistent option on the navigation bar, or both. Most usability experts recommend that if an option exists for the home page link on the home page, it should not be live. Search. While not all sites offer search capabilities, it’s becoming more common for medium-to-large-scale sites to implement them. Effective search can make a site visitor’s experience easier, so all Web designers and developers should consider search features for their sites. Many experts recommend that the search feature be very prominent, often appearing as a first option on the primary navigation bar. Many usability advocates feel that there are at least two exceptions to consistent placement of elements, search pages and forms, because they often require different features.

Figure 4-17 shows a screenshot of the Wiley Web site. The logo, primary navigation, search, contact, help, account, and shopping cart information remain persistent as well as consistent throughout all levels of the site.

⽧ ⽧ ⽧

Secret #58: Drop-Down Menus Drop-down menus are a very popular means of offering navigation options and options within forms. Drop-down menus can be especially effective because they are familiar to Web audiences, are easy to use, help reduce errors, and take up a lot less screen space than long menu systems.

⽧⽧⽧

Chapter 4: Making Sites Usable and Persuasive

⽧ 85

Figure 4-17: Consistent placement of elements assists users in navigating and orienting within a site. However, using drop-down menus shouldn’t be something done just for these reasons. Offering a menu like this has to make sense. What’s more, usability experts such as Jakob Nielsen make some excellent recommendations when it comes to using drop-downs, such as the following: ⽧





Avoid very long menus. Too many options in a drop-down menu become problematic because they require the site visitor to scroll uncomfortably. This can also cause problems for the mobility impaired, limiting the site’s accessibility. Avoid menus with short entries. Any menus offering options with very short entries, such as state abbreviations, also become problematic for visitors. Typing the abbreviation into a text box is easier. Avoid menus of known information. Nielsen points out that information we type frequently, such as our birth dates, are better collected via text boxes than drop-down menus. His claim is that this kind of information is “hardwired’’to people’s fingers, and that it’s easier on them to type it than go through the trouble of selecting a drop-down menu.

Despite these warnings, I’ve often favored drop-down menus for quick links to site locations, or for enhancing search (see Figure 4-18).

⽧ ⽧ ⽧

Secret #59: Pop-Up Windows The trouble with popups is easily illustrated by the proliferation of pop-up blocking software and implementation of pop-up blocking in Web browsers such as Mozilla. But most of this has been as a result of the proliferation of interstitial advertising. Various, reasonable uses of popups have been around for a while.

⽧ 86

Part I: Tools, Planning, and Content

⽧⽧⽧

Figure 4-18: The search drop-down menu in use here is very effective due to its familiarity and short list of options. When working with popups, first and foremost, be aware that many people will have popups blocked in the public sector, so they simply may not be the best choice. Some applications that are considered reasonable for popups include the following: ⽧



⽧ ⽧

Product details. If you are offering a product on a page with other products and would like to provide specific details for each, the use of a pop-up window is credible. Visual details. Details of graphics can be extremely helpful. Consider sites displaying mechanical and scientific information and commerce sites. Details of devices and products can be provided in popups. Code samples. One of my favorite uses for popups is for code samples in tutorial and script reservoir sites. Weblog comments. A current common use for pop-ups is for comment systems in Weblog software (see Figure 4-19). In Weblog comments, URLs are often shared. While linking within popups isn’t considered the best practice, many Weblog users are adept at managing links within popups. For more general audiences, you may wish to avoid links within your popups.

note

If you do choose to use popups, consider the following guidelines as a way of reducing problems related to accessibility and usability: ⽧ ⽧ ⽧

Let your visitors know that the link leads to a pop-up. Avoid links within the windows (see preceding note for exception). Ensure windows are available even if JavaScript is disabled.

⽧⽧⽧

Chapter 4: Making Sites Usable and Persuasive

⽧ 87

Figure 4-19: Pop-up commenting system on my Weblog.

Accessibility specialists suggest that you should not remove any of the browser’s components from your pop up, including browser frame, menus, and scroll bar, and that you should be sure that your users can resize the window.

note

For more information about making sites more accessible, see Chapter 10, “Adding Accessibility Features.”

⽧ ⽧ ⽧

Secret #60: Consider Tabbed Navigation Any lover of Amazon.com knows that they were one of the first sites to implement what eventually became a practically ubiquitous means of managing navigation— tabbed navigation. Tabbed navigation is an attractive option for numerous reasons, including the following: ⽧





Tabs are familiar. Tabbed navigation is so common both online and offline (the familiar tabs within a file folder) that even the most inexperienced of site visitors can use it with ease. Tabs are persistent. Tabs are by nature persistent from page to page. The only thing that should change is that the tab related to the current page should appear as the dominant tab (see Figure 4-20). Tabs are consistent. Along with persistence, tabbed navigation is consistent in its general visual features.

⽧ 88

Part I: Tools, Planning, and Content

⽧⽧⽧

Figure 4-20: Dominant tabs should contrast well with other aspects of the tab. You can see this in two instances on my TypePad control panel page.

If you’re using tabs, the current tab and the related space below it should contrast well with tabs in the background.

tip

⽧ ⽧ ⽧

Secret #61: Provide Orientation The concept of orientation is another major aspect of user interface design. At any point while visiting a Web site, the user relies on subtle (and sometimes not-sosubtle) cues to keep a sense of where they are within the site. As mentioned earlier in this chapter, not every site visitor enters your site from the home page. Therefore, it’s very important to offer orientation aids on all pages.

note

You can assist your site visitors with orientation in a number of ways, including the following: ⽧

Show site name and location in title bar. By showing the site name and specific location in the title, you can improve orientation. If you have a very large site, just having the site name and subsection of the site, such as “All News: Technology Headlines Today’’will be a helpful aid to your visitors, even if there’s no easy way to create individual titles for all the specific topic pages.

⽧⽧⽧



Chapter 4: Making Sites Usable and Persuasive

⽧ 89

Use some change in navigation to reflect location. A very familiar technique is having the color or style of a navigation link or image change to indicate that you’re on a specific page (see Figure 4-21). Using arrows or other symbols is also common.

Figure 4-21: Changing a link style in some way can assist with orientation. ⽧



Make sure sections are clearly demarcated. Each section within a site should be identified. Whether you use iconography, text, photos, color-coding, or other visual design techniques to achieve this, make it clear to visitors when they’re in the “Books’’section of your site rather than the “DVD’’section. Use breadcrumb navigation. Breadcrumb navigation is an excellent way to keep visitors oriented, as well as to provide them with ways to link back to other sections within the site (see Figure 4-22).

Figure 4-22: Breadcrumb navigation remains one of the most helpful ways to keep a site user oriented, as well as provide additional navigation features. ⽧

Provide a site map. Especially important for very large sites, a site map denoting locations with links to individual areas can be extremely helpful for people trying to orient themselves to your site.

⽧ ⽧ ⽧

Secret #62:

Date and Time Formats

The web is a worldwide phenomenon, and there are numerous ways across the world to denote time and date. Sometimes these formats can conflict depending upon the format used in a given country. Consider the following date: 09/02/04

If you’re a reader in Europe, you’ll likely interpret this to mean that it’s the ninth day of February of the year 2004 (dd/mm/yy). U.S. readers understand this time format to mean the second day of September of the year 2004 (mm/dd/yy). And you’ll find still other date formats in use around the world. The secret when it comes to date formats is to use the International Date Format. This is an International Organization for Standardization (ISO) standard, which makes it truly international. It places the century and year first, then the month, then the day. So for the ninth day of February 2004, you’d write the following: 2004/02/09

Or, effectively, ccyy/mm/dd. Another way you can assist users with date formatting is to write the date out in some way, such as in the following examples:

⽧ 90

Part I: Tools, Planning, and Content

⽧⽧⽧

9th of February, 2004 February 9, 2004 9 FEB 2004 9 February 2004

If you choose to do this, it’s recommend that you do so in addition to including the international format.

note

You can learn more about international standard formats at the ISO Web site, www.iso.ch/. The date and time standard is ISO–8601.

A related issue is the way we describe time in documents. Most of the world uses the 24-hour time format—something that people in the United States typically refer to as “military time’’ and only use in formal settings. Otherwise, we use an A.M./P.M. format to denote time. Most of the world: 13:00 U.S.: 1 P.M. Fortunately, most people in the United States are familiar with the 24-hour time format, so use it to reach the broadest audience possible. The ISO 8601 standard echoes this logic: it says to use 24-hour time in all cases. However, while this is a reasonable solution, there are going to be cases where using international formatting isn’t the best choice, such as with U.S.-based intranets or U.S.-centric sites. In those cases, using U.S. formats may be the better choice.

tip

If you’re going to use U.S. time formats, include the “A.M.” or “P.M.” for greater clarity.

⽧ ⽧ ⽧

Secret #63:

Cost-Controlled Usability Testing

Perhaps one of the greatest controversies in Web design is how to perform usability tests that provide results without incurring significant cost to the client. There are two primary types of usability testing: Lab-based and remote. In the lab-based version, testers observe site visitors as they manually go through a set of tasks. Testers will interview the participants and write up an overview of their research. The research results can then be applied to the site to improve its usability. The advantage of lab-based testing is that the process can be tightly controlled and cleanly observed. The major disadvantage of lab-based testing is that it can be extremely costly. In remote testing, the people to be tested are using the Web site in question, online. The key component of remote testing is finding good online meeting tools and online applications so testers can observe remote site visitors. The advantages of remote testing include being able to reach a wider audience and keeping costs down. Usability studies can be offered throughout the life cycle of a site’s development, something that many usability specialists recommend. The drawbacks to

⽧⽧⽧

Chapter 4: Making Sites Usable and Persuasive

⽧ 91

remote testing are that it can be technically problematic (connectivity problems, slow applications), and those who are administering the test have limited or no visual feedback from the individual’s face or physical demeanor. Usability testing is important for any major site. However, the way in which you achieve your test and apply results is going to vary greatly based on budget, project life cycle, and human resources.

note

For more information on the pros and cons of remote usability testing, see “Experience remote usability testing, Part 1” at IBM developerWorks, www-106.ibm.com/developerworks/library/wa-rmusts1/. Another excellent article on the topic is “Remote Online Usability Testing: Why, How, and When to Use It” at Boxes and Arrows, a rich resource for those interested in real-world applications of usability techniques. Finally, to learn about usability-related Web sites, additional articles, and books, see Appendix C, “Helpful Reading, Web Sites, and Resources.”

Summary The study of usability and user experience on the Web is so active an area that it’s producing massive quantities of documentation, methodology, and testing techniques. The Web design field grows deeper by the day, partly due to the attention being paid to how users use the Web, why they use it, and how we can help them use it more effectively. Of course, a site can be extremely usable, but what good is usability without real content? Chapter 5 gives you a look at how to create and manage content, increasing your ability to persuade audiences and making their experience easy as well as rewarding.

Chapter

Creating and Managing Fantastic Content

5

⽧⽧⽧⽧⽧⽧⽧⽧⽧⽧⽧⽧⽧⽧⽧⽧⽧⽧⽧⽧⽧⽧⽧⽧⽧⽧⽧

Secrets in This Chapter #64: #65: #66: #67: #68: #69: #70: #71: #72: #73: #74: #75: #76: #77: #78: #79: #80:

Finding Your Voice . . . . . . . . . . . . . . . . . Clarifying Site Purpose . . . . . . . . . . . . . . Text and the Computer Screen . . . . . . . . . . Writing Effective Paragraphs . . . . . . . . . . . Varying Pace . . . . . . . . . . . . . . . . . . . . Removing Extraneous Information . . . . . . . . Using Tables to Organize Data . . . . . . . . . . Using Lists to Simplify Ideas . . . . . . . . . . . Using Headers Meaningfully . . . . . . . . . . . Applying Style Standards . . . . . . . . . . . . . Avoiding Problem Grammar . . . . . . . . . . . . Understand Copyright! . . . . . . . . . . . . . . . Extending Copyright with Creative Commons . . Protecting Intellectual Property with Trademarks The Role of Patents on the Web . . . . . . . . . . What Is Digital Rights Management? . . . . . . Exploring Content Management Systems . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

⽧⽧⽧⽧⽧⽧⽧⽧⽧⽧⽧⽧⽧⽧⽧⽧⽧⽧⽧⽧⽧⽧⽧⽧⽧⽧⽧

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . .

94 95 96 99 100 102 102 104 105 106 107 107 108 109 110 110 111

⽧ 94

Part I: Tools, Planning, and Content

⽧⽧⽧

A

Web site’scontent is the most persuasive aspect of a site. But creating content for the Web is a totally different activity than creating content for other media such as books and white papers. Along with creation of Web content comes protecting and managing Web content. After you’ve prepared it appropriately, legally protecting your (or your client’s) property and strategically managing it can be a huge issue. This chapter shares secrets that will help you create and manage content in effective ways, including how to write more effectively for the Web, understand intellectual property (IP) issues and how they influence the work of Web designers, and what is required to make strategic decisions about long-term management of content. This chapter is very U.S.-centric because it deals with language and law, and these issues vary greatly from country to country. I’ve included some international resources here and there, but depending upon the languages you work with, some of the material here may not apply. The (IP) information centers on U.S. law. You will have to check with your country’s approach to rights management to see if similar laws and methods are in place. In all cases involving legal concerns or questions, a visit to an attorney is advised.

note

⽧ ⽧ ⽧

Secret #64: Finding Your Voice The human voice can express a wide range of sound: It can be loud or soft, silky or gravelly, or suave or gruff. The variety of sound has significance—how you use a given sound can help you in your conversations with others—to persuade them, calm them, express concern, and so forth. Voice in writing is the personality and character of the language used. You find it in literature, of course—where the author or characters in a given story have their individual style of language. You also see many examples of voice in the advertising world—think about the last commercial you saw on TV. Well-written advertising uses language that will influence and persuade the audience highly. Using these techniques on the Web is as important to the effective communication of your site’s intent as it is in more traditional forms of media. Consider how different one site is from another—each has its own personality. Some examples of how voice can be helpful for a type of site include the following: ⽧



Popular clothing catalogue. If you’re selling the latest style of jeans, your site might benefit from the use of hip, trendy language. The target audience, feeling comfortable and enjoying the fun and familiarity of the jargon, will be more likely to buy from a site that quite literally “speaks to them” than a similar site that uses bland language. Check out Girlshop at www.girlshop.com/ for a great example of a site that uses voice to communicate effectively with its young clientele (see Figure 5-1). Family car dealership. For a local car dealership aimed at selling mid-size cars and SUVs, language that expresses comfort and confidence can persuade by instilling a sense of security in its site visitors. For example, the Ford Motor Company Web site, www.ford .com/, has a section called “Heritage” in which Ford’s commitment to

Chapter 5: Creating and Managing Fantastic Content

⽧⽧⽧

⽧ 95

Figure 5-1: Girlshop uses fun, light language to sell to its young audience.



quality is expressed through its company history and profiles of Henry Ford and his family. In this case, more conservative language is being used as a means of conveying stability and quality. Anti-drug public service site. In this case, a more somber use of language is in order. The nature of the message may even benefit from a stern voice, compelling site visitors to take the message very seriously. For example, read the Bryan Lee Curtis story at whyquit.com (http://whyquit.com/whyquit/BryanLeeCurtis.html), a Web site dedicated to helping people quit smoking.

Whether you are creating a site for a clothing manufacturer, a car dealer, or a drug education Web site for a nonprofit organization, voice is going to matter. Take some time to review your site’s intent, your target audience, and develop a voice that is appropriate to your site goals.

⽧ ⽧ ⽧

Secret #65:

Clarifying Site Purpose

An issue that drives me completely mad (and will turn your visitors away faster than you can say “boo!”), is a site that fails to immediately identify its reason for being. You’re certain to be familiar with this scenario. You get to a Web site, maybe you followed a link from another site or from Google, and the site has no clear purpose. The content doesn’t reflect in any easily discernable way what the site is about. On my personal Web site, I stuck my tongue in my cheek in an effort to make fun of this problem (see Figure 5-2).

⽧ 96

Part I: Tools, Planning, and Content

⽧⽧⽧

Figure 5-2: Screenshot of Molly.Com clarifying the site’s purpose.

But just because I have the liberty to play doesn’t mean you will when it comes to a professional circumstance. Clarifying site purpose is achieved using a number of techniques, as follows: ⽧ ⽧





Ensure that you have some language on your home page that clearly defines the purpose of the site. Ideally, make your site name clear and self-evident, such as “The Anti-Smoking Site.” If you’re working with a company that’s more ambiguous, such as “Rad Industries,” consider including a descriptive tagline. I might not know what the company name refers to if I see it alone, but if you include the tagline “electric power for the future,” I’m going to more readily understand the significance of the name, and therefore, the site itself. Your headings and navigational elements should be written to reflect the topics within your site. If you’re working on the content of an anti-smoking site, using words such as “smoking,” “quitting,” and other language related to smoking helps to further express the primary topic of the site. Title your pages effectively. This is something a lot of Web designers (including myself, I’m ashamed to admit) often overlook. Using effective titling within the HTML . . . tags on pages helps orient the site visitor as well as reinforce the site’s purpose. Always begin with the site’s name, followed by the location within the site. A simple example that reflects this idea would be using “The Anti-Smoking Site: Welcome!” for the home page. By consistently using the term “The Anti-Smoking Site” in titles, it becomes far easier for site visitors to remain oriented.

Not identifying your site and its purpose is a dreadful mistake and should be avoided at all costs. Every site must have some mechanism by which the intent of that site is clearly expressed.

⽧ ⽧ ⽧

Secret #66:

Text and the Computer Screen

One of the difficulties in preparing text content for Web sites is that computer screens vary greatly in their technical complexity and the way they are affected by the operating system software the computer is running. So, much of effective text rendering depends upon the configuration of the site visitor’s computer, including the following:

Chapter 5: Creating and Managing Fantastic Content

⽧⽧⽧



⽧ 97

Screen resolution. Screen resolutions vary greatly, and it will influence the size and appearance of text. In Figure 5-3, you can see text at the resolution of 640 × 480, and in Figure 5-4, you’ll see text at a resolution of 1024 × 768. Of course, many people are viewing the Web at other resolutions, including the very popular 800 × 600 and 1280 × 1024 and higher. The variations are indeed significant, so always keep this in mind when working with copy.

Figure 5-3: Text as seen at a resolution of 640 × 480.

Figure 5-4: The same text viewed at a resolution of 1024 × 768.

⽧ 98





Part I: Tools, Planning, and Content

⽧⽧⽧

Color management. The way color is interpreted on screen varies greatly, too. Color is managed in part by the video card, in part by the monitor, and in part by the operating system in use. The variations are so great from set-up to set-up that it’s impossible to be sure how a person reading a Web site will perceive a given color. What’s more, some monitors run “hot,” meaning they exude a lot of brightness. While this is usually adjustable, many nontechnical people don’t realize they can make that adjustment. Hot monitors can cause headaches and fatigue, making people less likely to read long passages of text on screen. Font smoothing. Without smoothing, which is usually controlled by the operating system, fonts can appear very jagged and difficult to read (refer to Figure 5-5), adding yet another challenge for the Web designer to manage. Choosing appropriate fonts for text can help address this issue.

Figure 5-5: Without font smoothing, this title text appears jagged.

cross ref

For more information on choosing appropriate fonts, refer to Chapter 8.

Because of these influences, the on-screen experience varies greatly from person to person. To the technological issues, add those physical issues affecting an individual and the problem becomes even more complex. Such physical factors include the following: ⽧





note

Color blindness. Some form of color blindness affects about one in 20 people. That’s a significant number of people, so when you’re designing text for the computer screen, it’s incredibly important to be sure you make color choices for your text that address this issue. Low vision. People over the age of 55 are one of the fastest growing demographics on the Web. While problem vision is common in all age groups, for this particular group, poor vision is abundant. Knowing that audiences comprise numerous individuals who have vision problems can help you ensure that there’s ample contrast between your foreground and background text colors, that you offer sizing options (See Chapter 8), and that you have ample white space to help balance things out. Blindness. Many Web users are completely blind. This causes concerns related to accessibility, about which you’ll read more in Chapter 10, “Adding Accessibility Features.” For the purposes of this discussion, keep in mind that you’re writing in some cases for people who will be hearing (or in the case of Braille printers, touching) your words. Write as clearly as possible at all times. There’s a great Web tool called “Color Vision” at www.iamcal.com/toys/ colors/index.php that emulates all forms of color blindness. You simply choose the type of color deficiency, then select your actual colors, and the tool displays them the way the person who has that deficiency will see them.

⽧⽧⽧

Chapter 5: Creating and Managing Fantastic Content

⽧ ⽧ ⽧

⽧ 99

Secret #67: Writing Effective Paragraphs My mother is a noted author and scholar of multicultural literature. She has a Ph.D. in English, when she sits down to write e-mails, they’re written in very long paragraphs with few breaks, as though they were in essay form. Beautiful letters, but because of the limitations of the on-screen medium, difficult to read unless printed out, which sort of defeats the purpose. I remember learning in school that a paragraph must contain at least four complete sentences. Of course, formal writing has changed significantly over the past 30 years, but I believe the point of having at least four sentences has more to do with the ability to write effectively and clearly than encouraging wordiness where it isn’t necessary. As is exemplified by my mother’s writing style, what works on the printed page may not translate well at all to the electronic environment. Because of the physical constraints of the computer screen, writing for the Web has become a study of its own, and while the rules I learned in school all those years ago may no longer apply specifically, the goals of writing effectively and clearly do. The popular term for dealing with text on the Web is called “chunking.” This is the act of breaking up your information into digestible bits, aiding in the goal of clarity. Depending upon the voice you’re using, and the type of site you have, the length of your sentences, type of vocabulary you employ, and the length of your paragraphs are going to vary. Consider this text example I received from a client. Here’s a view of the cottonwood trees along the San Pedro River at the Three Links Farm, north of Benson, Arizona. This place is important to me because it is the first river I have had a hand in resuscitating. The Nature Conservancy bought this farm partly because of computer modeling work that I did for them starting in 1996, in order to retire the irrigation pumping and let the river flow again without interference from heavy irrigation pumping. The river flows year round now that the pumps are out of the ground, and we hope that the flow will continue to increase and benefit several miles of the river downstream as well. I am planning a drive out there this weekend, to take some pictures of the rusty old irrigation pumps stacked up in the shed, and give the kids a chance to mess around with driving a stick shift—super farm roads to drive on. As you can see, it reads pretty well but it’s a lot of text without any line breaks. My “chunking” broke up the paragraphs and ultimately created a more visually pleasing affect because of the added white space, too (see Figure 5-6). Here’s a view of the cottonwood trees along the San Pedro River at the Three Links Farm, north of Benson, Arizona. This place is important to me because it is the first river I have had a hand in resuscitating. The Nature Conservancy bought this farm partly because of computer modeling work that I did for them starting in 1996, in order to retire the irrigation pumping and let the river flow again without interference from heavy irrigation pumping. The river flows year round now that the pumps are out of the ground, and we hope that the flow will continue to increase and benefit several miles of the river downstream as well.

⽧ 100

Part I: Tools, Planning, and Content

⽧⽧⽧

Figure 5-6: Chunking text adds white space and makes it easier to read on screen.

I am planning a drive out there this weekend, to take some pictures of the rusty old irrigation pumps stacked up in the shed, and give the kids a chance to mess around with driving a stick shift—super farm roads to drive on. The rule of thumb with paragraph writing on the Web is to chunk all text to its most essential ideas. Sometimes this means a paragraph is going to contain fragments, or have less than the recommended four sentences. It doesn’t matter how short the paragraph gets—it matters that its content remains meaningful and clear.

⽧ ⽧ ⽧

Secret #68:

Varying Pace

If you’re going to have a lot of information on your site, keep in mind that along with voice and chunking, the pace of your language is going to influence your visitors. A catalog description can read at a slow pace. The “Leatherman” style of shoes is made of high quality leather for maximum comfort, fit, and style. These shoes are perfect for the casual gentleman and wear well from a day at the office to an evening on the town. To pick up the pace, simply shorten the sentences, use fragments, and add some energy. You’re a guy on the go. From the office to a night out, choose Leatherman! It’s the perfect style.

Chapter 5: Creating and Managing Fantastic Content

⽧⽧⽧

⽧ 101

Nick Usborne is a copywriting and content expert whose Web site, Weblog newsletters, books, and presentations have helped Web designers create convincing copy (see Figure 5-7).

Figure 5-7: Nick Usborne’s Web site provides excellent resources for individuals preparing content for the Web. Usborne suggests three steps to help improve the pace of your text: ⽧





note

Be sure the language fits the voice appropriate to your site. If the pace is too quick on a serious site, it can come across as insincere. Conversely, if you have a site that requires an active, spirited voice, pacing the voice too slowly can be detrimental. Fit the pace to the purpose. A privacy policy shouldn’t be written in a short, sharp, hip fashion just as a commerce-oriented site should avoid long descriptions on any pages where a buying decision could be made. You can always have additional information on a product located elsewhere on the site, or downloadable in PDF format. This way, site visitors can get complete specifications for a product, which is important, but they do it at their discretion instead of becoming impatient reading through information just to get to the purchase process. Vary the pace. No matter your audience or your goal, keeping a fast pace or slow pace throughout the language of an entire site is going to cause fatigue and boredom for many of your visitors. You can vary pace by following the simple technique shown in the preceding example.

You can visit Nick Usborne at www.nickusborne.com/.

⽧ 102

Part I: Tools, Planning, and Content

⽧ ⽧ ⽧

Secret #69:

⽧⽧⽧

Removing Extraneous Information

While it seems kind of obvious, removing information not critical to communication can come in handy when writing or editing text for the Web. This relates back to the idea of chunking information. Once you’ve got the chunks, you can look a little more closely at the text and see if there’s anything you can get rid of, or if you can rewrite the paragraph to be leaner and meaner. Consider the following “chunked” paragraph from the earlier example. The river flows year round now that the pumps are out of the ground, and we hope that the flow will continue to increase and benefit several miles of the river downstream as well. Any language that doesn’t relate to the heart of the discussion, is in a somewhat confusing order, or adds extraneous detail can be removed. Now that the pumps have been removed, the river flows year round. Hopefully, the flow will continue to increase as it benefits several miles of the river. I reduced the paragraph by seven words, improved its pace, and made its main idea more prominent. In the case of writing for the Web, less is almost always more.

⽧ ⽧ ⽧

Secret #70: Using Tables to Organize Data Along with chunking, it’s important to take advantage of the various means of formatting available with HTML. HTML tables offer some rich features for organizing data. Add Cascading Style Sheets (CSS) to the mix for style and you can come up with terrific tables for your information that also break up the monotony of too much text by adding color and space. Tables have a stormy history on the Web. They were introduced to HTML as a means for scientists and researchers to adequately manage tabular data. Prior to tables, the only way to accomplish columnar layouts was to use preformatted text and painstakingly figure out how many spaces belonged between each entry. Later, tables became the grid system upon which most Web sites through the 1990s and into the early part of this century were built. However, using tables for layout has many significant problems, so a move to CSS for layout has become the popular cry. Despite the unpopularity of tables, they are still wonderful and necessary to do exactly what they were developed to do: organize content. Some of the content you can successfully input into well-designed tables includes the following: ⽧ ⽧

Financial information. Many companies and organizations (especially banks) use tables to display financial data (refer to Figure 5-8). Calendar-based information. Tables are a natural choice to design a calendar layout for the Web (see Figure 5-9).

Chapter 5: Creating and Managing Fantastic Content

⽧⽧⽧

⽧ 103

Figure 5-8: Tables are an excellent way to format financial content.

Figure 5-9: Calendars are familiar constructs and useful in the display of date-related content. I’ve turned the borders on so you can see the table structure of the calendar itself. ⽧

Product tracking or feature comparisons. Many commerce companies use tables to reflect product status, availability, pricing, tracking, and comparison (as shown in Figure 5-10).

⽧ 104

Part I: Tools, Planning, and Content

⽧⽧⽧

Figure 5-10: Displaying product features is an excellent use of tables. With a strong database attached to any of these examples, the integration of content and technology becomes clear. A good introduction to using tables for data can be found at http://markl.f2o.org/tutorial/tables/Advanced-Tables .html.

note

⽧ ⽧ ⽧

Secret #71: Using Lists to Simplify Ideas From a content standpoint, lists are extremely useful—especially unordered lists, which achieve the following: ⽧ ⽧ ⽧ ⽧

Assist the content writer in his or her goals to improve pace Keep information chunked Ensure clear communication of ideas Break up the visual space for improved readability

Ordered lists are very helpful in certain cases, especially if you’regiving directions, as in the following example: 1. Take this book. 2. Close it. 3. Go have a coffee and/or take a walk.

Chapter 5: Creating and Managing Fantastic Content

⽧⽧⽧

You can see why we use lists so much in technical book writing.

⽧ 105

You’ll be working with lists a great deal in this book. Here are some cross-references for your list-learning pleasure.

cross ref

Learn about using lists for structure in Chapter 6, “Crafting Pages with HTML” and the correct process for nesting lists in XHTML in Chapter 7, “Moving Ahead with XHTML.” Lists are an extremely popular way of creating visually rich yet accessible and interoperable navigation. See Chapter 8, “Style Tips for Type and Design.”

⽧ ⽧ ⽧

Secret #72: Using Headers Meaningfully Headers have been used as a means of hierarchically organizing written ideas for centuries. However, the way headers are supposed to be used—both in writing and structurally within markup—is only recently coming into widespread understanding for those people working with markup. As any reader even somewhat familiar with HTML knows, header markup consists of an “h” followed by a numeric value, and there are six values, h1–h6. These headers have a conventional visual representation in Web browsers, with h1 being bold and large and h6 being bold but quite small; this visual representation is up to the browser manufacturer to implement. HTML specifications are not concerned with visual presentation per se. HTML and especially XHTML are concerned with structure and semantics. Instead of presentation, markup is concerned with the meaning of the elements. A header level 1, h1, isn’t about being bold and large. It’s about being the most significant heading on the page. Structurally speaking, think about the text in this chapter. There’s a chapter header—that would be a header level 1. Then, you have subheads, which would be header level 2, and so on. Because this book has style applied, there are specialty headers, such as the header style used for each secret. Using CSS, you can take the standard HTML h1–h6 level headers and style them with the same finesse. Follow these tips when using headers: ⽧



Reserve h1 headers for the most significant header on the page. It’s also recommended by many developers that you don’t use more than one h1 header. Some who argue the issue claim that it’s simply more semantically correct to only have one instance of an h1. There are also concerns that because many search engines look at h1s for cataloguing purposes, intentional misuse of h1s has become popular. Avoid “widowed” headers. With the exception of h1, you should have at least two subheads for each section. This is a classic concern in making information balanced and readable and has become conventional in print. While you can deviate from the norm, typically your content will be more understandable when broken up into sensible sections.

⽧ 106

⽧ ⽧

Part I: Tools, Planning, and Content

⽧⽧⽧

Avoid stacking headers. Always have text between headers. The purpose of headers is to separate text into discernable sections. Use clear language. Writers are always wondering why their editors are changing the titles the writer has so painstakingly crafted. I’ve come to learn that the reason is while I’m trying to be witty or clever with my titles, I’m not telling the reader what the content is about. Clear use of language within headers is, as with any other text, imperative. To learn how to structure headers using HTML, see Chapter 6, “Crafting Pages with HTML.”

cross ref

⽧ ⽧ ⽧

Secret #73: Applying Style Standards In Chapter 3 you read about the defining of style standards and creation of a style guide for a given site. You learned that style guides help with the site development process in a wide range of applications: code, visual design, and, of course, content. Many issues must be confronted when determining style guidelines for your text on the Web. Using a traditional style guide such as Strunk & White is helpful, but some issues seem to pop up on the Web a great deal more frequently than other print-related issues, such as the following: ⽧ ⽧





note

Case and titling. Traditional “title” case has been modified style-wise in print and on the Web. Pick a case convention and stick to it. Punctuation. Determine a punctuation style, particularly in terms of hyperlinks and list items. Typically, placing punctuation after hyperlinks is advisable. Using periods after list items is a debated topic, but again, choose what works in your best judgment, and then stick with it. Avoid additional spaces in hyperlinks. This will help keep links contained to the text that’s supposed to be linked, rather than additional space. Determine which special characters are to be used. Certain grammatical elements, such as quotes, symbols, hyphens, em dashes, and so forth require special characters. Also referred to as character entities, these characters sometimes have browser support problems. Figuring out what you’re going to use and not use ahead of time will help anyone working with copy be more efficient in applying the site’s style standards. The US Department of Housing and Urban Development (HUD), at www.hud.gov/library/bookshelf15/policies/standard.cfm, has published an interesting style guide that can both serve as a model and provide additional information on content-related standards. To read more about traditional grammar style, see The Elements of Style at www.bartleby.com/141/.

Chapter 5: Creating and Managing Fantastic Content

⽧⽧⽧

⽧ ⽧ ⽧

⽧ 107

Secret #74: Avoiding Problem Grammar While defining a style guide and sticking to it can cut down on grammar-related problems, some very common grammar problems are unavoidable. At some point, you’ve probably typed “ your” when you’ve meant “ you’re” or “affect” when you meant “effect.” Having a few good grammar books for your language on hand can be helpful. There are excellent resources online for style and grammar. Check those mentioned in this chapter and in Appendix C, “Helpful Reading, Web Sites, and Resources.”

For common grammar annoyances in English, see “Common Errors in English” at www.wsu.edu/∼brians/errors/index.html.

note

Another interesting topic is how to write without bias toward gender, race, or physical ability. The American Psychological Association (APA) has published some excellent style guidelines in this area. I highly recommend reading these guidelines and making them available to anyone with whom you will be developing site content. ⽧ ⽧ ⽧

Removing Bias in Language: Disabilities, www.apastyle.org/disabilities.html. Removing Bias in Language: Sexuality, www.apastyle.org/sexuality.html. Removing Bias in Language: Race and Ethnicity, www.apastyle.org/race.html.

⽧ ⽧ ⽧

Secret #75: Understand Copyright! There are three main branches in traditional IP law: copyright, trademark, and patent. Web designers and developers would do well to have a practical understanding of these issues, and copyright is the most important with which to begin.

note

The spirit of U.S. Copyright—and all IP law for that matter—exists for an intriguing reason. It is meant to place balance between the artist and the public value of a work. The founding fathers suggested that neither the creator nor the public should gain all the benefits of any piece of IP. So, while you as an artist can and should reap all the rewards due to you for your contributions, the original copyright laws were designed to protect you for only 14 years, with the option to renew for an additional 14. After that time, your work is entered into the public domain, allowing the public to build upon and innovate on it. Times have changed, of course, and at the time of this writing, a copyright can last up to 70 years after the death of the creator.

⽧ 108

Part I: Tools, Planning, and Content

⽧⽧⽧

Copyright in the United States covers any original work of an author. Examples include the following: ⽧ ⽧ ⽧

Literature, including fiction, nonfiction, stage plays, screenplays, poetry, Weblog entries, and original copy for Web sites Music, including compositions, song lyrics, and recordings Art and craft works such as pottery, painting, and sculpture

Works are considered copyrighted the moment they are created—you do not have to register a copyright to own the rights and display the copyright symbol. Of course, registering the copyright provides you with more formal and explicit protection, so it’s a good idea. You need to do a few things as a Web professional when it comes to copyright: ⽧

⽧ ⽧

Determine the copyright holder. Is the content already copyrighted by the client? Typically, clients do retain the rights to their work and it is questionable ethics to try and own their property. If your client hasn’t copyrighted their Web site content, encourage them and assist them in doing so. If you created the work for yourself, be sure to register the copyright to protect the work. Display the copyright symbol appropriately. Most Web sites carry the copyright at the very bottom, often linked to more detailed information about the content rights for the site. The U.S. Copyright office has great resources, including links to registration forms for formal copyright registration, at www.copyright.gov/.

note

Copyright information for the United Kingdom is available through The UK Patent Office, at www.patent.gov.uk/copy/. The Canadian IP Office can be found at http://strategis.ic.gc.ca/ sc-mrksv/cipo/welcome/welcom-e.html. What about using others’ materials? If a work is copyrighted, using any significant amount of the work is illegal without permission. You should always try to obtain permission for the reuse of copyrighted materials. Most readers will have heard the term “fair use”. This is a narrow window into the use of copyrighted materials. Fair use examples include the following: ⽧ ⽧ ⽧ ⽧

Quotations (length is limited, and the quote must be fully attributed) Parodies Photocopies for nonprofit and educational use only Home copying of television programs

Getting permission to use other people’s materials is still the best safety net. If you have detailed questions, please see an attorney who specializes in IP.

⽧ ⽧ ⽧

Secret #76: Extending Copyright with Creative Commons Creative Commons is a group of attorneys and interested parties who are interested in re-examining the original vision of IP that the founding fathers had with the hope of offering extensions to allow easier sharing of property without violation (refer to Figure 5-11).

Chapter 5: Creating and Managing Fantastic Content

⽧⽧⽧

⽧ 109

Figure 5-11: The Creative Commons Web site is a great place to learn more about IP in the digital age. Their efforts have thus far resulted in the creation of three licensing options under the Creative Commons that extend copyright. The licenses clarify to anyone interested in your materials how you’d like your content treated. The three licenses allow you to extend a copyright to someone else with the following extensions: ⽧ ⽧ ⽧

Available for all use, including commercial use Available for noncommercial use, provided that attribution is made Not available for use

Licenses from Creative Commons are growing in popularity largely because of Weblogs and the desire of Weblog authors to aggregate their content effectively. An extension of copyright to others via Creative Commons makes it very clear how a work can be disseminated—or not—as the author sees fit.

note

The Creative Commons Web site, at www.creativecommons.org/, is a very informative site for those interested in pursuing more knowledge about IP and the Web.

⽧ ⽧ ⽧

Secret #77: Protecting Intellectual Property with Trademarks Trademarks are any word, name, symbol, or device used in the trade of goods. To that end, Web designers and developers need to pursue trademarks of their logos and company names, and encourage their clients to do so as well.

⽧ 110

Part I: Tools, Planning, and Content

⽧⽧⽧

Trademarks protect only the symbol or the name, not the services that you are offering. So while you can protect your company logo, you can’t prevent other people from providing the same kind of service you’re providing.

Getting something trademarked can be a long process—it took me nearly three years to trademark the name “Molly” (names are notoriously difficult to trademark as well)—but if you want to protect symbols relevant to your trade, it’s worth the process. This is especially true when it comes to hanging on to domain names— something that directly affects the Web designer.

note

For more information on trademarks, see the U.S. Patent and Trademark office Web site, www.uspto.gov/index.html.

⽧ ⽧ ⽧

Secret #78: The Role of Patents on the Web Along with copyrights and trademarks, patents make up the third area of U.S. IP law. Patents exist to cover inventions, and to protect inventors in the same way that copyright protects the creator of a work of art. Unless your company or a client invents a new technology, Web designers usually do not run into the need to obtain or advise someone to pursue a patent. However, patents do affect Web designers in peripheral ways via hardware and software inventions. Patent policies are also a concern of anyone wishing to ensure that Web technologies remain open standards. Patents can directly affect the tools and technologies of the Web, as evidenced, for example, in the recent Eolas versus Microsoft lawsuit. Eolas successfully sued Microsoft regarding technology related to the plug-in engine used by the Internet Explorer (IE) Web browser. Eolas claimed it owned the patent on the technology. The case continues unfolding at this time, with appeals in the works. The impact of this sort of dispute can radically affect the way Web designers work—they would have to redo any pages using embedded objects, such as Flash, Java Applets, movies, and audio—and also the way future policy will be created.

note

The World Wide Web Consortium (W3C) has a working group dedicated to patent policy and the Web. You’ll find the Patent Policy Working Group home page at www.w3.org/2001/ppwg/. To learn more about the Eolas patent suit and how it has affected Web designers, see “What does Eolas v. Microsoft mean to you?” at http://builder.com.com/5100-6373-5083455.html.

⽧ ⽧ ⽧

Secret #79: What Is Digital Rights Management? Another area where IP is affecting the work of anyone creating content for the Web is Digital Rights Management (DRM). DRM is the attempt to provide social, legal, and technical solutions for protecting IP in the digital age.

Chapter 5: Creating and Managing Fantastic Content

⽧⽧⽧

⽧ 111

Many major software companies are adopting DRM in some fashion. Office 2003, for example, has all kinds of digital signatures and security-related features to allow authors to protect their documents.

But DRM is extremely controversial, largely due to the fact that many people feel restricting rights goes directly against the greater spirit of innovation and the sharing of the resources of common goods. DRM gained momentum via the Digital Millennium Copyright Act (DMCA). This act, which was signed into law by President Clinton, is considered to be the most significant reform in U.S. IP history. DMCA outlines, in great detail, how digital rights should be managed. DMCA is as controversial as DRM, because many advocates for a free and open exchange of ideas see the DMCA as favoring big business, restricting innovation, and ultimately limiting the ability of technologists to move technology forward without constantly having to face lawsuits or limitations due to rights restrictions. You can read the actual DMCA at http://thomas.loc.gov/ cgi-bin/query/z?c105:H.R.2281.ENR:.

note

Follow the anti-DMCA controversy at http://anti-dmca.org/. Learn about Digital Rights Management and its related controversy at www.epic.org/privacy/drm/.

⽧ ⽧ ⽧

Secret #80:

Exploring Content Management Systems

Content management systems (CMS) are a hot topic these days as a means to wrangle all the content created for a site and manage it more efficiently. CMS also attempts to eliminate the need for content-related workers to have to be markup specialists. The goal is to allow anyone to create new files and copy and paste data from other applications into Web-based documents for publication on public or internal sites. Sounds pretty reasonable, right? Well, one of the more sobering issues related to CMS is cost. When the early systems emerged, such as Vignette Storyserver, the price tag caused many a weak heart to wane. Investments for CMS ran into the multi-million-dollar range, and the frustration level of getting the CMS to work properly was extremely high, causing grave concern about the high maintenance cost of managing content. Fortunately, the concerns of cost and functionality helped focus attention on the improvement of the CMS situation. It is still very far from the day where CMS solutions are easily chosen, but more information exists to help designers and developers recommend, install, and design sites using CMS. A variety of CMS types include the following: ⽧

Commercially packaged CMS software. These are systems that you purchased and installed for your company or client. They are typically very costly and often difficult to install, configure, and maintain. However, they can also be excellent for certain situations, especially when there are many people working on content, the site is very large, and the site is continuing to grow.

⽧ 112







Part I: Tools, Planning, and Content

⽧⽧⽧

Open-source based CMS software. The open-source community has a number of CMS solutions that are very good and far less costly than proprietary packages. However, as with almost all open-source software requiring server-side attention, the installation and implementation is best left to those experienced with open-source languages and methods. CMS application service provider. In this case, instead of installing the CMS on your server, a provider offers the technology for you. Your job is to configure templates and permissions, allowing various individuals access to those content areas they will be managing. CMS provision of this nature can be a reasonable choice for many situations because of the low overhead, lower cost, and usually excellent support that goes with the service. Custom CMS development. A good programmer can create a CMS from scratch or customize one from any number of open-source options for less money. The disadvantage of rolling your own CMS is that it takes a lot of time, and you will need to take into account that ongoing support will likely be required.

Along with major CMS applications and services are smaller content-related tools that have emerged for the purposes of Weblogging. In the case of smaller sites, some of these tools—such as Movable Type—are excellent choices for content management. Tools of this nature are highly customizable (they are often opensource) and tend to be very affordable. Before jumping into a CMS, make sure you have a detailed process to evaluate the short- and long-term content requirements of a given project, submit a reasonable budget, and study the available options and how they might best serve you or your client needs.

note

To learn about open-source CMS, see www.cmsinfo.org. The site keeps details about a wide range of open-source CMS projects. For a complete guide to CMS news, analyses, reports, and other helpful information to assist you in making choices regarding content management, see CMS Watch at www.cmswatch.com/.

Summary You should now have a very good idea of what challenges working with content on the Web can bring. Be confident that with good resources and a sensible approach to the creation and management of content, you won’t have much trouble improving and streamlining the content aspect of your work. At this point in the book, you’vecome through the organization and strategy aspects of site development and design. Now it’s on to markup and style! The upcoming part contains chapters covering HTML, XHTML, CSS, and accessibility.

Part II

HTML, XHTML, CSS, and Accessibility Chapter 6: Crafting Pages with HTML Chapter 7: Moving Ahead with XHTML Chapter 8: Style Tips for Type and Design Chapter 9: Laying Out Pages with CSS Chapter 10: Adding Accessibility Features

Crafting Pages with HTML

Chapter

6

⽧⽧⽧⽧⽧⽧⽧⽧⽧⽧⽧⽧⽧⽧⽧⽧⽧⽧⽧⽧⽧⽧⽧⽧⽧⽧⽧

Secrets in This Chapter #81: #82: #83: #84: #85: #86: #87: #88: #89: #90: #91: #92: #93: #94: #95: #96: #97: #98: #99: #100: #101: #102:

Create a Markup Style and Stick to It . . . . . . . . . . Understand Document Types and Language Versions Use DOCTYPEs . . . . . . . . . . . . . . . . . . . . . . HTML is Root . . . . . . . . . . . . . . . . . . . . . . . Use and Appropriately . . . . . . . Always Use . . . . . . . . . . . . . . . . . . . . Manage Character Sets . . . . . . . . . . . . . . . . . Author Documents Structurally . . . . . . . . . . . . . Use Lists to Enhance Structure and Readability . . . . and versus and . . . . . . Know your Document Tree . . . . . . . . . . . . . . . . Elements, Tags, and Attributes . . . . . . . . . . . . . Intrinsic Events . . . . . . . . . . . . . . . . . . . . . . Special Characters . . . . . . . . . . . . . . . . . . . . Limit Color Names to Standard Colors . . . . . . . . . Avoid the font Element . . . . . . . . . . . . . . . . . . Avoid the center Element . . . . . . . . . . . . . . . . . Avoid All Deprecated, Obsolete, and Proprietary Elements and Attributes . . . . . . . . . . . . . . . . . Use Elements as They Were Intended . . . . . . . . . Restrict Use of Tables . . . . . . . . . . . . . . . . . . . Restrict Use of Frames . . . . . . . . . . . . . . . . . . Validate, Validate, Validate! . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

118 119 122 123 124 125 125 127 128 130 131 133 134 135 136 136 138

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

138 139 140 141 141

⽧⽧⽧⽧⽧⽧⽧⽧⽧⽧⽧⽧⽧⽧⽧⽧⽧⽧⽧⽧⽧⽧⽧⽧⽧⽧⽧

⽧ 116

Part II: HTML, XHTML, CSS, and Accessibility

⽧⽧⽧

J

ust the other day I was reading someone’s Weblog and he was thanking a pal for helping him unravel the “tangle” of the Hypertext Markup Language (HTML) tags that he’d gotten wrapped up in. He’d been using a visual editor to build his site. Not being very familiar with markup, he had the good sense to get someone to help him who was, or he wouldn’t have reached his goal of having a working Weblog for himself. What interested me about this fellow’s comment was how he viewed HTML—a tangle. HTML is a primary slice in the Web site creation pie.

Is HTML Easy? The fact is that HTML is pretty easy to play around with and get some results from without having much experience with it. That’s not so much due to HTML itself. Rather, Web browsers are incredibly forgiving when it comes to errors in HTML. If they weren’t, the Web would never have become so thriving and multifaceted. As a result, people tend to think HTML is easy and don’t dig deeper into its features, nuances, rules, and limitations.

HTML is a Markup Language HTML is not programming per se; some will argue it isn’t even code. What HTML is at core is a system of tags that are interpreted by a user agent such as a Web browser, a browser in a hand-held device such as a PDA, or an assistive device. A user agent’s job is to interpret and then render the language of the document being requested.

note

User agents can be as complex as the most contemporary Web browser created for today’s commercial computers, or as simple as required by wireless, Web-enabled devices such as mobile phones and pagers.

As with any language, HTML has grammar. There are rules of structure and semantics. HTML has a distinct vocabulary, and complicated specifications define the many aspects of HTML as a formal language. But browser competition has often led to the emergence of elements and features related to a given browser. Some of these elements have in fact been introduced into the specifications (which are the documents that define “Web Standards”) and have been integrated into the language, but some have not been adopted. All working Web professionals should have some awareness of HTML as it is specified rather than as most of us learned it—by viewing source, asking a colleague, and employing hacks and workarounds to get the various desired results.

Face the Changes The by-our-bootstraps days of learning markup are gone. Awareness among the professional community has grown strong, in no small part due to the work of The Web Standards Project (WaSP), a grass-roots organization dedicated to promoting Web standards and resources for Web professionals. Figure 6-1 shows the WaSP site.

note

For news, resources, and reference materials about Web standards, visit the WaSP Web site at www.webstandards.org/.

⽧⽧⽧

Chapter 6: Crafting Pages with HTML

⽧ 117

Figure 6-1: WaSP is a grass-roots volunteer organization advocating the use of Web standards. In addition, we now have very good CSS support in all modern browsers. This means we can clean up the hacks we used to lay out pages visually, remove extraneous tags from our HTML, and write cleaner, clearer, more structured and less confusing documents, making HTML a lot easier to use—even for complex needs. What’s more, many product vendors, especially Macromedia, are becoming more interested in making sure their products allow users to create and maintain valid pages, which helps us all in the long run. So, if you’re still building your sites with nested tables, graphic shims, and sliced graphics, the time has definitely come to begin exploring the more sophisticated options available to you. Even if you are unable to drop those conventional practices for contemporary, specification-driven ones, you can become more aware of the language requirements of an HTML document, how to keep it as structured as possible to assist with accessibility and portability across browsers and platforms, and how to write a conforming document even if you’re using practices that are being shelved in favor of more effective options.

Document Conformance Document conformance in Web markup means that each page of HTML (or XHTML) you author conforms to the official W3C specification to which it is written.

Author to the Specification This means each of your HTML pages will have markup within them that is part of this conformance. In the case of HTML, the language type you use is found within a DOCTYPE, a declaration at the top of the HTML document that declares what kind of document it is and which version of HTML the DOCTYPE in question

⽧ 118

Part II: HTML, XHTML, CSS, and Accessibility

⽧⽧⽧

is referring to. You’ll learn about language versions shortly, but keep in mind that along with a DOCTYPE, you must make sure that all the tags and attributes you use are allowed within the language version that you are declaring.

Validate the Document Conformance is checked by the process of validation, which is covered later in this chapter. Validation is the comparison of your document with the language you declared in your DOCTYPE, just to see if you’ve made any errors. Validators return a list of errors, which you can then correct. Once you validate the document without any errors whatsoever, it is considered a conforming document, which is also referred to as a compliant document. Conforming documents are easier to work with, particularly when more than one document author is involved, and the process of validation is an excellent means of not only eliminating errors, but also of learning more about the languages with which you are working as a result.

⽧ ⽧ ⽧

Secret #81: Create a Markup Style and Stick to It One of the biggest headaches in managing the code side of Web design is the variations that exist in how markup is formatted. I don’t mean how it will look on display, but how the code itself is formatted behind the scenes. Readers authoring their documents by hand have often developed their own formatting practices (see Figure 6-2 for an example), such as indenting tables and lists, by placing elements in uppercase and attributes in lowercase, and not quoting attributes. Add to this

Figure 6-2: A look at my personal formatting habits within my favorite editor, Homesite.

⽧⽧⽧

Chapter 6: Crafting Pages with HTML

⽧ 119

the discrepancies in Web publishing software (refer to Figure 6-3), and what you have is a big mess.

Figure 6-3: Here’s an example of formatting in Dreamweaver MX 2004. Imagine working in a group environment where files are modified and updated by numerous content and document authors. If there is no consistency in the style of markup, chaos not only can, but most likely will, ensue. Even if you’re working on your own, disparities in how you format your HTML within the page can affect you. For example, perhaps you’dlike to perform a search and replace on a large number of documents, but the formatting is vastly different from one document to the other. Most software won’t recognize something that is formatted dramatically differently than the piece of markup you might be searching for, making the time required to fix or update those 100 pages far greater. So whether you’re working on a team or by yourself, making some decisions about how to properly format your markup can help save hours of frustration for all. Table 6-1 offers some ideas for better success with formatting HTML.

⽧ ⽧ ⽧

Secret #82:

Understand Document Types and Language Versions

Not all markup was created equally. When Tim Berners-Lee and his colleagues were cooking up the Web in their particle physics lab at The European Organization for Nuclear Research (CERN) in Switzerland, the need for a very simple markup language for formatting text on-screen with the ability to have hyperlinks became obvious.

⽧ 120

Part II: HTML, XHTML, CSS, and Accessibility

⽧⽧⽧

Table 6-1: HTML Formatting Strategies Action

Benefit

Example

Indenting Table Cells

For streamlined tables, some indentation is helpful when working with nested portions of the table. This provides white space and allows the person working on the markup to quickly find specific data or problems within the code itself



As with nested table cells, indenting nested lists can be very helpful in troubleshooting and more effectively finding content that requires repair



    Indenting List Items and Nested Lists

content here




  • Managing Case

    HTML is not case sensitive. Prior to XHTML (See Chapter 7, “Moving Ahead with XHTML”), case in HTML was irrelevant, so you’d often get a total mishmash of case styles—even within the same document. XHTML is case sensitive, and I recommend all authors use lowercase at this time, even if they’re working in HTML. If an upgrade to XHTML is ever in the future of those documents, the process will be far easier and less time-consuming as a result

    In HTML you can have a variety of cases:



    All of these mean the same thing. When you advance to XHTML it changes. As a result, contemporary authoring is best kept to lowercase:

    For more information on case in XHTML, see Chapter 7

    Managing Quotes

    The concerns regarding quotes around attribute values in HTML are similar to those for case. HTML is far less strict than XHTML in terms of quoting rules. While you can never go wrong in HTML quoting an attribute value, you can go wrong not quoting it. So, quote all attributes, even in HTML where the rules about quotes are fairly arbitrary

    In HTML, you could correctly write the following:

    It will likely work in the vast majority of browsers. However, think about the error margin that emerges here. You could add a start quote but forget the ending quote. A mistake of that nature can leave you in troubleshooting hell for hours. By quoting all attribute values, you reduce or even eliminate this kind of problem

    ⽧⽧⽧

    Chapter 6: Crafting Pages with HTML

    ⽧ 121

    Action

    Benefit

    Example

    Using Comments

    Comments are a gift from the programming forefathers and we should take care to use them effectively. Properly commenting particular areas within a document means you, or your colleagues, can find that area more quickly. You can also provide information about the content, directions to other authors or content specialists, and hide information from a browser that might be needed sometime in the future

    Add comments to the beginning of a section:

    As directions:

    To hide information for later use: Holiday Specials! --> One important note here is to use comments but to do so where most needed. Over-commenting a site can be just as troublesome as having no comments available at all

    HTML in its infancy included very simple markup—at the time Berners-Lee was adding the spices to his stew, the Web did not serve up a graphical user interface (GUI). Therefore, the primary markings needed were related to simple structural elements such as headings, paragraphs, line breaks, lists, and horizontal rules. Of course, the Web shot out of the hands of CERN researchers faster than you could say “it’s soup!” and suddenly the Web was everywhere. GUI interfaces began to emerge (Mosaic being the first in widespread use), and with a graphical means of displaying pages, new features were desired. Over the next few years, chaos ensued, and HTML became so mixed up that sites using no formal HTML are referred to as being written in “tag soup.” This became extremely problematic, as there was no consistency in workflow, browser support, and developer tools support. The W3C creates specifications for three primary audiences: browser developers, Web developers, and software developers creating programs for Web design and development.

    note

    To address the changing needs, the W3C broke HTML 4.0 up into three distinct types. Each of these varieties is governed by a separate Document Type Definition (DTD). A DTD is the list of elements, attributes, characters, colors, and related requirements for a given language, or in this case, language variety. The three DTDs for HTML 4 are as follows: ⽧

    Strict. Strict versions of HTML call for a separation of structure and presentation. Few presentational attributes or elements are available in this version, such as font tags, alignment attributes, and so on. The idea is that strict versions are to be used with CSS. Strict DTDs do not allow for anything that is considered obsolete (no longer in use) or deprecated (still in use but moved aside to make way for a better method) in the language to be used.

    ⽧ 122





    note

    Part II: HTML, XHTML, CSS, and Accessibility

    ⽧⽧⽧

    Transitional. A lot more leniency exists with presentational attributes. You can freely use font elements in a transitional document, although it’s not recommended nor is it considered necessary because of the widespread support of most font-related features in CSS. Transitional DTDs allow deprecated elements and attributes with the understanding that people using these techniques are transitional—not quite ready to commit to a strict DTD. Frameset. The frameset DTD defines the allowed elements and attributes within the frameset document. This document controls frame-based sites. Documents within a framed site should be written according to either strict or transitional DTDs. HTML 4.01 is a minor editorial update to HTML 4.0. Most people who work with HTML now use HTML 4.01 as their language, with the DTD varying depending on their site needs.

    ⽧ ⽧ ⽧

    Secret #83:

    Use DOCTYPEs

    DTDs are declared in the document using a DOCTYPE declaration, which, as mentioned earlier, describes the language, version, and language type. Using a DOCTYPE is required to have a document that conforms. DOCTYPEs are placed at the very top of a document, above the opening tag.

    Consider the following snippet, which is a DOCTYPE declaration for HTML 4.01 Strict:

    For those familiar with HTML, you’ll recognize some of what’s here, but some of the syntax is different. That’s because DOCTYPEs aren’t HTML; they are SGML constructs. To translate this DOCTYPE declaration, one could say this: The document type in question is an HTML document. It is PUBLIC, which means that the DTD it refers to is publicly available for use. It was authored and is housed at the W3C, and it refers to the HTML 4.01 Transitional DTD, in English, and is located at the URL typically found indented on the second line of the declaration. (This placement is convention—you can place all the information on a single line or break it up differently, as long as those items that require a space between them get the space, and those items that have no spaces are kept intact.) Table 6-2 shows the appropriate DOCTYPEs for HTML 4.01. DOCTYPEs used to be passive code until validation, when the validator used the code to determine which DTD to compare your document to. In today’s browsers, however, a new technology called “DOCTYPE switching” exists, making the use of proper DOCTYPEs not only required, but critical to the stability of your designs. Either way, the professional designer or developer uses correct DOCTYPEs.

    Chapter 6: Crafting Pages with HTML

    ⽧⽧⽧

    Table 6-2: DOCTYPEs in HTML 4.01

    ⽧ 123

    DTD

    DOCTYPE

    Strict

    Transitional

    Frameset

    cross ref

    For more information about DOCTYPE switching, see Chapter 7.

    ⽧ ⽧ ⽧

    Secret #84:

    HTML is Root

    Now that you have an idea of what DOCTYPEs and DTDs are, you can begin authoring your documents. Oddly enough, in early versions of HTML the tags were not required. In fact, if you create a document and leave the tags out of it, it will surely display, even though it won’t be a conforming document. However, the tagset does form an important piece of the structure of a document—one that you will later want to have available for use with style and scripting, and for global application of the lang attribute, discussed later this chapter. It’salso important to move forward with XHTML, as you’llsee in Chapter 7. The html element is what’s referred to as the “root” of the document. It is from this root that the document tree grows. Document trees are a means of showing the schematic relationships of elements within the document. Being able to identify trees within documents will help you immeasurably as you work with style and scripts. Check out Listing 6-1. In it, I’ve begun to build a document using HTML 4.01 Transitional. While incomplete, it includes the proper DOCTYPE declaration and the root element with its opening and closing tags. Listing 6-1: Building a document tree with a DOCTYPE and html as root



    tip

    Think of elements that have an open and closing tag (also referred to as a “tagset”) as containers. As you add a tag, always add its companion at the same time. This helps to avoid missing a necessary closing tag.

    ⽧ 124

    Part II: HTML, XHTML, CSS, and Accessibility

    ⽧ ⽧ ⽧

    Secret #85:

    ⽧⽧⽧

    Use and Appropriately

    Once your root elements are in place, you can add the head and body portions of your document. Addressing the idea of not using these very basic HTML elements might seem silly, but I have seen countless pages where these critical tags either don’t exist, are improperly nested, or appear more than once—or have the wrong type of information within them.

    The head portion of a document comes after the root and before the body elements. The head of a document is like the head of a human—it contains all the stuff that’s used to keep things working, such as the following: ⽧ ⽧ ⽧ ⽧





    cross ref

    Title. This is the title that will appear in the browser’s title bar. Metadata. All forms of meta information, including description, keywords, and character set definitions. Scripts. Document-related scripts can appear in the head within or linked to the document via the script element. CSS. Embedded CSS can appear in the head between the style element, external CSS can be imported using the style element, and external CSS can be linked using the link element. Aggregation. XML-based aggregation such as Rich Site Summary (RSS), Resource Description Framework (RDF), and related formats can be linked from the head using the link element. Favicons. You know them as the little icons that appear in the address bar of certain browsers. You can add them using the link element with the head portion of a document.

    You can find more information about aggregation technologies in Chapter 13, “Keeping Content Fresh and Engaging.”

    HTML markup that is not allowed in the head portion of a document is any html element or attribute not related to metadata, scripting, style, and other information about rather than on the page. The only exception to these items is that special characters can be used in the text content of titles: Sugar & Spice

    Directly below the head and its contents is the body. Almost every element and attribute used within the body relates either to the structuring of content, or to its formatting (although again, CSS is encouraged for all presentation). Sometimes, scripting is included. Listing 6-2 adds the head and body elements to our growing document. Listing 6-2: Adding the head and body elements



    ⽧⽧⽧

    Chapter 6: Crafting Pages with HTML



    ⽧ 125



    ⽧ ⽧ ⽧

    Secret #86:

    Always Use

    While style, scripting, aggregation, and metadata are all optional elements within the head element based on what’s required by a specific site, a title with a good description is never optional. You must always have a title element for your page, or the page will not validate. Keep titles clear, and use them to orient your site visitors.

    cross ref

    Read more about writing titles in Chapter 5, “Creating and Managing Fantastic Content.”

    Listing 6-3 shows the growing document including a title. Listing 6-3: Adding the title element

    Creating a Conforming HTML Document



    ⽧ ⽧ ⽧

    Secret #87: Manage Character Sets Languages use characters, and different languages have different characters. Character sets in HTML define the character set used in the document and inform the user agent which character set is in use. Character sets can be defined in one of three places: ⽧

    An XML declaration. This declaration can be used in XML documents, including XHTML. See Chapter 7 for specifics about the XML declaration. If you are using an XML declaration (and there are certain reasons you probably should not), it is an acceptable place to add character set information.

    ⽧ 126





    Part II: HTML, XHTML, CSS, and Accessibility

    ⽧⽧⽧

    A meta element. This is a common way to include character set information in a document. I think it’s a good idea to use it, even if you are using other forms. It’s simply a preference—it’s easier to validate a document locally if the character set is defined within a meta element. On the server. Server administrators can define the character set in the server’s HTTP headers. This is actually the most recommended method, but it’s out of the hands of most Web designers and developers, who can easily implement character sets using the meta element.

    Many character sets are available for use. For documents in most Latin-based languages including English, Spanish, French, Italian and so on, the Latin set is often used. The following HTML snippet shows the charset attribute with a value for the Latin set:

    UTF-8, a more universal character set, is also growing in use:

    note

    Values for other languages include shift js for Japanese, EUC-JP, which is another Japanese encoding, and ISO-8859-5, which supports Cyrillic. For a complete discussion and linked references regarding character sets in Web documents, see “HTML Document Representation” for HTML at the W3C, www.w3.org/TR/REC-html40/charset.html.

    Listing 6-4 shows the document with the meta element for a Latin character set (suitable for English) in place. While it’s not necessary to have this for a valid document (due to the fact that character sets can also be denoted elsewhere), it is necessary to validate the document via upload using the W3C’svalidator, discussed later this chapter. Listing 6-4: Adding the meta element

    Creating a Conforming HTML Document



    Save this listing to your local computer for use as a basic template for almost all HTML authoring needs.

    ⽧⽧⽧

    ⽧ ⽧ ⽧

    Secret #88:

    Chapter 6: Crafting Pages with HTML

    ⽧ 127

    Author Documents Structurally

    With everything in place, DOCTYPE and structural components of the document such as head and body intact, you’re ready to add content to your document.

    In Chapter 5 you read about the fact that Web authors and authoring tools don’t always use headers properly—instead of a hierarchical implementation, they are used because of how they display. This, while not a conformance problem, is a problem that will cause you countless hours of frustration later on as you attempt to style your document effectively. So, keeping documents very cleanly structured is important. This means using headers, paragraphs, even horizontal rules with sensitivity toward the semantic meaning of the tag. Listing 6-5 shows an example of structural markup with content.

    Listing 6-5: Adding structural markup

    Creating a Conforming HTML Document

    Welcome to Meyer Shoes

    Welcome to the Meyer Shoes web site. Here, you'll find a complete catalog of our styles for men, women, and children as well as information about our company and fast, responsive customer service.

    Meyer Style

    If you hunger for style, crave quality, and desire comfort, look no further! Meyer Shoes is a specialty shoe company that uses only the highest quality leathers and fabrics to handcraft each of its unique styles.

    Custom Style

    Whether you are looking for men's, women's or chidren's styles, we're sure we can help you find a shoe that meets all your wishes. And if we somehow don't offer a style that yells "Me!" we'll custom design a pair that is distinctly yours.



    Copyright 2004 Meyer Shoes, Inc.



    ⽧ 128

    Part II: HTML, XHTML, CSS, and Accessibility

    ⽧⽧⽧

    This simple document shows appropriately structured headers, paragraphs and rules within the body element.

    note

    You might have noticed that I’m closing all my paragraphs using the closing paragraph tag

    . In HTML, you are not required to close certain elements that contain content, such as paragraphs and list items—you can input either a single

    or

  • at the beginning of your paragraph or list item and follow it with its content without adding a closing tag. However, requirements change when you use XHTML, and I also believe closing all elements with content makes styling that content more precise and managing that content more efficient, and ensures that anyone working with you can easily understand and maintain the documents. As a result, I opt to close such elements in all cases.

    ⽧ ⽧ ⽧

    Secret #89:

    Use Lists to Enhance Structure and Readability

    A structured document is one that is portable across user agents and platforms and far easier to style and manage for the long term. Lists, as I mentioned from a content perspective in Chapter 5, are a very good way to enhance readability on a page, and they are an equally good way to structure information. In the past few years, it’s become extremely popular to use lists for navigation. As the awareness of structure becomes more widespread, and the use of CSS becomes

    Figure 6-4: The unstyled but very structured results.

    ⽧⽧⽧

    Chapter 6: Crafting Pages with HTML

    ⽧ 129

    more readily available for most Web designers, lists—especially of the unordered variety—have begun to form the markup side of very impressive navigation design that doesn’t rely on any scripting for visual enhancements.

    note

    You’ll learn to create navigation—both vertical and horizontal designs—all using lists in Chapter 8, “Style Tips for Type and Design.”

    It makes a great deal of sense to use lists for navigation. Even if you style the list to appear on a Web page horizontally, it’s still a list of like items—all links to other locations on the site. The logic pans out, too. If we add a list of navigation links to our current document, while it won’t look very pretty for now (Figure 6-4), it surely makes logical sense. Listing 6-5: Adding a list

    Creating a Conforming HTML Document

    Welcome to Meyer Shoes

    Welcome to the Meyer Shoes Web site. Here, you'll find a complete catalog of our styles for men, women, and children as well as information about our company and fast, responsive customer service.

    Meyer Style

    If you hunger for style, crave quality, and desire comfort, look no further! Meyer Shoes is a specialty shoe company that uses only the highest quality leathers and fabrics to handcraft each of its unique styles.

    Custom Style

    Whether you are looking for men's, women's or chidren's styles, we're sure we can help you find a shoe that meets all your wishes. And if we somehow don't offer a style that yells "Me!" we'll custom design a pair that is distinctly yours.

    • Styles for Kids
    • href="about.html">About Us href="contact.html">Contact Us (continued)

      ⽧ 130

      Part II: HTML, XHTML, CSS, and Accessibility

      ⽧⽧⽧

      Listing 6-5: (continued)

      Copyright 2004 Meyer Shoes, Inc.



      note

      If you think this looks like a document you might have written in 1994, good. The point is to get back to the simplicity of markup and content. We have CSS to perform all the presentation now. If you open this document up in browser it’s going to look boring as heck, but that’s because it’s an unstyled document. What’s more, you can look at it in any kind of browser conceivable, even Mosaic 1.0, and the document contents will display. And while it’s still without style, it’s formatted in a logical way, since it’s structured logically.

      ⽧ ⽧ ⽧

      Secret #90:

      and versus and

      Many people wonder what the difference is between these text formatting options: em, strong, i, and b. The em and strong are structural, semantic elements, whereas i and b are considered presentational.

      The fact that any content marked with an em element will display as italic and strong as bold is convention. It is not required that these elements appear specifically as italics and bold. If a blind person reading a Web page using screen reader technology comes across text markup with emphasis, the reader voice modulates to emphasize the words in question. Similarly, the strong element will be read in a more full voice. The i and b elements are meant for presentation: italics and bold. There is a difference between structure and presentation, and it matters big-time in today’s contemporary design practices. I recommend using em and strong in all cases where you might have thought to use i and b.

      note

      Another element to add to your avoid list is the u element, used to make an underline. Critics of this element say that underlining text confuses users because underlines typically signify links on the Web.

      In Listing 6-6, I’veadded instances of emphasis and strong to our current document to show how they might be used. Listing 6-6: Adding emphasis and strong

      ⽧⽧⽧

      Chapter 6: Crafting Pages with HTML

      Creating a Conforming HTML Document

      ⽧ 131

      Welcome to Meyer Shoes

      Welcome to the Meyer Shoes Web site. Here, you'll find a complete catalog of our styles for men, women, and children as well as information about our company and fast, responsive customer service.

      Meyer Style

      If you hunger for style, crave quality, and desire comfort, look no further! Meyer Shoes is a specialty shoe company that uses only the highest quality leathers and fabrics to handcraft each of its unique styles.

      Custom Style

      Whether you are looking for men's, women's or chidren's styles, we're sure we can help you find a shoe that meets all your wishes. And if we somehow don't offer a style that yells "Me!" we'll custom design a pair that is distinctly yours.

      • Styles for Kids
      • href="about.html">About Us href="contact.html">Contact Us

        Copyright 2004 Meyer Shoes, Inc.



        Figure 6-5 shows the modified markup as rendered in Mozilla Firebird.

        ⽧ ⽧ ⽧

        Secret #91: Know your Document Tree Now that we have an entire document, we can map out the tree.

        In the document we just created, we began with the DOCTYPE declaration, which isn’t considered part of the tree. Think of it as the tree’s label. It denotes what kind of a tree it is. But if we begin with the html element and chart the hierarchical

        ⽧ 132

        Part II: HTML, XHTML, CSS, and Accessibility

        ⽧⽧⽧

        Figure 6-5: Viewing the document in Mozilla Firebird. relationships between elements, we end up with a graphical representation very similar to a family tree (see Figure 6-6).

        Figure 6-6: Map of the document tree. The terminology used to describe relationships with elements is very familial. The html element is a parent element to its children, the head and body elements. Because the head and body elements sit on the same level of the hierarchy, they are considered siblings. This language becomes important in CSS, when you examine the concept of inheritance. This is the idea that properties (which you can think of as traits) are passed down from one element to another. So, if I were to give a style rule to html that contained inheritable traits, those traits would be inherited right on through the tree.

        ⽧⽧⽧

        Chapter 6: Crafting Pages with HTML

        ⽧ 133

        Choose a document you’re working on and sketch out its tree. This is a good way to become comfortable with the way elements relate to one another.

        tip

        ⽧ ⽧ ⽧

        Secret #92:

        Elements, Tags, and Attributes

        One thing that drives me to distraction is the way terminology is constantly misused in HTML. Very few of today’s working Web designers have had formal training in the language, so misuse of nomenclature is understandable. However, the trouble it causes is twofold: ⽧ ⽧

        Vague use of language makes it difficult for team members, including project managers, to make clear, understandable statements. An individual with an improper understanding of terminology may influence or incorrectly instruct co-workers, causing confusion.

        An element is a tagset, or a tag and any content it relates to. An element can be made up of an opening and closing tag or a single tag. Any element that contains text content (such as headers, paragraphs, and list items) is considered a nonempty element and usually requires an opening and closing tag in HTML (although as previously mentioned, HTML versions don’t require a closing tag for certain elements, such as paragraphs and list items). Any element that does not contain content is considered an empty element. Examples include line breaks, horizontal rules, and images. Elements are also considered to be either block or inline. A block element is one that is self-contained. Block elements generate a carriage return. Examples include headers, paragraphs, and list items. Inline elements are those used within a block but without generating any breaks, such as links, images, emphasis, strong, and so on. Tags are the literal markup tags that are used to express the element, such as ..., , , and so on. Attributes allow certain traits to be applied to an element. Attributes are made up of two components, the attribute name and the attribute value. The name defines what the attribute is, and the value (which can vary in value types) describes how the attribute is to be applied, such as in the following example: align="right"

        Figure 6-7 shows the anatomy of an element, including its attributes.

        Figure 6-7: Anatomy of an element.

        ⽧ 134

        Part II: HTML, XHTML, CSS, and Accessibility

        ⽧ ⽧ ⽧

        Secret #93:

        ⽧⽧⽧

        Intrinsic Events

        Intrinsic event handlers are a type of attribute reserved as a way to handle events within the browser, and to attach scripts to elements via the Document Object Model (DOM). The DOM is the interface within a browser that enables scripting to actively influence elements and their behavior. The attribute value will be related to the script in question. Table 6-3 shows event handlers in HTML and what they do.

        Table 6-3: Intrinsic Events in HTML 4.01 Intrinsic Event

        Description

        Allowed Elements

        onload

        This event occurs when the browser finishes loading a document into a window, or all documents are loaded within a frameset

        body

        onunload

        This event occurs when the document is removed from the browser

        body

        onclick

        This event occurs when a user clicks on an element

        Almost all elements

        ondblclick

        This event occurs when a user double-clicks on an element

        Almost all elements

        onmousedown

        This event is triggered when the mouse button is in the down state over an element

        Almost all elements

        onmouseup

        This event occurs when the mouse button is released from the element

        Almost all elements

        onmouseover

        This event occurs when the mouse passes over the element

        Almost all elements

        onmousemove

        This event happens when the mouse is moved over an element

        Almost all elements

        onmouseout

        This event occurs when the mouse is moved away from the elements

        Almost all elements

        onfocus

        When an element receives focus either via a pointing device or tabbed navigation, this event occurs

        a

        frameset

        frameset

        area label input select textarea button

        onblur

        When an element that had focus loses focus due to the pointing device or tabbing moving away from the element

        Same as for onfocus

        ⽧⽧⽧

        Chapter 6: Crafting Pages with HTML

        ⽧ 135

        Intrinsic Event

        Description

        Allowed Elements

        onkeypress

        This event occurs when a key is pressed and released over an element

        Almost all elements

        onkeydown

        This event occurs when a key is pressed and held down over an element

        Almost all elements

        onkeyup

        This event is triggered when a key in a pressed position is released

        Almost all elements

        onsubmit

        This event occurs when a form is submitted

        This applies to the form element only

        onreset

        This event occurs when a form is reset

        Also applies to the form element only

        onselect

        This occurs when text in a text field is selected

        input

        onchange

        This occurs when a form control loses input focus and the value has already been modified

        input

        textarea

        select textarea

        tip

        Many people use camel case for their intrinsic events, such as onMouseOver. This is a popular convention, but wise to avoid if you’re using or ever plan on upgrading your HTML documents to XHTML. In XHTML, you can’t have any uppercase characters in your attribute names (See Chapter 7).

        ⽧ ⽧ ⽧

        Secret #94:

        Special Characters

        Another area where you, as the designer, should take care to conform to specifications is in working with special characters. Special characters, or character entities, are a series of codes that control symbols, letters, and math-related characters. You’ve probably come across some of these entities in your work. Common examples include the entity for the copyright symbol, © and the entity for a nonbreaking space,  .

        note

        There are numerous entities, but not all of them are considered standard. Unfortunately, some Web design software packages include entities that aren’t standardized, which makes working with them even more difficult, although validating a document with nonstandard entities will return a helpful error. For a complete set of conforming character entities, see “Character Entities in HTML and XHTML” at the Web Standards Project (www.webstandards.org/learn/reference/entities.html).

        ⽧ 136

        Part II: HTML, XHTML, CSS, and Accessibility

        ⽧⽧⽧

        There are three types of character entities within HTML (and XHTML): ⽧ ⽧



        ISO 8859-1 characters. This set includes the Latin set of character entities. Symbols, mathematical characters, Greek, and Latin letters. This set includes entities for various symbols (such as copyright symbols and so on), math characters, and Greek and Latin letters. Markup-significant characters. This set includes internationalization characters such as those required for bi-directional text.

        All characters are represented by both a named and numeric value. You can use either value as long as you find the character among those considered valid, and test the character in the target browsers for your project. If you’ve chosen a named or numeric value that doesn’t display consistently in your target browsers, consider using the other value type.

        tip

        ⽧ ⽧ ⽧

        Secret #95:

        Limit Color Names to Standard Colors

        As with special characters, numerous color names in HTML are not standardized. In fact, the list of standard names for use with HTML is so short that it’s included in this section in its entirety. You should remember a few things about color names: ⽧ ⽧ ⽧ ⽧

        You can use any standard color name in place of a hexadecimal value in an HTML document. Because there are only 16 standard names, you might prefer to use hexadecimal values instead. Not all standard color names are part of the Web-safe palette, if that’s a concern to you. You can use these color names with CSS, too. CSS offers more color value options than HTML, and it’s no problem to combine names and other available values, but if you’re going to use a color name, it has to be one of the following in order to be valid.

        Table 6-4 shows standard color names. The corresponding hexadecimal values are included so you can see what’s Web-safe and what’s not.

        note

        Want the truth about Web-safe colors? See Chapter 11, “Sophisticated Visual Design in a Global Market.”

        ⽧ ⽧ ⽧

        Secret #96:

        Avoid the font Element

        The font element was a problem element from its inception. It’s not that it isn’t well supported because, ironically, it happens to be very well supported. And it’s not that more font faces are available in CSS—the same issues concerning font

        ⽧⽧⽧

        Chapter 6: Crafting Pages with HTML

        ⽧ 137

        Table 6-4: Standard Color Names for Use in HTML, XHTML, and CSS Color Name

        Corresponding Hex Value

        Black

        #000000

        Silver

        #C0C0C0

        Gray

        #808080

        White

        #FFFFFF

        Maroon

        #800000

        Red

        #FF0000

        Purple

        #800080

        Fuchsia

        #FF00FF

        Green

        #008000

        Lime

        #00FF00

        Olive

        #808000

        Yellow

        #FFFF00

        Navy

        #000080

        Blue

        #0000FF

        Teal

        #008080

        Aqua

        #00FFFF

        support occur in CSS and in HTML, although CSS offers more sizing and display options. Problems arise for two main reasons. The first is that using the font element goes against the premise that ideally we separate our structured document (which you’ve learned to do in this chapter) from anything that is presentational. Historically, presentation via CSS wasn’t very well supported. However, at this time, almost all font features in CSS are supported across every conceivable contemporary browser, as well as having some support in older browsers such as Netscape 4.x versions and Internet Explorer (IE) as early as 3.0, which incidentally was the first commercial browser to include any CSS support. The second concern is that using the font element clutters up documents greatly. This is especially true in table-based layouts, where a font has to be redefined in every single table cell. Using the font element within tables accounts for the majority of unneeded page weight out there on the Web. What’s the bottom line when it comes to the font element? Don’t use it. It’s unnecessary at this point in history, and CSS is much more practical.

        note

        Warren Steel’s “What’s Wrong with the Font Element” is still one of the most requested Web documents around. The article gives a detailed look at problems related to the font element; find it at www.mcsr.olemiss.edu /∼mudws/font.html. Another interesting article is “ Considered Harmful,” in which the specifics of the face attribute are criticized. Read it at http://alis.isoc.org/ web ml/html/fontface.en.html.

        ⽧ 138

        Part II: HTML, XHTML, CSS, and Accessibility

        ⽧⽧⽧

        ⽧ ⽧ ⽧

        Secret #97: Avoid the center Element What’swrong with the center element? It’svalid in transitional documents, it works, and we’ve used it for years.

        Introduced by Netscape back in the day, center was very valuable in terms of helping us center text or tables on a page. We now know that this was a kludge to begin with. Here is what’s wrong with the center element: ⽧ ⽧ ⽧

        The syntax of center is ambiguous. It is semantically more suited to be an attribute, not an element. It is a deprecated element in HTML 4.01, and as with all deprecated elements, it should be avoided (as addressed in the next secret). The concept of center is presentational, so its use has fallen out of favor. Use CSS instead. Centering in CSS is its own challenge. See “CSS Centering” in Chapter 9, “Laying Out Pages with CSS.”

        note

        ⽧ ⽧ ⽧

        Secret #98:

        Avoid All Deprecated, Obsolete, and Proprietary Elements and Attributes

        If an element or attribute is deprecated, obsolete, or proprietary, avoid it. A deprecated element or attribute is one that is allowed for use in some DTDs, but a preferred method exists. I always imagine a deprecated element or attribute as being the kid in the dunce cap—he’s still in the room, but he’s almost on his way out. Deprecated elements that should be avoided include the following: ⽧ ⽧ ⽧ ⽧ ⽧ ⽧ ⽧ ⽧ ⽧ ⽧

        applet basefont center dir font isindex menu s strike u

        Obsolete elements are those that have been removed from a specification, but had been there at some point in the past. Typically, you won’t have likely ever even

        ⽧⽧⽧

        Chapter 6: Crafting Pages with HTML

        ⽧ 139

        seen obsolete elements, which include such elements as listing, plaintext, and xmp.

        Proprietary elements and attributes are those that are browser-specific and have never been entered into any specification. One such proprietary element that causes challenges to designers seeking to work within the specs is the embed element, used to embed Flash and other media into Web pages. The standard alternative is to use object, but there are browser compatibility issues with that.

        cross ref

        For more information on how to add media to a page using standards-compliant workarounds, see Chapter 12, “Spicing it Up with Dynamic Content and Rich Media.”

        Some common proprietary attributes include leftmargin and rightmargin. These attributes are often used to set page margins (but we have CSS for that now).

        tip

        Validating documents will find any instances of obsolete or proprietary elements and attributes. Deprecated elements and attributes will not cause errors in validation if you are using a DTD that supports them, which will typically be a transitional rather than strict DTD. Note that you can even use deprecated elements in Transitional XHTML (see Chapter 7), but again, if you can use CSS for the job, do so.

        ⽧ ⽧ ⽧

        Secret #99:

        Use Elements as They Were Intended

        Another issue with HTML elements is that people use them to achieve visual results—something for which HTML was never intended. Using elements in an inappropriate way is also referred to as a hack, and you want to avoid hacks in most instances. Whether it’s to add space by stacking break tags on top of each other:




        Or using a space within a nonempty element to create space:

         



        Or adding space at the end of a line of list items:
        • Here's my item



        The point is that while usage of this nature might not be invalid, it’s not recommended. Space can be controlled using style, and that control is far more effective

        ⽧ 140

        Part II: HTML, XHTML, CSS, and Accessibility

        ⽧⽧⽧

        and less problematic than using hacks of this nature. Always try to use elements as they were intended to be used.

        ⽧ ⽧ ⽧

        Secret #100:

        Restrict Use of Tables

        Using tables for layout is the biggest HTML hack around. Table elements and attributes were developed for one reason: to display tabular data. Using them for any other reason is inappropriate. That someone got the bright idea to turn off borders and create a grid system upon which we could lay out our Web documents so they were attractive on screen was truly revolutionary. Despite the standards movement and a growing understanding of why using tables for layout has so many disadvantages, the vast majority of Web sites use tables as their means of page layout.

        But we’re now moving into a more sophisticated realm of understanding. It’s becoming clear that restricting the use of tables brings many advantages, including the following: ⽧ ⽧ ⽧ ⽧

        Cleaner, more streamlined pages, which are easier to manage Improvement of support for multiple user agents and device types including mobile phones, pagers, and PDAs. Improved accessibility for those with physical impairments Reduction of page weight by an average of 50 percent, resulting in faster download times and economic savings in bandwidth and storage.

        These are all very attractive advantages, but if you’re not using tables, how do you lay out your Web sites? If you can use all CSS-based layouts, you should. If you have to support browsers that have partial, imperfect, or nonexistent CSS support, use tables if you have to. Then, supplement with CSS where you can. The use of tables with some CSS for layout purposes is referred to as transitional design and is a very good option for those designers who have to support diverse browsers. If you do choose this option, follow these guidelines for best results: ⽧ ⽧ ⽧

        Reduce the number of nested tables as much as possible. Reduce the number of table rows. Reduce the number of table cells.

        In other words, use as simple a table as possible to achieve your layout, and fill in with CSS where you can.

        note

        For an interesting perspective on the transition from tables to CSS for layouts, see “From Table Hacks to CSS Layout: A Web Designer’s Journey” by Jeffrey Zeldman, at www.alistapart.com/articles/journey/.

        ⽧⽧⽧

        ⽧ ⽧ ⽧

        Chapter 6: Crafting Pages with HTML

        ⽧ 141

        Secret #101: Restrict Use of Frames Just as with tables, restricting use of frames makes for a more manageable, accessible, and usable Web site. Frames can serve a few important purposes. They are excellent if you’re creating some kind of a Web-based application where static content is desirable. IFrames are popular for managing advertising, and frames can be written to be completely valid. But they are known to have all kinds of problems associated with them, such as the following: ⽧ ⽧

        ⽧ ⽧ ⽧

        The focus of frames is layout, which goes against HTML as a structural language. Because of their presentational nature, frames are limited to Web browsers and are not supported at this time by those user agents on mobile devices, limiting your site’s portability and interoperability. Frames require multiple documents to create a single visual output. This means more documents to manage and store. Frames are difficult or downright impossible to manage by screen readers and other assistive devices used by those with physical disabilities. If a user agent doesn’t support frames, there is no way to degrade the documents; the agent simply can’t display the results unless you provide script-based workarounds, meaning extra work for you and all kinds of support problems for your users.

        Deciding to use frames for any reason should be a decision that comes about after researching other alternatives for achieving the same goals.

        ⽧ ⽧ ⽧

        Secret #102: Validate, Validate, Validate! Find out if your document conforms by validating it. Validation is the process of comparing your completed document to the DTD defined in the DOCTYPE. Your document is compared and any errors will be displayed. Typically, begin troubleshooting invalid documents by fixing the first error along with any errors related specifically to proprietary or problem elements and then revalidate. Fixing the first reported error and then revalidating will often reveal that numerous other reported errors were a result of that first, incorrect error.

        tip

        You can validate documents using any number of validation tools. See Chapter 1, “Setting up a Master Toolbox” for more details.

        I ran the document we created in this chapter through the validator at the W3C. You can see the favorable results in Figure 6-8. Also, because we have no presentational elements or attributes in our document at all, we can now rest comfortably

        ⽧ 142

        Part II: HTML, XHTML, CSS, and Accessibility

        ⽧⽧⽧

        Figure 6-8: Validation success. knowing that the document is a conforming, compliant, standards-based structural document ready for styling.

        Summary Everything in this chapter was geared to help those who have been working with visual editors or marking up documents according to conventions rather than standards, move toward a more sophisticated understanding of the languages with which you work. Next, we take a look at XHTML. While it is perfectly acceptable to use HTML for your Web documents, XHTML offers more insight into structure and semantics, greater flexibility, and a more forward-thinking methodology with which to author our documents.

        Chapter

        Moving Ahead with XHTML

        7

        ⽧⽧⽧⽧⽧⽧⽧⽧⽧⽧⽧⽧⽧⽧⽧⽧⽧⽧⽧⽧⽧⽧⽧⽧⽧⽧⽧

        Secrets in This Chapter #103: #104: #105: #106: #107: #108: #109: #110: #111: #112: #113: #114: #115: #116: #117: #118: #119: #120: #121:

        Choose a DTD . . . . . . . . . . . . . . . . . . Avoid the XML Declaration . . . . . . . . . . Use Correct XHTML DOCTYPEs . . . . . . . . Add the Namespace to Root . . . . . . . . . . Implementing Style in XHTML . . . . . . . . Adding Scripts in XHTML . . . . . . . . . . . XHTML and Case Sensitivity . . . . . . . . . Quotation of Attribute Values in XHTML . . . Managing Nonempty Elements . . . . . . . . Terminating Empty Elements . . . . . . . . . Managing Minimized Attributes . . . . . . . Entities and XHTML . . . . . . . . . . . . . . alt Attribute Required . . . . . . . . . . . . . . Understand Well-Formedness . . . . . . . . . Proper Nesting of Lists . . . . . . . . . . . . . DOCTYPE Switching . . . . . . . . . . . . . . Enclose Inline Elements in Blocks . . . . . . . name Becomes id . . . . . . . . . . . . . . . . The target Attribute is Unavailable in Anchor

        . . . . . . . . . . . . . . . . . . .

        . . . . . . . . . . . . . . . . . . .

        . . . . . . . . . . . . . . . . . . .

        . . . . . . . . . . . . . . . . . . .

        . . . . . . . . . . . . . . . . . . .

        . . . . . . . . . . . . . . . . . . .

        . . . . . . . . . . . . . . . . . . .

        . . . . . . . . . . . . . . . . . . .

        . . . . . . . . . . . . . . . . . . .

        . . . . . . . . . . . . . . . . . . .

        . . . . . . . . . . . . . . . . . . .

        . . . . . . . . . . . . . . . . . . .

        . . . . . . . . . . . . . . . . . . .

        ⽧⽧⽧⽧⽧⽧⽧⽧⽧⽧⽧⽧⽧⽧⽧⽧⽧⽧⽧⽧⽧⽧⽧⽧⽧⽧⽧

        . . . . . . . . . . . . . . . . . . .

        . . . . . . . . . . . . . . . . . . .

        . . . . . . . . . . . . . . . . . . .

        147 148 149 150 151 152 153 154 155 155 156 156 157 158 159 162 163 164 165

        ⽧ 144

        Part II: HTML, XHTML, CSS and Accessibility

        ⽧⽧⽧

        T

        his chapter debunks myths, explains what XHTML is and why it’s so very important, and provides all the scoop on how to author XHTML documents that you can use in every browser known to humankind—even those for alternative devices such as PDAs and cell phones.

        About XHTML If you’re wondering why we need another language when HTML seemed to work just fine, you’re not alone. Many people in the Web industry—including some markup experts—aren’t necessarily convinced that XHTML offers any of the advantages for most Web designers that HTML does. You might be surprised to read that I agree. For the most part, if you’re designing Web sites, you can use HTML or XHTML. My major concern is that you use one or the other according to the standard and according to the rules and practices described here and in Chapter 6, “Crafting Pages with HTML.’’ Aside from that, I do believe that XHTML is a better choice for a few significant reasons, and this introduction and the subsequent secrets here reveal the advantages that XHTML does offer.

        History As you are aware, SGML is the meta-language from which Tim Berners-Lee created HTML. As the Web progressed both as a social and technical phenomenon, working groups at the W3C began to study long-term ideas for the languages and methods used on the Web. Many technologies have since emerged, including the Extensible Markup Language (XML). XML, like SGML, is a meta-language that consists of specifications and guidelines for creating applications and other language subsets. XML, like HTML, also emerged from SGML, although not as a subset language itself. Think of XML as SGML “lite’’for the Web—it is more streamlined than SGML, yet retains SGML’s strict rules while simultaneously offering its authors flexible customization options. With XML in hand, HTML 4.0 in place with its three DTDs, and CSS available, the W3C began re-examining HTML and determined that it had limitations in the way it is specified and would not extend beyond those limitations after a certain point in time. Seeking stricter practices but wanting to offer extensibility, the W3C looked to XML as a means to influence HTML. So HTML was reformulated as an application of XML (rather than its original SGML) and the Extensible Hypertext Markup Language (XHTML) was born.

        Goals of XHTML The limitations of HTML largely emerge from its very specific vocabulary, which carries over into XHTML. XML itself is very semantic—remember in Chapter 6 the discussion of semantic meaning and tags? In HTML, we use specific tags to achieve a given goal. In XML, tags are more specific to the topic at hand and are entirely generated by the author. XHTML attempts to provide some bridge from the limitations of a specific vocabulary to a more open specification where the author can create his or her own DTDs and modify the language as required. Following are some of the specific goals of XHTML: ⽧

        To bring more rigor (rigid rules) to the authoring of Web documents

        ⽧⽧⽧

        ⽧ ⽧

        Chapter 7: Moving Ahead with XHTML

        ⽧ 145

        To provide extensibility to Web authors To support a growing number of alternative devices such as set-top boxes, PDAs, pagers, and other mobile or unique devices tapping into Web-based information

        Newcomers sometimes ask if XHTML is backward compatible and supported in older browsers. Yes, XHTML is supported by any browser that can interpret HTML (see Figure 7-1), because XHTML uses HTML’s vocabulary. The main difference is in the rigor, how the language is written, and how strictly its rules are adhered to.

        Figure 7-1: I took the valid HTML document created in Chapter 6, upgraded it to XHTML 1.1, and viewed it in Mosaic, the Web’s first widely used graphical Web browser. It works!

        note

        An excellent repository of Web browsers is available at http://browsers .evolt.org/.

        XHTML Versions and DTDs Like HTML, XHTML comes in versions and offers a range of DTDs from which to choose. Table 7-1 describes the language versions, DTDs, and uses for XHTML. You can see that a major change occurred with XHTML 1.1. This is because by this point in the language, there is no longer any need for Transitional DTDs—CSS can handle presentation, and all that’s really required in the document itself is the structural markup and content. Another important point about XHTML 1.1 is that it’s modularized. It’s broken down into individual modules such as text, tables, forms, and so on. This gives authors the flexibility to write their own DTD, pull in only those modules they

        ⽧ 146

        Part II: HTML, XHTML, CSS and Accessibility

        ⽧⽧⽧

        Table 7-1: XHTML Versions and Document Types XHTML Version

        Document Type

        Usage

        XHTML 1.0

        Transitional DTD

        In widespread use insofar as XHTML goes—it’s the version generated by most contemporary Web editors with XHTML support, such as Dreamweaver MX and MX 2004

        XHTML 1.0

        Strict DTD

        In use by most Web designers working with CSS and Web standards

        XHTML 1.0

        Frameset DTD

        For use in XHTML framesets only

        XHTML 1.1

        XHTML 1.1

        XHTML 1.1 is the currently recommended specification. It has only one DTD, based on XHTML 1.0 Strict. It is not in widespread use due to concerns related to the way it’s served (discussed in detail later this chapter)

        want, and leave others out. This is especially important for browser and user agent developers designing for multiple devices—think about it, you can’t run a complex Java application on a smart pager or mobile phone just yet due to technological limitations, but you can access basic Web content. There isn’t the same need on smaller devices to support the kinds of features and functions necessary on desktop and notebook computers.

        note

        Read more about the modularization of XHTML at the W3C site, www.w3 .org/TR/xhtml-modularization/.

        The ability to write one’s own DTD is part of the essence of XHTML because it is there that we find the extensibility and customization features that HTML cannot offer. Writing your own DTD can also enable you to include elements and attributes in the language that don’texist in the public DTDs at the W3C. This is more trouble than it’s worth for smaller Web sites, but for very large sites using custom features, it can be extremely useful to have that flexibility available.

        note

        To see a custom DTD in action, visit www.ibm.com/ and take a look at the DOCTYPE in use. IBM, being one of the earliest adopters of SGML applications for document management, authors and adheres to its own DTDs.

        At the time of this writing, XHTML 2.0 is being worked on and has caused some controversy as the working group studying it has decided to add some elements and take away others—some that are popular and widely used. As a result, new features will have to be supported by browsers without any chance for backward compatibility, and features that are removed can no longer be used.

        ⽧⽧⽧

        Chapter 7: Moving Ahead with XHTML

        ⽧ 147

        As I’ve already suggested, just because a language type or version exists or is a current recommendation doesn’t mean you have to use it. You can choose to use any language you want. Remember, most of the Web isn’t even using valid markup. For the best results, choose a language and DTD that is appropriate for the work you do and for your target browsers.

        note

        So Is XHTML Better? Back to the question at hand: If we have HTML and it serves its purpose on the Web, is XHTML better? I believe it is, and here are my reasons: ⽧ ⽧



        ⽧ ⽧ ⽧

        You get greater rigor in authoring results in more consistently authored documents. Grammar rules are far less arbitrary in XHTML than they are in HTML. As a result, authors with good knowledge of markup will make fewer errors and waste less time debugging and troubleshooting. XHTML is suitable for a wide range of needs (not just Web), making it a good choice for those designers and document authors looking to extend their content beyond the Web. XHTML is easier to learn and teach because the rules are stricter. Greater rigor in the language means greater consistency in documents from author to author. Extensibility features, even if never tapped into, provide long-term flexibility should the need arise.

        If you’d like to upgrade to XHTML but have a limited budget, begin using XHTML on new projects or new portions of your Web site. This way, you begin tapping into the advantages of XHTML without spending money and time redoing older HTML pages.

        tip

        ⽧ ⽧ ⽧

        Secret #103: Choose a DTD Since you already know that you must have a DOCTYPE that declares a proper DTD, the first step when working with XHTML is to choose the DTD with which you’re going to work. You have the following choices: ⽧

        ⽧ ⽧

        XHTML 1.0 Transitional. Choose XHTML 1.0 Transitional when you want any kind of presentational elements or attributes in your documents. XHTML 1.0 Strict. XHTML 1.0 Strict is great when you are relying on CSS for all presentation. XHTML 1.0 Frameset. Use this DTD for frameset documents. Individual framed pages can be in any valid format.

        ⽧ 148



        Part II: HTML, XHTML, CSS and Accessibility

        ⽧⽧⽧

        XHTML 1.1. The XHTML 1.1 DTD is based on XHTML 1.0 Strict, but it must be served as application/XML, a media type used to define applications using XML. Choose XHTML 1.0 Strict in place of using XHTML 1.1 to avoid media type problems.

        tip

        XHTML 1.1 is supposed to be served using the media type application/xhtml+xml, not as text, even though you can serve it as text and have it work properly—there’s a bit of dissent about this in the technical community (see the note that follows for more details). The problem with serving XHTML as XML is that the Web server in use must be configured properly or use content negotiation—concepts outside the realm of this book, and the browser must be able to properly display the results. At this time, it’s a hit-or-miss issue, so most people either write in XHTML 1.1 and just serve it as text or avoid it altogether. To understand the media type issues in more detail, see www.w3.org/ TR/xhtml-media-types/.

        note

        At this time, unless I’m expressly asked to author something in HTML, I use XHTML 1.0 Strict along with CSS for almost all my Web documents.

        ⽧ ⽧ ⽧

        Secret #104:

        Avoid the XML Declaration

        The XML declaration (also referred to as an XML prologue or XML prolog) is a bit of XML markup that you can place in XHTML documents above the DOCTYPE declaration, as follows:

        The purpose of the XML declaration is to identify the document as being an XML document, and you can denote the version of XML as well as the character encoding (see Chapter 6, “Crafting Pages with HTML’’). Unfortunately, the XML declaration causes a lot more trouble than it’s worth for Web designers at this time. There are several reasons for this, all of them due to browsers not properly knowing what to do with the XML syntax used by the declaration. Known problems with the XML declaration include the following: ⽧ ⽧ ⽧

        Browsers not interpreting or rendering the markup, but displaying the source instead Browsers rendering the XML tree (see Figure 7-2) instead of the document Browsers with DOCTYPE switching support (discussed later this chapter) not performing the switch

        According to the XHTML specifications, the W3C says that the XML declaration is recommended, but it is not required for an XHTML document to be valid. Because

        ⽧⽧⽧

        Chapter 7: Moving Ahead with XHTML

        ⽧ 149

        Figure 7-2: The XML declaration can cause some browsers to render the XML tree rather than the document. Here’s a sample of how that might look. of these rendering problems, my suggestion is to leave it out. However, if you have a specific target browser that has no problem interpreting documents properly with the XML declaration in place and you do not have to support any that do, you can consider using it.

        note

        For a helpful chart displaying those browsers with and without issues related to the XML declaration, see www.webstandards.org/learn/reference/ prolog problems.html.

        ⽧ ⽧ ⽧

        Secret #105: Use Correct XHTML DOCTYPEs As with HTML, the DOCTYPE declaration must appear at the top of your document for a document to be validated—and to validate. DOCTYPEs are required in both HTML and XHTML.

        Once you’ve chosen the appropriate DTD and begin to construct a document template, you’ll want to include the correct DOCTYPE. Table 7-2 shows the available DOCTYPEs in XHTML. As you surf around and view source, you’ll notice that not all DOCTYPEs look like the ones you’ve seen in this book. Some of them are shorter, without the URL. Some have relative URLs. These DOCTYPEs aren’t necessarily incorrect, but they may not be functional both in validation and in DOCTYPE switching if they are not among those listed here (and in Chapter 6, for HTML DOCTYPEs).

        ⽧ 150

        Part II: HTML, XHTML, CSS and Accessibility

        ⽧⽧⽧

        Table 7-2: DTDs and DOCTYPE Declarations in XHTML DTD

        DOCTYPE Declaration

        Use

        XHTML 1.0 Transitional