MaKey MaKey is an invention kit for the 21st century. Turn everyday objects into touchpads and combine them with the internet. It’s a simple Invention Kit for Beginners and Experts doing art, engineering, and everything in-between.

I love the spirit behind this. As the father of a 15 month old, I can imagine that this will amount to infinite hours of creative invention for me him in the future.

I was sure the pixel-dense screen would take the websites we’ve built and peel back their layer of pretty, revealing something less than perfect (like HD cameras did to sitcom actors). Was this layer we’ve so painstakingly designed, sliced, exported, and built stylesheets around really so thin? Just before the screen lit up, I realized this was nothing new. For the first time, I saw the Internet for  what it really is—a tall, lanky junior high kid who is pissed at the world because he just got done being a short, fat grade schooler.  It’s never just right. Rather than grow proportionally and gradually,  it hits terribly awkward spurts that throw everything off balance.

So, how will the retina change the shape of the web, and do we need to rush to update everything we’ve ever built? Of course not, part of building for the web is accepting that everything is in a constant state of flux—there isn’t enough time and money in the world to “fix” the internet every time a company releases a new technology. Instead, we cling to sensibility by seeking a middle ground and building things with the future in mind. Here are a few specific things I’ll do (or continue to do) as screen resolutions evolve:

Rely on web type & CSS.

We’ve always wanted better rendering for web fonts, and seeing type on a pixel-dense screen for the first time is mind-blowing. It’s also a validation that our commitment to making great type happen on the web without image replacement has paid off. Retina exposes those places where images are used rather than HTML text or CSS. Next to the ultra-crisp text that CSS + HTML render on retina, those fuzzy spots around image buttons and letters tend to stand out. For comparison, here’s a retina iPad screenshot of a button exported as an image, then rendered with web type and CSS (minus the dot texture):

I recently wrote that seeing how blurry the sprite icons on this site looked next to retina text pushed me to get to know font icons better. The advantages are numerous, namely how easily scalable they are and how quickly we can re-color or transition them with CSS. Using font icons whenever possible seems like a low-risk investment. Especially when implemented with care.

Images shouldn’t all be doubled in size...

unless, perhaps, you’re serving images as amazing as NASA. It might make sense to use media queries to target pixel density for handling things like background images in CSS, or even look to Retina.js to serve larger images to high-resolution displays, but should we always do it? As designers who’ve learned that every millisecond counts for load times, we can’t assume that just because someone is browsing from a retina device, they want to download 2x the image assets. Alongside that, there are a lot of smart people working on responsive images, and perhaps the picture element will prove to be the most sensible method, at least for inline images.

Of course this is subjective, but I’d say that for the most part, even 72dpi images (photographs, textures, and illustrations) look better on a retina display. Now that we’ve been using fluid-images and CSS background-size for responsive sites, when those images display even a little smaller than actual size, those smushed together pixels actually continue to shine through on retina. So, perhaps it doesn’t always have to be about serving uniquely-sized images to each device. In many cases, I think loading images that are just a bit better will go a long way. Make images a few percentage points (not 2x) larger, then optimize the hell out of them.

A pixel is still a pixel.

At least it is as far as I can tell. I’m sure I’m not alone in saying I’m scared when I think about how pixel densities across multiple devices will impact web design, but I have to say that everything I’ve seen thus far puts me at ease. Right now I am staring at a 1 pixel line drawn with CSS on a retina iPad and an iPad with an older display. They look the same. I’m not saying there’s not a lot of work to be done, just that I’m relieved to see that device makers seem to be doing quite a lot of it. Likewise, if we rely more on CSS than image exports, I’d say we’re doing our part.

So, that panic button? It gets to go back into the drawer for another occasion. Sure, the internet’s clothes are going to fit funny for a while as it figures out how & where to put all those extra image KBs, but we’re going to be okay. These are awkward times, but rejoice. We all get to play the role of the guidance counselor: having discussions, writing specs, and building tools that continually reshape the web into its full potential.

While I think the Freelancers Union site has some great resources & goals, I can’t get on board with the attitude of the longest invoice page. Since being in business, I’ve had 2 unpaid invoices. Sure, I’m disappointed in the clients, but I’m more disappointed in myself. I run a small business and like the fact that the buck stops at my desk, but I also realize it’s my responsibility (through things like contracts, legal advice, and payment schedules) to be sure that the buck gets there in the first place.

This post is my small way of participating in Ideas of March.

It pains me to admit it, but I wasn’t too keen on responsive web design right out of the box. Weeks after Ethan’s ALA article, I even briefly entertained the idea of writing a post haranguing the practice, nit-picking concerns on how using media queries to relocate elements on a page could disorient users, but I knew deep down I was full of it. My short-lived adverse reaction wasn’t rooted in any specific limitation of the responsive approach itself, but in my inclination to cling to the way I had always perceived (and built for) the web.

That perception had solidified over 10 years of making websites in a particular way. Pages were wire-framed, then fleshed out in Photoshop, which was where, for the most part, design ended. HTML & CSS were merely used to execute the prescribed layout. I took comfort in that approach, particularly in the control I had with a rigid grid and a perfectly pressed pixel-based structure. What you saw in the comp was what you got on the web. Bada Bing.

To think about the web responsively is to think in proportions, not pixels.

That approach, however, only works for a single view, a concept quickly becoming a thing of the past. Mobile browsing has exploded, and tablets (along with a slew of other devices of varying size) have confirmed the web’s status as a moving target. The choice was before me: retain the control in my original approach but accept that I’d be designing three or five or ten layouts, or redefine the way I think about the web. I found that to think about the web responsively is to think in proportions, not pixels. I traded the control I had in Photoshop for a new kind of control—using flexible grids, fluid images, and media queries to build not a page, but a network of content that can be rearranged at any screen size to best convey a message. Web pages (not that the term ever fit perfectly) aren’t really what we’re building anymore.

