On April 3rd at 11:30am CST, I’ll be presenting at AMA Iowa on the topic of Responsive Web Design. If you’re in the Des Moines area on that day, and would like to attend, I’d love to see you there. Registration details are below.

The title of the talk is “Responsive Web Design: One website. All devices.” From the program description:

The number of mobile devices and web browsers has exploded in recent years, and it is nearly impossible for anyone to create or maintain websites for every device in the world.
So what’s the solution? Responsive Web Design is a guiding principle in modern web design that eases the stress of our inter-connected, multi-device world.
During this presentation, you’ll learn the why, who and how of Responsive Web Design, how to keep your message focused and laser-sharp on every device imaginable and strategies for dealing with legacy websites and web applications.
Key Takeaways:

• What is Responsive Web Design anyway?
• The key strategies and processes to undertake a Responsive Web Design project
• What the future holds for the web in our multi-device world

If you’d like to register for this talk, please do so by Monday April 1st. Pricing details are on the registration page.
Looking forward to seeing you guys there!

Let’s get something out of the way right at the start: There is no such thing as the fold on the Web!! Anyone who tells you differently is more wrong than Wrongly Wrongham of 14 Wrongingford Road, Wrongleton; winner of last year’s Mr Wrong Contest.

There’s always more underneath…

1. Whose fold are we talking about? Yours on that swanky 1920×1200 laptop display? Or mine on my iPad’s 1024×768 screen? How about your iPhone’s display? Where’s the fold on that? Different devices means different interactions with your site, and the concept of the fold is blown away.
2. Do you really believe all your users have forgotten how to scroll? In this era of mobile browsing, where everything is a swipe away? Trust me, they haven’t.
3. Is the most important content always going to be at the top? What happened to the concept of the teaser? If we always shove everything as close to the top of the page as we can, inevitably users will get pretty fed up when they realize the rest of the site isn’t up to snuff.
4. The Web is different from print. Accept this truism and move on. The concept of the fold was born in print. It lives on in print, and will continue to do so for quite some time. It’s right that it remains there, and wrong that is has been brought over to the Web and turned into something as ugly and pervasive as it has.

Before Perficient I worked with someone who firmly believed their “vision” (oh yes, this person used that word) of a website was The One True Way, and 1024×768 was The One True Resolution. It delighted me to present wireframes to this person, only to be told (fingers together in a pyramid as they spoke), that “Martin, we really need to be getting more content above the fold, you know. I really need you to see that.” Suffice it to say, I’d flip to the next slide (the mobile resolution slide) and watch this person’s face fall a little. I can be cruel like that.
But this nameless someone came from a print mindset, and – unfortunately – wasn’t able to break themselves of it, despite all the evidence to the contrary, and the amount of business they were trying to win in the digital space. So web projects would run over as we’d make iteration after iteration, cramming more and more content above an imaginary fold (all completely unbidden by the client, by the way), until this person was satisfied. Then we’d present to the client, the client would hate it (wouldn’t you?), and I’d whip out my original wireframes, untouched by meddling hands, which were inevitably declared winners.
If we ignore the complexities of multiple devices with different resolutions (which comes with its own – blindingly obvious – reason why we need to ignore anyone who uses the phrase, “above the fold”), and simply focus for a moment on a desktop website, ask yourself one key question: Do I want my customers to get everything they asked for right at the beginning of their interaction with your website? Probably not. (Note: I’m not for one second saying hide your content, hee hee hee!) What you want is to build anticipation as your users explore your site. Make interacting with the site as much a part of the experience as the payoff at the end.
Parallax scrolling websites can be great examples of exactly this kind of interactivity. One of the best is Ben the Bodyguard. Go on, take a look. And scroll!

Making images responsive on the Web is actually pretty easy. Don’t specify the width and height of the image, and include one simple CSS declaration, and bingo! Responsive images that scale beautifully as the page resizes and reflows. But what if you want a different crop of your image on a mobile device? Well, that’s where a new HTML5 element and a new HTML5 attribute come in.

But first…

Why do we need something new, again?
I’d argue one of the biggest use-cases for a new way of incorporating images is that of art-direction. Scaling is a solution that works, but it hardly achieves the goal of focusing the image on its most important aspect, especially at smaller resolutions.
Consider this image of the legendary Tom Baker:

Tom Baker. Legend.

The <picture> element

First proposed by Mat Marquis in his A List Apart article, this brand new HTML element is now under active development by the Responsive Images Group. The syntax goes a little something like this:

<picture width="500" height="500">
  <source media="(min-width: 720px)" src="tom-large.jpg">
  <source media="(min-width: 480px)" src="tom-med.jpg">
  <source src="tom-small.jpg">
  <img src="tom-med.jpg" alt="Tom Baker">
  <p>Much longer accessible text that could be used to describe this image of Tom Baker to users of assistive devices (for example).</p>
</picture>

It’s verbose, but pretty straightforward. This syntax allows us to declare multiple sources for our images, and when to display them. In the example above, “tom-large.jpg” will only appear when the screen size is a minimum of 720px wide. The new element is backwards compatible (through the use of the fallback <img> element) and potentially much more accessible than traditional image usage by allowing for significant text content that isn’t limited to the alt attribute.
I like the <picture> element. It’s logical and it makes sense. But then the W3C had to go and muddy the waters…

The srcset attribute

Taking our example from above, here’s how that same set of three images would be described using srcset:

<img src="tom-med.jpg"
  srcset="tom-small.jpg 480w, tom-med.jpg 720w, tom-large.jpg 1x"
  alt="Tom Baker">

Much less verbose, and (to my mind) much less understandable. In a nutshell, the srcset attribute lets us specify as many image sources as we like (comma separated), and makes us add a dimension (480w) to it. This dimension value specifies the maximum viewport dimension that the image is intended for. So, tom-small.jpg is intended for viewports of 480px wide and less. (We’re using the src attribute as the fallback for browsers that don’t understand srcset – in much the same way that we specified an <img> fallback in the <picture> element above).
But what does that last dimension value mean? The 1x value? Took me a moment to figure it out too, but it’s a way of saying “use this image on all viewports larger than the previously specified width”. 1x refers to the pixel density: 1 CSS pixel per device pixel. Not exactly intuitive…

Which one should I use?

Neither. They’re not ready for prime-time yet. Sorry.
The whole area of responsive images is undergoing serious development, and the srcset attribute is currently making its way into the <picture> element. Which means we may end up with either the best of both worlds, or a horrible frankenstein. Let’s hope for the former!
But in the meantime what you can do is polyfill support for the <picture> element into your work, via some crafty jQuery. jQuery Picture is an example of a plugin that adds support for the <picture> element, and is actively being developed. As with all solutions that require JavaScript, I advise caution in its (over) use, but this may be a very good solution for a hero image that really ought to be art-directed properly.
I have no doubt that by the end of 2013 we’ll have some standardization in responsive imagery; a number of major browsers will natively support the new code (and those that don’t will have suitable fallbacks in place anyway); we designers and developers will have better means of art-directing images across multiple screen sizes; and therefore our clients will have a new and fantastic way of showing off their products to their customers. Wins all round!

The Web marches inexorably forward, and we love to see the innovations that come from that progress. But usually, a proportion of your users won’t see the new hotness. They’re stuck on an old ‘n busted browser that they either can’t update (because IE8 is the highest version of IE available for Windows XP, and corporate IT isn’t upgrading yet, and IT policy dictates IE only on the desktop) or won’t update (through sheer bloody-mindedness? I dunno…). So what do we as designers do?

There are two schools of thought here. One is right and good and just. The other is just wrong. Dirty, wrong and bad. Let’s deal with the bad first:

Graceful Degradation

Graceful degradation is the practice of building your web functionality so that it provides a certain level of user experience in more modern browsers, but it will also degrade gracefully to a lower level of user experience in older browsers. This lower level is not as nice to use for your site visitors, but it does still provide them with the basic functionality that they came to your site to use; things do not break for them.
Dev.Opera

Once the darling of the web community, graceful degradation fell from…ahem…”grace”…(thanks, I’m here all week…try the veal…) a few years ago when all of a sudden, everyone realized that building something and then making it partially work in other browsers (or, heaven forbid in this day and age of mobile devices, on other platforms) wasn’t the best way to go about development. Or, at the very least, it’s not ideal. So what’s the alternative?

