A Client- And Server-Side ApproachProviding The Best Mobile User Experience Possible

Advertisement

Now and again, I hit the swimming pool. It’s a good way to exercise, but also to relax after a long day in front of my PC. I can do quite a few laps in my front crawl, but only because I don’t use my legs much. I kick steadily to ensure that my legs stay lifted and don’t slow me down. I don’t use my legs much for forward propulsion. An instructor once explained to me that legs can definitely help with propulsion in the front crawl, but only at the cost of much higher energy consumption.

He also explained that champions use their legs a lot. Their hearts are powerful, and they can happily sacrifice the extra effort for the small yet significant gain in speed. People with modest competitive ambitions are typically better off with moderate leg usage.

Does this relate to mobile Web development, responsive Web design and server-side device detection?

The analogy is a stretch, but yes, it does. As the inventor of WURFL, I used to live in a world where mobile devices were so limited in capabilities that there was no way a commercial website and its corresponding mobile website could be supported through a unique set of HTML pages without the support of some server-side logic. Strategies to detect and tweak content for mobile devices varied from simple detection scripts to the adoption of full-fledged device description repositories (DDR) such as WURFL.

Today, things have, to a large extent, changed. Many still have a feature phone, but the majority of users who care about accessing the Internet from their mobile devices will have a smartphone. A 2013 smartphone means the following: a quite fast connection, a great WebKit-based browser, a 320-pixel wide (or wider) touchscreen and a great operating system that allows for the installation of apps.

This evolution has turned the mobile Web into a swimming pool available to every Web designer. Programming strategies such as progressive enhancement (PE) and responsive Web design (RWD) enable everyone to make their full websites usable enough on smartphones from a single set of HTML pages — i.e. with no need for server-side device detection. This is awesome. Webmasters can now make their websites more mobile-friendly without introducing a significant amount of extra complexity. Yet, just like in my initial analogy, the saving is only achieved at the cost of sacrificing certain aspects of the mobile UX that “champions” would not be OK with sacrificing.

In a previous article by Ronan Cremin and me, “Server-Side Device Detection: History, Benefits and How-To,” we explored the different aspects of client-side approaches versus server-side approaches, and we concluded that server-side strategies still offer a lot to mobile Web developers. I won’t repeat it here; rather, I will go one step further and explain how the two worlds can happily coexist for everyone’s benefit.

Client-Side Vs. Server-Side: A False Dichotomy

Most IT people are familiar with the saying, “When all you have is a hammer, every problem looks like a nail.” This is perfectly applicable to mobile development, where, in my experience, developers with a JavaScript and CSS background tend to favor client-side solutions to the problem of device diversity, while developers with traditional system development skills find server-side approaches more natural.

Unsurprisingly, there are pros and cons to both approaches, and, more importantly, the two approaches are not mutually exclusive and can be made to work together. After all, for any organization that offers a website, the ultimate purpose is to create the greatest user experience possible for its users within the constraints of the project’s timeline and budget.

Best Of Both Worlds

When it comes to building a strategy for a website that is friendly to mobile users, there is a whole range of possibilities. At one extreme, a designer might adopt a purely responsive website because they cannot afford to maintain a server-side detection component (or simply because they do not find enough value in the extra complexity). At the other extreme are large companies whose websites (and mobile websites) address particular quirks of popular devices. This approach requires an investment and dedicated team so large that typically only major Internet companies (think Facebook, Yahoo and Google) would go for it.

Most other companies will find the optimum point somewhere between the two extremes by segmenting the world of connected users in ways that make the most sense in their markets. Such segmentation will need to rely on some form of server-side detection.

One way to put it is that one should adopt a “best of both worlds” hybrid approach. In this article, I will show an example of this.

Every software project is one-off. The Web is no exception. Nor is mobile Web development, where the super-rapid progress of mobile devices is constantly turning best practices into moving targets. For this article, I figured that nothing could make the point better than a real example with real code.

My example is a cross-browser and cross-device slideshow. I will show how server-side and client-side detection can be made to work together to deliver a great UX on a variety of clients.

Segmentation (Good Ol’ Divide And Conquer)

The slideshow will be made available to the following classes of HTTP clients:

  • non-smartphones (or feature phones),
  • smartphones,
  • tablets and desktops.

