If you’re interested in where the web is headed, you have to look to its past. With Jeremy Keith’s new book, Resilient Web Design, the veteran designer digs into the web’s humble beginnings and the lessons it has taught.
While those lessons are indeed fascinating in their own light, Keith shows us how they’ve led us to a new way to approach web design. The journey wasn’t always easy (there were those of us who were a little slow to adapt – counting yours truly) but, as the book shows, it’s clearly been worthwhile.
Jeremy was kind of enough to chat with us about his design background, his affection for web history and how we can utilize the concept of Progressive Enhancement in our work.
Q: Please do tell us about your background in web design. Are there any particular areas you specialize in?
Jeremy Keith: I made my first website back in 1996, I think. Or maybe it was 1997. I can’t recall exactly. I was living in southern Germany at the time, selling bread in a bakery by day and playing in a band on the side. We decided the band should have a website, and I said I’d have a go at that. I ended up really enjoying it, and I was hooked.
Then people in other bands asked me to make websites for them too. So, early on I guess I specialised in band websites. Then I started freelancing, and moved to Brighton in 2000. From then on I did a bit of everything so I wouldn’t say I’ve got any particular specialisation these days. At Clearleft we work with all kinds of clients on all sorts of projects.
Q: In the book, you really dig into the history of web design. Could you tell us a little bit about the research you conducted and what, if anything, that may have surprised you?
JK: I’m such a sucker for the history of the web, the internet, and computing in general. I didn’t do too much specific research for this book, but for years I’ve been linking to interesting web history stuff, and reading books on the topic.
“Weaving The Web” by Tim Berners-Lee is an obvious touchstone. “Where Wizards Stay Up Late” by Katie Hefner is a wonderful book on the origins of the ARPANET and Internet.
Brian Kardell has written a series of posts on his blog called A Brief(ish) History of the Web Universe—I love those.
There’s also a web history community group at the W3C. It’s a very low-traffic list, but it occasionally brings up some real gems.
In terms of surprises along the way, I definitely had a “huh!” moment when I first went to CERN. I knew I’d be blown away by all the science going on (and I was), and I knew I’d be blown away by being at the birthplace of the web (and I was), but I wasn’t expecting to be blown away by the *way* work gets done there. There’s almost no hierarchy! It feels like one big hack day …but a hack day on the fundamental questions of science.
Q: One of the more fun aspects of the book is your retelling of the old HTML hacks (single pixel images, table-based layouts, etc.), the original browser wars and our clinging to fixed-width layouts.
Do you feel that time period was a necessary step in getting to where we are today in terms of how we build websites?
JK: Oh, yes! Spacer gifs and table layouts were hacks, but they were necessary hacks. The alternative was to have no decent graphic design on the web at all. Designers couldn’t be expected to just sit and wait for standards to come along.
That said, once we do finally get a standardised solution, that’s when it’s time to put the hacks away. I think we’re going to see this pattern repeat as we move to HTTP2. Concatenation, sprites, and other performance tricks that work great today will become anti-patterns in the future.
Q: The practice of Progressive Enhancement, along with people’s misconceptions of it, are something you discussed quite a bit. You allude to the fact that some designers (I include myself in this) are creatures of habit and not always open to change their processes.
In your opinion, how does using Progressive Enhancement change the way a designer approaches building a site?
JK: Progressive enhancement is pretty much entirely about *approaching* the practice of web design and development. That’s both a blessing and a curse. On the one hand, it means it can be applied to almost everything, from a simple component to an entire website. But, on the other hand, because it isn’t about a specific technology, there aren’t really any progressive enhancement tools.
That can seem like a real shame; that you can’t just download and install some software to get up and running with progressive enhancement. But on a longer timescale, it’s good news. Software comes and goes. Tools come and go. But a way of approaching your work can last a lifetime. That’s quite powerful.
Q: One of the challenges of being a web designer seems to be learning to adapt as things change.
What advice would you give to designers, both new and experienced, with regards to keeping up with these ever-evolving techniques?
JK: I think it can be useful to distinguish between the different timescales that tools and techniques operate at. For instance, when it comes to design, principles of contrast, colour, and whitespace are close to timeless. But trends with textures and type treatments can literally change by the season. That’s okay …as long as you’re aware of those different timescales.
Likewise, some approaches to web development—ways of structuring code; employing progressive enhancement—those can last for the long haul. But build-tools, frameworks, and libraries can change all the time.
I guess the pattern here is that broad principles and approaches can be long-lasting, whereas specific implementations and tools come and go. With that in mind, you can devote your energies accordingly—building up some long-term muscles, while at the same time checking out the latest hot new dev tool, knowing that it won’t be around forever.
Q: You mention the use of Photoshop, and how it’s not necessarily the best tool for creating mockups.
What tools do you prefer to use for layout and then building out a site?
JK: I didn’t mean to pick on Photoshop specifically. After all, it was never actually intended for mocking up web pages.
Rather than asking what the best tool is for creating a mock-up, I think the first question to ask is who the mock-up is for. If you’re designing for sign-off, then you want to make the mock-up as beautiful as possible and Photoshop will work just fine. But if you’re designing for handover to development, then that’s a completely different audience. Maybe a tool like Sketch is better. Of course, what tends to happen is that a mock-up created for one purpose (sign off) ends up getting reused for a different purpose (handover for development). That leads to frustration all around.
There’s a third reason to create a mock-up: when you trying to get ideas out of your head. In that situation—where nobody else might ever need to see the results—use whatever tool you like.
Personally, I’m a big fan of paper and pen—its cheapness allows you to get ideas down nice and quickly. Then when you need more fidelity, you can move into a graphic design tool like Photoshop or Sketch, but I think there are diminishing returns on staying too long in that phase. Getting designs into web browsers and in front of people is the only way to really tell how well a design is working.
Q: Do you have any future plans to write a follow-up to Resilient Web Design? What’s next for you?
JK: When people talk about writing a book, what they’re usually saying is “I’d really like to have written a book”, not “I’d really like to go through the process of writing.” It took me a year and a half of mostly procrastinating to get Resilient Web Design written (and that’s a really short book), so I don’t think there’ll be a follow-up any time soon. That said, I’m very pleased with the end result so while I may not have enjoyed doing the writing, I very much enjoy having written.
- How the Web Kept the World Moving in 2020
- 2020 Web Design Year in Review
- 50 Free Responsive HTML5 Web Templates for 2021
- The Grumpy Designer Looks Ahead to 2021
- Our 50 Favorite Web-Based Tools for Web Designers from 2020
- 10 Free Resources to Help You Learn Git
- Avoiding ‘Wasteful’ CSS in Your Projects