Progressive Enhancement

This is the exact opposite approach:

[Progressive Enhancement] start[s] by establishing a basic level of user experience that all browsers will be able to provide when rendering your web site, but you also build in more advanced functionality that will automatically be available to browsers that can use it.
Dev.Opera

So while graceful degradation assumes complexity and tries to fix for older browsers, progressive enhancement assumes simple and builds complexity in as browsers become more capable.

How this applies in practice

By building your site and then removing functionality/design for older browsers (the graceful degradation approach) we’re providing a sub-par experience for what could amount to a significant proportion of your audience. On the other hand, by starting with a solid foundation, and building up we provide a consistent user experience that works everywhere, on every device, in all environments, and then adding features progressively as current (and future) browsers support them. This approach is future-proof.
So that user stuck on IE8 in their cubicle? A site built with the principles of progressive enhancement will work no matter what. It doesn’t matter that they’re on IE8. Sure, they may not see a few enhancements, but the core functionality and look of the site will be there, and it’ll look great to them.
Why choose progressive enhancement over graceful degradation? It’s the right thing to do for your users. But I’ll refer you back to the dev.opera.com site yet again for their final word on the subject:

Progressive enhancement will make both the end users and you happier:

• Regardless of environment and ability you deliver a product that works.
• When a new browser comes out or a browser extension becomes widely adopted you can enhance to yet another level without having to touch the original solution — graceful degradation would require you to alter the original solution.
• You allow technology to be what it is supposed to be — an aid to reach a goal faster than without it, not a “must” to be able to reach a goal in the first place.
• If you need to add new features, you can do so after checking if they are supported at a certain stage, or you can add it to the most basic level of functionality and make it better in more sophisticated environments. In any case, the maintenance happens at the same spot and not in two different places. Keeping a progressively enhanced product up-to-date is much less work than maintaining two versions.

Dev.Opera

A couple of years ago I was working on a small project where the client wanted to visualize data from their field operations on a map. Nothing overly complex – just locations, custom icons, radius of operation for that location, etc. Easy, I thought. We’ll use a system like Google Maps. Except the client wanted the maps branded with their own color schemes, to blend in visually with the rest of their site. I tried for a week to find a solution that used modern, open web technologies. In the end I admitted defeat and the client went with a set of custom-designed maps in Flash.

That experience has led me to search for mapping solutions wherever possible. The fantastic OpenStreetMap resource has been revelatory in bringing custom maps within reach. But with the addition of tools from MapBox we can really bring interactive, custom designed maps to everyone, complete with powerful data visualization.

Styled map of Scotland, with custom markers on the Isle of Skye

We’ve all been there: A new technology emerges (cough Responsive Web Design cough), all shiny and spiffy. We get excited about it – tweet and blog our way around it for months – until our excitement and the sheer saturation from the community spills out into the wider business community. And at a certain point, it’s like everyone knows about it. The secret is out, and your grandmother is asking how she can make her cat’s Facebook page responsive. Bless. Then a little while later, all the business blogs are viciously biting at the ankles of the once-darling new technology. What happened?

The Hype Cycle

provide(s) a graphic representation of the maturity and adoption of technologies and applications, and how they are potentially relevant to solving real business problems and exploiting new opportunities.
Gartner Research

