Future-Proof Web Design E-Book

Alexander Dawson

• Herausgeber: John Wiley & Sons
• Kategorie: Wissenschaft und neue Technologien
• Sprache: Englisch

Seitenzahl: 516

Veröffentlichungsjahr: 2011

Beschreibung

Best practices for flexible design that meet common challenges The web is constantly changing and evolving with an increased range of devices, browsers, and standards that need to be considered in design. Web designers know they must stay sharp in order to keep up with the rapid pace of technology change. This much-needed book teaches the art of flexible and adaptable design that can work easily with new devices, technologies, and standards. You'll quickly discover how this resource stands out from the crowd as it provides you with a roadmap for ensuring that your designs are stable and flexible enough to handle whatever technology changes are coming in the future. * Takes you on a journey of discovery as you learn how to prepare yourself for undefined changes in the dynamic environment of web design * Shares straightforward tips for adopting a forward-thinking approach to the subject of web evolution * Uncovers the essential skills you need in order to survive the future of the web Using the fundamental skills and processes laid out in this roadmap, you'll be able to boost your stability and flexibility while coding with confidence.

Leseprobe

Future-Proof Web Design

Table of Contents

Introduction

What’s This Book About?

No Artificial Flavorings

Conventions Within This Book

Your Marauders Map

Chapter 1: Future-Proof Survival Techniques

Understanding the Environment

The truth behind terminology

Mythology and folklore in design

Keeping up with the Joneses

Planning for a Successful Website

Determining project requirements

Setting goals while dodging holes

Planning for implementation

Learning to Adapt or Evolve

Taking advantage of new technologies

Solutions for a successful layout

Beyond design: An essential business guide

Resolving Issues of Compatibility

Debugging for durable devices

Cultivating customer service

The Web: Survival of the fittest

Chapter 2: The Five Principles of Ubiquity

Websites Are like Onions

Level 1: Graceful Design

Beginning graceful degradation

Justification for applying graceful degradation

Considerations of compatibility: Graceful design

Level 2: Progressive Design

Progressive enhancement

Justification for applying progressive design

Considerations of compatibility: Progressive design

Level 3: Adaptive Design

Adaptive paths to degradation

Considerations and justifications: Adaptive design

Level 4: Responsive Design

Responsive design: A love story

Considerations and justifications: Responsive design

Level 5: Reactive Design

Reactive sites: Beyond behavior

Philosophies of a reactive Web

Ubiquity to the power of five

Chapter 3: Designing for the Desktop

Knowing the Challenge: Compatibility

Desktop

Practical solutions

Best Practices

Laptop

Practical solutions

Best Practices

Netbooks

Practical solutions

Best Practices

Nettops

Practical solutions

Best Practices

Chapter 4: Helping Out the Handheld

Benefiting from Portability

Tablet

Practical solutions

Best practices

Smartphone

Practical solutions

Best practices

Featurephone

Practical solutions

Best practices

eReader

Practical solutions

Best practices

PDA

Practical solutions

Best practices

Wristwatch

Practical solutions

Best practices

Chapter 5: Evolving for Entertainment

Bringing the Web into the Living Room

Television

Practical solutions

Best practices

Game Console

Practical solutions

Best practices

Handheld Console

Practical solutions

Best practices

Media Player

Practical solutions

Best practices

Set Top Box

Practical solutions

Best practices

Chapter 6: Automobiles and Appliances

Preparing for Your Dream Reality

Embedded Gadgets

Practical solutions

Best practices

Connected Objects

Practical solutions

Best practices

Transportation

Practical solutions

Best practices

Physical Goods

Practical solutions

Best practices

Chapter 7: Designing for Input Tools

Just Point and Flick!

Pointer

Practical solutions

Best practices

Touchpad

Practical solutions

Best practices

Keyboard

Practical solutions

Best practices

Remote Control

Practical solutions

Best practices

Microphone

Practical solutions

Best practices

Imaging

Practical solutions

Best practices

Scanner

Practical solutions

Best practices

Other Tools

Practical solutions

Best practices

Chapter 8: Designing for Output Tools

Your Digital Eyes and Ears

Display

Practical solutions

Best practices

Projector

Practical solutions

Best practices

E Ink

Practical solutions

Best practices

Speakers

Practical solutions

Best practices

Printers

Practical solutions

Best practices

Chapter 9: Environmental Influences

Internal and External Factors

Components

Practical solutions

Best practices

Connectivity

Practical solutions

Best practices

Bandwidth

Practical solutions

Best practices

Chapter 10: Influencing Operating Systems

Inside the System Shell

GUIs

Practical solutions

Best practices

Controls

Practical solutions

Best practices

Associations

Practical solutions

Best practices

Typefaces

Practical solutions

Best practices

Colors

Practical solutions

Best practices

Security

Practical solutions

Best practices

Chapter 11: Details on Design Software

What You Code is What You Get

CMSs

Practical solutions

Best practices

Visual Editors (WYSIWYG)

Practical solutions

Best practices

Snippets

Practical solutions

Best practices

Wizards

Practical solutions

Best practices

Chapter 12: Befriend the Web Browser

Windows to the Web

Trident

Practical solutions

Best practices

Gecko

Practical solutions

Best practices

WebKit

Practical solutions

Best practices

Presto

Practical solutions

Best practices

Mobile

Practical solutions

Best practices

Proxy

Practical solutions

Best practices

Alternates

Practical solutions

Best practices

Chapter 13: Providing Powerful Plug-Ins

Plug-and-Play Interactivity

Enhancements

Practical solutions

Best practices

Extensions

Practical solutions

Best practices

Multimedia

Practical solutions

Best practices

Chapter 14: Alternative Content Applications

Browsing Without a Browser

Reformatters

Practical solutions

Best practices

Apps and Widgets

Practical solutions

Best practices

Accessibility Aids

Practical solutions

Best practices

Augmented Reality

Practical solutions

Best practices

Chapter 15: The Consequences of Code

The Compatibility of Code

(x)HTML

Practical solutions

Best practices

CSS

Practical solutions

Best practices

JavaScript

Practical solutions

Best practices

WML

Practical solutions

Best practices

Metadata

Practical solutions

Best practices

Non-Standard Code

Practical Solutions

Best practices

Chapter 16: Third-Party Dependency