I have always called these “segments,” and I have referred to the splitting up into segments as “segmentation.” The key point is that each segment will be provided with a fundamentally different UI structure. Such segmentation will be supported through server-side detection.

Within each segment, there will still be space for further optimization of the UX. Such optimizations will happen with RWD and device detection. Notably, this approach will be used to obtain pictures in different sizes and to address the bandwidth problem, particularly for mobile devices.

Let’s start by sketching the different UIs for the different classes of HTTP clients (i.e. segments).

Non-Smartphones

Non-smartphones are commonly referred to as feature phones in the industry. There is no standard definition of what a smartphone is, but a device that possesses the following features would likely be called a smartphone by most:

  • touchscreen;
  • a screen that is 240-pixels wide or wider;
  • Android 2.2, iOS, Windows Phone 7.5 or higher, RIM OS 7 or higher, Symbian Belle or higher, Nokia N9 WebKit-based browser;
  • not a tablet.

This is a totally arbitrary definition, but good enough for the purpose of this article.

Devices that do not support one or more of the above features will be considered feature phones.

Because no assumption can be made for non-smartphones, we will assume a small screen, no touchscreen and limited bandwidth (which entails the need to minimize the number of HTTP requests required to download all of the content).

Please note that the lack of a touchscreen might require users to click the “down” button multiple times to get to the icon they wish to select.

The following wireframe nicely illustrates what we are getting at:

feature phone view
Feature phones (i.e. non-smartphones) have relatively small screens (typically narrower than 240 pixels). The presence of a touchscreen should not be assumed for devices in this segment.

Smartphones

Smartphones have a large screen, and users don’t have to click their way through icons to get to the one they want. They simply touch it. Because of this, a UI such as the following is better suited to them:

smartphone view
Smartphones have large screens (240 pixels or wider). The presence of a touchscreen and of basic media queries for changes in orientation may be safely assumed.

Tablets and Desktops

In the case of tablet and desktop browsers, we can safely assume that a large screen is available. In this case, consolidating the two views (i.e. the navigation and the actual picture) into a single screen makes sense:

tablet view
A screen 700 pixels wide (or wider) may be assumed.

Of course, I created a single segment for tablets and desktops for illustrative purposes, but a real project might segment differently, based on the business model of the organization and the traffic it sees from different classes of devices.

Before delving into the code to implement this, I should discuss a few aspects of mobile development.

Important Note About Mobile Bandwidth: Speed Isn’t Everything

US carriers (i.e. network operators) boast in their advertising about their increasingly faster 4G networks and the blazing download speeds that their customers can get. My experience (and the experience of others) is that those figures are sometimes truthful under good network conditions, as in the case of a large single download or of video streaming. In practice, things are a bit more complicated. The overhead of establishing an HTTP connection in mobile is high.

Many browsers and devices open only one or two concurrent connections with the server (partly because of what the HTTP specification says, and partly because of hardware limitations). Keep-alives cannot be assumed to always work as one would expect in mobile, because of strategies that the devices follow to save battery power.

The problem is at the lower levels and is rooted in the fact that mobile networks and TCP/IP were not built to play well together to begin with.

Techniques such as “domain sharding” (i.e. fooling the browser into believing it’s talking to different servers) help to increase the number of concurrent connections. However, if you want to increase the download speed (both real and perceived) of a website, limiting the overall number of HTTP connections is your best bet.

May Your Days Be Merry And Your URLs Unique

People share links on Twitter, Facebook, Google+ and a lot of other services these days. This is good, but it has also exposed a shortcoming with a popular approach to managing the mobile channel — i.e. creating a separate mobile website (with separate URLs to the mobile view of the content). In short, a user will share http://m.coolsite.com on Twitter, and users on desktops and tablets will be offered a sucky UI. Having http://www.coolsite.com serve both the Web and mobile experience would effectively solve the problem.

As my last article explains, there are ways to have a single URL “multi-serve” content for different media. Of course, this requires a bit more design and work from the service architect as compared to purely client-side approaches.

In the case of PE and RWD, the “uniqueness” of the URL comes free of charge. In the case of server-side detection, a strategy to multi-serve content from a unique URL needs to be designed into the system. We will see one way to achieve this in the code discussed further down.

Content = Content + Presentation? A Little (But Important) Aside

