Case StudyImprove Mobile Support With Server-Side-Enhanced Responsive Design

Advertisement

In many ways, responsive Web design deserves a big share of the honor for making the Web more usable on non-desktop devices. This trend of letting the browser determine more about how a Web page should be displayed makes sense, especially now that mobile browsers are slightly more trustworthy than in the old days of mobile.

However, a responsive website is not automatically a mobile-friendly website. Amid the buzz of trendy Web development techniques, the good ol’ Web server doesn’t get the spotlight it deserves. Modern Web development should be about finding the right balance between server-side and client-side implementation.

Serverside or client side1
Find the right mix of client-side and server-side logic for adaptive Web design.

There is no one right answer to what should be done on the server and what should be done on the client side. That depends on the website in question. It is clear, however, that an either/or approach would fail to meet expectations. I will use a real-life project that my company is working on, with real requirements and pain points, as a reference. We are taking a pragmatic approach to the Web, starting with a blank sheet of paper to find the best solutions for both the technical and business requirements.

The Starting Point

Our client in this project is a large global news provider. Mobile is obviously crucial to it, because a large proportion of its audience doesn’t have access to a desktop device. Nevertheless, desktop access is just as important, and the solution needs to account for both.

Like many “forward-leaning” Web projects today, a general requirement was to consider mobile first2, from both a technical and business perspective. That means HTML5 and RWD (in its broadest sense), for starters. At the same time, because the client was a global content distributor, having tools that could handle less-capable browsers and devices (ones that don’t support the principles of RWD and HTML5) well was essential.

The real challenge in this project was to make the most of RWD techniques, but also to address some of the challenges of RWD from a mobile perspective. This is where the server-side part comes into the picture. Doing as much optimization on the server side as possible makes sense, to relieve the client of data transferring and the execution of logic in the browser.

The main reason for doing this is performance. Most of the time taken by a page to load3 is caused by the browser trying to make sense of the data being received. Being slow has a cost4, and every millisecond counts, regardless of the business model. Especially for big websites like our client’s, the cost of poor performance adds up to significant numbers. Even if you have many great polyfills5 that provide shims, with fallbacks for missing functionality in browsers, favoring speed, performance and maintainability over polyfills makes sense.

Another point in favor of server-side device detection is its support of different business models and other business requirements. Advertising and other third-party content is one example that is much discussed, but other requirements need to be met, such as customized experiences6 for specific devices, like the iPad.

With these considerations in mind, here are some of the requirements identified in our reference project:

  • No black box magic. The client needed to be able to control the full value chain.
  • Effortlessly integrated into the editorial process and CMS. Mobile had to be a part of the daily routine.
  • Fast page loading, to minimize data transfer and rendering time.
  • Easy for Web developers to use, regardless of the technology, to enable innovation and free thinking.
  • Support of business requirements, such as targeted business models and advertising and customized experiences for specific devices.

general requirements7
A summary of our requirements, which I believe are pretty standard for most current mobile-oriented Web projects. (Image: WPZOOM8)

The Approach

The logical way to approach this is to find a way to combine the best of RWD and client-side techniques with server-side functionality based on device detection. This is sometimes called RESS9 (responsive Web design with server-side components). The purpose of RESS is to do the heavy lifting on the server, making work easier for the browser, but also providing enough flexibility to meet any business requirements as described above. However, both RWD and RESS are parts of a bigger picture, sometimes referred to as adaptive design10.

Making the design adaptive, throughout the value chain, is our goal. Presenting content in a browser is only a part of the story. A lot of stuff happens to the content before it reaches the browser.

From a developer’s perspective, there are no real best practices or dedicated tools for these kinds of requirements. The wheel has to be invented — or at least developers have to be helped to decide which wheel to use when, and how to mount it to different vehicles.

We decided to address the lack of tools. Even if there are some emerging best practices for RWD and good ol’ device-detection software, there are no good tools for combining the two to address the current needs when developing for the ubiquitous Web.

During our project, we identified five areas where the server’s side could be put to work to enhance client-side techniques.

