CHAPTER 3 The Vanilla Web Diet
For example, I skim and triage my news feeds on my phone and book-
mark to read later. When I get to my laptop, I read in detail what I book-
marked and share it with the world. Yet, I have to use more or less the same
interface on both devices and I’d love to have a simpler one on the phone,
tailored to my need to triage, and one that makes sharing easier on the
laptop.
With new ways of interacting with our content being devised all the
time — gestures, touch, glasses, buttons in the steering wheels of cars —
we need to be ready to build bespoke experiences quickly and with ease.
We cannot do that if we try to discover the holy grail of one design that
works everywhere, or start with a framework that promises us that. It
doesn’t exist, unless you stay incredibly simple and leave untouched a lot
of the opportunities modern browsers and hardware offer.
We need to let go and leave some decisions to our users. Look at eBook
readers. I love how Google Play Books changes from landscape to portrait,
and how the Kindle allows me to change from black on white to gray on
black when I want to read in the dark. Let’s think about what our users do
in different contexts, rather than throwing the kitchen sink at them and
hoping that hiding parts of it is enough. We’re not doing enough right
now, which is why mobile browsers have “Reader” modes or allow users to
force a “Desktop version” on to their small screen as the mobile interface is
disappointing and frustrating.loaD onlY whaT iS neeDeD
Why should a browser get a library or a data file if it cannot do anything with it?
One of the most exciting techniques we discovered in the wake of the
DHTML days and now powered by AJAX is that of lazy loading. In essence,
this means that we only load resources when we need them. Why should a
user on a small device get a massive image that can never be displayed in a
satisfying way? Why would you include a JavaScript library targeted at iOS
on an Android device or even the desktop?