Ethan Marcotte, arguably the inventor of RWD, correctly identifies the URL issue in his book Responsive Web Design:

“I do think fragmenting our content across different “device-optimized” experiences is a losing proposition, or at least an unsustainable one.”

This sentence has been quoted endlessly, and it seems hard to disagree with. Yet, it contains an ambiguity that makes it very debatable, to say the least. What Ethan calls “content” has historically been referred to as “presentation” by most. In fact, I could easily argue that separation of content and presentation is the foundation of a plethora of Web programming frameworks, such as model-view-controller (MVC), but also Windows DNA in the late ’90s.

While I am aware that designers will argue that the difference between content and presentation is blurry (advertising is the best example of this), such a differentiation has been very helpful to Web programmers in multiple ways over the past 15 years. In general, professionals are much better off preserving this separation, rather than blurring the difference between the two.

Software architects should obviously not fragment the content managed by their system. At the same time, they should be ready to multi-serve the presentation of the same data to users of different media and different devices in the name of an optimal UX. I would go so far as to argue that PE and RWD are also about providing multiple presentations of the same content, inasmuch as the clever use of grids and media queries allows developers to confine the “multi-serving framework” to a single page.

End of the aside.

Getting back to URL uniqueness, it is obvious that, in the case of server-side detection, a URL strategy must be designed with extra use of resources. Of course, webmasters have managed similar issues all their careers. Internationalizing a website presents the same challenges: one could have content served in multiple languages from the same URL (or even JSP or PHP page) or simply provide sibling websites, one for each supported language. Support for the potential lack of JavaScript presents a similar issue, as does the fact that an international content provider may wish to offer different (i.e. more relevant) content to visitors from different geographic regions, even where the language is the same. Supporting this means extra effort and cost. Typically, after the cost versus benefit equation is solved, some companies will go for the benefit in spite of the cost.

After so many words, let us see how the following code implements everything we’ve illustrated above.

The Code

Everything that has been discussed so far is illustrated in practice with a self-contained example that I built (along with my friend Steve Kamerman, COO at ScientiaMobile) to reinforce the points in this article. Be aware that, for the sake of clarity, the example hardwires many of the resources that would normally be isolated in separate databases or configuration elements.

Here is a list of the main components in the code:

  • a DDR;
  • an MVC framework;
  • a controller with the segmentation logic;
  • a server-side image-resizing framework;
  • the views — feature phone, smartphone and tablet/desktop, in our case.

Let’s discuss each of them.

Device Description Repository

A DDR is a software framework that enables an application to associate an HTTP request with the properties of the client (Web browser, mobile device, Internet-enabled wristwatch, etc.). In our example, I will be using ScientiaMobile’s DDR, WURFL Cloud, because it’s the easiest to install on all platforms and also comes with a free offering for those who want to play around with it.

Of course, any other DDR could be used in place of WURFL Cloud, including AGPL-licensed WURFL or other open-source frameworks based on user-agent string analysis through regular expressions.

For the purpose of this article, here is the core bit of code that explains how to use the DDR (in the index.php file):

:
require_once dirname(__FILE__).'/lib/WurflCloudClient/Client/Client.php';
  :

// Disable caching for testing
$cache_enabled = false;

$wurfl_config = new WurflCloud_Client_Config();
$wurfl_config->api_key = 'XXXXX:YYYYYYYYYYYYYYYYYYYYYYYYYYY';
  :
if ($cache_enabled) {
	$wurfl = new WurflCloud_Client_Client($wurfl_config);
} else {
	$wurfl = new WurflCloud_Client_Client($wurfl_config, new WurflCloud_Cache_Null());
	header("Cache-Control: no-cache, must-revalidate");
	header("Expires: Sat, 26 Jul 1997 05:00:00 GMT");
}
$wurfl->detectDevice();

Note: The cache is disabled because this is handy for testing purposes. But you’ll want to enable it on a production website, or else every HTTP request from your users will be a request to the cloud.

Once this code has run, you will be able to look up device capabilities on your server, without any need to interact with the client through JavaScript or the like, as simply as this:

$wurfl->getDeviceCapability('is_tablet')

All of the magic of looking up the HTTP request and recovering a profile for the device is happening under the hood.

Model-View-Controller Framework