The Weakest Link

Resources

Practical solutions

Best practices

Frameworks

Practical solutions

Best practices

Services

Practical solutions

Best practices

Chapter 17: Deliberations About Design

The Art of Aging Gracefully

Architecture

Practical solutions

Best practices

Content

Practical solutions

Best practices

Layout

Practical solutions

Best practices

Iteration

Practical solutions

Best practices

Chapter 18: Fun with Futuristic Features

The Tools of Tomorrow

Visual Effects

Practical solutions

Best practices

Interoperability

Practical solutions

Best practices

Personalization

Practical solutions

Best practices

Chapter 19: Dealing with the Robot Army

Of Machines and Men

Search Engines

Practical solutions

Best practices

Social Networks

Practical solutions

Best practices

Automated Tools

Practical solutions

Best practices

Verification

Practical solutions

Best practices

Chapter 20: Factoring in the Human Element

A Matter of Being Human

Physical Conditions

Practical solutions

Best practices

Intellectual Challenges

Practical solutions

Best practices

Emotional Factors

Practical solutions

Best practices

Social Expectations

Practical solutions

Best practices

Future-Proof Web Design

A Survival Guide

Alexander Dawson

This edition first published 2012

© 2012 John Wiley & Sons, Ltd

Registered office

John Wiley & Sons Ltd, The Atrium, Southern Gate, Chichester, West Sussex, PO19 8SQ, United Kingdom

For details of our global editorial offices, for customer services and for information about how to apply for permission to reuse the copyright material in this book, please see our Web site at www.wiley.com.

The right of the author to be identified as the author of this work has been asserted in accordance with the Copyright, Designs and Patents Act 1988.

All rights reserved. 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 or otherwise, except as permitted by the UK Copyright, Designs and Patents Act 1988, without the prior permission of the publisher.

Wiley also publishes its books in a variety of electronic formats. Some content that appears in print may not be available in electronic books.

Designations used by companies to distinguish their products are often claimed as trademarks. All brand names and product names used in this book are trade names, service marks, trademarks or registered trademarks of their respective owners. The publisher is not associated with any product or vendor mentioned in this book. This publication is designed to provide accurate and authoritative information in regard to the subject matter covered. It is sold on the understanding that the publisher is not engaged in rendering professional services. If professional advice or other expert assistance is required, the services of a competent professional should be sought.

978-1-119-97877-0

A catalogue record for this book is available from the British Library.

Set in 10/14 Chaparral Pro by Wiley Composition Services

Printed in Italy by Trento

About the Author

Alexander Dawson (@AlexDawsonUK) is an award-winning, self-taught, freelance web professional, writer, published author, and recreational software developer from Brighton (UK). With more than 10 years of industry experience, he spends his days running his consultancy firm HiTechy (www.hitechy.com), writing professionally about web design and giving his free time to assist others in the field.

In recent years, Alexander has become an established web writer, providing articles for some of the industry’s most respected sites including Smashing Magazine and Six Revisions. In addition, as a member of the Guild of Accessible Web Designers, he actively promotes and advocates the benefits of a good user experience and web standards. When Alexander isn’t coding or writing about design and development, he enjoys a game of tennis or chess and watching movies.

Credits

Some of the people who helped bring this book to market include the following:

Editorial and Production:

VP Consumer and Technology Publishing Director: Michelle Leete

Associate Director- Book Content Management: Martin Tribe

Associate Publisher: Chris Webb

Publishing Assistant: Ellie Scott

Development Editor: Colleen Totz Diamond

Technical Editor: Kayla Knight

Copy Editor: Melba Hopper

Editorial Manager: Jodi Jensen

Senior Project Editor: Sara Shlaer

Editorial Assistant: Leslie Saxman

Marketing:

Senior Marketing Manager: Louise Breinholt

Marketing Executive: Kate Parrett

Composition Services:

Compositor: Jennifer Mayberry

Proof Reader: Melissa D. Buddendeck

Indexer: Potomac Indexing, LLC

For the long-suffering professionals who work tirelessly to make the web a better place, and those individuals who continue to strive for a more accessible, standards-compliant Internet.

Author’s Acknowledgments

Writing a book is always a challenge and this title, in particular, had more ahead of it than many; but with a fantastic group of people behind you, anything becomes possible. As always, my thanks firstly have to go out to the entire team at Wiley (including Chris Webb and Ellie Scott in particular) whose hard work and effort in getting this unusual idea out of my head and into print shouldn’t go unsung. Without such an understanding group of individuals who’ve worked tirelessly at every level (behind the scenes) to ensure the quality of this book and its content, it likely wouldn’t have succeeded!

Next, there are three further individuals who deserve an incredible amount of credit. Firstly, I need to give a shout out to my copy editor (Melba) who has done an exceptional job at helping me craft my occasionally mind-boggling prose into something legible! Also, there’s my great technical editor (Kayla Knight) who kept my facts in check and offered lots of useful advice to improve the reading experience, making this title all the better for you. Finally, my gratitude has to go out to my editor (Colleen Diamond) who undertook a superhero-like performance, despite the universe attempting to disrupt our efforts.

Next, I would like to thank all of the people who have supported me throughout the writing process: from my friends and followers on social networks, IRC, instant messenger, and the websites where I’ve written, to the amazing and inspiring individuals who I’ve met at conferences or just chat to on a daily basis (you know who you are!). Ending this, the biggest thanks of all go out to you, the reader. By purchasing this title, you are supporting months of hard work, and if this book can help you craft flexible, future-proofed layouts that withstand the test of time, accounting for the many variables at work in a site, all of that effort I’ve put into writing this reference guide will have been worthwhile.

Introduction

The Web is wondrous. From its humble beginnings as a text-only interface, to its modern incarnation as an interactive, immersive experience, it has suffered many highs and lows (like the move toward web standards or the past obtrusiveness of scripting). Throughout the Web’s development, designers have been forced to innovate, endure, and push through limitations to ensure that their sites retain stability and flexibility. By making sites usable in a wide range of situations (future-proofed against changing usage), we can ensure that sites may be enjoyed by the next generation of Internet users, no matter how they use the Web.

