Search icon CANCEL
Subscription
0
Cart icon
Your Cart (0 item)
Close icon
You have no products in your basket yet
Save more on your purchases! discount-offer-chevron-icon
Savings automatically calculated. No voucher code required.
Arrow left icon
Explore Products
Best Sellers
New Releases
Books
Videos
Audiobooks
Learning Hub
Newsletter Hub
Free Learning
Arrow right icon
timer SALE ENDS IN
0 Days
:
00 Hours
:
00 Minutes
:
00 Seconds
RESS Essentials
RESS Essentials

RESS Essentials: If you're involved in Responsive Web Design, then you'll find this book on the fundamental features and techniques of RESS a very useful tool. It's the ideal introduction to a revolutionary new methodology.

eBook
$17.99 $19.99
Paperback
$32.99
Subscription
Free Trial
Renews at $19.99p/m

What do you get with Print?

Product feature icon Instant access to your digital copy whilst your Print order is Shipped
Product feature icon Paperback book shipped to your preferred address
Product feature icon Redeem a companion digital copy on all Print orders
Product feature icon Access this title in our online reader with advanced features
Product feature icon DRM FREE - Read whenever, wherever and however you want
Modal Close icon
Payment Processing...
tick Completed

Shipping Address

Billing Address

Shipping Methods
Table of content icon View table of contents Preview book icon Preview Book

RESS Essentials

Chapter 1. Why Does RWD Change the Internet?

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.

The RESS idea


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.

Controversies


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.

"Separate mobile websites are a good thing"

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.

"RWD is too difficult"

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.

"RWD means degrading design"

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.

RWD benefits


Let's take a look at the advantages RWD and RESS can offer to members of each of their various user groups.

Freedom for designers

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.

Invest less, reach out to a larger audience

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.

Users


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.

Developers


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.

RWD evolution and experiments

Originally RWD consisted of three basic technologies used in a somewhat defined way, shown as follows:

  • Fluid grids: Based on % measurements

  • Flexible images: Scaled down with the CSS max-width trick

  • Media queries made with philosophy Mobile First or Progressive Enhancement: That means code for the smallest screen was written first and then features for larger screens were added

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 em or rem based 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.

Summary


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.

Left arrow icon Right arrow icon

Key benefits

  • Easy-to-follow tutorials on implementing RESS application patterns
  • Information flow diagrams which will help you understand various RESS architectures with ease
  • Perform browser feature detection and store this information on server side

Description

RESS is a new methodology in the world of web design and development. It attempts to solve the problems that accompany the RWD (responsive web design) approach to web design. RESS is still in its infancy, but it is growing at an exponential rate. RESS Essentials shows you how to make server-side applications smarter and more aware of a visitor's environment limitations (device, screen size, and browser). This allows you to create faster and more reliable websites. Through this book, you will build a solid base of knowledge on RESS-related technologies, while the step-by-step tutorials will help you to create your own RESS system. This book is an introduction to RESS alchemy and gives you an incentive to build your own RESS lab. It will give you a broad overview of the multiple techniques used to code responsive websites in responsible ways. Beginning with an overview of RWD, you will learn the steps involved in setting up RWD for client-side development. You will then learn how to scale images using client- and server-side technology. By the end of this book, you will have learned about the implementation of RESS application patterns, browser feature detection, and various RESS architectures. RESS Essentials will also teach you how to use jQuery with some RWD design patterns and how to employ REST API for RWD pages.

Who is this book for?

This book is aimed primarily at web developers interested in writing applications that leverage both client- and server-side code to optimise content for various devices.

What you will learn

  • Write your own code to detect user screen size and store this information on server side
  • Install and integrate the WURFL device detection library with your application‚Äìboth cloud and standalone versions
  • Apply RWD principles to write HTML and CSS
  • Use HTML5 Boilerplate and its jQuery components
  • Integrate other CSS libraries with responsive grids using Gridpack
  • Create a RESS application based on RESTful API with the PHP SLIM framework
  • Develop jQuery plugins to handle web page components in responsive ways
  • Implement your own responsive images application