MVC is a popular programming pattern among Java developers that over the years has made inroads among programmers of other languages (including PHP). In short, the MVC framework analyzes an incoming HTTP request and “dispatches” the actual handling to a different PHP page that has been deemed to be more apt for the job. In our case, the framework will route the HTTP request to the PHP page that would implement the best UI for that “segment.”

For the record, the MVC framework we’re using in our example is homemade, but Steve explains that it was inspired by a micro-framework named Silex.

The framework itself is implemented in the lib/SimpleApp.php file:

require_once dirname(__FILE__).'/lib/SimpleApp.php'; 
  :
$app = new SimpleApp();

Once the MVC framework is included, dispatching an HTTP request to the right view (see below) is as simple as this:

$app->render('image/smartphone.php', $view_data);

The interesting part is that the URL will not be affected by this. Users will only see the index.php page that responded to the request. This effectively solves the problem of URL uniqueness that we discussed above.

Controller

The controller (the “C” in MVC) is in charge of segmentation (i.e. deciding the view to which a certain HTTP client should be directed based on its profile). Here is the core of the controller (in index.php):

if ($wurfl->getDeviceCapability('is_smartphone')) {
	$app->render('index/smartphone.php', $view_data);
} else if ($wurfl->getDeviceCapability('is_mobile') 
&& !$wurfl->getDeviceCapability('is_tablet')) {
	$app->render('index/featurephone.php', $view_data);
} else {
	$app->render('index/desktop.php', $view_data);
}

In light of what we have explained, this part should be rather self-explanatory: smartphone.php handles smartphones, featurephone.php handles feature phones, and everything else (including tablets) is handled by desktop.php. There are actually two sets of views, one that manages the discovery page (i.e. the thumbnails with pictures) and one that represents the single picture.

The is_smartphone capability is a so-called “virtual capability” — i.e. a computed property that relies on other capabilities and that represents ScientiaMobile’s understanding of what a smartphone is. A lot of people find this handy. Of course, nothing prevents a WURFL user from choosing the capabilities and rolling a particular segmentation that make the most sense for their business model.

Image Resizing (RESS)

RESS stands for “responsive images and server-side components,” making it the most screwed-up abbreviation I have ever seen in my life. Because it is now common, though, I will use it, too. The premise of RESS is fairly reasonable: RWD is cool, but sending 500 KB pictures to a mobile device is not a good idea for a variety of reasons. This is why even the most inveterate RWD promoters will concede that resizing pictures on the server in order to speed up downloading and rendering on mobile devices is still a good idea. Of course, CSS and JavaScript files are also resources that you’ll want to make as light as possible. These also fall under the RESS umbrella.

Users of WURFL Cloud also have access to a service called Image Resizer. In short, Image Resizer enables you to create a URL that piggybacks the following bits onto itself:

  • the URL of the original picture,
  • a combination of parameters that specify how the picture should be resized and manipulated.

Requesting the URL will result in a picture with the desired features being obtained. For the record, other services of this kind are around, such as Sencha.io Src and the up-and-coming WhateverWeb, which promises to go beyond simple image resizing. Call me a romantic, but I prefer that we eat our own dog food for this example.

A photographer also graciously gave me some pictures of Chicago for this article, which I’ve hosted at http://cto.scientiamobile.com/chicago/ (i.e. in a place where Image Resizer can pick them up):

Let’s see how Image Resizer is used in practice (see views/index/smartphone.php):

// Compute the size of the image thumbnails
$thumb_width = 95;
$thumb_height = 95;
$rszr_tumbnail = "http://rszr1.wurflcloud.com/234341/w_$thumb_width/
                  h_$thumb_height/m_cropbox/";
  :
<div style="width: 100%; float: left; margin: 5px;">
  <?php foreach ($images as $id => $image) { ?>
   <div style="float: left; margin: 5px;">
      <a href="<?php echo $app->getUriPrefix().'/image/'.$id; ?>">
        :
       <img alt="" src="<?php echo $rszr_tumbnail.$image['src']; ?>" />
      </a>
    </div>
  <?php } ?>
</div>

This will generate markup like the following snippet:


<div style="float: left; margin: 5px;"><a href="/smash/image/1"><img alt="" src="http://rszr1.wurflcloud.com/234341/w_95/ h_95/m_cropbox/http://cto.scientiamobile.com/chicago/chicago2.jpg" /></a></div>

