This book is about two phenomena in the world of contemporary web design and web development, RWD and RESS. RWD stands for Responsive Web Design and RESS means RWD with Server Side Components. Both are based on attempts to find a way to deliver content to multiple devices more easily, and efficiently while reducing development time and keeping application and data structures maintainable. The RWD concept appeared first in 2010 in an article by Ethan Marcotte (available at http://alistapart.com/article/responsive-web-design). He presented an approach that allows us to progressively enhance page design within different viewing contexts with the help of fluid grids, flexible images, and media queries. This approach was opposed to the one that separates websites geared toward specific devices. Instead of two or more websites (desktop and mobile), we could have one that adapts to all devices. The technical foundation of RWD (as proposed in Marcotte's article) consists of three things, fluid grids, flexible images, and media queries.
Illustration: Fluid (and responsive) grid adapts to device using both column width and column count
Fluid grid is basically nothing more than a concept of dividing the monitor width into modular columns, often accompanied by some kind of a CSS framework (some of the best-known examples were the 960 grid system, blueprint, pure, 1140px grid, and elastic), that is, a base stylesheet that simplifies and standardizes writing website-specific CSS. What makes it fluid is the use of relative measurements like %, em, or rem. With changing the screen (or the window), the number of these columns changes (thanks to CSS statements enclosed in media queries). This allows us to adjust the design layout to device capabilities (screen width and pixel density in particular).
Images in such a layout become fluid by using a simple technique of setting width, x% or max-width, 100% in CSS, which causes the image to scale proportionally.
With those two methods and a little help from media queries, one can radically change the page layout and handle this enormous, up to 800 percent, difference between the thinnest and the widest screen (WQXGA's 2560px/iPhone's 320px). This is a big step forward and a good base to start creating One Web, that is, to use one URL to deliver content to all the devices. Unfortunately, that is not enough to achieve results that would provide an equally great experience and fast loading websites for everybody.
Besides screen width, we may need to take into account other things such as bandwidth and pay-per-bandwidth plans, processor speed, available memory, level of HTML/CSS compatibility, monitoring color depth, and possible navigation methods (touch screen, buttons, and keyboard). On a practical level, it means we may have to optimize images and navigation patterns, and reduce page complexity for some devices. To make this possible, some Server Side solutions need to be engaged. We may use Server Side just for optimizing images. Server Side optimization lets us send pages with just some elements adjusted or a completely changed page; we can rethink the application structure to build a RESTful web interface and turn our Server Side application into a web service. The more we need to place responsibility for device optimization on the Server Side, the closer we get to the old way of disparate desktops and mobile web's separate mobile domains, such as iPhone, Android, or Windows applications.
There are many ways to build responsive websites but there is no golden rule to tell you which way is the best. It depends on the target audience, technical contexts, money, and time. Ultimately, the way to be chosen depends on the business decisions of the website owner.
When we decide to employ Server Side logic to optimize components of a web page designed in a responsive way, we are going the RESS (Responsive Web Design with Server Side components) way. RESS was proposed by Luke Wroblewski on his blog as a result of his experiences on extending RWD with Server Side components. Essentially, the idea was based on storing IDs of resources (such as images) and serving different versions of the same resource, optimized for some defined classes of devices. Device detection and assigning them to respective classes can be based on libraries such as WURFL or YABFDL.
It is worth noting that both of these approaches raised many controversies. Introducing RWD has broken some long-established rules or habits such as standard screen width (the famous 960px maximum page width limit). It has put in question the long-practiced ways of dealing with mobile web (such as separate desktop and mobile websites). It is no surprise that it raises both delight and rage. One can easily find people calling this fool's gold, useless, too difficult, a fad, amazing, future proof, and so on. Each of those opinions has a reason behind it, for better or worse.
A glimpse of the following opinions may help us understand some of the key benefits and issues related to RWD.
You may have heard this line in an article by Jason Grigsby, Css media query for mobile is fool's gold, available at http://blog.cloudfour.com/css-media-query-for-mobile-is-fools-gold/.
Separate mobile websites allow reduction of bandwidth, prepare pages that are less CPU and memory intensive, and at the same time allow us to use some mobile-only features such as geolocation. Also, not all mobile browsers are wise enough to understand media queries.
That is generally true and media queries are not enough in most scenarios, but with some JavaScript (Peter-Paul Koch blog available at, http://www.quirksmode.org/blog/archives/2010/08/combining_media.html#more, describes a method to exclude some page elements or change the page structure via JS paired with media queries), it is possible to overcome many of those problems. At the same time, making a separate mobile website introduces its own problems and requires significant additional investment that can easily get to tens or hundreds of times more than the RWD solution (detecting devices, changing application logic, writing separate templates, integrating, and testing the whole thing). Also, at the end of the day, your visitors may prefer the mobile version, but this doesn't have to be the case. Users are often accessing the same content via various devices and providing consistent experience across all of them becomes more and more important.
The preceding controversy is just a part of a wider discussion on channels to provide content on the Internet. RWD and RESS are relatively new kids on the block. For years, technologies to provide content for mobile devices were being built and used, from device-detection libraries to platform-specific applications (such as iStore, Google Play, and MS). When, in 2010, US smartphone users started to spend more time using their mobile apps than browsers (Mobile App Usage Further Dominates Web, Spurred by Facebook, at http://blog.flurry.com/bid/80241/Mobile-App-Usage-Further-Dominates-Web-Spurred-by-Facebook), some hailed it as dangerous for the Web (Apps: The Web Is The Platform , available at http://blog.mozilla.org/webdev/2012/09/14/apps-the-web-is-the-platform/). A closer look at stats reveals though, that most of this time was spent on playing games. No matter how much time kids can spend playing Angry Birds now, after more than two years from then, people still prefer to read the news via a browser rather than via native mobile applications. The Future of Mobile News report from October 2012 reveals that for accessing news, 61 percent mobile users prefer a browser while 28 percent would rather use apps (Future of Mobile News, http://www.journalism.org/analysis_report/future_mobile_news). The British government is not keen on apps either, as they say, "Our position is that native apps are rarely justified" (UK Digital Cabinet Office blog, at http://digital.cabinetoffice.gov.uk/2013/03/12/were-not-appy-not-appy-at-all/).
Recently, Tim Berners-Lee, the inventor of the Web, criticized closed world apps such as those released by Apple for threatening openness and universality that the architects of the Internet saw as central to its design. He explains it the following way, "When you make a link, you can link to anything. That means people must be able to put anything on the Web, no matter what computer they have, what software they use, or which human language they speak and regardless of whether they have a wired or a wireless Internet connection." This kind of thinking goes in line with the RWD/RESS philosophy to have one URL for the same content, no matter what way you'd like to access it. Nonetheless, it is just one of the reasons why RWD became so popular during the last year.
CSS coupled with JS can get really complex (some would say messy) and requires a lot of testing on all target browsers/platforms.
That is or was true. Building RWD websites requires good CSS knowledge and some battlefield experience in this field. But hey, learning is the most important skill in this industry. It actually gets easier and easier with new tools released nearly every week.
Fluid layouts break the composition of the page; Mobile First and Progressive Enhancement mean, in fact, reducing design to a few simplistic and naive patterns.
Note
Actually the Mobile First concept contains two concepts. One is design direction and the second is the structure of CSS stylesheets, in particular the order of media queries.
With regard to design direction, the Mobile First concept is meant to describe the sequence of designs. First the design for a mobile should be created and then for a desktop. While there are several good reasons for using this approach, one should never forget the basic truth that at the end of the day only the quality of designs matters, not the order they were created in.
With regard to the stylesheet structure, Mobile First means that we first write statements for small screens and then add statements for wider screens, such as @media screen and (min-width: 480px). It is a design principle meant to simplify the whole thing. It is assumed here that CSS for small screens is the simplest version, which will be progressively enhanced for larger screens. The idea is smart and helps to maintain a well-structured CSS but sometimes the opposite, the Desktop First approach, seems natural. Typical examples are tables with many columns. The Mobile First principle is not a religious dogma and should not be treated as such. As a side note, it remains an open question why this is still named Mobile First, while the new iPad-related statements should come here at the end (min-width: 2000px).
There are some examples of rather poor designs made by RWD celebrities. But there are also examples of great designs that happened, thanks to the freedom that RWD gave to the web design world.
Note
The rapid increase in Internet access via mobile devices during 2012 made RWD one of the hottest topics in web design. The numbers vary across countries and websites but no matter what numbers you look at, one thing is certain, mobile is already big and will soon get even bigger (valuable stats on mobile use are available at http://www.thinkwithgoogle.com/mobileplanet/en/). Statistics are not the only reason why Responsive Web Design became popular. Equally important are the benefits for web designers, users, website owners, and developers.
Let's take a look at the advantages RWD and RESS can offer to members of each of their various user groups.
RWD for designers means the end of the standard-screen-width paradigm that ruled the Web for a long time. When I started web designing, standard screen width was considered to be 600px. Soon it reached 800px and stabilized for years at 1024px (960px standard available width for design).
Illustration – standard screen width
Following this "standard", the lowest screen width our visitors used to have, resulted in designs using only 50-75 percent of the screen real estate that most monitors could provide. The rest usually just had some nice background pattern.
Responsive Web Design that had to adjust to various devices' resolutions made the "standard width" concept obsolete. If we do responsive design, why not use all the available space? Standard document 960px width uses less than 40% screen real estate on a monitor more than 2500px wide. Creating documents that use 100% available width allows us to create more engaging and interesting designs. Browsing the best web designs of 2012, one gets the impression that someone opened a box with fullscreen website designs that provide a cinematic or game-like experience (you can see that most of them provide fullscreen experience). This is just the beginning.
This is probably the dream of any website owner. RWD or RESS is not a silver bullet against all problems to provide content to devices. Each case should be carefully analyzed to find out what type of solution is best, or at least possible, in a particular circumstance. Having said that, in many typical applications it is the cheapest and the fastest way to web design. Additional costs of design, implementation, and testing will probably not be even comparable with the cost of creating several mobile website versions together with respective native applications (hybrid applications as described at http://www.wired.com/insights/2012/11/native-apps-vs-mobile-web/).
The Web is a good thing for users, and they definitely prefer a browsable website over one they can hardly see on their smartphone/tablet.
Ability to link content is crucial for the Internet. Users expect links to work no matter how they access the Internet, and it is not possible to link to content inside some native apps. Browsing a mobile version of a website with desktop browsers or the opposite is not comfortable. It may happen though as a natural consequence of the nature of links.
Lowering budget constraint means that more websites can afford to optimize content for more devices, which will hopefully make the Web easier to browse on smartphones.
It is hard to find statistics on how much consumers like or dislike responsive layouts. They don't care much about the technology involved. For them, experience is the only thing that matters. RESS is an approach, one of many, that may help in providing great experiences across devices. Of course it is important to provide this experience, instead of failing before we provide anything or providing unusable content. Whenever conversion of an existing website to responsive layout is considered, we need to understand the limitations and, when possible, overcome them with the use of Server Side components and JavaScript.
After we are able to provide the user experiences we intended with our design, the benefits are obvious, which are as follows:
On big screens, the web page finally uses the whole possible area, which enables a more engaging experience.
On small screens, readability is guaranteed.
Lowering costs of "going mobile" for website owners means that users will get more websites optimized for devices than it would be possible without RWD.
Bandwidth issues can be solved with RESS.
In many scenarios native applications or mobile websites can provide better a user experience, but before resigning from responsive solutions some questions should be asked such as, does this advantage justify the difference in the cost of development and maintaining separate versions of the website? Is our device detection kit really as reliable as we'd like to believe? And how future proof will this solution be? Borders between device classes (used to determine templates to device relations) are blurry and will fade even more with time.
Note
Future proof is a buzzword often used by the RWD community as a selling point for RWD: www.techopedia.com states; in reality, very few things are truly future proof and that is the sad truth about all web things. RWD probably will be more future proof than native applications; the future will tell us. Nonetheless, it will be definitely cheaper to maintain RWD/RESS websites than native applications.
Most RWD critics come from the developers' community. This is surprising, but not very. Multiresolution design complexity adds to an everlasting tension between designers and developers. Implementing what the designer created in Photoshop is often a challenge for programmers, even without the necessity to make it fluidic and responsive. Besides that, RWD is a concept with no API or technical documentation to study. It introduces many problems, enough to mention responsive (adapting to resolution) images. The good news is that after two years of evolution we have some well-tested CSS frameworks, a growing number of JS libraries, and last but not least, responsive design principles, which are implemented in new versions of popular open-source content management platforms such as Drupal. In Drupal 8 there are several responsive elements. One of them is the Picture display formatter for image fields, being a Drupal way to implement the picture element proposal for HTML5, available at http://picture.responsiveimages.org/.
On the list of tools a responsive design developer may need, respond.js
(available at https://github.com/scottjehl/Respond) takes first place, a lightweight script that enables responsive design in browsers that don't support CSS3 media queries.
If you need a conditional resource, loading another JavaScript Modernizr (available at http://modernizr.com/) can help you.
There are many responsive Boilerplates to help you get started quickly. HTML5 Boilerplate (available at www.html5boilerplate.com) is most often used and can be used as a starting point for almost every web project. It contains an HTML template with normalize.css that normalizes default stylesheets of various browsers, Modernizr script, and examples of best-practice server configuration files.
The base version is not a responsive CSS framework, as it doesn't impose on the developer any particular way to handle responsiveness, but you can also get it in two other flavors, Responsive or Bootstrap. Each of them proposes its own perspective on building the page structure. Responsive is a concept of three views and layout versions, mobile, intermediate, and large.
HTML5 Boilerplate Responsive features two columns and typographic settings optimized for readability
It is perfect for fast, simple projects that don't require a complex layout.
The Bootstrap version is a responsive framework based on a 12-column responsive grid. The 12-column internal structure of this version (and its possible applications) is explained in detail at http://getbootstrap.com/css/.
12 columns of default grid in HTML5 Boilerplate give some flexibility in planning the page
Twelve columns allow us to create more complex layouts, but still it is a rather rigid system. Most designers would not be happy to have a fixed column number, with widths and margins defined for them. During the last five years, many tools and frameworks aimed at creating all kinds of grids on the Web appeared; ZURB CSS Grid Builder available at http://www.zurb.com/playground/css-grid-builder and Gridulator available at http://gridulator.com/ to name just two. A more extensive list can be found at http://www.thegridsystem.org/categories/tools/.
As flexibility and speed in creating responsive grids becomes one of the key issues in the web design / web development workflow, Adobe is trying its best to keep this market segment under its wings. It is hard not to admit that their tools lead the race. Inside Dreamweaver CS6 one can use a two-step process to streamline, creating responsive layouts.
At the first step it is possible to set up grids for three resolutions, with any number of columns on each screen width.
On the created framework, one can place content blocks and adjust their placement for each of three screen resolutions by dragging their edges.
Generated code is based on HTML5 Boilerplate and can be manually tweaked. The Dreamweaver interface allows us to also build content blocks on a grid framework.
On 14 February 2013 Adobe released the public preview of a completely new tool: Edge Reflow (free at the time of writing this). Its sole purpose is to allow fast and easy creation of CSS and HTML for responsive layouts.
Originally RWD consisted of three basic technologies used in a somewhat defined way, shown as follows:
The most important additions are the Modernizr and Respond.js libraries used in conjunction with a number of techniques to improve cross-browser compatibility.
Fluid grids should rather be named fluid and responsive in the original version. What is the difference? A fluid grid works like an old-fashioned fluid layout, that is, the columns' widths change when the browser window's width changes. A responsive grid responds to this change by changing the number of columns. In the original orthodox RWD concept, grids did both and the change was driven together by media queries and by the use of percentage values to set up layout.
For some people and projects this approach worked well but:
Some were not happy with fluid columns and made "frameless grids" (available at http://framelessgrid.com/), a CSS grid system with columns of fixed width
Some decided that it's better to use
emorrembased scaling to take the resolution out of the equation and made The Goldilocks Approach an HTML and CSS Boilerplate (available at http://goldilocksapproach.com/)Some thought that breaking a grid into bricks instead of columns may be more funny and made Masonry (available at http://masonry.desandro.com/)
Some (authors of this book among them) are happy to write their media queries by hand and adjust layout when it is necessary in a way required by the design
Last but not least RESS techniques emerged. Nobody really defined how RESS is supposed to work, besides that it couples RWD with Server Side components. A neat example of this kind of thinking is Adaptive Images (available at http://adaptive-images.com/), the PHP library that takes care of resizing images on the server. A similar solution was employed at Boston Globe, the huge news website being the flagship example of a complex RWD implementation.
The RESS idea can be described as Server Side optimizing page components for devices with the use of browser-features detection. In other words, RESS is an attempt to marry client-side responsive design achieved by using media queries and some JavaScript with Server Side logic. The purpose here is to make the whole system more efficient, and to overcome the constraints of a client-side application. These are vague statements and we need to be more precise before we can build any actual RESS systems. To know what RESS can do for us we have to know what problems we need to address and what Server Side infrastructure we have in place. RESS solutions are most often employed just for image optimization, but you could use it for serving the 3D Web GL version for those who can use it, FLASH for those who have it, CSS animations for those who see it, and so on.
The most underestimated RWD advantage is that it allows us to make better designs: designs that always use all the available screen width. This is the case for the first time since the very beginning of the Internet. The old way of making fluid layouts was a flawed solution that never grew out of childhood diseases. In the following chapter, we will build a really simple RWD example based on the HTML5 Boilerplate, using a responsive navigation component from H5BP (HTML5 Boilerplate). We will not use the default grid system but replace it with one that we define ourselves with the Gridpak service.