Forget dogs. Man’s new best friend is the Internet. In a short period of time, the Web has grown from being accessible solely upon a desktop or laptop with one or two browsers to being experienced on netbooks (using one of many configurations), smartphones, and a range of other devices like TV sets! It has become a vital means of communication for the world as well as a port for those seeking knowledge, entertainment, or a place to voice opinions. Also: It can be used practically anywhere and is only limited by our imagination.

With each change and improvement the Web has encountered comes an increasing range and number of tools to help you build more engaging interfaces. However, with the sweet comes the sour. This fast-paced, increasingly diverse medium provides web designers with more challenges than ever to overcome and so many variables to account for. Making our layouts continue to work with old (compatibility quirks in devices) and new situations (future-proofing to withstand the test of time) is an investment to ensure long-term success.

What’s This Book About?

If you regularly build web sites, you’ve probably noticed that your content is consumed in increasingly unique ways. Back in the ’90s, you could assume that users accessed your site using a desktop computer, with one or two base resolutions and either Internet Explorer or Netscape Navigator. Today, just trying to guesstimate how much screen real estate a user has is like chasing a pot of gold at the end of a rainbow. You’ll either get lucky or end up targeting what doesn’t exist (except in legend or mythology), such as the “average user.”

During the browser wars (the time of Internet Explorer versus Netscape), web designers focused heavily on ensuring that interfaces worked in specific situations, building rigid, inflexible layouts (because of a lack of situations where diverse layouts would make a real difference). Some designers still build fixed layouts and have failed to notice how the Web’s landscape is changing. Variables that used to be considered a safe default no longer apply, attitudes are altering, and the designer’s challenge is to understand the scenarios visitors may encounter, determine whether these users require a specific solution, and then account for these factors within his or her site (to encourage visitors to keep visiting the site).

More and more, devices are gaining the “web enablement” treatment. Unique hardware products have gained online support. Software is playing a more active role in how layouts render. New standards and web languages are gaining traction. Even users are changing and adapting their behavior to match new technologies. To stay ahead of the curve, you must ensure that your site functions with what a user has, while also accounting for future variables that may spring up and become popular (as they gain mainstream adoption).

Your work isn’t just affected by code and browsers. You need to split apart the various layers of the Web (such as devices, hardware, software, standards, and consumers) to uncover the wealth of factors that can affect your site’s stability and users’ experiences. Accounting for each layer involves considering what can impact how users interact with your site (such as the operating system or browsers in the case of the software layer), and making sure that your layouts can withstand any changes that may occur as a result of a user’s environment.

No Artificial Flavorings

Now that you understand that the Web is evolving, allow me to introduce myself. My name is Alexander Dawson, and I’m a web designer who’s been building and improving sites for more than ten years (in addition to writing on the subject). If you’re the type of person who relishes any opportunity for trial and error, enjoys learning from the perspective of users, and has a passion for straightforward advice, fantastic! You’ve got the right book. For those of you who prefer detailed step-by-step instructions, this book may present more of a challenge.

It’s worth cutting to the chase and saying that this isn’t going to be a progressive tutorial to help you build some mobile layout (or an explicit design for any other type of device, for that matter). Because every situation you design for will be different, my philosophy is that the space in this book is better served by giving you the tools you need to make practical decisions, instead of providing you with a template (or “color by numbers” guide), which really serves its purpose only in a generic environment aimed at a non-existent audience.

This book is not made up of tips and techniques for creating that perfect layout, and it’s not a book of inspiration, reeling from the wonderful work of others (though I do encourage design by inspiration). What you will find within these pages is a wealth of information regarding the variables that can affect your sites or render them differently, occasionally causing issues. If the Web were a living, breathing entity, it’s possible that this book would be considered a guide to its ever-diverse biology and how to ensure its long term health!

My motivation for writing this book is straightforward. As is often the case with designers, I noticed the recent upsurge in new technologies that demanded additional testing, restrictive design considerations, or a more flexible method of serving data. So, my goal within these pages is to break down the misconceptions regarding what makes user experiences unique and to highlight some lesser-appreciated factors in the designer’s workflow. By examining the variables listed within this book, you can adapt your sites to meet the needs of each user.

Conventions Within This Book

Many enjoy the free content that gives some extra insight into movies they watch. When it comes to books, I like to think the same is also true. Of course, only so much information will fit within a set number of pages we have to explore this subject, so to give you more for your money, I have planted some useful “extras” within the pages of this book where possible, all with the aim of giving you some food for thought, useful links, and important details to keep you better informed. Keep an eye out for these extras as they appear.

Below are the conventions, with details about their purpose and function:

> Tips and Notes: Throughout the book, I provide tips and tricks to give you ideas, words of caution, and important, relevant details that can help you on your quest.

> Resources: Don’t just take my word for it. Throughout the book I include useful links that expand upon the variables to help you design in various situations.

> Checklists: Marking your progress can be helpful and fun. The lists at the end of a variable set goals to help you ensure a site will be as stable as possible.

If you are new to the web design world, you probably should work through this book in order (accounting for each variable as you read about it), but if you are a veteran, you may want to use the book as a quick reference guide, jumping to sections you want to know more about. This will allow you to account for the many cool new technologies on the horizon that will soon become “required reading” and keep up-to-date with the subjects that require our attention to ensure that our work continues to function on legacy devices.

Your Marauders Map

Keeping up-to-date with the latest trends and innovations is tough, especially in the field of web design. Within this book, you’ll explore the variables in that environment, learn, or see how designers are trying to maximize performance between platforms, and gain basic advice to help you when venturing into the unknown.

Chapter 1 has one goal in mind: Survival. Because the Web is still evolving at a rapid pace, from time to time new variables appear that must be catered to. They could literally be anything making its first appearance into your workflow; don’t you just love surprises! Perhaps it’ll be one of the predictions made by this book, or something totally obscure. As such, it seems only fitting that you are prepared for whatever may happen, and this chapter acts as a training session before you start engaging in the battle for site stability that’s ahead.

Chapter 2 builds on the work of the first chapter, showcasing the methodologies that many designers are using to build increasingly flexible layouts. However you build your sites, accounting for as many variables as possible is important. Getting used to the concepts provided will help you better meet an audience’s needs. Because each variable has its own requirements and considerations, applying these useful tricks requires some imagination and clever coding, but this goal is entirely possible to achieve if you put in the hard work.