In reality, I’ve cheated a bit. I cut some interesting bits from the code above. In particular, I’ve removed a trick to use a really important technique called the data URI scheme, which enables developers to nest pictures in the HTML itself in the form of ASCII Base64 garbage. As you can imagine, not all devices support the feature (although smartphones usually do). This is where WURFL’s image_inlining capability, along with the ability of the image resizer to provide the picture already in Base64 format, comes in handy. The image_inlining will tell you whether the data URI scheme is supported:

$image_inlining = $wurfl->getDeviceCapability('image_inlining');
if ($image_inlining) {
	$rszr_tumbnail = "http://rszr1.wurflcloud.com/234341/w_$thumb_width/
                         h_$thumb_height/m_cropbox/in_true/"; } else {
	$rszr_tumbnail = "http://rszr1.wurflcloud.com/234341/w_$thumb_width/
                         h_$thumb_height/m_cropbox/";
}	
  :
<div style="width: 100%; float: left; margin: 5px;"<
<?php foreach ($images as $id => $image) { ?>
  <div style="float: left; margin: 5px;">
    <a href="<?php echo $app->getUriPrefix().'/image/'.$id; ?>">
    <?php if ($image_inlining) { ?>
      <img alt="" src="<?php echo file_get_contents($rszr_tumbnail.$image['src']); ?>"/> 
    <?php } else { ?>
      <img alt="" src="<?php echo $rszr_tumbnail.$image['src'];?>"/> 
    <?php } ?> 
  </a></div>
<?php } ?>
</div>

In the case of a device that supports image inlining, the code above will produce the following:


<div style="float: left; margin: 5px;">
<a href="/smash/image/1"> <img alt="" src="data:image/jpeg;base64,/9j/4AAQSkZJRgABAQAAAQABAAD//gA7Q1JFQVRPUjogZ2QtanBlZ..
  :
AUhMQYSQVEHYXETIjKBCBRCkaGxwQkjM1LwFWJy0QoWJDThJfEXGBkaJicoKSo1Njc4OTpDREVGR0hJSlN
   : 
cH14z9RXHTc6jb6dWdM3GmrdT//Z" /> </a>
</div>

As we discussed earlier, this is particularly crucial because of the importance of minimizing the number of HTTP requests demanded by a mobile device to download a page, an aspect that is simply not worth optimizing in classic Web programming: too much extra work for way too little gain.

Of course, the data URI scheme will greatly increase the perceived download speed on smartphones and non-smartphones alike.

The Views: Feature Phone, Smartphone and Desktop/Tablet

The three segments we initially defined map one to one with our three views (feature phone, smartphone and tablet/desktop), according to the MVC paradigm. Each view offers a user experience that is best suited to the respective class of devices and browsers.

It goes without saying that adopters of a DDR still retain control over the UX of a deployed application simply by configuring a device to access a given view (for example, by downgrading a misbehaving smartphone to the feature-phone view).

The feature-phone view is particularly interesting because you’ll want to serve XHTML Mobile Profile (XHTML MP) as a markup to those devices. Developers who approach mobile today might get away with ignoring XHTML MP, but for years XHTML MP has been the standard mobile Web markup. Still today, smartphones will immediately recognize a website created in XHTML MP as being a mobile website, even when no viewport meta tag is available. Be aware that XHTML MP is typically better served with a different MIME type than text/html.

Note: Covering XHTML MP is beyond the scope of this article. If you are curious about the world of mobile programming on feature phones, my document “Global Authoring Practices for the Mobile Web” enjoyed some popularity for some time. Most people find it very informative still today.

The following screenshots visualize what the different UIs mean in practice:

Feature Phones
The view on feature phones.

View on smartphones
The view on smartphones.

Tablet
The view on tablets and desktop. Above: The page on an iPad.

Xbox (MSIE 10)
Here is the same page on the Xbox 360 (IE 10).

Of course, this example is just a proof of concept. Nothing prevents a programmer from making the desktop view even more responsive than it already is, or from adopting something like the good PhotoSwipe to provide interactive slideshows on smartphones and tablets (but not on older phones, where they would be unlikely to work). Divide and conquer.

Conclusion

Purely client-side approaches such as RWD and PE can make Web pages accessible on smartphones. For companies and organizations, this means that supporting mobile devices could be cheaper now than it was a couple of years back. Yet, these savings come at the cost of sacrificing certain aspects of a full-fledged cross-channel Web offering.