With regards to Responsive Web Design, it’s been amazing how closely this pattern has been followed! In 2010 we had the Technology Trigger – Ethan Marcotte wrote his seminal article for A List Apart , and the combination of techniques that form Responsive Web Design was officially born. The web design community were immediately engaged.
The Peak of Inflated Expectations is the period where a technology is viewed as the solution to every problem. It’s pushed to its (still burgeoning) limits, and there are a few notable successes in its implementation that lead to huge amounts of attention, grabbing the interest of people from outside the technology’s particular community. In the case of Responsive Web Design that probably occurred when the Boston Globe launched their responsive site in 2011. It was the first large brand to use this new technology, and its impact was felt everywhere.
The Trough of Disillusionment is where reality sets in for a lot of people. This new technology isn’t the panacea, it won’t solve world hunger, and it probably won’t call you in the morning. The cad. So did Responsive Web Design fall into this chasm? Certainly. It became very difficult towards the end of 2011 to read any articles on mobile development without an opinion piece on how responsive design wasn’t the way forward, that discrete mobile solutions was the way to go, and that <insert provider’s platform of choice> was really the only platform worth worrying about anyway, honest guv’nor…
Some of those attitudes are still prevalent, unfortunately. However, at the start of 2013 we seem to be pretty much at the top of the Slope of Enlightenment (which sounds like a fantastic vacation destination – just remember to pack your hiking boots). Risks and benefits are clear, and there are a lot of large sites and applications in the wild that are using Responsive Web Design. Users understand it, stakeholders see the benefits in it, and the design community understands that it’s another tool in the arsenal, not the be-all-end-all.
2013 is the year where Responsive Web Design hits its Plateau of Productivity. Optimistic minds (like mine) would argue that we’re already there. But what do you think?

A little while back I wrote this nugget of wisdom:

Creating a great user experience extends beyond the research, beyond the wireframes, and even beyond the visual design. All that hard work is ultimately for nothing if your website or web application isn’t fast. Why? Because if your site doesn’t load quickly, your users will go elsewhere very quickly indeed!

I was focusing on the performance of your website in that post, but there’s a more general point to be made: That a great user experience requires great front-end development.

In November of last year, I became the Practice Lead for the Innovation & Implementation team within Perficient’s XD (Experience Design) group. Part of my responsibilities include preaching to you guys on the importance of great development. Great development that’s owned and performed by a team that’s as much about User Experience as the person who did the research, or created the wireframes.
But why is that? Why is it important to us at Perficient XD that a role that is typically part of IT actually forms a key part of our services?

Developers are Designers, Designers are Developers

I don’t much like the term “front-end developer”. It implies a lack of creativity – someone who is on the team strictly to code. But someone truly adept at the front-end (and I’m lucky to work with a whole slew of ’em here!) thinks like a designer too. They understand nuance and the language of design, and can talk to technologies that improve the product. A great front-end developer isn’t a developer at all. They’re a designer.

We Own What We Do

I like owning a solution from start to finish. We work with a multitude of clients, and sometimes we drop into a project part-way through, or finish our engagement before the solution launches. That’s all fine, and the nature of the services we as XD offer. But I personally believe that the very best work comes from a top-to-tail approach, and that includes front-end development. XD is very proud to be a full-service creative agency – no subbing out work here thankyouverymuch! – and owning the front-end development part of the project means we can align that portion of the project to the rest of the work we’ve done. Code optimization for example, is hugely important to us (for reasons I’ve mentioned previously) and we believe fervently that the very best user experiences come from a place where the code has as much love and attention given to it as the creative.

Iterating faster

There’s nothing more frustrating than being told by a developer, “We can’t do that.” It means hours of revisions to a set of designs that may have already been through one set of approvals. When XD owns a solution, our Interaction Designers can quickly get answers to technical questions. No big deal. And having Innovation & Implementation as part of the core delivery team from the get-go means we’re a part of the conversations that lead up to design decisions being made, so no nasty surprises!

Conclusion

Ultimately, a user’s experience on the Web is successful only if the team that delivered the final code that is executed in your user’s browsers is the very best it can possibly be. In XD, close collaboration and a mindset whereby everyone is encouraged to think like a designer, means we’re able to offer design solutions that are unique, and an execution model that’s modern and constantly evolving.

“To design responsively, one must prototype responsively.”
– Martin Ridgway, 2013

Quoting myself. A good start. But honestly, the statement above is important. After all, how best to communicate principles of responsive design but to do it as early in the engagement as possible?
However, prototyping should be fast and iterative. As of January 2013, standard prototyping tools like Axure and Balsamiq don’t provide easy interfaces for creating responsive designs that work. Which means only one thing: We need to get our hands dirty with some responsive HTML frameworks.

Responsive frameworks provide a fast, easy way to develop prototypes. All you need is a little HTML knowledge, and the ability to read documentation.

1. Which framework should we use?

