Tag: Ethan Marcotte

How are Beatles albums like mobile-first web design?

When I’m meeting with clients and collaborators to discuss building websites, I like to make analogies. As the representative “tech geek” in most of these meetings, I find them the best way to convey the meaning of esoteric technical concepts, even if they’re sometimes rather strained. (I make car analogies a lot, for some reason.)

The other day I was explaining my two favorite (and overlapping) current trends in web design: Responsive Web Design and Mobile First. (How convenient that A Book Apart has books on both topics. I mention A Book Apart a lot in meetings, too.)

Suddenly in the meeting it occurred to me that mobile-first web design has an analogy with the production of most of the Beatles’ albums. In the early and mid-1960s, popular music was released primarily in mono format. Most of the market for these albums was listening to them on small mono turntables, not expensive stereo equipment. (And apparently at the time mono equipment could not properly play back stereo records.)

When the time would come for the Beatles to prepare the final mixes of their albums, the band members would join George Martin in the studio and carefully perfect the mono mixes. Then the boys would all head to the pub and leave George Martin alone to hastily assemble the stereo mixes as an afterthought. (And, frankly, it shows.) But somewhere along the way (in 1968, specifically) stereo had caught on enough that the last few albums (Yellow Submarine, Abbey Road and Let It Be) were mixed in stereo first.

The web is kind of like those Beatles albums. Up until now, websites were designed for “mono”: a computer screen. Eventually enough people started using the web “in stereo” (on mobile devices) that mobile versions of websites became necessary, but they were a hasty afterthought. But we are presently arriving at a time when a lot of people are doing a lot, if not most, of their web browsing on mobile devices, of a variety of shapes and sizes and capabilities. It’s starting to make sense not just to consider mobile versions, but to start with the mobile design.

Fortunately, we’re also at the point (to, as usual, strain the analogy) where the mono equipment can play back stereo records. There’s no need to design two separate websites, one for mobile and one for desktop. Responsive web design (via the magic of CSS3 media queries) lets us build one site that works on any screen.

But why mobile first? I see two main benefits, stemming from one main factor: the small screen size. By targeting the smallest screens first, you 1) focus on what’s most important, and 2) can more easily see what’s not important… or, at least, less important.

Mobile first fits well with the model of best-practices web design I like to promote. The decisions you make to create the best mobile experience will generally create the best experience, period. Granted, the needs of a visitor on their way to your office and checking your site on their smartphone may well differ from those of the visitor casually browsing your site on their iPad in bed, or from the customer placing an order from their office PC, but it’s easy enough to enhance the experience for users of those larger displays after the core needs of the mobile user have been addressed.

It’s an exciting time to be a web designer. Things are really starting to… come together.

(Come on, you knew I had to end with a Beatles reference.)

Responsive Web Design: On embracing the web’s uncertainty principle

What do Werner Heisenberg and Ethan Marcotte have in common? First and foremost is probably that I have just mentioned them in the same sentence. Second, whereas Heisenberg’s uncertainty principle paved the way for quantum physics (which revealed that matter and energy can exist as both a particle and a wave), Ethan Marcotte’s Responsive Web Design promises to usher in a new era where we discover that desktop and mobile websites, too, can be one and the same.

My analogy may be stretching thin, but the point remains that we are entering a new phase in web design. We can no longer assume websites are being viewed on a desktop computer screen of certain minimum dimensions. We also can no longer justify building and maintaining two (or more) discrete sites, shunting mobile users off to a scaled-back, limited experience while allowing desktop users access to the full version. And all of this means that we must consider the dynamic (and, in fact, increasingly so) nature of the web as a medium from the earliest steps in the design process.

Many examples of Responsive Web Design are beginning to crop up (including this site), but the best high-profile example so far is a site Marcotte himself consulted on: the new BostonGlobe.com. I’m hopeful that soon this design approach will become the norm for most websites.

But the challenges facing those of us who are ready to embrace Responsive Web Design are many. Getting a handle on the use of CSS3 media queries is the first and probably easiest of these, if you’re comfortable with code. Most of the leading innovators in web design have long worked directly in code — and knowing and working directly with HTML5 and CSS3 is pretty much a requirement for effective use of the Responsive Web Design approach.

But I would guess that the majority of web design going on today is still being done the “old fashioned” way. A graphic designer, usually with experience primarily in print, puts together a layout in one of Adobe’s creaky monolithic Creative Suite applications (Photoshop, Illustrator, InDesign), then (if we’re lucky) hands off that design file to a developer to build out as HTML. If the developer is with it, they will follow best practices and web standards, building out semantic HTML document structures with design properties defined in CSS. (No tables, please.)

There are many potential points of failure in this arrangement, because a design in an Adobe application bears little resemblance “under the hood” to an HTML/CSS layout in a web browser. It’s not just that the canvas you’re painting on is different, although there’s that. It’s that they’re not even both canvases. No matter how much Adobe tries to ease the transition for print designers, any process that forces you to start by specifying page dimensions just isn’t going to translate effectively to the nebulous, dynamic format of a website.