Finally, you find the variables themselves, the true substance of this book, in a wealth of useful chapters (denoted in the following bulleted list by the category each chapter falls into). Each layer has several chapters, and each chapter has several variables that affect a layout!

Here are the various layers (or factors) of the Web, as covered in this book:

> Devices: Desktops, handhelds, entertainment, and appliances (Chapters 3-6)

> Hardware: Input and output tools plus environmental factors (Chapters 7-9)

> Software: OSs, web editors, browsers, plug-ins, and more (Chapters 10-14)

> Standards: Code, third parties, design, and innovations (Chapters 15-18)

> Consumers: Robotic influences and human-based factors (Chapters 19-20)

Addressing problems with every variable goes beyond the scope of this book, as there are far too many considerations to account for. If you think about a keyboard, users may have faulty keys, be slow typists, and have access to backlighting or more! This book aims to give you a few pointers in the right direction and actually showcase how complex and intricate the web machine actually is; by doing so, you should be able to consider the tips and tricks that are provided and build better personas and solutions accounting for these variables.

This journey will serve as a landmark for your future design and development projects as you come to appreciate how delicate our sites are against the veritable storm of the underlying processes involved. By coming to terms with the variables mentioned (and any yet to make themselves known) and changing your way of thinking, you can become a better designer! While this subject may seem overly theoretical, it needs to be explored and the truth is, when we start asking the right questions, good decisions follow.

Building a site is a challenge, and it’s one that will only increase in complexity as the Web evolves. We’ve gone from a world in which desktops ruled like dinosaurs to a landscape filled with many creatures with their own unique characteristics. The thing to remember is that visitors remain firmly in the driver’s seat, dictating how they’ll engage with your sites. Mobile devices, 3D, new browsers, CSS3, social networks, and more have their unique place in this scenario. As a designer of the next generation of sites, you need to be prepared.

Please note that some special symbols used in this eBook may not display properly on all eReader devices. If you have trouble determining any symbol, please call Wiley Product Technical Support at 800-762-2974. Outside of the United States, please call 317-572-3993. You can also contact Wiley Product Technical Support at www.wiley.com/techsupport.

Chapter 1: Future-Proof Survival Techniques

Tools for tomorrow’s Web

Web design projects contain four essential components. First, you must know your environment. Then you need to plan ahead, learn to adapt, and finish the process by resolving compatibility issues as they arise. Meeting these objectives is challenging, but the work is necessary if you are to successfully future-proof your site. This chapter describes each of these components and illustrates the importance of being flexible to change your way of thinking about your design methodology, now and in the future.

Understanding the Environment

When you design a site, understanding the environment where it will exist is critical. You need to know what factors increase or decrease the chances of your site being noticed, and you need to be familiar with the tools visitors will have at their disposal when interacting with your site. Understanding what makes up the Web’s current incarnation is important, as is learning what is and isn’t possible (or useful) when designing for it. Before you can access any of that information, however, a number of untruths need to be dispelled.

The truth behind terminology

Throughout the Web’s history, designers have become adept at assigning names to things, even if the names aren’t required or deserved. Names have been assigned to specific technologies, techniques, and events that occurred long ago, and abbreviations have been created that try to encompass entire technologies. Although some of these terms (for example, HTML and CSS) do a great job at identifying an important technology, an unfortunate slew of buzzwords has been forged, leading to confusion among designers.

Here are three of the biggest offenders:

> AJAX

> Web 1.0, Web 2.0, and Web 3.0

> the Mobile Web

Although forged from the technologies it employs, AJAX (asynchronous JavaScript and XML) didn’t need a shorthand name because developers were already employing these techniques in their work. The mechanism behind AJAX is a sound one, in that you can avoid page refreshes by pulling or pushing data from the server to a user’s device in the background, but as far as the stability of your site is concerned, the mechanism can be fraught with problems, such as the unavailability of scripting.

Ubiquitous and future-friendly layouts cannot be obtained by jumping onboard with every new technique or technology as it arrives (as AJAX shows). No matter how popular these buzzwords become, the name of the technique is never important; what matters is the problem that the technology aims to solve and whether it, in fact, solves it. A great example of this is the Web 1.0 to 3.0 movement. The terms themselves have little meaning except to try to “mark” the Web’s evolutionary progress. Yet, for all of its public appeal, it solves nothing.

What makes buzzwords extra confusing is that some of them have different connotations, so they can mean different things to different people or in different situations. Web 2.0, for example, isn’t just a defining era of the Web; it’s also a highly recognized design trend.

Terms like Web 2.0 have come to mean different things to different people, and often just stereotype sites as meeting a list of criteria that keeps them current. The trouble is that not all users will demand the same things and not all devices or browsers will be capable of reliably implementing the proposed features, which, as such terms imply, are critical to the evolution of the Web. In essence, not all sites require AJAX or collaboration features, and including them could damage a user’s experience on your site.

I’ve established that AJAX can be problem for certain users and that Web 2.0 doesn’t offer a firm solution to help create or maintain a stable and usable site, so the next step is to investigate what’s been dubbed the Mobile Web. This term appeared when the use of handheld, non-desktop, web-enabled devices increased, which put pressure on designers to make their sites mobile friendly. Unlike Web 2.0, this term makes some practical sense, but the trouble begins when you try to define what actually constitutes a “mobile” device, and trying to define mobile variables just creates more questions, including these:

> If mobile just equates to a small screen, aren’t laptops mobile?

> If mobile is about not being “desktop,” are 100-inch TVs mobile?

> If mobile is focused on the new wave of technology, what about PDAs?

> Perhaps mobile equates to data speed, so what about dialup users?

If your aim is to make a flexible and usable layout, all that matters is that users of such devices can take advantage of your site. To achieve this goal, avoid stereotyping users’ needs and situations and build real-world solutions that are flexible and durable enough to accommodate every environment, whether it’s a handheld device with a touch screen attached or a desktop computer with a large display, mouse, and keyboard.

Mythology and folklore in design

In the following sections, I confront a few common myths in web design. The information in these sections will help you look beyond the old one-size-fits-all environment and begin to understand the need for layouts that flex to your users’ demands. The critical thing to take away is that no silver bullets or shortcuts can ensure a stable site that’ll last into the future. Instead, future-proofing your site includes balancing the needs of users with the tools you can provide.

