Datasheet

CHAPTER ONE FUTUREPROOF SURVIVAL TECHNIQUES
33
In the past, bugs in browsers have caused a number of problems for designers. However,
because of the limited array of devices and circumstances in which sites were regularly
viewed, issues related to a damaged experience had a minimal impact (you could  x a
problem by throwing hacks at it, often resolving early browser bugs). So, the problems of
maintaining a stable and ubiquitous site have always existed; it’s just that the method of
interaction and content absorption has dramatically changed in the visitors favor.
Many site issues could be labeled as critical (severe), moderate, and mild, but I’m not one
to place labels on quirks because what may appear as an inconsequential error to one indi-
vidual may well be a catastrophic, game-changing bug for another! An essential part of
designing your sites to be durable on many di erent devices (and within many di erent
situations) is that you really focus on identifying  aws and solving them. Often, designers
get so caught up in the debate about best practices and ideals that they may lose sight of
the bigger picture.
When a problem occurs, don’t conclude that you must attack it in a “nuclear-warhead”
fashion. Actually, its rare for a site to be in such a poor state that users’ online experi-
ences become totally inaccessible. Often, the quirks and issues are mild enough to simply
cause irritation or confusion. On the other hand, don’t put o implementing a  exible
design just because it seems trivial to you, even if the  x for that quirk could have a simi-
lar e ect!
You can debug code in many di erent ways. You have concurrent debugging that e ec-
tively involves checking and retesting your work as you progress through a series of stages.
ere’s elimination debugging, where you  nd a problem and begin crippling bits of code
in order to eliminate potential causes from the list (what Sherlock Homes would do if he
were a programmer). Finally, theres proactive testing in which you uncover quirks or issues
(plus the e ectiveness of  xes) by getting users to report faults (Figure 1-14).
Figure 1-14: Proactive testing can consist of structured usability studies or simple veri cation tests.
04_9781119978770-ch01.indd 3304_9781119978770-ch01.indd 33 10/25/11 1:08 PM10/25/11 1:08 PM