“Design in the browser” is the new mantra. And again, that’s great if the person designing knows how to do that. But many designers don’t, and it’s not necessarily fair to expect them to. The entire process needs to change. Developers and designers need to work together more collaboratively, and earlier on in the project. For years I’ve been promoting the importance of designers understanding HTML/CSS and the capabilities (and limitations) of web browsers, even if they don’t necessarily write the code themselves. It’s not just about knowing what certain browsers can or can’t do (like the fact that Internet Explorer didn’t support layered backgrounds until version 9). It’s about knowing all of the things browsers can do that can’t possibly be replicated or even represented in a static design built in an Adobe CS app.

There are so many aspects of this that have always been important (how best to slice up a design; what’s background/foreground; what should be images and what shouldn’t; when to use JPEG vs. PNG; optimal page widths; where the “fold” is and whether or not it exists even as a concept; the fluid nature of vertical elements; how users interact with elements and how the page gives feedback using JavaScript and/or CSS; etc.), but now on top of all of these concerns we have the additional complexity — and opportunity — of working with different classes of devices with radically different screen sizes, capabilities, and interaction methods.

Again, “design in the browser” is the ideal. But until we get there, it’s essential that graphic designers who aspire to work with the web take the time to really understand the medium: how it works, how varied it can be, how quickly it changes. Then, even if the designs are, for now, still delivered in an Adobe format, their structure and content will at least be better informed by the practical realities of the form they will finally take in a web browser.

So, as a designer, what’s the best way to get informed? Working with a developer who understands and is enthusiastic about Responsive Web Design is a great option (hint, hint), but at the very least I recommend reading Ethan Marcotte’s book. In fact, the entire A Book Apart series is essential reading for anyone who wants to build forward-looking websites. The future is coming. We may not know what it will look like yet, but it’s a safe bet that tools and techniques that were already antiquated a decade ago are not the way to get there.

I don’t want to end on a down note, so I’ll pose this final challenge to inspire and motivate any designers who might be reading this. Despite the potentially intimidating appearance of code, web standards are first and foremost about simplicity. The dynamic duo of HTML5 and CSS3 are a world apart from the hairy mess of table layouts and <font> tags that dominated the early web. Watching a design take shape directly in the web browser can even be fun! And with the powerful interactive capabilities of JavaScript tools like jQuery, and the typographic world that has been opened up recently with font embedding services like Typekit and Google Web Fonts, there’s never been a better time to be a web designer. The more you know about what goes into realizing your designs in a web browser, the better you will be at your job and the more opportunities you will have.

Yes, it’s… yet another redesign

I’ve redesigned this blog more times than I can count. Many of those redesigns have been incremental tweaks, to be sure, but still, there’ve been probably dozens of times that I’ve completely torn it down and rebuilt it, more-or-less from scratch. This is one of those times.

I’ve also (finally) wised up a bit. Usually when I post these redesign announcements, I don’t include a screenshot… as if this is the last time I’ll ever redesign the site. I wish I could go back to some of those earlier posts and see what the site actually looked like when I announced the changes. I can remember most of them, even from the pointless ramblings I composed to commemorate their creation. But it would still be nice to see them on the outside of my brain.

There are some big changes in this version. Most significantly, I’m using two (relatively) new technologies as both key components of the underlying structure and also as inspiration for the design itself. They’re created (or at least inspired) by some amazingly talented people in this field, so they deserve recognition.

First, the fonts are being delivered by Typekit. Finally, web designers have more fonts at their disposal than Arial, Georgia and Verdana. (Yes, there are some others, but these three are the most excessively used.) There are some awesome people behind Typekit, but I especially want to call out founder Jeffrey Veen and creative director (and probably the best web designer on the planet) Jason Santa Maria.

Next up, we have a responsive web design using CSS3 media queries. (Yes, that’s probably the most boring possible link about one of the coolest technologies out there right now in web design.) I think we have Ethan Marcotte to thank for devising this brilliant use of CSS3 media queries to dynamically adapt web page layouts to the size of the browser window. At the very least, he named it and helped spread the word with the aforelinked A List Apart article and his new book.

In short, by employing CSS3 media queries to adjust the page layout to an appropriate width and number of columns (and smartly resizing elements within), it’s possible to easily adapt a web page’s presentation to suit the capabilities and dimensions of a number of screens. Just take a look at this site on your 27-inch iMac and then on your iPhone (or your roughly equivalent non-Apple devices) to see what I mean. I’m sure I’m not doing Ethan’s work justice, either in my description or in my application of it here, but I’m excited about the potential regardless.

It’s a great time to be a web designer!

Update: I went for less than 48 hours with Futura PT Light as my primary font for body text here, despite knowing it was too light and, perhaps, too geometric for good body type. Finally, at a friend’s prodding, I resorted to the inevitable: Proxima Nova. I love Proxima Nova. It’s the primary font I use in all of my business materials (and in my logo itself). I had envisioned a kind of ’50s retro school textbook concept with this site redesign, and Proxima Nova, a 21st century font, doesn’t fit that description, but… man, it just looks so good. So, now it’s here.