Menu Search
Jump to the content X X
Smashing Conf Barcelona

You know, we use ad-blockers as well. We gotta keep those servers running though. Did you know that we publish useful books and run friendly conferences — crafted for pros like yourself? E.g. our upcoming SmashingConf Barcelona, dedicated to smart front-end techniques and design patterns.

Responsible Considerations For Responsive Web Design

Responsive Web design has been evolving rapidly ever since Ethan Marcotte coined the term two years ago. Since then, techniques have emerged, become best practices and formed part of our ever-changing methodology. A few obvious examples are the multitude of responsive image techniques, conditional loading, and responsive design and server-side components (RESS), among many other existing and emerging strands stemming from the core concept of responsive Web design.

I’m going to discuss a few of the lesser practiced elements that are quietly becoming part of the responsive Web design ecosystem under the umbrella of responsible Web design1. Responsible Web design practices are mainly concerned with responding to the user’s context by providing the ideal scenario in which they can experience your product.

Further Reading on SmashingMag:

Like responsive Web design, the responsible practices detailed in this article are open to interpretation and modification. I have covered what I feel are the most important elements: context-sensitive interactions, performance and progressive enhancement.

Context-Sensitive Interactions Link

Pattern Translations Link

In a responsive Web design project, each breakpoint defines the experience within a certain range of viewports: between the minimum amount of space and a maximum within the boundaries of that breakpoint. Some interactions that suit a breakpoint range over a large space — for example, a carousel with image thumbnails and pagination — might not suit the viewport boundaries defined by your breakpoints for smaller screens. The lack of available real estate could reduce the effectiveness of these superfluous navigation items if they end up obscuring the content or adversely affecting the user experience.

This is where the art of pattern translation6 comes into play. Pattern translation is the practice of taking the essence of a design pattern (whether it’s the content itself, the components or perhaps both) and ensuring that it applies across different breakpoint ranges and contexts.

The Great Discontent8 features pagination arrows that float in a fixed position as you read the page on large displays. Upon hover, it reveals the name of the interviewee on the next page. Larger view9.

On smaller displays, hover states aren’t easy to achieve. To combat this, the designer (and interviewer), Ryan Essmaker11, displays the pagination as big tappable blocks in the footer, showing the next interviewee’s name. Larger view12.

When we talk about contexts, it could mean an array of things, such as the breakpoint range, the type of device (touchscreen or another form of input), or the environment surrounding and affecting the user. We need to be very careful when talking about contexts — design decisions related to context must be based on fact rather than assumption. For example, a context-based assumption would be to change the language of a Web page in response to the location of a device — a terrible idea because the reader might speak a language that isn’t native to the detected country.

A more definitive responsive design decision would be to react to screen size (which we have been most accustomed to doing in responsive Web design). Using our carousel example, we could provide a context-sensitive interaction for a user on a touchscreen by allowing them to swipe to advance the carousel rather than tapping on the pagination buttons.

Eden Spiekermann14 has a carousel on its home page, with pagination dots for precise pointing devices such as mice.

For smaller displays, the carousel’s appearance and behavior change to suit touch-based devices.15
For smaller displays, the carousel’s appearance and behavior change to suit touch-based devices. Larger view16.

Similarly, we know that mobile phones have a keypad for inputting numbers effectively. By using HTML5 input types for the numerical entry of credit-card numbers, phone numbers and any other fields that require only integers, we can help the user type quickly and eliminate the stress of having to change input methods to complete a straightforward task.

Media Queries Level 4 Module Link

At the time of writing, the current crop of browsers (in their stable channels) do not recognize some exciting media queries on the horizon, detailed in the “Media Queries Level 4” module, which will help us craft context-sensitive interactions more effectively. We will have the pointer media type at our disposal, which recognizes three types of pointers: coarse, fine and none.

coarse is essentially the same as saying that the device is a touch device, with a pointer that has a large surface area (for example, a finger). fine is the same as saying that the input device has a precise hit area (for example, a mouse). With this information about the user’s context at our disposal, we have the capability to deliver an experience suitable to their situation. The components we build can benefit the accuracy of a mouse pointer, and we can build alternatives within media queries that recognize that the input device requires a larger hit area, such as a finger.