Myth #1: Layouts can be made to appear pixel-perfect

Web designers try to make the sites they design look and feel as consistent as possible in various environments, but the idea of being pixel-perfect is flawed. By making something pixel-perfect, I mean trying to enforce strict viewing guidelines akin to those in the print industry, thereby making everything look the same in every situation. Because so many variables play a role in a site’s rendering, situations will continue to exist where users experience some kind of limitation. Perhaps they’re missing speakers for sound, or they navigate using a dodgy browser. Not all experiences are created equal.

For older devices, pixel-perfect layouts were impossible from the outset. Desktops could handle feature-rich HTML and CSS layouts with plenty of complex interactive features, but traditional featurephones could handle only WML code devoid of the stylistic beauty and script-powered behavior that desktops were afforded for years.

The truth is, user experiences don’t have to be identical for your site to work. You may actually want to design so that user experiences differ among platforms and make your site more usable. You might offer separate, altered experiences based on the capabilities of the different devices. (Note that a unique WML layout was compelling for older handheld devices.) As long as your content remains visible and users are willing, within reason, to adapt their navigation techniques to interact with your site in a way that matches the requirements of their devices, you don’t need to worry about precision design.

Myth #2: Designs can be considered “complete”

I’m a big believer in continued improvement, and because standards and use of sites will always be changing, based in large part on users’ activities and preferences, sticking with one layout and declaring to the world “I’m finished” is . . . well, surely said in jest. Your goal as a designer is to make sure your site continues to gauge the interests of users, and although you don’t want to redesign a site every week, it makes sense to iterate and improve your services regularly (as shown in Figure 1-1). As technologies and best practices change, new methods to help your visitors will appear.

Figure 1-1: Iteration allows designers to continually improve their work.

The idea behind a completed site is that nothing can be done to make it better, which doesn’t add up. Improvements can always be made and new features can always be added. Also, be sure to maintain and update the content on your site to encourage visitors to return. If you own the site that you’re building, you can set it up so that iteration can occur naturally. When you’re building for clients, suggest that they establish maintenance schedules and frequently improve the content of their site.

Myth #3: A design can be totally bulletproof or future-proof

Although this book’s goal is to help you maintain stability in a layout and make your site as future-proof as possible, ultimately no design is immune from all that the Web can throw at it. When a site is said to be bulletproof, it means that the site won’t fall apart under any circumstance. That a site can be bulletproof is an idealistic and unattainable notion. When a site is said to be future-proof, the implication is that the site will work successfully forever, across new devices and emerging platforms, all while maintaining compatibility with previous browsers and devices. In this book, I do my best to help you head toward that goal, but as much as I’d like to guarantee that goal, I can’t, because the Web is far too unpredictable.

By considering the variables in this book, you can better address the concerns that designers of today’s sites deal with. Keep in mind that those variables will play an important role in the Web’s future landscape. But who knows what’s on the horizon? In ten years, the Web may change so drastically that designers will once again find themselves building sites in new, unconventional ways. Perhaps a whole new range of variables will exist. Ultimately, all you can do is use the information you have and make the most of it.

Myth #4: Validation ensures quality and compatibility

Many Web designers make the mistake of taking validation of code as a guarantee of standards, which is why you see so many of those “Valid” buttons embedded within so many sites (see Figure 1-2). However, as you probably already know, you can have some of the best-formed code and still see quirks and inconsistencies in how a site will render among browsers and devices. This isn’t to say that validation is useless because, for example, knowing how to spot bugs that could lead to quirks is important. They just aren’t a silver bullet for ensuring the stability of websites.

Figure 1-2: Validation buttons don’t guarantee the quality of code or impress average visitors.

Validation is a useful tool that can help identify common flaws and mistakes that designers make when coding. Including validation in your workflow is useful, but it’s just a tool. Don’t consider validation programs as an alternative to or replacement for testing your work properly, and don’t assume that all validation programs work equally well. Accessibility validators are notoriously bad at uncovering major failings in accessibility; manual testing is the only safe option.

Myth #5: The newer, the better — the more, the merrier

Designers often get carried away in their bid to be creative, and more importantly, they can be overly zealous about how much of a good thing their visitors will enjoy. In an effort to stay current, some designers revamp their sites regularly, when redesigning is clearly unnecessary; or they add too much information, media, or imagery to their pages thinking that substance in great quantity encourages more interaction. Of course, keeping your design and content updated is necessary; just be rational about when and how to do so.

Be sure to remove clutter from your interfaces. Often, pages become stagnant and bloated as a result of mismanagement or residual features such as animation effects that you think look great but offer no real benefit to users. Overuse of design or content is a common problem, so try to keep your designs tasteful.

Incorporating the latest and greatest features can be an improvement if your goal is to improve users’ experiences. If you use these features mainly to compensate for poor-quality content, you could create a real problem for visitors to your site. For each new redesign you create, just remember that your visitors’ learning curves will increase because they must readapt to the new interface. The same goes for bundling more features and content on a page. Simplicity is often better than complexity. Keep in mind that adding features and too many choices may be a burden for some visitors.

Myth #6: You profile the average user or device

Design is rarely an objective art form, and as much as designers want to base their decisions on the needs of users, designers’ personal biases and skewed perspectives can influence their work. For example, when designers think of a visitor, they often visualize an idealized visitor rather than one based on reality. Moreover, when designers try to profile the type of environment visitors will be using, those profiles may fail to take into account the differences between different users’ experiences. The idea that an “average” user (Figure 1-3) or browsing environment exists is unrealistic.

Figure 1-3: Designers often use personas to group variables together, forming a browsing scenario.

The differences among the environments where your site must function can be substantial — for example, whether Flash or JavaScript are supported. The differences among users are important, too. Some users may encounter accessibility issues, and others may simply be more selective in the features they’ve enabled. Designing for ubiquity requires looking beyond stereotypes; instead, you need to be open and adaptable in terms of your audience. Promote equality and be flexible with whatever your site needs to function. By doing so you’ll end up with a stable and usable layout.

Keeping up with the Joneses

Designing for next-generation devices poses a real challenge. After all, how can you be expected to design for something that doesn’t exist or, if it does exist, hasn’t gained widespread adoption? Consider how the Web works on cellphones and tablets. In a few years, the Web may work on all sorts of other unique devices, such as televisions. When you think about it, gadgets like the iPod Nano have the potential for web enablement, and it’s only the size of a wristwatch, so imagine how diverse web experiences may become!