***

Did I forsake Photoshop? No. Reagan and I still start designing with a wide, desktop-sized view, but it means something very different to our process. It’s a starting place, and once we’re going, Photoshop is ultimately used for asset building (textures, photos, etc.). The largest and most exciting part of the design process now happens in the browser.

Did I dismiss hierarchy? No, but “squishy” was the unflattering term I initially used to describe responsive sites.  For me, websites take on an increasingly familiar skeletal form as I mentally map content in proportion to specific areas. When working with clients that’s how we address content. Elements are sized & placed purposefully to create order. I was worried that fluid content would have no visual impact and spinelessly reflow, breaking the established hierarchy. However, I soon found that didn’t have to be the case. While working on our first few responsive projects at Paravel, we used fluid-width images, videos, and even text headlines when appropriate, along with proper planning (content choreography) to maintain strong visual presence. The hierarchy, and thus the message, can be preserved at any view.

***

In the process I discovered, to my great relief, that I didn’t have to throw away my design sensibilities to ‘go responsive’; instead, I could develop techniques to incorporate design elements I gravitate towards (like interesting typographic arrangements or full-width images) in a responsive way. My stubborn unwillingness to abandon those sensibilities has made these initial steps into responsive web design worthwhile. It’s gratifying to use the things that might have kept me from adopting a responsive approach as inspiration to innovate. 

If there’s anything I’ve had to learn the hard way through all of this, it’s that responsive web design isn’t bolt-on. Whereas progressive enhancements (like border-radius), or web fonts can easily be added and removed from a site, responsive (for me at least) has required a complete redefinition of how I approach my craft down to the pixel. The more I learn & adapt, the more certain I am that this is the best way to build for the web. The process of adopting a responsive approach has made me better at my job, and I’m thankful for that.

media screen and (min-width: 1234px) and (min-height:700px) {
body {font-size: 137.5%;}
}

This bumps body copy up to 22px for those bold enough to view the site at least 1234px wide. Why 1234px? Just because that’s where, with all % values for widths & container padding, my site hits its max-width.

What’s with the vertical media query? I used min-height to target screens that are wide enough to trigger the change, but not tall enough for it to make sense. As an example, my wife has an 11” MacBook Air that has a screen resolution of 1366px X 768px. With the menu bar & browser window, the screen is not tall enough to trigger that final bump up in font-size unless you enter into full screen browsing, which to me is a good thing.

But maybe vertical media queries could do much more than this. For projects where the fold *gasp* is a concern, perhaps setting min/max-height could be a new way to control how content is served up to screen widths and heights of any size. If you just have to get that sign up button in view without a scroll, you could trigger a smaller banner image or nav bar to make room when necessary on shorter screens.

For what it’s worth, it’s stuff like this that gets me excited about the future of web design. We’re leaping past any point where the word webpage makes any sense, and into a a world where what is seen at any one screen size (or Photoshop comp) only captures a sliver of the display capability responsive websites muster.

Fine control remains elusive – kerning, character spacing – controlling these aspects are both difficult to specify for numerous reasons. This is frustrating to designers who love typography and want to have that finer control.

Huzzah! I couldn’t agree more. As web designers, now that our type options have drastically expanded, we want the same level of control over them that print designers do. That includes kerning as well as more interesting & intricate typographic arrangements. The key here is specificity. If we can target letters and words with CSS the sky is the limit. For further reading here are some posts that my friends and I have written on the topic:

• Controlling Web Typography: An older post I wrote summing up Lettering.js and explaining why we hope CSS makes it obsolete
• A Call for ::nth-Everything: This is Chris Coyier’s take, but much more comprehensive and clearly reasoned than mine.
• Lettering.js: I like to think of the gallery as a series of case studies for how enhanced selectors would be useful.
• Dave Rupert’s original Lettering.js post: A great introduction to how Lettering.js came about and how to implement it.

One interesting potential issue with finer control could be what happens if we target specific letters or words on a multi-lingual site. Something as detailed as this might make no sense, or break visually in another language. This was a point Christian Heilmann raised last summer at ConvergeSE, and something I don’t yet have a good answer for.

Overall, I think that the fewer situations where web designers have to resort to image replacement for text the better.

I’m honored to have been a part of this Issue alongside, Alex, Mark, Karen, Cennydd, and Josh. Also, it was thrilling to see something I’d written elevated by the illustration work of Paul Blow.

Gosh, what an across-the-board privilege. Thank you to Andy, Carolyn, and Jez for the opportunity. Be sure to visit alwaysreadthemanual.com and snag yourself an annual subscription.

The template > slot > ad mental model is engrained both in advertisers, planners and web sites. Providing space for ads needs to be broadened into multiple spaces for one ad concept. This requires closer collaboration between advertisers and web sites, designers and marketeers and sales teams.

It’s clear that Mark has gotten his hands dirty working on a solution, and I like his idea for selling slot packages rather than single spaces. I could even see that instead of sending out the typical PDF diagram of ad slots and sizes, sales teams could point people to an actual responsive layout/template so they could see how their ad resizes and relocates within the site hierarchy at various widths.

What happens if ads become fluid and text is designed into the images or movies? Readability will certainly suffer, as will clicks. I wonder if advocating a similar image + HTML text approach much like The Deck or Fusion Ads would be a possibility. That may be a lot to ask, but if things need to be redefined, let us not be short-sighted.