Since Ethan Marcotte published his seminal article on Responsive Web Design there’s been an explosion of articles related to this topic. The guy truly made a good work also publishing a book about it, deepening on what many consider, since then, should be a standard for web design. If you have no idea of what this thing is, this Responsive Web Design thing, but simultaneously you’ve been thinking and working on a way for your web projects to be viewable in multiple devices, then you are instinctively working on responsive web design. Here’s a little insight: The main objective of responsive web design is the inherent flexibility a website can acquire through the application of fluid grids, images and CSS Media Queries to adapt the content and design of the website to any device, even if it is a desktop computer, a laptop, an iPad or a Smartphone. You do not have to create a mobile version of your website; you do not have to create an application for every popular device on earth. Just one and it will adapt to everything.
The example below shows the responsive website www.cohenspire.com, and this is how we see a responsive website with different screen resolutions. The top of the image shows the website at a resolution of 1680×1050.
In its original size, the site displays on the left corner the main menu and in the right corner the social menu. Just below that is shown the title and description, which will have several changes thanks to media queries applied to fonts and images. In this image we find that the content tends to organize horizontally, from texts to images.
With a resolution of 1024×768, the tablet version of this website does not differ too much. It displays basically the same content, with the exception that it rearranges the divs to fit the screen. It loses a 39 per cent of width compared to the size of the website shown before.
With the next resolution (320 x 480), proper for Smartphones, there are relevant changes: we can see that in the place where should be placed the social menu, it disappeared completely. This actually has a good reason to be since most social networks have applications to distribute its content on mobile devices, making a menu like that, if not irrelevant, misleading. The dark rectangle on top shows the main menu, which gets centered, and the highlighted rectangle at the bottom shows part of the content, which becomes vertically organized. The font size and images get smaller with this screen resolution. This image is perfect for an iPhone or a Samsung Galaxy S and its main characteristic is the shrinking of the texts, using the smallest font size possible, as well as a reduced size for the images. The website loses 1340px in width, making it almost 81 per cent smaller than the original width. You can actually see how different responsive websites look like with different screen resolutions with the web-based tool ScreenFly.
“This is amazing!” Is what everyone might think. And yes, it is amazing: Just the promise to access a website from any device is kind of enough to make me start replacing my old HTML templates… or is it? Well, I don’t think so. Every proposal must have some weak points and this, as a “new one”, shouldn’t be considered the solution to the world’s problems. In the heat of the moment, not many people stop and think about the downside, the mistakes and the compatibility issues this proposal may have; and this is actually very normal. In the end, we’re just starting to know how this thing works, right?
However, the thing itself is not new. It’s been outside for quite a long time. In fact, if you use Adobe Dreamweaver frequently, you’d probably notice that a while back an update was released for the software, specifically the 11.0.3 Update. As noted on the description by Adobe, it includes HTML5 and Media Queries support, and also a Multiscreen button, allowing you to see how your website looks like with three different screen resolutions. This specific fact shows us two things: it indicates that Adobe was working on something related to responsive web design (it would be great to know how were they calling it back then) for a while before they actually release the update, and on the other hand, it gave us a hint on what should be the focus on mobile web design, or at least something to think through, like the fact that right now we’re not living in a desktop-based world anymore, instead of a mobile one. It is also very coincidental that Adobe’s update was released on August 31st 2010 while Marcotte’s book hits the streets in June 2011, almost 10 months after Adobe’s update. Would it be possible by any chances he was inspired by Adobe? We’ll never know. There’s no single mention to Adobe in his book whatsoever…
But speaking of sources against responsive web design, I realize I have found, though, only one article published in the blog Cloud Four pointing out important flaws to consider. Most of the rest consider the subject as the ultimate solution for web design. Negative points of view are as important as positive ones because the existence of a counterpart offers a vision to equilibrate the charges. It creates a debate and ultimately it helps us consider whether a proposal is good or bad. With that in mind, we’re going to point out the negative aspects we’ve encountered about responsive web design.
1. Image Resizing
This is a major issue considering that every good designer must rely on images to illustrate its concepts. In responsive web design this is the most problematic matter because resizing a desktop image to fit a mobile device’s screen implies downloading an image that’s been suited for a desktop environment. To view full images on a mobile device you need to download an unnecessary large file and resizing it to fit the screen. The next table shows an amazing example of the impact the load of large images has on mobile devices.
A good practice, though, is that if your mobile project requires large images to be displayed but your target device only allows small images to be displayed, break those large images up into smaller sections and deal with them separately as recommended by the W3C in section 184.108.40.206 How to do it
of Mobile Web Best Practices 1.0 Basic Guidelines
2. Resizing images forces CPU and memory
Viewing a responsive website on a mobile device forces the CPU and memory of it while resizing images because you are downloading a large image, uncompressing it in your phone’s memory and then resizing it to fit a small screen. This process takes about 3 bytes per pixel of memory, so a 1024×768 image will take about 2.36 MB of memory. Most clients only request 4 images in average at the time, but 9.44 MB is still a lot for a page load. A recommended file size for images in a mobile context could be 100×100, but this is kind of utopic since a suitable image for desktop websites exceeds that resolution.
On the Mobile Web Best Practices 1.0 Basic Guidelines, released by the W3C, at point 2.6 Device Limitations, it’s shown that:
“Some activities associated with rendering Web pages are computationally intensive – for example re-flowing pages, laying out tables, processing unnecessarily long and complex style sheets and handling invalid markup [T-MOB]. Mobile devices typically have quite limited processing power which means that page rendering may take a noticeable time to complete. As well as introducing a noticeable delay, such processing uses more power as does communication with the server.”
And they add:
“Many devices have limited memory available for pages and images, and exceeding their memory limitations results in incomplete display and can cause other problems.”
They also refer to the Adaptation Implementation Model on section 3.3, regarding to in-Network adaptation, indicating that:
“In-Network adaptation is where the content is altered as it passes through one or more network components. Some network operators, for example, compress images before they are passed over the air to the mobile device.”
This specific fact forces the mobile device to uncompress and resize the image, using the memory and the CPU of the device to show a result in its screen.
However, if your project needs require resizing images, you can use the tool imgble, a web-based tool which could help you resize your images to best fit a mobile device screen. This is a great way for you to adequate images.
3. Mobile devices download non-viewable data
One good example for this can be viewed within the old dconstruct 2010 website. It displays, as the site grows bigger, bigger images of the speakers, which were not viewed on mobile devices thanks to CSS media queries placed on the div where the images are. Instead, labels are shown with the names of the speakers when the width is lesser than 450px, fitting perfectly some of the most popular mobile devices. Although this is kind of cool, images were still being downloaded on the device. This can be identified by making a copy of the website into a local server, loading it on a device and watching the web server logs to see what was downloaded. Other way is by setting up a computer as a proxy server and set the device with it to see if every request to the site was logged. Both cases showed the same result: the device downloaded 172K in photos that were not seen.
Now, they create a new version for their 2011 responsive website, probably learning by the positive and negative exposure they’ve got during the last months in the articles by Rachel Andrews of Smashing Magazine and the one by Jason Grigsby from the blog Cloud Four respectibly. The new layout does not remove the images of the speakers when viewed on a mobile device, it just makes them smaller.
When the website is accessed from a mobile device, it has two good improvements. The first is the fact that the images of the speakers do not disappear, but instead resized at a proper size to fit the screen. As we see in section two of this article, image resizing is not a good practice, but here we can apply the law of the lesser of two evils, since downloading images that would not be seen is actually worst than resizing them. The only change, also well planed is the removing of the hover on the images showing the description over, since it is basically worthless in mobile devices, but very useful in desktops.
The second aspect is that the mobile version also highlights the location button. Previous versions of the website did not pay attention to this button, probably the most important one along with the register button. But it still has issues to work on, because if you click on it, it just shows you a map with some pins indicating where the conference, workshops, pre party and after party sites are, but it has no relation with the registrant whatsoever. No geolocation feature and no directions are included, making the map nearly decorative. On the other hand, the info below the map is very difficult to reach, since the map is within an iframe, if you sweep, what you are going to see is more of the map; you actually have to tap and sweep the border of the map to scroll down.
4. Mobile speed vs. Desktop speed
There are several factors that affect mobile speed. With 3G connectivity, being the greatest feature the type of coverage. For this there are as well several types like GPRS, or 2.5G, which has a download rate of 64 Kbps and a 20 Kbps upload rate. UMTS (Universal Mobile Telecommunications System) or 3G, which has a download rate of 14Mbps and is the most popular nowadays with several releases and updates. HSDPA (High Speed Downlink Packet Access) is the 5th revision and optimization of UMTS, also known as 3.5G, 3G+ or turbo 3G. It has a 14Mbps download rate. There is also HSUPA (High-Speed Uplink Packet Access), which is the 6th release of UMTS and the evolution of HSDPA, also known as 3.75 (3.75G) o 3.5G +; this technology offers improved rates of voice and data.
HSPA (High-Speed Packet Access) is the combination of previous releases, HSDPA and HSUPA, and it has a theoretical download speed of 14.4 Mbps and a 2Mbps upload rate. In addition, HSPA+ is an evolved state of HSPA. It was released in 2008 and has a download rate up to 84 Mbps and a 22Mbps upload rate. Finally, e-UTRAN (evolved UMTS Terrestrial Radio Access Network), possess low data transfer latencies and download rates up to 299.6 Mbps, not being yet widely implemented.
If we have the possibility to count on a good mobile internet connection, there is still a secondary factor for mobile speed to consider: the type of device in which we’re connecting to the internet. These devices could be of any kind and they will be connected to the fastest network when the device and the network itself allow to.
OK. You manage to have a good type of coverage and an excellent device. But that’s not all. There are still some other aspects that affect mobile speed like the intensity of the signal, which could be at its full potential depending on the coverage area and the obstacles the device finds while trying to reach a 3G node. The mobility of the user affects speed since the device has to leave a 3G node to reach a new one if the user is, let say, on a car or a bus. Also, you have to add up the saturation of the network’s 3G node and the node itself you are connected, because the more users a node has, the slower the service gets.
These features are regarding 3G connectivity, but what about WI-FI? Well, WI-FI networks have a greater capacity to transfer voice or data thus making you web experience better. One might think a WI-FI network is a good choice, but it is actually worst because these are usually protected by its owner and because of its local condition, they are not everywhere; in order for you to find one, you’d probably have to go or get near to a café, an airport or a shopping mall, and this fact is not going to guarantee the connection is going to work fine.
This infographic from the blog Marketing Tech Blog is amazing to understand the difference and the impact of mobile and desktop internet speed reaching to an intriguing conclusion: an e-commerce website making $100,000 per day could actually be losing $2.5 million annually with just a 1 second delay.
Because of all of these, mobile devices need to be resourceful. On desktop computers we would not probably notice websites’ latency unless poor planning results in a very slow website or because of a slow internet connection. However in mobile devices, even on iPhones –good handlers of internet content– mobile speed takes important place while loading a website, so is relevant for if to be appropriately built for a mobile device.
5. Hiding background images is a bad idea
Using CSS media queries isn’t very bad to handle images and one might think hiding background images is a better idea than using labels. Well, the display:none won’t stop a background image to be downloaded on a mobile device2. Other part to consider is that if you use CSS media query to replace the background image with a mobile version; in some cases it would actually download both images4. Nonetheless, there are two cases that seem to work: setting the parent of the element with a background image to display:none3, and using a min-width declaration to specify a minimum browser width for the desktop image and a max-width for the mobile image5. The result of both is only the mobile image been downloaded and viewed on the mobile device.
On the Mobile Web Best Practices 1.0 Basic Guidelines, it is specified at point 2.3 Bandwidth and Cost that:
“Even if the content type can be interpreted by their device there is often an issue with the experience not being satisfactory – for example, larger images may only be viewable in small pieces and require considerable scrolling.’”
And they also add:
“Web pages can contain content that the user has not specifically requested – especially advertising and large images. In the mobile world this extra material contributes to poor usability and may add considerably to the cost of the retrieval.”
6. More code, more to update
So as a result of good coding practices, a faster website load, as shown in the infographic by www.strangeloopnetworks.com, is key for user engagement and will affect whether a user returns to the website o not. More code means more time to wait. You’d probably want to avoid that.
There are components working perfectly on a desktop version of a website, but in some cases they are not going to show up in the mobile version; it could be a video, an embedded map or an image. CSS media queries work incredibly well hiding things, but not that well removing them. CSS media queries won’t remove any unnecessary script or html you won’t use on mobile or desktop versions. It just leaves it there: hidden.
8. CSS media query is a bad choice for multiple devices
As indicated on the Mobile Web Best Practices 1.0 Basic Guidelines at point 2.6 Device Limitations, most devices often do not support scripting or plug-ins, limiting the content which can be viewed. They said:
“Mobile browsers often do not support scripting or plug-ins, which means that the range of content that they support is limited. In many cases the user has no choice of browser and upgrading it is not possible.”
Responsive web design’s promise is to be compatible with every device, but this method relies on CSS media queries to achieve its goals; the bad news is that most mobile devices are not compatible with CSS media queries. This table shows the compatibility of CSS with most mobile browsers and Smartphones and although these issues have been corrected on newer versions of popular mobile operating systems like Android Gingerbread and iOS4 it shows us that even with safari on iPhones, the styles are not updated when the resolution changes and CSS media queries do not work with most Nokia, Samsungs and early versions of Android.
9. “Great mobile products are created, never ported”
Brian Fling, Author of the book Mobile Design and Development actually makes a lot of sense with this statement. On page 66 he illustrated perfectly why a mobile web site often achieves a different goal than the one its developer intends in the first place because mobile devices generally possess quality features which are made to ease people’s lives. He wrote:
“Take an airline website, for example. Simply taking the web experience and trying to put it on a small screen doesn’t help the user at all; in fact, it has the opposite effect. If the user is on the way to the airport and needs to check whether a flight is delayed, the last thing your user has time to do is scroll around to find where to check flight times. If you’ve found yourself racing to make a flight and needing to find your flight information, such as times, gate, etc., you need that information quickly.”
This probably wouldn’t matter much if your segment is publishing or blogging, but in other industries, understanding the context and the needs of the user will most likely lead you to create a different website for mobile users.
10. Mobile needs are different from desktop needs
Recognizing the mobile context is not just to be aware of the difference between screen sizes. Responsive Web Design does not recognize the mobile context because it just adequates a website to fit a screen, but it omits key mobile features like the location of the user, the connectivity, the time the user has and the information the user needs, hardware limitations, software potential, overall performance of the device, aspects like lighting, sound, visibility, accessibility and privacy. Each one of these is as important as a single piece for a great mobile experience that if you focus your design skills to adequate a desktop website for a mobile device, you’re missing the advantages the device could offer.
[This Chart from Morgan Stanley published on the website Online Marketing Trends shows the incredible global mobile sales’ growth and the estimated within the next two tears. Since 2005 the annual desktop sales’ growth has been stable, with some years decreasing. Instead, the mobile market, due to its low prices, has grown from less than 100 million that year to more than 300 million in 2011, and the estimated growth is increasing almost exponentially, locating 2012 as the inflection year, when there would be more Smartphones that PCs around the world.
This means more people want the features provided by mobile devices and Smartphones and the possibilities they bring. These features are usually ignored with a responsive website, and ignoring this context is a dangerous bet for web designers.
The Mobile Web Best Practices 1.0 Basic Guidelines makes a lot of sense when it indicates at point 3.1 One Web, that there are diferent contexts for diferent services and devices. They indicate:
“Some services have a primarily mobile appeal (location based services, for example). Some have a primarily mobile appeal but have a complementary desktop aspect (for instance for complex configuration tasks). Still others have a primarily desktop appeal but a complementary mobile aspect (possibly for alerting). Finally there will remain some Web applications that have a primarily desktop appeal (lengthy reference material, rich images, for example).”
Regarding presentation issues, most of the websites are designed exclusively to desktop computers and not only are they designed for that but to exploit the capabilities of desktop browsers and software. So accessing a website with these characteristics turns out to be a bad experience for the user. There are factor like pages not suited and bad laid.
This limited size also affects the visibility since it requires the page to be constantly scrolled down, especially if the top of it is filled with images or logos (as it happens with responsive websites).
11. Better create a mobile website than a responsive one
We test three different websites’ home pages and their mobile versions with YSlow, and we found there are significant differences regarding performance in both versions of the tested sites, which are between the 10 most visited around the world (YouTube, Yahoo and Wikipedia). The Wikipedia website has an overall performance average score of 92 (out of 100) and its weight is 16.5 times greater in the desktop version. It also has 13 less HTTP requests (the lesser HTTP requests it has, the faster the website will load).
Yahoo’s weight difference is not as remarkable as Wikipedia’s. It is only 3 times bigger that mobile and it has an overall performance average score of 96.5. We can all agree it’s still better to load 167.9K than 501.6 though. The amount of HTTP requests in this case is reduced by 20.
In the case of YouTube, its overall performance average is 97 and the weight difference between websites is enormous. Mobile version is 15 times lighter and it has 22 less HTTP requests than the desktop version.
Regardless of these problems, it’s essential to have in mind that responsive web design is a great way not to use it as an ultimate solution, but as a step towards integration among platforms. Every day the technology industry is striking the market with new devices, computers, Smartphones and tablets. So we, as designers and developers, have to choose between focusing on the development of applications for every device with a good market share, or apply the rules of a web design that fits everything. The first job is not only time consuming but will draw your resources at a lightning’s speed; the second one would be easy to build but it won’t capture all the advantages mobile devices have to offer. The offset option is to create mobile versions of our websites, which is certainly a wise choice. Still, it is important to specify that a responsive scheme settles a ground on web design and extends a wide range of opportunities to experiment and test on the vast variety of new, intuitive and fast devices. Whether this becomes a standard for web designers or only stands as an alternative way of designing, only time will tell.