1. Use Your CMS

But first, the obvious. The most important server-side component is the content management system (CMS).

If you look back a couple of years, mobile Web development was done by mobile specialists who performed their magic. This is not the case anymore. Web design and development is now driven by Web developers, usually working within, or at least connected to, the client’s organization. This is important to note, because this rules out the traditional approach to mobile Web design, whereby a magic mobile-platform proxy black box produces the mobile website. These platforms are usually based on some sort of proprietary XML format, screen scraping or other custom stuff that has to be learned.

We’re going mobile, but we are not replacing our CMS.

Another reason why a mobile publishing platform is not an option is that it would interfere with the editorial process. Being in control of the content and its behavior is important. So, the CMS is key. Managing all online entities, mobile, desktop, TV and so on from the current CMS makes sense, but going mobile must not require the content owner to change their CMS.

A side effect of making mobile an integral part of content publishing, which was important for this project, is that the Web developers, those working with the presentation of content, are able to effortlessly account for mobile. Mobile becomes a natural part of their work.

The best way to utilize the presentation layer in the CMS and to power-charge it is to tackle a range of devices, operating systems, browsers and interaction models. This is what’s so great about RWD. You can apply the technique on top of any CMS. RWD should be the default baseline of all Web projects. RWD restores fluidity to the Web. For websites that display mostly text and little fancy stuff, it might even be enough to serve the purpose alone.

Because the CMS might be just as important as the browser in creating an adaptive website, the server-side components must also be capable of enhancing the CMS. This happens to be true of the next four server-side techniques we’ll look at.

2. Use A Device-Description Repository

In my own experience, avoiding the need for some sort of server-side device detection has proven difficult. A few tools are available for device detection. The WURFL-powered device-detection repository (DDR) provided by ScientiaMobile11 has been around the longest and is the basis for much of the server-side optimization in our project. However, even though ScientiaMobile provides an API to the WURFL database, we needed more flexibility and, so, built a RESTful12 API on top of it.

The device database can then be queried like this:

GET http://example.com/ddr/c/<WURFL capability here>

And the answer is returned in JSON format (asking for the device model):

HTTP/1.1 200 OK
Content-Type: application/json

{"model_name":"iPhone"}

With this simple API, device detection can easily be used directly from the browser, using AJAX, or from the server-side programming language. Moreover, it can easily be used with popular feature-detection frameworks such as Modernizr13.

The nice thing about doing this server side is that the same information is available both client side and server side (including the CMS). Furthermore, it also provides a way to store “tacit knowledge14,” defining how the client should tackle certain aspects of the website. Tacit knowledge can be stored as custom capabilities and accessed the same way as any standard WURFL capability. The service is accompanied by a JavaScript library that appends additional client-side detected data. This helps the service make sense of a request when traditional analysis of the HTTP header is insufficient.

Today, the type of markup is not important, and most of the adaptation has moved into the CSS, JavaScript and images. In general, there is no need to serve any markup other than plain HTML5. The only exception is certain markets around the world in which feature phones, rather than smart devices, are dominant. In these cases, we need enough flexibility to handle these devices by serving a particular markup such as XHTML MP15. The device-detection service will provide that.

A Note on Caching and CDNs

As traffic from mobile devices increases rapidly, caching and content delivery networks (CDN) become keys part of the value chain. Adapting the markup to each device type or user agent would lead to “cache pollution,” which basically means that the cache is too big to make any difference. Keeping the markup of a page as static as possible across devices is key. As mentioned, most optimization in modern browsers happens in CSS and JavaScript. Cache pollution is a relevant issue for those resources, too, but less critical because CSS and JavaScript are easier to cache in the browser and are also typically generic to the website (i.e. the whole website uses the same CSS, so the file needs to be cached only once to be served to all pages on the website).

3. Execute CSS Media Queries Server-Side

Media queries in CSS are one of the key parts of RWD. They are also one of the page resources with the most overhead when it comes to excess data downloaded16. A mobile phone will download and process styles meant for desktop devices, which can have a detrimental impact on speed and user experience. Of course, well-designed CSS will minimize the issue, but more can be done to reduce CSS overhead.