Large organizations may still want to adopt server-side device detection in some form to deliver a great UX to everyone who accesses their websites. While RWD and PE strategies can (and should) be adopted by companies, a hybrid client- and server-side approach is the most likely to deliver a great service to desktop, tablet and mobile users alike.

We’ve discussed an instance of such a hybrid approach by showing how segmentation, server-side resized images and the data URI scheme are key components to a great user experience across devices and browsers.

Have a look at the demo app, or download the full source code.

(al) (ea)

↑ Back to top

Luca Passani is an Italian software engineer with many years of experience in Web and Mobile Internet development. Prior to co-founding his company, ScientiaMobile, inc., Luca has worked for Openwave Systems, AdMob (now part of Google) and taken part in projects for Telecoms in the US and Europe. He is known to the community of developers for identifying the issues of device diversity (an area in which Luca is a recognized expert) as early as 1999.

Luca's work has been the basis for further development in this area. In 2001, Luca created WURFL, the Wireless Universal Resource FiLe, an Open-Source project that addressed the challenges of device fragmentation and established itself as the reference framework in the field. He holds a Master in Computer Science from University of Pisa, Italy.

  1. 1

    Daniel Schwarz

    May 14, 2013 5:45 am

    I thought this was VERY interesting. There’s been a lot of articles about UX and mobile lately, especially about responsive design. The biggest problem, I think, is that front-end developers think that front-end is the way to go, and back-end developers think that back-end is the way to go. I completely agree that these two can work together, I learnt this when I built the airwalk-design.com platform.

    At first everything was client-side, it seemed quicker and easier. But then I added server side validation to forms due to the number of visitors the site was getting, because it was safer. Eventually, using data obtained from Google Analytics, it seemed that client side validation wasn’t needed to I stripped it to achieve cleaner code. Then, for a better UX, I decided that an ajax loading form was more convenient when “sharing” content – this brought back the client-side validation. I felt like Goldilocks for a while, testing all the options and seeing what was best. I haven’t developed a mobile site for Airwalk Design yet, but having briefly tested it in the iPad and mobile, I’ve noticed that some features need some work, for example infinite scrolling; it seems that the iPad has an issue with scrollTop.

    Should I have pagination for the iPad instead? This sounds like a terrible idea, it’s very hard to navigate on a mobile device. Scrolling is just easier. I achieved it by querying new content from the database only when it is needed, in smaller amounts, over a graduate space of time, but determined by the user (only providing new data when it’s requested, without requiring much input from the user). Like Luca said, speed isn’t everything, however I managed to achieve a 100/100 Perf. Grade score (according to Pingdom Tools) while still offering a great UX. Obviously one of the biggest factors in this, as Luca mentioned, was limiting the HTTP requests. This was in the browser, not the mobile.

    I think I can still offer the same service via mobile by adopting the mentality of using both client and server side languages in harmony. This was a great article, with some helpful code hints, which hopefully I can use when developing the mobile version of Airwalk Design. If anybody is interested to see, the link again is airwalk-design.com, built with PHP as the server side and jQuery as the client side. I welcome any tips and suggestions!

    -Daniel.

    0
  2. 2

    Hi!
    This is a great article. Thank you for spending the time to teach us.
    The download link for the sourcecode is not working.:(

    Thanks.

    0
    • 3

      Steve Kamerman

      May 14, 2013 8:00 am

      I understand there was an issue with the source code package – a new one is being uploaded right away!

      0
  3. 4

    “A 2013 smartphone means the following: a fast connection, a great WebKit-based browser”

    You lost me there already. Might I remind you that there are other browsers that are not WebKit-based, even on smartphones. I use a Windows Phone for instance, which runs IE10 Mobile – or there’s Firefox on Android. Please don’t make WebKit the new IE6 by ignoring other browsers by only using -webkit prefixes.
    Furthermore, there is no such thing as one “WebKit browser”. Every implementation of WebKit (soon to be joined by Google Blink on Android) has different features and bugs.
    Why even mention WebKit? Why not just say “a great browser with support for modern web standards”?

    0
    • 5

      Not to mention that a smartphone has nothing to do with a fast connection. In fact, the whole reason different content is usually served up for mobile is precisely because mobile connections tend to be slower. 4G is great and all but it’s not available for a very large part of mobile phone users.

      Then again, the rest of the article goes on and talks about serving up smaller files, so I really have no idea why that sentence claiming smartphones have a fast connection was left in.

      0
      • 6

        The main reason why organizations produce mobile sites is because the form factor is hugely different from the desktop. Full stop.
        Generally speaking, bandwidth is obviously an issue too, albeit the perception of this will change depending on who you ask, why you ask, where you ask, what year you ask and, some times, even what time of the day you ask.

        After so many years, I could comfortably argue that bandwidth in mobile has got a lot better or that it is still not good enough :)

        0
    • 7

      Asbjorn, you are totally right. The ironic part of this is that I did the webkit comment because I wanted to pre-empt the usual objection that I receive: “who cares about other browsers? it’s all webkit now!”

      0
  4. 8

    Daniel Mullins

    May 14, 2013 7:08 am

    Unable to download source attachment. Just redirects to mobile.smashingmagazine.com

    0
  5. 11

    Congratulations for the article really interesting, a good solution for sure for any web/wap development, this is the fastest and accuratest way to detect the capabilities of the device entering your site

    0
  6. 12

    Bravo, Luca!

    Recent advancements in responsive web design have been encouraging, but all of it seems to be pushing the work out to the client side. We need to balance the load, and to do it mindfully, so the server and the client each do what each does best.

    All these technologies are good, but we need to get the different practitioners to work together if we’re going to develop something sustainable. Thank you for pointing out a path that will move us forward in the right direction.

    0
  7. 13

    Daniel, Jeff, Daxpo, happy you guys enjoyed the article.

    0
  8. 14

    Maybe I missed something, but this seems to be primarily a server-side approach: determine and do everything (sense the client, resize the image) on the server and serve up the right view to the client. No?

    0
    • 15

      I wouldn’t say so. Within each segment, developers are free to apply client-side adaptation, compatibly with the capabilities of the device/browser. This is a great advantage because, at that point, you don’t need to deal with the shortcomings of legacy browsers and devices.

      There are some who think that any amount of server-side, no matter how small, is still too much server-side for their taste.

      As Italian wisdom goes, “the world is beautiful because there is a lot of variation”.

      0
  9. 16

    Great article, Luca.

    I’ve also been spreading the message on various LinkedIn forums.

    One thing out of scope of your article is just how many full-web-page-capable tablets share screen dimensions with mid-range smartphones: something that’s completely overlooked by RWD designs which assume 768px breakpoints for Tablets.

    0
    • 17

      Hey Chris, how are you?

      Great point about those tabloids. I can confirm that I have seen what you are talking about in person, and yes, those are the devices where RWD doesn’t shine the most. As usual, it is a matter of cost vs benefit. That’s a situation where server-side helps a lot.

      0
  10. 18

    Nice article,

    One point though, you quote RESS – which is great – but get the definition wrong by proclaiming its just for responsive images:

    RESS stands for “responsive images and server-side components,”

    As the original article you link to by Luke Wroblewski states, it is Responsive Design + Server Side components, not just limited to images. In fact your article as a whole could be treated as a RESS technique.

    I am worried this may confuse some people :)

    0
  11. 19

    Eduardo Casais

    May 15, 2013 6:04 am

    We need more such articles that make it clear that, given the persistent difficulty of delivering great Web services to mobile devices, the reasonable approach is to draw on all available means — especially if they have proven their worth in practice. RESS is the way. People like Stephanie Rieger have been saying this for a few years now, but the message does not get through easily.

    I am a bit concerned that purely client-side approaches have taken so much hold of the mindset that solutions like the one described in this article will take quite some time to get widely accepted. When I read about the (disparate, sometimes acrobatic Javascript, DOM and CSS) schemes to perform content selection on the client, or when I read that mobile Web developers “should actively encourage people to switch to a better browser”, because “working around [Android 2.x browsers'] many limitations” is just too bothersome, I wonder about the direction in which the field is going.

    0
    • 20

      Thank you, Eduardo. Knowing that you have appreciated one of my articles is always a great confidence boost for me. It goes without saying that the points you make are valid.

      0
  12. 21

    Thanks for the great post! Clear, concise and easy to follow. Being a very visual learner, i found your diagrams extremely helpful. Thanks!!

    Also.. “Call me a romantic, but I prefer that we eat our own dog food for this example.” made me laugh/snort/spit out my coffee:D

    0
    • 22

      Leigh, I think that I will preserve an article’s “gag reel” next time. Between the stuff that I self-censor out of my early drafts and the strict review process of smashing magazine, there are quite a few funny bits to be found which will never reach the readers. Glad you liked the article.

      0
  13. 23

    Hi Luca,

    Great article !! Just what I needed to read – and helps solve a big dilemma im trying to work through right now.

    Just out of curiosity though – and this may seam like a silly question, but would RWD work its way into this approach ? If so how would that work ? Would there be a case where you would bother to use @media ? Or is the primary idea to serve only whats needed via this server side processing ?

    0
    • 24

      Hey Matt, glad you liked the article.

      The answer to your question is “it depends”. To examplify, on one side, you have a pub owner who is also an amateur web master. This guy will be served more than decently by a pure RWD approach (say: adapt existing template to the few static pages hosted at $5 a month). On the other side, you have a multi-national corporation selling to consumers around the globe. For those, a strategy that gives them control over the UX on specific devices is probably a good idea, since it all translates into more conversions and, ultimately, the true universal standard of our era, i.e. cash.

      If you really had to generalize, you should start by asking yourself a few questions. “Is my website still too bloated for mobile devices?”, “Is ‘it sort of works’ good enough for my company or do we need to do better than that?” or even “If a user of my site complains about their mobile experience, am I comfortable telling them that it is their problem and not ours?”. If the answers to those questions is that you can live (and make your mobile users live) with a sub-optimal mobile user experience, then you probably don’t need a DDR or server-side detection. On the other hand, if you do want more control over your web offering, then you need a tool to control the mobile UX at levels that RWD can hardly provide. Server-side detection is likely to be part of the solution in that case.

      Once you answer these questions, whether you should use @media is a corollary of the other choices you took upstream.

      0
      • 25

        Hey Luca, that makes sense.

        May I ask then in your opinion what the advantage this technique may have over Jon Arne Sæterås server-side enhanced responsive technique outlined here:

        http://mobile.smashingmagazine.com/2013/04/09/improve-mobile-support-with-server-side-enhanced-responsive-design/

        From what I can see this approach would take all the goodness you have described, however consolidating everything into The one responsive template rather than having to maintain several (feature phones excluded of coarse)…

        0
        • 26

          My opinion is that the approach described by Jon Arne addresses the same issues that I describe in my article.
          One way to look at it is that the approach in my article describes how to build a solution by employing low-level components (a DDR + MVC mainly), while Jon Arne’s approach gives you a framework that provides a more high-level, cohesive, integrated, self-contained solution, with the added advantage of making things look more familiar for your typical front-end developer. My understanding of the system is that it allows you to see things in terms of (server-side) CSS, JavaScript and HTML, which are obviously more familiar to regular web developers than having to deal with a DDR.
          As everything in computer science, an engineer’s best bet is to get an understanding of the possible approaches and pick the one that best fits budget, level of expertise, long-term support strategy and other factors that he may be aware of…

          Thanks

          0
        • 27

          Jon Arne Sæterås

          May 21, 2013 5:52 am

          Matt,
          Thank you for reading my article too :)
          The approach I describe in the article (which is currently in public beta at http://whateverweb.com) addresses similar issues, but is wrapped completely different to keep the footprint small and make it plug-and-play for any web dev out there. All based on one html document. So, if you want to handle feature phones and older devices of some sort, you would still need Lucas approach to serve the right kind of markup.

          0
  14. 28

    Nice Article. I think the readers should also go through this article which reads “Your website has two faces” http://alistapart.com/article/your-website-has-two-faces#latest

    Correct. Two faces viz human face interacts with people, while its machine face interacts with computer systems.

    The same applies in case of applications as well. I am part of a mobile development company, endeavour (http://www.techendeavour.com). We do a lot of work on mobile and the real challenge today is to design for the computer system which comprises of various hardware elements like your laptop, mobile, tablet and even a TV. To be able to create a UI which scales and meets the expecations on all these computer systems is what defines the success.

    You may also look at this link for some of the work we have done while addressing the above gap
    http://www.techendeavour.com/iphone-application-development

    0

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