I don’t have a horse in this race. I recommend taking a look at the excellent Responsive CSS Framework Comparison Chart and figuring out what kind of features you’re looking for from your framework, and how it fits into your overall workflow. The options presented here aren’t your only choices, of course. But they are probably the frameworks with the largest user bases, and large user base (generally) means better support.
I like all three of the options presented on that chart. Twitter Bootstrap is excellent (and I’m using it to design responsive prototypes on a current project), and is particularly well-suited to web application prototyping, due to its superb default form styles. The other options are good for when you may not want such high-fidelity mockups this early in the design process.

2. Fitting a responsive prototype into your workflow

Again, this is a very personal choice. Me, I like to replace static wireframes (that are of a fidelity greater than sketches) completely where I can. I just don’t see the point of duplicating work. Sketching is very different, of course, and is the absolute best way to get ideas down quickly. But once you have a set of sketches, why not move to responsive prototypes? I can guarantee that the sooner you start thinking about your site/application responsively, the sooner potential problems with your design will rear their heads, and the sooner you can solve those problems.
So when should you start your responsive prototype? You know your design methodology better than me. If you’re a sketcher (like me), then try my approach. Just launch right in! But if you prefer to use a higher-fidelity static wireframe as your starting point for a responsive prototype, go right ahead! There’s no right or wrong answer. Like everything on the Web, the answer is a definitive “Maybe”.

3. Benefits of responsive prototyping

I’ve already mentioned one in the previous section, but a full list of the benefits (as I see them) to prototyping responsively are:

• Sets the expectation as early in the design process as possible that this is a responsive design, and provides the interface to demonstrate as much
• Speeds up design, and cuts down on repetitious work (i.e., a static set of wireframes followed by a prototype)
• Creates a consistent user experience across the prototype
• Provides a solid code base from which a development team can work.

Go forth and prototype responsively. You’ll thank yourself later, I promise.

Arial, Verdana, Georgia, Times New Roman, Courier New, Impact, Trebuchet and <shudder>Comic Sans</shudder>. Those are the basic web-safe fonts we’ve all been using for the majority of our text-based content since the dawn of time. Or at least, since the Web came along. If you wanted something “fancier” for your text, you had to use an image, Flash, or something equally funky.
But we’re not shackled anymore. This is The Future
M’colleague Zach, recently posted his own take on Web fonts, but I wanted to go down a slightly different track. So before we get into the nitty-gritty, I should point out something. Historically, Internet Explorer has been the fuel of nightmares for a lot of web designers and developers. Its support for even the most basic of web standards was – until relatively recently – pretty woeful. In recent years, the IE team have done a lot to mend fences with the web community, and IE10 looks set to be a very solid browser.
Having said all that, IE got it right with regard to web fonts years ago! Everyone else was lagging behind. Yep. IE has had support for custom web fonts built in since IE4. I’ll wait for the gasps of astonishment to subside…
Now, that implementation wasn’t without its problems (specifically surrounding licensing of the fonts themselves), but it was a step down the road, one that other browser manufacturers wouldn’t even attempt for at least 6 years. Now, the concept of font downloading has been included in the W3C’s CSS3 Fonts Module, turning what was once a proprietary implementation into a formal guideline and (eventually) a recommendation.
Support for custom web fonts is pretty universal. IE has been solid for years. Firefox since version 3.5 (as of this writing, Firefox is currently at version 17), Safari since version 3.1 (currently at version 6), and Opera since version 10 (currently at version 12). Chrome uses the same WebKit rendering engine as Safari, so its support is solid, and has been for a long time. So we’ve got browser support covered. Great! Now on to licensing…

Working with the foundries

Fonts are licensed, just like photos. And the terms of those licenses vary from font foundry to font foundry. Some have embraced the revolution of web typography, while others are – understandably – concerned about illegal redistribution of the fonts that have been licensed by the site owner. After all, the fonts themselves are raw, unencrypted, and are downloaded to every user’s computer in their browser cache folder for ludicrously easy installation and dissemination.
This lack of protection for font files slowed down usage of custom fonts for a while, until some ingenious folks set up the missing link in the picture: A font hosting service. Typekit is one such service (there are others), which offer the convenience of easy-to-install custom web fonts, with the security that helps the font foundries sleep at night. In essence, you sign up for an account with Typekit (there are various levels, one of which is free), copy and paste a couple of lines of JavaScript into your website source code, and then choose the fonts you want. When you’ve done that, you write the necessary CSS (which is typically just including the name of the custom font into a font:family declaration) and your chosen font magically appears wherever you decided you wanted it! Easy.
Typekit and its brethren offer a vast array of fonts, from some of the major foundries. Using these services means you can be certain the fonts you’ve chosen are licensed appropriately, and can’t be easily pirated. And now Typekit has been bought by Adobe, the choice of fonts at that particular service is only going to increase. So designers! The next time you want Garamond Premier Pro for your headlines and Myriad Pro Condensed for your body copy, you can!