Estimated delivery fee Deliver to United States

Economy delivery 10 - 13 business days

Free $6.95

Premium delivery 6 - 9 business days

$21.95
(Includes tracking information)

Product Details

Country selected
Publication date, Length, Edition, Language, ISBN-13
Publication date : Oct 25, 2013
Length: 134 pages
Edition : 1st
Language : English
ISBN-13 : 9781849696944
Vendor :
jQuery
Languages :
Tools :

What do you get with Print?

Product feature icon Instant access to your digital copy whilst your Print order is Shipped
Product feature icon Paperback book shipped to your preferred address
Product feature icon Redeem a companion digital copy on all Print orders
Product feature icon Access this title in our online reader with advanced features
Product feature icon DRM FREE - Read whenever, wherever and however you want
Modal Close icon
Payment Processing...
tick Completed

Shipping Address

Billing Address

Shipping Methods
Estimated delivery fee Deliver to United States

Economy delivery 10 - 13 business days

Free $6.95

Premium delivery 6 - 9 business days

$21.95
(Includes tracking information)

Product Details

Publication date : Oct 25, 2013
Length: 134 pages
Edition : 1st
Language : English
ISBN-13 : 9781849696944
Vendor :
jQuery
Languages :
Tools :

Packt Subscriptions

See our plans and pricing
Modal Close icon
$19.99 billed monthly
Feature tick icon Unlimited access to Packt's library of 7,000+ practical books and videos
Feature tick icon Constantly refreshed with 50+ new titles a month
Feature tick icon Exclusive Early access to books as they're written
Feature tick icon Solve problems while you work with advanced search and reference features
Feature tick icon Offline reading on the mobile app
Feature tick icon Simple pricing, no contract
$199.99 billed annually
Feature tick icon Unlimited access to Packt's library of 7,000+ practical books and videos
Feature tick icon Constantly refreshed with 50+ new titles a month
Feature tick icon Exclusive Early access to books as they're written
Feature tick icon Solve problems while you work with advanced search and reference features
Feature tick icon Offline reading on the mobile app
Feature tick icon Choose a DRM-free eBook or Video every month to keep
Feature tick icon PLUS own as many other DRM-free eBooks or Videos as you like for just $5 each
Feature tick icon Exclusive print discounts
$279.99 billed in 18 months
Feature tick icon Unlimited access to Packt's library of 7,000+ practical books and videos
Feature tick icon Constantly refreshed with 50+ new titles a month
Feature tick icon Exclusive Early access to books as they're written
Feature tick icon Solve problems while you work with advanced search and reference features
Feature tick icon Offline reading on the mobile app
Feature tick icon Choose a DRM-free eBook or Video every month to keep
Feature tick icon PLUS own as many other DRM-free eBooks or Videos as you like for just $5 each
Feature tick icon Exclusive print discounts

Frequently bought together


Stars icon
Total $ 98.97
RESS Essentials
$32.99
Mastering HTML5 Forms
$32.99
JavaScript and JSON Essentials
$32.99
Total $ 98.97 Stars icon

Table of Contents

8 Chapters
Why Does RWD Change the Internet? Chevron down icon Chevron up icon
Sample RWD Setup for Client-Side Development Chevron down icon Chevron up icon
Server Side Setup – Device Detection Libraries Chevron down icon Chevron up icon
Sample RESS Page Chevron down icon Chevron up icon
Responsive Images Client- and Server-Side Approaches Chevron down icon Chevron up icon
Performance Chevron down icon Chevron up icon
Extending with jQuery Chevron down icon Chevron up icon
Employing a REST API for RWD Chevron down icon Chevron up icon

Customer reviews