For this project, we decided to do two things:

  1. Execute media queries server side, based on what we know about the client, using the DDR.
  2. Take it a step further by turning the device’s capabilities into media features.

To illustrate the first point, styles in the following media query would not be served to an iPhone because the viewport would never be as wide as 1200 pixels.

@media screen and (min-width: 1200px) {
    /* styles here */
}

This requires a slightly different way of thinking and must, of course, be used with caution because breakpoints might never reach the client. Hence, CSS architecture is important.

The second illustrates the more powerful side of this, where device capabilities become media features:

@media screen and (pointing-method: touchscreen) {
    .button{
        padding:1em;    
    }
}

The above adds some extra padding to buttons to make them easily touchable on touchscreens. Another, perhaps more useful, example is the handling of fonts in CSS:

@media screen and (font-face: true) {
    @font-face {
      font-family: 'Rambla';
      font-style: normal;
      font-weight: 400;
      src: local('Rambla'), local('Rambla-Regular'), url(http://themes.googleusercontent.com/static/fonts/rambla/v1/4oKK3Z-EimNu4ISiv21vMuvvDin1pK8aKteLpeZ5c0A.woff) format('woff');
    }
}

Thus, all capabilities defined in WURFL17 are available for querying. Custom capabilities can also be added to the system to be made available as media features, too. Again, it’s a different way of thinking about styling. But it’s very powerful, especially for handling browser bugs, “undetectables” and “false positives” from feature detection (which are pretty annoying when they happen), and third-party content. Tests we performed indicated that up to two thirds of the data could be saved using this technique.

To comply with the requirements of the project, we decided to implement it in the markup like this:

<link 
href="http://example1.com/css/http://example2.com/path/style.css" 
rel="stylesheet" 
type="text/css" />

In this snippet, the service executing the media queries lives at http://example1.com/css/, and proxies the CSS located at http://example2.com/path/style.css, and then executes, caches and returns the CSS needed by the client.

4. Optimizing Images

Image optimization18 has been a hot potato lately. Until standards and support are established, and given that polyfills are not an option, the best way to optimize images is still to resize and prepare them server side.

The principle of image resizing is similar to CSS and has been proven to work with TinySrc (now Sencha.io19):

<img src="http://example.com/img/http://farm9.staticflickr.com/8154/7705240114_fdc69e5882_k_d.jpg" alt="Butterfly" />

In this example, the service will download and resize the image according to the screen size of the requesting device, and then cache and serve it to the client.

Being able to specify a size is also handy:

<img src="http://example.com/img/px_320/http://farm9.staticflickr.com/8154/7705240114_fdc69e5882_k_d.jpg" alt="Butterfly" />

But this is not very responsive. This is one of those times when we need to combine client-side feature detection with server-side logic.

Below is an example of a JavaScript add-on defining different breakpoints and communicating this to the server through a cookie.

if (vpw >= 1024) {
    vpw = 1024; //viewport
    bp = "w"; //breakpoint for current viewport
} else if (vpw >= 768) {
    bp = "m";
} else {
    bp = "n";
}

Then, we instruct the resizing service to behave differently according to the current breakpoint. In the image URL in our markup, we state that for breakpoint w, we want an image scaled to 80% of the viewport’s width. For breakpoints m and n, the values are 60 and 40%, respectively.

<img src="http://example1.com/img/vpw_768/bp_m/pc/w_80/m_60/n_40/http://farm9.staticflickr.com/8154/7705240114_fdc69e5882_k_d.jpg" alt="Butterfly" />

High-DPI screens are also supported through the @ notation:

<img src="http://example.com/img/px_300/@_2/http://farm9.staticflickr.com/8154/7705240114_fdc69e5882_k_d.jpg" alt="Butterfly"/>

As noted by Daan Jobsis20, a high-resolution image does not necessarily entail a ton of data, because the image could be compressed much more than a low-resolution image without a visible loss in quality.

5. Pre-Processing and Intelligent Caching

When addressing these issues, we noted that some tasks are “compile time” and others are “runtime.” Runtime tasks typically perform device detection on the server side to optimize something for a particular device or browser’s capability. Compile-time optimization handles the preprocessing of images, the minification of JavaScript, the preprocessing of Sass and LESS and so on. This can easily be implemented as Git hooks21. It enables an alternative workflow for Web developers, which might be more relevant for some, depending on the server’s configuration and architecture.

By using Git, the CSS, JavaScript and images (and even the page itself) can be pushed to a host (e.g. static.example.com) where static content would be served from. The static resources would, of course, be optimized runtime as well to enable the server-side media queries and image resizing. This way, the extra roundtrip for fetching the resource, as described above, is avoided, too.

This approach might seem to be a trivial detail at first, but if you think of it like a CDN or a cache for static content, it becomes very powerful. Suddenly, the cache becomes intelligent. You can perform tasks when pushing to the cache (compile time) and also do runtime optimization for the device or browser.

The Findings

To illustrate the findings, I have made a demo22 based on one of the examples that comes with Twitter Bootstrap23 and that puts the server-side components to work. The demo is very simple, and much more adaption of Bootstrap should be done, but it illustrates the findings well.

The diagram below shows the distribution of different content types tested in a desktop browser and on an iPhone with Safari. The most obvious difference is the savings we get when optimizing images.

weight of content types24
Distribution of content types

Faster and Leaner

The overall result is that we can definitely save time and money by letting the server help the client with adapting the content and presentation:

Desktop iPhone
Page size  927.1 KB  338.8 KB
Rendering time (onload)  6.6 seconds  4.64 seconds

The page for an iPhone is only 37% of the total page weight of a desktop client. The page also loads faster on the iPhone. It is not the fastest page to begin with, but a 30% increase in speed is a good start.

Yes, many factors come into play that can influence the tests’ results, but the tests prove that knowing who you are talking to at the other end pays off25.

With this approach, we think we have been successful in designing a system that solves the current issues involved in getting the Web to work on different devices as well as in providing Web developers with useful tools to support their goals. The server can definitely improve the performance of RWD and other client-side techniques on mobile devices!

As standards emerge and as devices and networks improve, some issues will disappear, but new ones will pop up as the Web becomes more diverse. Handling diversity is a question not so much of whether to do things server side or client side, but of how to make the whole value chain as intelligent and adaptable as possible to prepare for the unknown — all the way from creating the content to caching to rendering in the browser.

During the project, we became so excited by the results and possibilites that we decided to make the tools available to Web developers out there. Because the project is still ongoing, we haven’t launched yet, but if you think the approach described here is worth a try, you can sign up at WhateverWeb26 to get early access. (It’s free, but we’d just like you to tell us what you think.)

(al) (ea)

Footnotes

  1. 1 http://www.smashingmagazine.com/wp-content/uploads/2013/04/serverclient.png
  2. 2 http://www.lukew.com/ff/entry.asp?933
  3. 3 http://www.webperformancetoday.com/2011/04/20/desktop-vs-mobile-web-page-load-speed/
  4. 4 http://www.slideshare.net/stubbornella/designing-fast-websites-presentation
  5. 5 http://en.wikipedia.org/wiki/Polyfill
  6. 6 http://www.lukew.com/ff/entry.asp?1509
  7. 7 http://www.smashingmagazine.com/wp-content/uploads/2012/12/smg-req.png
  8. 8 http://wpzoom.com
  9. 9 http://www.lukew.com/ff/entry.asp?1392
  10. 10 http://bradfrostweb.com/blog/mobile/beyond-media-queries-anatomy-of-an-adaptive-web-design/
  11. 11 http://www.scientiamobile.com/
  12. 12 http://en.wikipedia.org/wiki/Representational_state_transfer
  13. 13 http://modernizr.com/
  14. 14 http://en.wikipedia.org/wiki/Tacit_knowledge
  15. 15 http://en.wikipedia.org/wiki/XHTML_Mobile_Profile
  16. 16 http://scottjehl.github.com/CSS-Download-Tests/
  17. 17 http://scientiamobile.com/wurflCapability/tree
  18. 18 http://www.alistapart.com/articles/responsive-images-how-they-almost-worked-and-what-we-need/
  19. 19 http://www.sencha.com/products/io/
  20. 20 http://blog.netvlies.nl/design-interactie/retina-revolution/
  21. 21 http://git-scm.com/book/en/Customizing-Git-Git-Hooks
  22. 22 http://mpulp.mobi/labs/smg/
  23. 23 http://twitter.github.com/bootstrap/
  24. 24 http://www.smashingmagazine.com/wp-content/uploads/2012/12/stats-dtvsip.png
  25. 25 http://www.slideshare.net/stubbornella/designing-fast-websites-presentation
  26. 26 http://whateverweb.com/

↑ Back to topShare on Twitter

Jon Arne is a mobile guy. He has been an active member and thought leader in the global mobile community since the late nineties. Jon Arne is a developer by trade, and truly believe that the key to success is a happy end user, and that innovative use of technology will help achieve that truly optimal user experience. Coding now is just done for recreation as he is now heading the Innovation and Products team at Mobiletech, a leading mobile software and services company, which he also invented and co-founded. Jon Arne is also an occasional writer, blogger and speaker. Tweets as @jonarnes.

Advertising

Note: Our rating-system has caused errors, so it's disabled at the moment. It will be back the moment the problem has been resolved. We're very sorry. Happy Holidays!

  1. 1

    Great post Jon. But I would like to highlight the importance of evaluating the capabilities of your server. Like mentioned above this method probably works best for large sites with budget for fast servers and good device detection.

    However, if you run a small site on a shared machine all of the savings in download size could be offset (or even worsened) by slow response time of a machine trying to chug and compile every users’ request. In this case heavy reliance on users’ device computing is the only sensible way (especially considering how fast those handsets are getting lately).

    Be careful my friends.

  2. 2

    “A responsive website is not automatically a mobile-friendly website.”

    …so glad to see people acknowledging that developing for different devices is about more than just chucking a few media queries at a site!

  3. 3

    I would rather call it an “adaptive design” as the CSS part makes the website adapt to the conditions of its host device. Anyways, a nice and informative share indeed!

  4. 4

    I really like your server-side CSS management idea. Potentially write your CSS with media queries, but strip out what isn’t necessarily needed with the current device, and obviously end up with a minimized/optimized CSS file.

    I agree with a previous response that stated this is probably best for larger sites with dedicated resources. Beyond the technological reasons, I would also point out that smaller sites often also have smaller budgets and developer resources. Trying to fit this much more optimized (and in some ways complicated) solution may be too much for those websites…at least until there is an easily installed package like the author’s WhateverWeb tools.

  5. 5

    I’ve given many seminars on how to accelerate your web/mobile application performance. But must say, that this link articulates several aspects that can help accelerate the loading and response times.

  6. 6

    Jon Arne, this is one great article.

    It is by now obvious to most that RWD’s value proposition is so strong that many companies (including enterprises) will hardly resist it. Yet, it remains a fact that, on a mobile device, a mobile website will load faster and be more usable than a RWD site. Period.

    Where do we go from here? well, you said that in your article, and in all honesty, it seems the right (and smart) way to go: Embrace RWD, but figure out a strategy to have the server help, by removing as much unnecessary fat as possible upstream.

    It seems to me that you and your team have found a sweet spot with your server-side media queries. Very elegant. I’m impressed. Keep up the good job!

    Luca Passani

    [Disclaimer: I am the WURFL inventor and ScientiaMobile CTO. Opinion is biased]

  7. 7

    My reading of the WURFL pricing is that the absolute minimum is $1500/year. It sounds like your client is operating at a sufficient scale where the WURFL expenses are not a factor, but for many projects this is going to be a tough pill to swallow. I find that the “lite” capabilities in the free offering from 51degrees offer a viable alternative (granted, with less information on each device) that works well for my needs.

    As an aside, I found it ironic that the ScientiaMobile website was essentially un-navigable on my Android Galaxy Nexus. The “responsive” menus pop down and immediately pop back up before they can be selected.

    • 8

      Hi ScientiaMobile CTO here.

      This comment forces me to clarify a couple of things.

      Your mention of ScientiaMobile’s pricing is absolutely out of context here, and it seems like a marketing move to promote a competing products (one that totally mimics WURFL, to be clear, and that started off by importing the WURFL repository) and it does not add anything to the article.

      For sake of clarity, WhateverWeb has of course licensed WURFL and users of WhateverWeb will be legitimately using the platform irrespective of what the price of a single license for WURFL is.

      As far as your mention of our website goes, we did test on the Nexus and we found that the menu is still ‘operatable’ on that device, albeit I would agree that it does not look too nice. We decided to leave it this way. The good news is that, if we wanted, we could easily switch on the fully-expanded menu with a server-side configuration. If anything, your comment proves the author’s point: RWD is cool, but enterprises will need more if they want to gain full control.

      Luca Passani

      • 9

        Thanks for responding. To clarify, I have no interests or relationships in either company. I’m just a small one-man shop building a couple of web sites. I’ve used both products (I only used WURFL back when it was free) and they both do a great job of giving you information on device capabilities.

        Respectfully, I don’t think my comment on pricing is out of context. The article suggests WURFL is a great solution, and I agree it is for an enterprise or other large scale implementation where software licensing costs are not a major driving factor or where the need for more depth in device capability information makes the price worthwhile. For small sites or projects, the lack of any option below $1500/yr is a major knock against WURFL. Given that there really are only two players in this market (that I know of), it is worth looking at the alternative.

        • 10

          Pat, your remark that you are not affiliated with the company is noted. Please allow me to comment that $1500 a year is by no means the only option for small companies. Our Cloud offering is available at $40 and $10 per month ($480 and $120 per year respectively), with the advantage of an always updated WURFL. If your use of WURFL is limited, we even offer Cloud access free of charge.
          But that’s not all. If someone has a legitimate use of WURFL and they can explain why $1500 is such an obstacle (non-profit, academia), we are willing to offer great discounts also on our standalone (OnSite) API (we have done this a few times in the past).
          So, I would be careful in representing what the price of WURFL is in a public forum, particularly when the “less expensive” alternative you mentioned was derived from WURFL to start with.

          Thanks

          Luca Passani

          • 11

            I hate to say it Luca, but you are sounding a bit patronising.

          • 12

            Dominic,

            ScientiaMobile is running a honest business. What should one do when someone misrepresents his/her company offer in a public forum?
            Anyway, I don’t see the patronizing. I was only trying to set the record straight.

          • 13

            I’ve checked out WURFL. I haven’t had a need to embrace RESS to such an extent yet, as we’re not doing high traffic publishing sites. I think those are best-suited to that degree of optimization.

            WURFL’s pricing is absolutely a factor in its applicability. I don’t object to any business being compensated for value. WURFL is a big investment for many people reading these articles, though.

            I appreciate that the cloud offerings offer a lower-cost alternative. But when we’re talking about performance optimization via RESS, I get nervous with incorporating a third-party API call into a solution as requisite to render a page. For all the safeguards you may have in place, latency and downtime do still occur. This applies to any third-party components, such as Typekit. CDNs offer performance optimization by caching the same resources and pushing them to the edge, but I still prefer to host fonts on the site’s server as often as possible on smaller projects.

            Again, I think WURFL is an admirable effort, and something that I would justify for a client with high traffic, performance and content accommodation requirements.

            I also think its costs should 100% be part of the conversation.

          • 14

            Mark, excuse me, but I have to insist.

            I am not sure why, in the comments, the focus has moved from Jon Arne’s good article on RWD and RESS tools to WURFL pricing. As I have explained, while Jon Arne’s solution does use WURFL under the hood, the regular WURFL pricing is completely irrelevant, because this aspect has already been handled for adopters of the product described by Jon Arne totally transparently for them.
            I understand that someone may think that apples sold at a certain grocery are expensive. Here we are talking about a restaurant that appears to be offering great value for money. People have gone out on a tangent because the restaurant has mentioned that they buy apples for their apple pie at the expensive grocery. This is totally irrelevant!!!

            Please go back to discuss the merit of the solution discussed in the article.

            Luca

            PS: Apologies to Jon Arne for the direction this thread has taken.

      • 15

        James Rosewell (51Degrees.mobi founder) here adding some facts about 51Degrees.mobi…

        Since December 2011 51Degrees.mobi has not used WURFL data. An entirely different data model and maintenance system is used to achieve 99.9% detection accuracy plus fast and consistent results. No data from WURFL was used to create the original data set. An 18 strong team of people were employed and trained to create the database from a clean sheet. 4 people are now employed maintaining the data every week.

        51Degrees.mobi uses the cloud to automatically update locally stored and processed data each week. Real time device detection via cloud services is not offered by 51Degrees.mobi as the performance penalty is too high. There is a great blog post on our web site relating to the reasons why which i won’t repeat here.

        Whatever solution you choose let’s all work to make great user experiences on every device using RESS techniques as highlighted in the original case study when appropriate.

      • 16

        James Rosewell (51Degrees.mobi founder) here adding some facts about 51Degrees.mobi…

        Since December 2011 51Degrees.mobi has not used WURFL data. An entirely different data model and maintenance system is used to achieve 99.9% detection accuracy plus fast and consistent results. No data from WURFL was used to create the this data set. An 18 strong team of people were employed and trained to create the database from a clean sheet. 4 people are now employed maintaining the data every week.

        51Degrees.mobi uses the cloud to automatically update locally stored and processed data each week. Real time device detection via cloud services are not offered by 51Degrees.mobi as the performance penalty is too high. There is a great blog post on our web site relating to the reasons why which i won’t repeat here.

        Whatever solution you choose let’s all work to make great user experiences on every device using RESS techniques as highlighted in the original case study when appropriate.

    • 17

      Jone Arne did not write “Use WURFL”, but “Use A Device-Description Repository”. You might as well use Device Atlas, or DetectRight — but if you find WURFL expensive, you are not going to find those other solutions cheap either. Otherwise try 51 degrees. Or Handsetdetection.com. Whatever. A professional uses the right tool for the job, within performance, functionality and, yes, as you point out, budget constraints. After all, CDN are mentioned in the article — they cost money too. Notice that Jone Arne is talking about his experience with “a large global news provider” — they had the necessary budget, and the approach proposed is best suited for medium to large sites, as other commentators stated.

      This being said, I liked the article very much. Content adaptation ensuring usability, performance and coverage of a wide range of terminal types is just too complicated a task for developers to be dogmatic (as exemplified by “never use server-side device detection”). The combination of client-side responsive design with server-side content adaptation seems ideal, and the solution is clever (I liked the server-side extended media queries relying upon the full DDR attribute dictionary).

  8. 18

    I’ve also been pondering if the best way to optimize images is to resize and prepare them server side … in the current climate of increased DOS attacks and Database injections however, is this actually a good premise?

    Part of running a good website should also be to anticipate operational quotas, and allowing the possibility for Bots to fill our servers by exploiting such server side-generated content is a worry to me, and a potential problem waiting to happen.

    I guess a way around it would be to allow for a handful of anticipated image dimensions and calculate those against the number of images available pre-launch (but for a CMS-managed website where users can keep uplaoding images however, this could be more of a challenge).

    If in 18 months, 4k or even 8k resolution displays appear, what happens to all the website users that have already uploaded (or simply might never have such resolutuon images in the first place) …. there will be potentially low resolution images on websites as we still see on new iPads today. Could the images look better in higher resolution? yes, of course, but technology innovators seem to have our backs covered and make alot of choices on developers behalf by making such decisions … higher resolution devices like the new iPad could have just sized images down instead and waited for eveyone to start re-uploading their images again, but as this is not the case I am inclined to think the reason Apple didn’t is because the final solution was easier for everyone as a whole, which makes me think coming up with hacks is an awful lot of effort, which could be complete overkill in 18 months, all becuase we’re impatient (the high resolution device market seems to be okay with how it is at present and I think that kinda says everything to me – especially in 18 months).

  9. 19

    I’m still in doubt about this whole server-side RWD thing. I think it is clear that it can cut major fat by conditionally loading resources, the numbers prove it, but I do have some thoughts about it:

    – Conceptually, and this is merely a theoretical point, it does not feel “right” to me to load different markup and other elements based on a device for the same URL. In a way it goes against the basic concept of a URI.

    – I think when you are building server-side frameworks to do conditional loading of text (html, css), resources that should be cached aggressively, you are at the very end of performance tuning, having solved issues far bigger than that. I wonder what the real win is of selective text loading is versus the “cost” of adding complexity on the server-side, knowing that almost all page weight does not come from text, especially not cached text.

    – Regarding images, personally I have achieved spectacular results using Daan Jobsis’ method: high PPI images that scale from mobile to desktop whilst still being small/acceptable in file size. Therefore, in my own project I am not doing conditional image loading at all, at least not in the mobile to desktop range. I’m not saying it works in every situation, but in my experience it works quite well. This can reduce the need to load images server-side.

    – This is not to say that conditional loading on the server is bad. I have used it before where an embedded Google map was unusable on mobile, therefore I only showed the location text there, whilst bigger viewports would receive the full map. I’m just saying that it does not feel right to me, and that my opinion is to be conservative in this aspect.

    – Regarding device detection, I am against it, as the whole point of RWD is to move away from devices. However, in your case device targeting was a customer requirements, which leaves you little choice. I’m currently working with a simple alternative: my javascript sets cookies about device properties (such as viewport width), not devices, which I then read from the server. This is basically server-side feature detection, instead of device detection. It is possible that the cookie is not set, for whatever reason, after which the server-side code just gives the non-optimized, default markup and resources.

  10. 20

    I would rather call it an “adaptive design” as the CSS part makes the website adapt to the conditions of its host device. Anyways, a nice and informative share indeed!

  11. 21

    Edward Robertson

    April 16, 2013 7:22 am

    I agree with using a mobile-first approach but it’s not possible without major hacks until the likes of IE6-8 die out. If you’re starting out in responsive web design and want to know if your site is mobile friendly you can use sites like http://www.iammobile.co.uk though.

  12. 22

    If you are going for best contents like me, just pay a quick visit this site all the time for the reason that it gives feature contents, thanks

  13. 23

    Great read! I have always has problems with clients side and duplicate # ID’s, Servers sided responsiveness (if you can call it that) could solve my problem! I’m going to have a go at using it on my website! http://www.pixology.net/

  14. 24

    I have gone through extensive research reports and trends on designing, and RESS seems to be the top recommended forward looking design practice across all design forums

    However after going through the comments posted by pro designers on RESS, I am having second thoughts about implementing RESS to my new private social networking website.

    How practical is RESS to build a new private social networking strartup on a limited budget say $2k-3k at pre-funding stage ?

  15. 25

    Great post, thanks! These are exactly the issues I have been struggling with. Media queries are great but not enough. Although this article is a bit outdated now: http://blog.cloudfour.com/css-media-query-for-mobile-is-fools-gold/

  16. 26

    This is one approach but the same results can be achieved without changing the server side at all. This approach just shifts some complexity to the server side which in the end leaves less flexibility on the Frontend.

Leave a Comment

Yay! You've decided to leave a comment. That's fantastic! Please keep in mind that comments are moderated and rel="nofollow" is in use. So, please do not use a spammy keyword or a domain as your name, or else it will be deleted. Let's have a personal and meaningful conversation instead. Thanks for dropping by!

↑ Back to top