The future

In the middle of last year a new trend started to emerge: Icon fonts. With the rise of responsive design, and designing for retina, techniques for providing crystal clear graphics at all resolutions is becoming ever-more important. An icon font can certainly help in that endeavor.
Symbolset is a great example of an icon font. Instead of having to create a whole load of icons in a graphics program, why not upload one custom font to your website and use that instead? It’s resolution-independent, and changing the color of your icons is as simple as altering the text color in your CSS. You really can’t get much easier than that.

Creating a great user experience extends beyond the research, beyond the wireframes, and even beyond the visual design. All that hard work is ultimately for nothing if your website or web application isn’t fast. Why? Because if your site doesn’t load quickly, your users will go elsewhere very quickly indeed!
There are a multitude of ways we go about making sure your websites are the best they can be, but one of the fundamental aspects to all our work is that what we deliver must load as fast as it can. At its very core, making your website as fast as possible for the end user means minimizing the payload that is delivered to that user. And there are a number of techniques that we can use to help that minimization:

Minify text files

Whitespace is useful to a human, but an irrelevance to a browser. So get rid of it! Before launching a site, minify all the text assets (the CSS files and JavaScript files). If possible, use a program or a script to take care of this as part of a push routine. However you go about it, make sure you do, because you can reap some serious savings by minifying alone.

Gzip all the things!

If you’re not serving up gzipped HTML, CSS and JavaScript to your users, you are doing it wrong! There is absolutely no reason (except if you still have to support absolutely ancient browsers – like Internet Explorer 1 kind of ancient – which didn’t support gzipping) to not enable this setting in Apache, IIS or whatever flavor of web server you’re using. And if your comeback is, “but it puts more of a strain on the server”, then I don’t care and you need to buy a faster CPU, and refocus your attention on the humans using your website, not the machine serving it up!
Bonus: Gzipping does a pretty good job of minifying by itself. Not as great as minifying and then gzipping, but pretty solid.

Concatenate, concatenate, concatenate

The more HTTP requests, the slower the website. It’s really that simple. So, use fewer! Use CSS sprites where possible to avoid a lot of unnecessary (and slow) HTTP requests. In the build process concatenate as many separate JavaScript files as you can into one. And do the same for your CSS. And to help with caching, if your concatenated files contain a unique string (maybe date-based) you can use that to your advantage…

Browsers have a cache. Use it!

In your .htaccess file on an Apache platform (IIS guys, use your equivalent) add Expires headers on content that won’t change very frequently. You know, like images, or the JavaScript and CSS files you concatenated earlier. As these files now have a unique identifier attached to them, every time you make a tweak and rebuild the concatenated file, you’re actually uploading a brand new file, so your changes will be applied globally, without your users having to do anything. And in the meantime, once they’ve visited a page on your site once, they’re happily browsing away using their locally cached copy of all your assets, meaning their experience is as fast as it can possibly be.

Perceived performance is as important as real performance

If you move all your JavaScript calls to the bottom of the HTML page, the browser doesn’t have to halt to load all of them first. Instead, it loads the content of the HTML file, and its associated CSS and images, and then loads the JavaScript last. That gets the user to the important stuff first! It’s no faster, but it feels faster.
Similarly, make sure all CSS is at the top of the document. That way it loads as quickly as possible and there’s no chance of a Flash of Unstyled Content (FOUC) disrupting the user’s experience of the page. Again, no real performance gain, but a perception of a high-performance site is incredibly important.

Living on the edge