Hardware is becoming less expensive to produce, and infrastructure for web connectivity is gaining adoption worldwide (even in hard-to-reach places like Mount Everest). This situation fosters the perfect environment for ubiquity because reduced cost and low-barrier entry encourages more people to go online using devices they have handy, be it in their homes, offices, or on the move. As the number and variety of devices used on the Web increases, you have two options: Patch as new devices appear, or be generic, yet flexible, regarding usage.

When a new device gains popularity, many designers immediately patch their sites to support it, target the device for a special independent site that caters to the platform, or just ignore it. These don’t seem like good options because they require you to choose what you will support and provide constant patches to the ever-growing technologies that arrive online. In some situations, but not all, a separate site might be helpful.

The debate over separate versus internal sites has been brewing for a while, leading to the idea of “One Web.” Some individuals believe this principle can achieve discrimination-free usability; others believe in the stricter definition of eliminating all proprietary, single-case solutions (which means demands ensuring that everything works for everyone). Check out Opera’s view of the “One Web” debate at this site: http://www.opera.com/business/oneweb/.

A better approach is to examine the symptoms, make a diagnosis, and find suitable solutions to treat the condition. It isn’t the brand or model that makes a device; the components make the device. The inside of an iPhone and the code it supports (such as HTML) differ significantly from what you find in a Nokia 6610i (which supports only WML, as shown in Figure 1-4). The issue boils down to two independently built renderers doing what they can.

Figure 1-4: When compared to today’s rich and engaging HTML and CSS, WML is a real ugly character.

Ultimately, the choice to keep up with the trends or retain support for only a select few of your audience’s situations is entirely up to you. It may be impractical to produce a site that is so flexible that it supports every type of product and situation without issue, and if you know what your audience requires, there’s no need to go over the top, covering all possible bases. However, unless you have a good reason to do otherwise, ensuring that your site caters to as many situations as you can eliminates the need to patch your site’s code in the future.

The browser wars proved that creating sites that depended on everything rendering in one way was problematic. Designers have since adopted more stringent measures for testing workflows. Currently, designers are struggling with the fact that devices and platforms force you to rethink how you present and organize content. In the future, perhaps your next tussle will be over dependency on frameworks, the continued support for deprecated code, or something else entirely. I do enjoy a good mystery—don’t you?

Planning for a Successful Website

Understanding the environment you’re designing for is critical when building a site, and knowing the needs of your audience is critical to a successful design. After all, recognizing potential situations beforehand allows you to make more informed, practical choices. With information about a user’s environment, you can avoid making potentially costly mistakes that could reduce a site’s usability, and by planning ahead, you can direct your attention to specific aspects of a design that may be more open to implementation quirks than others.

Determining project requirements

When developing for the Web, you must be able to determine the requirements and needs of a project. Often, for service providers, the demands of a project include the additional features, functionality, and layout choices that users may find helpful. For situations in which you produce work for clients, the ability to look beyond just the scope of a site and into the future needs of their businesses will help ensure that the design works for the specific audiences the clients are targeting. Because every site will be different, catering to niches is important.

The initial requirements that influence your tactics are those laid down by the users of the site. Happy visitors often result in customer loyalty, so, whenever you can, put users first. Ensuring that your users have access to sites and services regardless of the platform or device they use (which equals ubiquity) means that you can more easily get them to choose you over a competitor — and choice is a powerful motivator.

Here are some features that make for happy users:

> Consistency in a site’s design

> Accessible and easy-to-use layouts

> Aesthetically pleasing designs

> Goal-oriented, useful layouts

Remember, the benefits of a ubiquitous interface extend beyond what the user sees and the devices the user uses to access your site. The number of social networks, search engines, and third-party tools connecting to your site is increasing, and it’s likely that the more demanding and restrictive methods they use to view and utilize your content will become increasingly important. Just think about software like Instapaper or an RSS reader, and you’ll understand how your site can be interpreted by a machine, not a human being; any errors affecting it will certainly reflect in the output.

Here are some features that make for happy robots:

> Search engines may struggle with proprietary code.

> Social networks require meaningful, contextual data.

> Browsers demand well-formed code to render pages.

If you’re working for a client, you can’t just plan around the needs of your users and the specific devices they use or the automated solutions that exist; you must also plan around the business or client. Clients may have certain niche requirements — if they are making an intranet, for example — or perhaps they want the added usefulness of platform-explicit applications (such as those in Android’s marketplace or Apple’s App Store). These days, sites encompass many more options than they used to, and every site’s requirements will be different.

Consider the client-user scenario as an adaptation of the “three laws” from Isaac Asimov’s I, Robot. Sites cannot harm a user, must obey clients’ orders (unless it violates the first law), and must do the same for designers (unless it violates the previous two). With this idealistic balance, the designer’s priorities should be set.

The needs of a site depend on the factors described in this section. You’ll probably spend as much time researching what is needed on an interface as you do building it. In a designer’s ideal world, people would conform to stereotypes, devices would be standardized, and clients would jump for joy at the thought of accessibility. Unfortunately, you don’t live in an ideal world, and it’ll be many years before widespread compatibility and ubiquity will exist (if it comes to exist) because meeting expectations can be fraught with hurdles.Changing dogmas or perceptions takes time.

Setting goals while dodging holes

As the Web has evolved, designers have found themselves playing a superhero-like role, which you’ll understand if you’re a fan of fantasy and shows such as Buffy the Vampire Slayer. Buffy worked her way through demons, taking on increasingly dangerous and deadly foes (you can relate to this if you’ve coded for Internet Explorer 6), and ended up in a final showdown with the “big bad.” In the show, overcoming each challenge on the path to winning the war wasn’t a matter of luck or charging in blindly; it involved careful planning and research.

Because each user and situation is different depending on the type of site being built, you must carefully consider any implementation that enhances or degrades a user’s experience. You need to establish primary goals to ensure that decisions are made for the right reasons. Perhaps your site will require visitors to enter some log-in details, but remember that input mechanisms can vary among web devices. Maybe a visitor will browse while on the move. These kinds of situations can trigger and affect the many variables you must consider.

The following situations affect specific factors or variables:

> HD video is affected by bandwidth and connection speeds.

> Color is eliminated if a visitor has a monochrome display.

> Mouse precision and accuracy are affected by click regions.

During the brainstorming stage, establishing where and how a site might be used is a great idea. Sites that compare prices of products are likely to be in heavy demand while visitors are on the move — for example, traveling on primary business streets and in shopping malls. The use of sites like the Internet Movie Database require specific consideration because they may be used in collaboration with cinemas, rental shops, and media retailers. Creating scenarios or profiles of these actions help you gauge targeted markets, although, of course, users browse in other kinds of situations, too.

The trick is to determine which influences and variables will affect your users; what those effects will be; how you can ensure that the interface will cater to your specific audience without negatively affecting others; and how to implement required changes in the most suitable way. Making these determinations requires a fundamental understanding of how human-computer interactions work and of the subtleties of users’ devices. For example, a smartphone may be subjected to data caps and roaming charges, and an old desktop computer may have a slow or low-quality connection (see Figure 1-5). Goals must always be identified within the context of acceptable methods of interaction.

Figure 1-5: Certain situations may require you to consider how data-heavy your sites and pages are.

Dodging some of the major pitfalls in design can be tricky, especially if you’ve become comfortable that what you have “works.” Ultimately, for any plan involving the longevity of a site, you need to observe changes in patterns of use, determine methods for improvement, and identify potential causes of concern. However, keep in mind that because the Web is constantly evolving, new standards will make providing flexibility increasingly convenient (as is the case with CSS media queries), and, as a result, your solutions can be better implemented.

Planning for implementation

Planning for the implementation of a ubiquitous site can be challenging. All too often, you’ll find yourself asking a variety of questions about your audience that have, in turn, a variety of answers. For example, what screen resolutions do they use? What browsers do they use? Do they visit the site on cellphones? Does your site please or somehow irritate them? You have many design and development tools available, and with tweaks, they’ll aid your ubiquity goals.

Planning ahead makes building a successful site more feasible. When envisioning your site, plan for code and a design that are well formed and as uncomplicated as possible. Set clear objectives and be willing to compromise for the sake of your users. While planning, identify where you can make implementations more accessible to and useful for your site’s users, as well as related variables they will interact with. Remember to set realistic goals; otherwise, your site may fail users in some way.

Treating how users will access and use your site as an afterthought is very risky. Every site relies on content and functionality; nevertheless, the basic design of the layout should always make users the top priority.

Ideally, the process of determining site-specific goals begins with competitor analysis and user testing. Next, you use wireframes, prototypes, mockups, concept sketches, and other tools to discover the specific needs of the project. If you think users may want something, don’t shy away from considering it. Planning can become second nature, once you get into the swing of things. Moreover, if you determine the needs of clients or of visitors to a site, you can implement suitable outcomes, right from the start. At its heart, web design involves inspiration, iteration, formulation, and publication (see Figure 1-6).

Figure 1-6: Inspiration, iteration, formulation, and publication are critical elements of web design.

Consider the issue of whether to offer a secondary mobile-oriented site. If you provide a separate site for visitors who are using less-capable devices, those visitors might avoid optimized environments entirely. Therefore, it’s important to give them the option of returning to the “full site” (if, for example, the optimized version is slimmed down, offering users less content). Remember, having choices empowers users.

When you empower users, you give them a sense of control, enabling them to feel as though they aren’t just at the mercy of a site’s demands. Perhaps you deem CSS or JS a necessity. That would be fine if it couldn’t be turned off, disabled, or unavailable. The best approach is to plan for the worst and hope for the best. If you make your content available to even the weakest link in the chain and, at the same time, enhance the experiences in more unique situations, you’ll ensure the maximum visibility of your content.

Learning to Adapt or Evolve

You know what’s going on, and you have a clever plan to provide a service that will be the envy of your competitors. Fantastic! Next on the agenda is deciding how to adapt your best-laid plans to particular environments. If you get dropped into a jungle, you don’t act like you landed in Siberia. Likewise, online, you’ll need a box of tricks to cope with the many different requirements a site may throw at you. Every site is different, as is its audience. Your job is to be prepared to find the answers to the difficult questions that environments can present.

Taking advantage of new technologies

Although you don’t want to use every new technology just for the sake of keeping up appearances, you also don’t want to let your concern over compatibility get the better of you. In an effort to appease the “old ones” (for example, Internet Explorer 6), many web designers have failed to take advantage of CSS3 (for example) purely because it creates inconsistencies with a browser’s older counterpart. Although I’m all for compatibility, as I said earlier in this chapter, trying to be pixel-perfect is neither worth the effort nor possible.

Compatibility should always be possible because of the following:

> If everything is disabled, content is the one thing that remains visible.

> Many technologies, when unsupported, can have an appropriate alternative.

> Targeting specific variables allows you to offer independent fallbacks.

Going beyond the bare necessities with your code is, of course, entirely possible. If you want to provide a particular piece of functionality, make sure you have a fallback (alternative) for users who are less fortunate. Such functionality can work against making a site ubiquitous, but that will occur only if you fail to update the site as new and better solutions arise. Ideally, rather than restrict yourself to a limited layout, train code around issues as they appear (see Figure 1-7).

As a web designer, you have a responsibility to your clients and customers. Failings on your site raise the risk of losing visitors, even if the failings are just small, but annoying, quirks. Knowing how to write code for a site helps you understand in advance where experiences can falter, provided that you take steps to ensure that your work flows and responds appropriately to user interaction and the environment in which it’s consumed. If you ignore the signs, however, issues are likely to occur and reoccur.

Figure 1-7: There’s no shame in providing Internet Explorer 6 users with a very usable and satisfying experience.

As the use of tablets increased in popularity, web designers on the cutting edge began to investigate how this unique input method could affect interactions on sites. At first, it seemed strange that people might not be using a mouse or keyboard. Continued study is the best route to understanding any device or design variable.

You want to make your site as unique and easy to use as possible—and give users a memorable experience (don’t go over the top). Designers have come to look fondly on trends (see Figure 1-8), conventions, and patterns for this very reason. Part of adaptation is moving with the times, working with your surroundings, and recognizing when views of how the Web should operate alter over the years. Maintaining a high level of awareness and staying ahead of the curve makes sense.