Currently, three more media queries that will help us build responsive designs are due to find a permanent place in the specification: the script media query (which I will address in the section on “Progressive Enhancement”), luminosity (which I will talk about in the section on “Sensors in Responsive Web Design”) and the hover media query. The hover media query detects whether the device has hover capabilities, and it will be invaluable for pattern translations on touch devices.

Take a drop-down navigation menu as an example — some links may require hovering in order to reveal sub-menus for sub-sections within the parent link. The behavior of hovering on touch devices is inconsistent and unreliable across mobile platforms. By being able to detect whether the device supports hovering, we can craft the experience accordingly. Ideally, you would code with a mobile-first methodology (i.e. assume the device doesn’t support hovering), and then build the drop-down navigation within the hover media query using feature detection to see whether the browser recognizes the new media query.

@media (hover) {
   li {
      display: inline-block;
      position: relative;
   li ul {
      display: none;
      position: absolute;
   li:hover ul {
      display: block;

Sensors in Responsive Web Design Link

Mark Boulton describes a responsive experience17 as being comprised of sensors, systems and actuators. Sensors tell us about the user’s context and environment around them — they inform us of their situation, enabling us to tailor the experience to better suit their circumstances. Mark details the array of sensors that we have at present, although I feel we have a few more to help us respond accordingly.

Through PHP and JavaScript, we can detect the time of day of the user’s current location. Liz Danzico serves an alternate style sheet to her readers depending on the time of day that a user visits her blog. If you visit it during daylight hours, the style sheet presents the text as dark text on a light background. You’ll see the opposite if you visit the website during the evening or night, which Liz does to optimize readability based on the assumption that your surroundings will have less light. This is responsive design.

Liz Danzico’s Bobulate19 has an “Evening Edition” that responds by adjusting the reading contrast according to your local time.

Granted, this example makes an assumption — not a dangerous one, but an assumption nonetheless. In fact, while writing this article, the specification for “Media Queries Level 4” has evolved to include a luminosity media feature to detect ambient lighting levels, thus addressing this use case. It may be some time before this reaches a browser that is able to make use of the device’s light sensor so that we can more accurately predict the user’s environmental conditions.

I look forward to the day when we have safe access to hardware features such as, for example, the microphone, so that we can sensibly adjust the volume for a video according to the ambient noise around the user. I recognize that this is pushing the far reaches of responsive design and its ever-growing strands, but there will come a time when discussions like this will become a part of our product process.

I am a firm believer that to be a good Web designer, you need to be a good anthropologist. Studying people as they use Web products in different contexts is a key skill and one that shouldn’t be ignored if we are trying to figure out how to use sensors to meet users’ needs.

I have said in the past that the best sensor is the user’s preference. I feel this advice still applies, even if we have access to a new array of tools in the browser to cater to our users. Take the text-heavy app Readability20 as an example. Readability allows the user to choose a font size and background color that suit them, rather than making the decision for them. Sometimes giving the user a choice is the best solution for your product, sometimes not. It depends.

Readability app
Readability’s elegant controls allow the user to adjust the reading experience until it feels comfortable.

As the specification evolves, so too will our ability to find out more about the user and to serve them according to their device and environment to ensure that they enjoy and are comfortable with our products. By establishing how design patterns translate across various contexts and by using anthropology to determine user needs, we can create context-sensitive interactions that quietly help our products shine.

Performance Link

Network Considerations Link

Speed is still a feature. This hasn’t changed since the days when dial-up modems were our main means of connecting to the Web. Since then, the landscape has become a lot more complex. When Internet use rose rapidly in the mid to late 1990s, most users were accessing the Web via either 28.8K or 56K modems. The Web was viewed at rates of 3.5 KBps and 6.8 KBps, respectively (when the modems were performing at their maximum rate). Then broadband was introduced, which brought much faster speeds. A short period of transition followed, and Web pages got a lot heavier as download rates improved.

Today’s Web is accessed over vastly different download rates. We now have 3G, 4G, LTE, Wi-Fi and all sorts of connections with different features and capabilities. It’s a different Web than it was in the late 1990s and early 2000s. We can’t safely bet on connection speed and build a page accordingly. A heavy page optimized for a speedy fiber-optic connection would put a good dent in a mobile user’s data plan when accessed over a 3G connection. The responsible Web designer would build for the lowest point of entry — a mobile-first approach, assuming for the slowest connection speed and building up from there to larger breakpoints for faster connections.

That’s the problem with the sensors that are available at the time of writing. The Network Information API21 isn’t widely available across browsers and platforms. The API will allow user agents set a value of a bandwidth attribute that indicates the characteristics of a connection. The user agent makes an estimation of the current bandwidth in megabytes per second and returns this value. If a value of “0” is returned, that means the user is offline and “infinity” if the bandwidth is unknown.

When this API arrives in major browsers, we will be able to make more informed decisions about the media that we display on our websites. We could serve compressed media with small file sizes to users when their bandwidth falls below a set value or if the value is unknown, and theoretically serve high-definition media for users with connections with ample bandwidth.

Think of the Network Information API as an extra dimension of responsive images. While the proposed <picture> and <img srcset="…"> elements and parameters would look for breakpoints and resolutions that allow you to control the shape of an image, the Network API will let you control the quality of an image based on the user’s connection speed, producing a result that fits the physical aspects and media capabilities of the user’s device.

One of the difficulties that browser vendors are experiencing with the Network Information API is that measuring bandwidth is a difficult task, in fact as Yoav Weiss writes22 – it may even not be worthwhile exercise.

Bandwidth, by its very nature, is variable over time… This variability is the major reason why making predictions about future bandwidth is likely to be highly inaccurate and error prone.

Additionally we need to consider the effect that latency can have on how a user experiences a product. Latency is the time between when the browser requests a resource from the server and when it starts to receive the server’s response. As you can imagine, as the number of requests grows, the latency increases. It’s a similar scenario to those awkward pauses in conversation that you see in television interviews between people in remote locations. Smashing Magazine’s own Vitaly Friedman has some excellent notes on this subject from his recent talk “Responsive Web Design: Clever Tips and Techniques372923.”

Page Weight Link

Perhaps all of this sounds too idealistic when the solutions mentioned above aren’t ready to be used yet. But that isn’t a reason to avoid the issue of performance altogether. This is a current problem. Tim Kadlec recently wrote an article24 blaming irresponsible Web developers for poor implementations of responsive Web design. Implementations that burden users with heavy downloads, regardless of context, undermine our ability to sell responsive Web design as an adaptive, forward-thinking methodology to clients. Such implementations need a diet plan for more modest contexts, rather than a pair of Spanx.

For years, product makers in various media have worked with restrictions on capacity. Artists in the music industry have around 72 minutes or less to hold their work on a CD. Game makers have similar constraints; a game designer for Nintendo’s SNES console couldn’t develop a game that was any larger than 4 MB.

Other than Web creators, music and game makers work with restrictions on capacity. Image Credits: bochalla26.

It’s a creative constraint. Its benefit is that it guarantees the maker that their product will be enjoyed in the ideal scenario, whether on a CD player or an SNES console. But what about us creators for the Web?

Our entry-level requirement is a much wider net: a Web-capable device. We have many more variables to consider, such as connection speed, device size and capabilities. There is no set maximum for page weight. The infinite canvas we work on creates the illusion of infinite size. The current worrying over page weight is a niggling concern that leads to thoughts like, “I’ll compress this later” or “The page won’t be too heavy…” How heavy?

Let’s assume that we complete a product for the Web and it weighs around 1.5 MB (not an unreasonable assumption). Sadly, we didn’t factor in performance from the beginning, and our “responsive” page weighs the same across all breakpoints and contexts. On a 3G connection (assuming the user can even get those speeds), our page would take a considerable amount of time to download. The Web isn’t about loading bars and progress indicators; we can do better than this.

A good starting point is ySlow, Yahoo’s tool for analyzing page performance. ySlow grades your page according to best practices and established techniques and metrics for a good Web page. I usually look at the “Components” tab, which gives a comprehensive list of all media, with individual and combined weights. It can be awkward but necessary viewing. Generally, I find that compressing images using services such as TinyPNG27 and ripping out those social button scripts28 can drastically reduce page weight. This should be more of an iterative exercise, rather than something done at the end of the project. Before doing this, a responsible Web designer would have used techniques such as conditional loading to keep page weight low.

Social widgets are often the worst culprits of page bloat. A standard Facebook “Like” button weighs in at a hefty 175 KB; Twitter’s sharing button is almost 100 KB lighter at 76 KB. Before adding these to your website, you really should question their effectiveness. How often will they be used? Are my users savvy enough to copy and share a URL. Does their device’s browser already have built-in sharing options (Safari on iOS does)? On his blog, Oliver Reichenstein offers some thoughts, research and sound advice on social widgets.

Sadly, one of the more elegant components of a Web page carries heavy bloat: Web fonts. Kits from font services can quickly escalate in size as you add more character sets. It’s a new creative constraint that we’ll have to get used to. Before the explosion in Web fonts, there were fewer than 10 fonts we could safely use in our designs — now, tens of thousands of fonts are at our disposal. This doesn’t mean we should use them like there is no tomorrow. It’s time to think about the baggage that comes with these fonts. The right balance between system and Web fonts can produce aesthetically pleasing results as well as reduce the hit on performance.

Conditional and Lazy Loading Link

Don’t confuse conditional loading with lazy loading, although both techniques are great methods of keeping page load down. Conditional loading queries the user’s conditions, mainly regarding screen width and resolution; then, if certain conditions are met, the appropriate content is loaded. People mainly use this technique to serve responsive images and media. For example, if the JavaScript indicates that the user has a small screen, then you could serve an image with smaller dimensions, rather than one for larger displays, which could waste bandwidth and (depending on the user’s connection) increase loading time.

Lazy loading is a similar technique in that you load media after the initial page load. Elements are loaded on demand. For example, if an image lies beyond the viewport’s perimeter, then not loading it right away would make sense, because the user might not want to scroll down the page and shouldn’t be burdened with images that they don’t intend to view. If they do decide to scroll, lazy loading detects when they are in range of the image and then loads it, ensuring that only what’s necessary gets loaded. I think of this technique as being akin to the “fog of war” in real-time strategy games: enemies on the map are obscured until you explore areas that reveal their units — the same goes for lazy loading media.

You can also use lazy-loading scripts to load other scripts — a technique used in large Web applications such as Gmail (although there is no reason not to use it in smaller Web pages and applications).

<script id="lazy">
// Make sure to strip out (or replace) comment
blocks in your JavaScript first.
/* JavaScript of lazy module */
function lazyLoad() {
var lazyElement = document.getElementById('lazy');
var lazyElementBody = lazyElement.innerHTML;
var jsCode = stripOutCommentBlock(lazyElementBody);
eval(jsCode); }

Code taken from slide 57 in Vitaly Friedman’s presentation “Responsive Web Design: Clever Tips and Techniques372923.”

It may sound like I am blaming page weight as the main cause of all Web performance issues, but it isn’t always the cause. I recommend using tools like ySlow and the Web Inspector’s “Resources” tab to get to the bottom of performance problems. Always remember to aim for speed above all else; page weight may be the most common cause of slow performance, but be sure to optimize, cache and compress to keep your product running like a well-oiled machine.

Progressive Enhancement Link

Enhanced Inputs Link

Progressive enhancement has evolved beyond the scatterings of border radiuses and of text and box shadows that have grown in popularity since the inclusion of these features in the specification. We now have subtler, more practical uses that respond to the context of visitors to your website.

Looking at the different keyboard layouts for iOS as an example, you may have seen the following layouts activate for different input states in apps. We can do this on the Web, too.

The various keyboard input types available on iOS. Other mobile platforms offer similar layouts depending on the specified input type.

The email input type is a cue to capable devices to show an email-friendly keyboard layout when the field is focused. This subtle progressive enhancement improves the usability of a product by saving the user the effort of switching keyboard modes and symbols to find email-specific formatting buttons, like the @ symbol and domain suffixes.

<input type="email" />

The same applies to numeric entries. If a field requires user input that is purely numeric, then using the number field type makes sense. This will activate a keypad similar to the number keypad on a physical keyboard and the number dial on a phone. Both keypads are ergonomically designed for numeric entry. Responding to the user’s context when the user is on a device capable of showing the keypad will make this step easier and, thus, improve the experience.

<input type="number" />

Enhanced Device Capabilities Link

Mobile operating systems are at war with each other to provide the best experience to consumers. As a result, companies such as Apple, Google and Microsoft push their software’s capabilities to enable us as developers to enhance our experiences for users. Smartphones and tablet computers are generally more technically advanced than desktop computers; when building a Web product that responds to different device metrics, we can use some of these features.

Most current mobile and tablet devices come equipped with GPS sensors that give developers access (when the user grants permission) to geolocation data returned by the device. We can use geolocation as an enhancement to location-based interactions, such as searching for nearby points on a map, thus saving the user from having to enter the data manually. Manual entry should be used as a fallback when you are progressively enhancing for geolocation, even if the device successfully returns a location — the result may be inaccurate or may need manual modification from the user in a text field.

Advanced Layout Methods Link

Earlier this year, I wrote about how we can perform content choreography 30, a term coined by Trent Walton31, using pure CSS to alter the layout hierarchy on small screens. An example of content choreography would be to move the navigation menu from the top of the page to the bottom when doing so makes sense. The effect is achieved using flexbox, an advanced CSS layout technique for building intricate layouts that would otherwise be complex using older CSS methods.

The strange thing about flexbox is that (at the time of the original article) desktop support was limited, although support on mobile and tablet devices (where we actually do the choreography) was healthy and has continued to flourish across platforms. This has made the technique a pretty safe bet if you want to use it.

Content Choreography32
A demo of content choreography33 using flexbox to reorder a layout at different breakpoints.

Given the nature of our work, there will always be devices that are less capable than others. We’ll never have an even playing field — and that’s OK. That’s the nature of the software as well as the hardware; progress with one often results in the progress of the other, as happened with the getUserMedia method for capturing camera images and video.

Hardware cameras became standard on devices, which led to browser software being equipped with a method of obtaining their output. But with progressive enhancement, we need to ensure that solutions degrade gracefully; so, our flexbox example would revert to the default document order in browsers that don’t support the CSS rule. Responsive design requires designing with foresight; we need to anticipate such scenarios and ensure that the basic experience is robust before layering enhancements on top of it.

Tools such as Modernizr34 help us progressively enhance by running quick JavaScript tests to detect features. They essentially enable us to set rules for devices that can or can’t use particular browser features, such as SVG and CSS animations. Feature detection is making its way into CSS35 in the form of the @supports rule, which will eventually remove our dependency on JavaScript libraries, meaning we can set feature-based rules on devices that either do not support JavaScript or have JavaScript switched off.

@supports (display:flex) {
  .container {
     display: flex;
     flex-direction: column;
  .nav {

I feel like progressive enhancement has the stigma of skeuomorphism because it’s used so much for shiny and bumpy design elements. Such flourishes of CSS may suit some designs, but the really useful enhancements are those that have a tangible benefit to the usability of a Web product.

In Summary Link

We can never guess who our next visitor will be or what their context, device or accessibility requirements will be. It’s impossible. We can, however, be ready for and responsive to them. By not anticipating for the device and by embracing and preparing for the unknown, we can provide true, honest responsive products that autonomously provide a “best fit” experience to the end user.

Responsive Web design is an ever-changing methodology that helps us address the unknown. Responsible Web design practices are merely one of many strands of this methodology — old practices being adapted to new ones. Our work is never done. We make, we adapt, we learn, and we make again. To me, that is the most comforting thought about what we do.

Resources Link


Footnotes Link

  1. 1
  2. 2
  3. 3
  4. 4
  5. 5
  6. 6
  7. 7
  8. 8
  9. 9
  10. 10
  11. 11
  12. 12
  13. 13
  14. 14
  15. 15
  16. 16
  17. 17
  18. 18
  19. 19
  20. 20
  21. 21
  22. 22
  23. 23
  24. 24
  25. 25
  26. 26
  27. 27
  28. 28
  29. 29
  30. 30
  31. 31
  32. 32
  33. 33
  34. 34
  35. 35
  36. 36
  37. 37
  38. 38
  39. 39
  40. 40
  41. 41
  42. 42
  43. 43

↑ Back to top Tweet itShare on Facebook

Jordan Moore is a Web designer and front end developer based in Bangor, Northern Ireland. He is a responsive web design enthusiast with a passion for typography and design theory. Jordan documents such thoughts and experiments on his blog. And you can follow Jordan on Twitter.

  1. 1

    Aaron Martone

    March 11, 2013 5:50 am

    I honestly don’t hope I come off bad in this post, because although the points made in this article are very valid, someone trying to coin ANOTHER freaking term is getting to be a very aggravating part of this career path. Everyone and their grandmother just wants to invent catchprhases so they can have some claim to fame that they started a trend.

    It’s going to get to a point where you can bash your keyboard and you’ll have had a good chance that you typed out a “technology” or “technique”.

    Again, good points one and all, but we don’t need to call this “Responsible Web Design” These are best practices. Best practices are like HTML, they develop and get better; we find ways of doing something better than before and adopt those practices in their stead.

    • 2

      I get what you saying man, but I don’t think you have to take terms that seriously. I got to where I am by making my own decisions and not paying too much attention to the buzzwords (which I am sure you have too). An article needs a catchy title though :)

    • 3

      Jordan Moore

      March 11, 2013 6:37 am

      Hey Aaron,

      Thanks for your comment, I can assure you the intention wasn’t to try and invent a catchphrase for web notoriety or to start a new trend (although these roller boots I’m wearing do look stylish and get me from A to B pretty quickly).

      Try not to read too much into the title – the intention of using the phrase “Responsible Web Design” was because a) as a pun on Responsive Web Design it makes a catchy title for an article about best practices and b) I needed it to serve as an umbrella term for the 3 sub-categories for the purpose of this article in which I could allude to rather than referring to the 3 sub-categories individually.

      Thanks again!

      • 4

        Aaron Martone

        March 11, 2013 7:00 am

        I might have done just that. Sometimes I fixate on things like that. :)

        Progressive web design is amazing how often it changes. And the perfectionist in me wants to be aware of as many best practices as possible.

  2. 5

    Matt Mehlhope

    March 11, 2013 5:56 am

    You should probably reference my article where I discussed this exact topic a few months ago, and coined the same term with a lot of the basic tenants that you expand upon —

  3. 6

    Very well written article, thank you. I learned something new here which is the ‘script’ media queries for progressive enhancement. I found this most interesting, although I doubt this will work on older browsers which is at least half the point of non-JS detection, right?

    Continuing on that topic, I was never able to find a solution that could both function within progressive enchancement methodology and utilize lazy load. LL will never work unless the images are added using JS at the time of the event dynamically (even hidden or display:none images are loaded by browsers before any CSS). This means that there will be no images on the page shall the user have scripting disabled. I would love to have anyone prove me wrong.

    • 7

      Brett Jankord

      March 11, 2013 6:59 am

      @Dmitri – You could load in small images and then if JS is enabled, load in images at the size you need. This way, users w/o JS still get an image.

      • 8

        Great point @Brett! I must say though that it still does seem a bit hackcky and would involve at least 25% increase in page size and almost double the requests, especially if there are a lot of images (like allery thumbnails).

  4. 9

    I find it interesting that this article is mostly just a brief on a few best practices with some oddities thrown in. All of them are solid ideas — and I guess could be lumped together under the term “responsible”. Most are worth applying to many projects. But let’s step outside the tactical for a moment.

    This definition is particularly lacking:

    “Responsible Web design practices are mainly concerned with responding to the user’s context by providing the ideal scenario in which they can experience your product.”

    No. This is just repackaged “responsive”. “Responsible web design” is not a technical solution.

    Being “responsible” means applying thoughtful, studied UX to help people accomplish tasks. It means elevating the content to the limelight, and ensuring that content helps the visitor. It means avoiding anti-patterns, and contesting clients who insist on them. It means crafting a website that is accessible and malleable across the vast breath of devices and content aggregators visitors use. It means paying attention to details. It means editing. It means doing a good job even when no one is looking.

    In other words, it’s a strategic concept that speaks to empathy over performance, thoughtfulness over parlor tricks. Best practices in development are just part of the equation.

    • 10

      Jordan Moore

      March 11, 2013 7:23 am

      Hey Kevin,

      I can’t really argue with that. Thanks for a really useful contribution :)

      Some of what you have touched on around accomplishing tasks is covered under the Context-Sensitive Interactions section – granted I don’t go into any specifics, although I’m planting seeds here. I would say though that performance comes under responsibility – performance concerns empathy (in fact empathy permeates everything we do).

      “Best practices in development are just part of the equation” – *raises glass* hell yes brother.

      Thanks again for a valuable comment!

    • 11

      Damn it that should have been “breadth” not “breath”. That was not responsible of me. :]

  5. 12

    Joe Zimmerman

    March 11, 2013 10:55 am

    Wonderful article. Just a thought, though: With everything you said about “Page Weight”, maybe that should have been more of a consideration for this article. You article uses 1.25MB of images. A few of the images could have been skipped because they offered little to no value.

    Even if you kept them all, if you ran the PNG images through TinyPNG, it would cut it down to 550KB. If you’re good with Photoshop and know how to perform manual optimizations, you could have cut it down to 277Kb (that’s what I got without really trying. Could have been less I’m sure). That’s well under 1/4 of the size and saves nearly 1MB, which would have cut the page weight for this article in half.

    I love what you preach, but please practice what you preach.

    • 13

      Vitaly Friedman (editor-in-chief of Smashing Magazine)

      March 11, 2013 11:08 am

      You are right, Joe! Actually, we always try to optimize images on Smashing Magazine — it’s even in our publishing checklist! — but ironically this article slipped. The images are replaced now!

  6. 14

    I’m not sure it’s a good idea to look at things like screen size when determining whether or not touch should be enabled. Windows 8 is an early example of a future where large screens may have touch input, and there doesn’t seem to be a compelling reason to pre-determine whether or not the device supports touch. Allowing touch on the site regardless of detected configuration is harmless, so why not go ahead and use the W3C Pointer API features to allow it on any screen at any time?

    • 15

      Jordan Moore

      March 12, 2013 4:43 am

      Hey Ted,

      I don’t think I suggested that we do rely on screen size to determine touch. I suggested:

      “When we talk about contexts, it could mean an array of things, such as the breakpoint range, the type of device (touchscreen or another form of input), or the environment surrounding and affecting the user. We need to be very careful when talking about contexts — design decisions related to context must be based on fact rather than assumption.”

      And then followed up with talk about the upcoming pointer media query which will allow us to make more accurate assumptions based on input characteristics.

      I agree with what you are saying though, we are on the same page!


  7. 16

    Christopher Hawkes

    March 11, 2013 1:41 pm

    Great article man, I appreciate the information!

  8. 17

    Interesting article and I’m looking forward to what the future has in store for responsive design. We really are just at the beginning of this latest, exciting chapter for the web.

    I noticed an issue though: Modernizr is spelled incorrectly in “Tools such as Modernizer help us progressively enhance…”

    • 18

      Jordan Moore

      March 14, 2013 2:20 am

      Thanks for the feedback Matt!

      Also, the spelling correction is now in place :)

  9. 19

    “When Internet use rose rapidly in the mid to late 1990s, most users were accessing the Web via either 28.8k or 56k modems. The Web was viewed at rates of 2.9 kbps and 5.6 kbps, respectively (when the modems were performing at their maximum rate).”

    You should really learn the difference between a bit and a byte, and how many bits are in a byte.

    • 20

      Jordan Moore

      March 13, 2013 6:08 am

      Fixed, thanks for the correction aptly named person!


  10. 21

    I have to admit I never realized the broad spectrum of responsibilities that come with responsive design. It seems new dimentiins are constantly being added to the methodology. For example, consider the 3D sensing technologies and the recent efforts to enable hand and object tracking near the screen. I think these kind of interactive technologies will add various new and exciting dimentions to responsive design. Thanks for this great article.

  11. 22

    Danielle Arad

    March 13, 2013 3:41 am

    I thoroughly appreciated this article. This is a resource that I will keep and refer to regularly. Thanks!

  12. 23

    I just visited the Bobulate website and it has a white background … is it “thinking” it’s night here? It’s 4.49pm and broad daylight. Maybe it’s not configured for the Southern Hemisphere …

  13. 25

    ‘Smashing’ (no pun intended) another great article out of the park Mr Moore, keep ’em coming!

  14. 26

    Pinmart – Pinterest Virtuemart Template

    Pinmart is responsive Virtuemart joomla template based on pinterest and designed for mobiles, tablets and desktops.
    It is compatible with Joomla 2.5 and VM 1.9.x onwards.

  15. 27

    Hi All,

    When doing responsive web design in photoshop, what DPI / Resolution do you use for psd templates?

    Thanks :)

    • 28

      Not sure I fully understand your question but I always use 72 DPI for web based design.


↑ Back to top