Rating distribution
Full star icon Full star icon Full star icon Full star icon Empty star icon 4
(1 Ratings)
5 star 0%
4 star 100%
3 star 0%
2 star 0%
1 star 0%
Dejan Glozic Jan 17, 2014
Full star icon Full star icon Full star icon Full star icon Empty star icon 4
Software industry is so fast moving, so ephemeral that books seem to fight a losing battle on being relevant the day they are published, never mind 6 months or a year down the road. Books on actual concrete products are very often little more than the missing manuals (so much so that O'Reilly actually has a 'Missing Manuals' series, with a 'The book that should have been in the box' tagline).Somewhat better fate is reserved for books that attempt to describe an approach or technique rather than any particular platform, language or library. Sound principles tend to outlive the actual building blocks used to implement them. This book falls into that category, since it attempts to address a fairly new approach to wrestling with the explosion of Web clients.In a nutshell, responsive Web design (or RWD) is used to make a Web application adapt to the various aspects of the client, and reformat the experience to best fit each client in question (be it desktop, tablet or phone). RESS (or REsponsive design Server Side) goes further by involving the server. The rationale is that CSS can hide or reformat content depending on the client, but everything is still sent by the server, whether it will be needed or not. RESS attempts to address the performance side of the responsive design by choosing what to send before any formatting decisions are made on the client.Even in Internet years, RESS is a young technique, and a very good illustration of that is that the authors felt the need to devote most of chapter 1 to controversies surrounding RESS. To put it simply, not everybody is convinced that RESS is a good idea. Nevertheless, enough people are (including the godfather of RESS Luke Wroblewski). As such, the rest of the book assumes you have been sufficiently convinced RESS is a good and useful thing and you want to get on with it.Chapter 1 also brought one of the unexpected insights into RESS and responsive design, where it can actually go to the other side of the client spectrum. When it comes to RWD, most of the focus is on how your site reacts to non-desktop clients. However, for eons the desktop design assumed certain maximum width and happily ignored the side bands, making browser window maximization futile. On high quality, large monitors these side bands seems like a waste of real estate (compared to how desktop applications or games use it). RESS and responsive Web design can unlock full potential of your high end monitor - no reason why we cannot add rules to keep adding more content if you maximize your browser on a 27'' or 30'' monitor.In chapter 2, authors pay homage to the client side, by diving into the real world example using Gridpak for the responsive grid and Twitter's Bootstrap for everything else.Real action starts in chapter 3, where focus is moved to the server - the key value add of the RESS technique. In order to determine what to send to the client, server-side device detection is used. Two most popular solutions discussed in the chapter are WURFL and DeviceAtlas. There is a problem - these services are not available for free, or if they are, the free (or even cheap Cloud-based) version is not a viable option for anything but a test site. For completeness, authors cover some Open Source alternatives such as YABFDL (also known as Dave Olsen's Detector) - more modest in its database but still usable and free with permissive license (with coverage that keeps up with new devices through the use of the modernizr.js library).Chapter 4 puts server side detection into action. Different markups for different clients (to optimize for ability, support for modern features and JavaScript), different media sizes based on screen width, and manual selection of page versions. This chapter mostly deals with the first of the three goals, with plenty of code snippets using both WURFL and Dave Olsen's Detector.Chapter 5 moves on to dealing with image resolution on the server. Images comprise a large portion of the overall site payload and sending images that are too large or of unnecessarily high resolution is costly both performance-wise, but also by eating into the monthly bandwidth allowance for mobile users. The RESS solution for handling image sizes and resolution is in line with the overall approach and has some interesting properties compared to the known alternatives.As said, all this effort around sending the right-sized images to the client is at least partially driven by performance considerations. In chapter 6, authors note that client screen size is not the only parameter to take into account - connection bandwidth is as important. Unfortunately, as of today there are no media queries for connection quality and bandwidth that could be used to tailor image size and compression to use. In their absence, authors offer a number of techniques to optimize images or reduce the need to use them in the first place.One thing I really liked in this chapter was a graph showing that with the reduction of screen size (and with RESS solution for images enabled), the size of CSS and JavaScript files started to overtake images, to the point where images were only 1/3 of the CSS/JavaScript files for iPhone portrait resolutions (320px). This was a good reminder that RESS needs to be combined with other good practices if performance was a concern. I particularly liked a tidbit that the average webpage reached 1585 KB on September 15, 2013. That's a lot of KBs to send to any client, particularly mobile phones, and underlines the need for techniques such as RESS to improve Web performance.Changing gears, chapter 7 switched back to the client and focused on using and extending jQuery and Bootstrap to make your site responsive when dealing with elements such as tables and carousels. jQuery has essentially become the equivalent of gravity for JavaScript libraries (i.e. you cannot avoid it and must play nice with it), and Bootstrap is insanely popular in its third incarnation. While not necessarily limited to RESS (the code in this chapter could be easily used in a client-only RWD solution), we should not forget that RESS is a combination of server and client side techniques for responsive design, and the examples in this chapter are definitely useful for Web developers that seek responsive design solutions.I am a bit puzzled with chapter 8, which introduces REST and combines it with RWD. It is not strictly RESS in that it simply uses Ajax to call REST services. There is nothing wrong with what is proposed in this chapter, but REST is another kind of 'gravity' for many teams including mine, and tossing it here on the pile with RESS and RWD seems odd, particularly because it involves PHP in code examples. Since this was the last chapter in the book, I was left wanting for a chapter that is more fit for wrapping it all up and reinforcing the key messages of the book (an epilogue, as it were).In the end, where does it left me, the reader and the reviewer? I would say that RESS Essentials is part of the new breed of 'mini-books', considering its size (120 pages including index). It is definitely not the first of its kind - Responsive Web Design by Ethan Marcotte is 143 pages, and Mobile First by Luke Wroblewski is 123 pages. This class of books covers areas and topics that are too complex to be covered in one blog post or article but perhaps not as complex to require a book that can double as a weapon and will consume years of author's life. The format definitely allows hot topics to be covered in a time frame that at least gives them a fighting chance of having some decent use before the inevitable progress renders them obsolete.I think that the authors did a good job covering the ground on the topic of RESS and I definitely learned a lot by reading it. The book is part of the 'Community Experience Distilled' series, and it definitely fits the description, since the authors provided a number of examples and code snippets that look like something they arrived at through personal experience while working on real world projects. Whether RESS itself has a staying power is left to be seen. I am concerned about the limited choices when it comes to server side agent detection (at least in the Open Source world), so Dave Olsen's Detector effort should be commended.When it comes to code snippets, I was more interested in general concepts than the server side code examples because they were universally in PHP. There is nothing wrong with PHP but I would prefer examples in Java, or even better, in JavaScript using Node.js. Using Java or Node.js would work better with the final chapter about combining REST with RESS.As far as the format and language is concerned, I have two minor nits to pick. While the book is generally well written, Joanna's and Jerzy's Polish background occasionally creeps into their sentence structure. Not being a native speaker myself, I cannot quite put my finger on why I was able to notice, I just felt that way as I was reading. Another mild nit is that the PDF version of the eBook results in too small a font, and when I tap to zoom in, the text is single-spaced, making it less than perfect for reading on iPads. On the flip side, single spacing made for faster vertical scrolling. YMMV if you use a different reader or format.Dejan Glozicdejanglozic.comDisclosure: I have received a free e-Book in the process of writing the review for my blog at dejanglozic.com. The review is based on the eBook version - I didn't have a chance to see the printed version.
Amazon Verified review Amazon
Get free access to Packt library with over 7500+ books and video courses for 7 days!
Start Free Trial

FAQs

What is the digital copy I get with my Print order? Chevron down icon Chevron up icon

When you buy any Print edition of our Books, you can redeem (for free) the eBook edition of the Print Book you’ve purchased. This gives you instant access to your book when you make an order via PDF, EPUB or our online Reader experience.

What is the delivery time and cost of print book? Chevron down icon Chevron up icon

Shipping Details

USA:

'

Economy: Delivery to most addresses in the US within 10-15 business days

Premium: Trackable Delivery to most addresses in the US within 3-8 business days

UK:

Economy: Delivery to most addresses in the U.K. within 7-9 business days.
Shipments are not trackable

Premium: Trackable delivery to most addresses in the U.K. within 3-4 business days!
Add one extra business day for deliveries to Northern Ireland and Scottish Highlands and islands

EU:

Premium: Trackable delivery to most EU destinations within 4-9 business days.

Australia:

Economy: Can deliver to P. O. Boxes and private residences.
Trackable service with delivery to addresses in Australia only.
Delivery time ranges from 7-9 business days for VIC and 8-10 business days for Interstate metro
Delivery time is up to 15 business days for remote areas of WA, NT & QLD.

Premium: Delivery to addresses in Australia only
Trackable delivery to most P. O. Boxes and private residences in Australia within 4-5 days based on the distance to a destination following dispatch.

India:

Premium: Delivery to most Indian addresses within 5-6 business days

Rest of the World:

Premium: Countries in the American continent: Trackable delivery to most countries within 4-7 business days

Asia:

Premium: Delivery to most Asian addresses within 5-9 business days

Disclaimer:
All orders received before 5 PM U.K time would start printing from the next business day. So the estimated delivery times start from the next day as well. Orders received after 5 PM U.K time (in our internal systems) on a business day or anytime on the weekend will begin printing the second to next business day. For example, an order placed at 11 AM today will begin printing tomorrow, whereas an order placed at 9 PM tonight will begin printing the day after tomorrow.


Unfortunately, due to several restrictions, we are unable to ship to the following countries:

  1. Afghanistan
  2. American Samoa
  3. Belarus
  4. Brunei Darussalam
  5. Central African Republic
  6. The Democratic Republic of Congo
  7. Eritrea
  8. Guinea-bissau
  9. Iran
  10. Lebanon
  11. Libiya Arab Jamahriya
  12. Somalia
  13. Sudan
  14. Russian Federation
  15. Syrian Arab Republic
  16. Ukraine
  17. Venezuela
What is custom duty/charge? Chevron down icon Chevron up icon

Customs duty are charges levied on goods when they cross international borders. It is a tax that is imposed on imported goods. These duties are charged by special authorities and bodies created by local governments and are meant to protect local industries, economies, and businesses.

Do I have to pay customs charges for the print book order? Chevron down icon Chevron up icon

The orders shipped to the countries that are listed under EU27 will not bear custom charges. They are paid by Packt as part of the order.

List of EU27 countries: www.gov.uk/eu-eea:

A custom duty or localized taxes may be applicable on the shipment and would be charged by the recipient country outside of the EU27 which should be paid by the customer and these duties are not included in the shipping charges been charged on the order.

How do I know my custom duty charges? Chevron down icon Chevron up icon

The amount of duty payable varies greatly depending on the imported goods, the country of origin and several other factors like the total invoice amount or dimensions like weight, and other such criteria applicable in your country.

For example:

  • If you live in Mexico, and the declared value of your ordered items is over $ 50, for you to receive a package, you will have to pay additional import tax of 19% which will be $ 9.50 to the courier service.
  • Whereas if you live in Turkey, and the declared value of your ordered items is over € 22, for you to receive a package, you will have to pay additional import tax of 18% which will be € 3.96 to the courier service.
How can I cancel my order? Chevron down icon Chevron up icon

Cancellation Policy for Published Printed Books:

You can cancel any order within 1 hour of placing the order. Simply contact customercare@packt.com with your order details or payment transaction id. If your order has already started the shipment process, we will do our best to stop it. However, if it is already on the way to you then when you receive it, you can contact us at customercare@packt.com using the returns and refund process.

Please understand that Packt Publishing cannot provide refunds or cancel any order except for the cases described in our Return Policy (i.e. Packt Publishing agrees to replace your printed book because it arrives damaged or material defect in book), Packt Publishing will not accept returns.

What is your returns and refunds policy? Chevron down icon Chevron up icon

Return Policy:

We want you to be happy with your purchase from Packtpub.com. We will not hassle you with returning print books to us. If the print book you receive from us is incorrect, damaged, doesn't work or is unacceptably late, please contact Customer Relations Team on customercare@packt.com with the order number and issue details as explained below:

  1. If you ordered (eBook, Video or Print Book) incorrectly or accidentally, please contact Customer Relations Team on customercare@packt.com within one hour of placing the order and we will replace/refund you the item cost.
  2. Sadly, if your eBook or Video file is faulty or a fault occurs during the eBook or Video being made available to you, i.e. during download then you should contact Customer Relations Team within 14 days of purchase on customercare@packt.com who will be able to resolve this issue for you.
  3. You will have a choice of replacement or refund of the problem items.(damaged, defective or incorrect)
  4. Once Customer Care Team confirms that you will be refunded, you should receive the refund within 10 to 12 working days.
  5. If you are only requesting a refund of one book from a multiple order, then we will refund you the appropriate single item.
  6. Where the items were shipped under a free shipping offer, there will be no shipping costs to refund.

On the off chance your printed book arrives damaged, with book material defect, contact our Customer Relation Team on customercare@packt.com within 14 days of receipt of the book with appropriate evidence of damage and we will work with you to secure a replacement copy, if necessary. Please note that each printed book you order from us is individually made by Packt's professional book-printing partner which is on a print-on-demand basis.

What tax is charged? Chevron down icon Chevron up icon

Currently, no tax is charged on the purchase of any print book (subject to change based on the laws and regulations). A localized VAT fee is charged only to our European and UK customers on eBooks, Video and subscriptions that they buy. GST is charged to Indian customers for eBooks and video purchases.

What payment methods can I use? Chevron down icon Chevron up icon

You can pay with the following card types:

  1. Visa Debit
  2. Visa Credit
  3. MasterCard
  4. PayPal
What is the delivery time and cost of print books? Chevron down icon Chevron up icon

Shipping Details

USA:

'

Economy: Delivery to most addresses in the US within 10-15 business days

Premium: Trackable Delivery to most addresses in the US within 3-8 business days

UK:

Economy: Delivery to most addresses in the U.K. within 7-9 business days.
Shipments are not trackable

Premium: Trackable delivery to most addresses in the U.K. within 3-4 business days!
Add one extra business day for deliveries to Northern Ireland and Scottish Highlands and islands

EU:

Premium: Trackable delivery to most EU destinations within 4-9 business days.

Australia:

Economy: Can deliver to P. O. Boxes and private residences.
Trackable service with delivery to addresses in Australia only.
Delivery time ranges from 7-9 business days for VIC and 8-10 business days for Interstate metro
Delivery time is up to 15 business days for remote areas of WA, NT & QLD.

Premium: Delivery to addresses in Australia only
Trackable delivery to most P. O. Boxes and private residences in Australia within 4-5 days based on the distance to a destination following dispatch.

India:

Premium: Delivery to most Indian addresses within 5-6 business days

Rest of the World:

Premium: Countries in the American continent: Trackable delivery to most countries within 4-7 business days

Asia:

Premium: Delivery to most Asian addresses within 5-9 business days

Disclaimer:
All orders received before 5 PM U.K time would start printing from the next business day. So the estimated delivery times start from the next day as well. Orders received after 5 PM U.K time (in our internal systems) on a business day or anytime on the weekend will begin printing the second to next business day. For example, an order placed at 11 AM today will begin printing tomorrow, whereas an order placed at 9 PM tonight will begin printing the day after tomorrow.


Unfortunately, due to several restrictions, we are unable to ship to the following countries:

  1. Afghanistan
  2. American Samoa
  3. Belarus
  4. Brunei Darussalam
  5. Central African Republic
  6. The Democratic Republic of Congo
  7. Eritrea
  8. Guinea-bissau
  9. Iran
  10. Lebanon
  11. Libiya Arab Jamahriya
  12. Somalia
  13. Sudan
  14. Russian Federation
  15. Syrian Arab Republic
  16. Ukraine
  17. Venezuela
Modal Close icon
Modal Close icon