Figure 1-8: Following trends isn’t a bad thing, especially because they’re usually based on established solutions.

Sometimes cutting edge or bleeding edge is used in reference to designers or developers who use tools that aren’t yet supported by the mainstream. Although both the cutting and bleeding edge may appear as unsuitable candidates for crafting a stable site, using one or a mixture of both can be done in such a way that those who have access to the supporting tools benefit and those who don’t have access have something just as fitting to use in its place.

If your competitors are going to provide support for a tool, and you look around to find that you could be the last person standing in the traditional-techniques circle, it may be time to investigate whether moving on can benefit your audience. Often, new technologies provide designers with appealing solutions that otherwise wouldn’t be possible (for example, CSS sprite rollover menus). Many designers keep an eye on sites that use cutting- edge work, looking for inspiration and creative ways to polish their own skills.

Adapting your site to account for the many existing variables gives you insight into the habits of users and how they embrace technology, and it gives you the opportunity to offer them more user-centered designs. You will see an increase in the use of small screens and the removal of the barriers of fixed-width design. Also, you’ll see how reducing the requirement for inputting text helps users without quick access to a normal keyboard. Creating future-proof sites is about molding platforms around experiences that can benefit every user.

Solutions for a successful layout

This section covers techniques for producing first-rate, scalable layouts. Before you can understand design variables in their entirety, you must first be conversant with the methods designers use to make layouts as flexible and future-proof as possible. This information includes making decisions about which methods you will use, why using a particular technique will benefit your audience, and which of the many layout techniques will sustain the highest levels of ubiquity.

Consideration #1: Need versus none

At first glance, it may appear a bit silly to ask, “Do I really need a flexible site?” For the purpose of this discussion, the aim isn’t to question whether having a flexible site is a good thing, because clearly it is. Also, if you design flexible layouts from the outset, you will reduce the chances that users will face problems with your site later on. However, understanding the needs of your audience can tell you a lot about their specific requirements or about non-issues that may influence decisions to build or postpone the implementation (see Figure 1-9).

Figure 1-9: If a site primarily attracts users of desktop browsers, you could postpone the flexible upgrade.

If you were to produce a site purely for consumers of Apple products, you would probably question the need for a stress-testing spree to try out the site with as many emulators, browsers, and devices as possible. On the other hand, making your site as flexible as possible is important, but there isn’t really much point in spending the next year and three months scaling your site to be in line with every potential variable. Let your users and their needs determine the level of flexibility and whether you can afford to cut corners.

Consideration #2: Rigid versus fluid

You can lay out content in different ways. In one camp, you have the grounded, rigid units of measurement that can cause unpleasant horizontal scrolling when the available space doesn’t match the demands of the interface (think fixed designs using pixel widths). In the other camp, you have fluid designs that are pleasing, until there’s too much or too little assigned space (causing occasional spillages or overflow from scrolling). In both cases, entire layouts can break if the equations don’t add up.

An article I have written shows how the formats of layouts are changing. Not too long ago, you had only fixed, fluid, and elastic to contend with. Today, you have no less than ten choices! They range from units aimed at print or default preferences to complex mathematically instigated alternatives. For details on how each could affect a design’s flexibility, visit this site: http://sixrevisions.com/web_design/a-guide-on-layout-types-in-web-design.

You can choose units of measurement based on compatibility (units aren’t treated equally online), on a design method (such as responsive design), and even on a hybrid of one or more techniques. Making the right decision about the mechanism of layouts can play a critical role in how variables interact with a layout and, more importantly, how a page will respond when under stress. You want to base such needs primarily on the requirements of the content and then on the space required for functionality on the web page.

Consideration #3: Dynamic versus static

Dynamic and static layouts also play a part in the construction of sites. Static designs are those with little to no interaction, are comprised entirely of text or images, and are more focused on a read-only approach. Dynamic designs, on the other hand, usually include scripts, changeable content, features, and perhaps some clever code in order to boost the site’s core flexibility (as shown in Figure 1-10). Both of these design types have advantages and disadvantages, and both affect a layout’s core stability.

Figure 1-10: You may be able to improve the flexibility of dynamic sites by structuring them around visitors’ preferences.

Static sites have little going on under the hood. What you see is really what you get. The benefits of this traditional form of layout are that once you’ve ensured the content scales appropriately, little else beyond the visual arrangement can go wrong. With dynamic sites, you may find that if scripting becomes unavailable or interaction requires additional user involvement, trouble can occur. However, even with such concerns, dynamic sites can offer a greater level of individually oriented flexibility than static sites can, so the payoff might be worth the effort.

Consideration #4: Internal versus external

This consideration relates to how to handle alternative device requirements. Sometimes, designers choose a “one site rules all” approach and account for variables by using scripts or stylistic fallbacks. Tools such as browser-detection scripts, frameworks, and media queries allow the layout’s appearance to change based on a user’s needs. Although this is the best choice (requiring little added maintenance), the major catch is that it forces you to rethink a site’s mechanics, based on assumed scenarios of use. Figure 1-11 illustrates the concept of a script working as a robot to “build” a site around you.

Figure 1-11: Scripts act like little robots, reporting on what will or won’t work.

If the work of designing for the lowest common denominator isn’t your cup of tea, a quick-and-dirty solution is to provide an external site that does the job, similar to what you may have seen in mobile-specific sites. In these optimized layouts, however, you’ll often find that content is either “dumbed down” to reduce the pressure of the layout or condensed to make things more lightweight. These layouts, however, beg the question, “If it’s not needed on a mobile site, why would you want it on the desktop?”

Consideration #5: Redesign versus realign

If you choose to accommodate various browsing environments, such as the use of specific devices or products by creating separate layouts, you must determine whether to build a new layout entirely from scratch or to realign an existing site’s design (if one exists) to consider the more diverse uses being asked of it. Ultimately, situations will exist when a new and separate layout may be beneficial (perhaps for a mobile-only service that’s not available for desktops), but in the vast majority of cases, keeping sites together requires less work.

Calculating whether to redesign or realign may be easy, depending on the state of the site in question. For example, if the layout is falling apart, cannot match the needs of the content, or is simply unattractive, redesign it! After all, revitalizing the layout can’t make it look, work, or feel any worse to your visitors than it does in the state it’s in now, right?