With Responsive Web Design and retina screens now making big waves in the online space, it’s important to consider performance as early as possible, for as many devices as you can. For example, only load assets that are required at particular screen sizes. If you don’t need that call to jQuery and its associated plugins at a mobile screen size, don’t load them! Use an intelligent loader like Modernizr (with its built-in support for yepnope.js) to load based on screen width. Just doing this can shave valuable seconds off the load time of your website.
Another area that is gaining traction is the concept of responsive images. That is, images that are sized correctly for the screen upon which they are being viewed, and the bandwidth that is available to view them. Unfortunately, it’s so new that right now there isn’t a one-size-fits-all solution. I’d recommend reading this article to learn more about the various options that are available to us (as of 2012).

In conclusion

Take performance seriously from the outset. Because ultimately, it doesn’t matter how well researched your site is, how intuitive the information architecture is, and how great the visual design is, if that experience fails the performance test. Slow sites equal frustrated users. And no-one wants a frustrated user.

Google has been pushing Responsive Web Design hard lately. In April they posted Responsive design – harnessing the power of media queries, which went into Google’s best practices for web development (spoiler alert: they like Responsive Web Design, a lot). There’s even a high-level tutorial for making your own site responsive.

Google's responsive Chromebook website

When building a website that targets smartphones, Google supports three different configurations:

1. Sites that use responsive web design, i.e. sites that serve all devices on the same set of URLs, with each URL serving the same HTML to all devices and using just CSS to change how the page is rendered on the device. This is Google’s recommended configuration.
2. Sites that dynamically serve all devices on the same set of URLs, but each URL serves different HTML (and CSS) depending on whether the user agent is a desktop or a mobile device.
3. Sites that have a separate mobile and desktop sites.

It would be fantastic if Google practiced what they preached, right? Well, although they’re not going all out with Responsive Web Design across their entire portfolio of sites (yet!), they are starting to use the technology. The new Chromebook website is responsive, which is great to see!

When was the last time you saw a floppy disk (outside of a museum, or your friendly IT guy’s stash)? In all likelihood it’s been a while. There may very well be some of you reading this who have never actually held a floppy disk, let alone used one. Oh man, that makes me feel so old…
Anyway, throughout our interfaces – both online and offline – we still use this outdated metaphor to indicate “save”, when an increasingly-large proportion of our user base actually has no idea why we’re using that icon. For a generation brought up with cloud storage, and auto-sync between devices, it will seem incredible that we ever had to carry around those little disks that only held 1.4MB (or 720KB back even further in the day!)
So the question becomes this: Should our industry start a conversation around changing this icon? And if so, what should it become?
I read an excellent comment on an old Slashdot article about this very topic that neatly and succinctly explains the problem, and a possible solution:

The whole concept of saving files (including the word itself) is counter-intuitive to most people. If you know that the computer makes a temporary copy of the file and then wants to copy the new file over the old one, then the word makes sense. You’ve made changes to a different file. But the average user doesn’t realize this, nor should they. They think that what they see on the screen is the file. When I edit a file, any fool looking at the screen can see that the changes have been made. Why would the computer ask you to do something you have already done? Intuitively, the screen represents the current state of the file, so if I wish to stop working on a document, it implies that I’m satisfied with its contents. If I create a new file, add some data and then try to close the document, at that point the software should intervene and ask me to pick a name for the file.
I could see a person accustomed to using the word ‘save’ in the phrase “I’m not sure I really need this any more, should I throw it away? No, I’ll save it, just in case…” to interpret the save prompt in the same way, i.e. I’ve decided to discard the changes I’m making, but maybe I’ll save them in case I want to make a permanent change later, more like a recycle bin.
My suggestion is get rid of ‘save’ altogether, and replace it with something like ‘Confirm your changes’, and a big green check mark in place of the floppy disk. Why bother the user with an icon representing the mechanics of the operation?

(Comment on “Modernizing the Save Icon“)

Logical. Still accomplishing the same thing, but in a way that makes sense to a user unaccustomed to iconography like floppy disks.
The thing is, I’m rather fond of not upsetting the status quo too much. Icons can become…well…icons, if you pardon the pun. Why change something so integral to the mechanics of computing? After all, sometimes context changes…

A police telephone box. Or the TARDIS, depending who you talk to