So, I’m nearing the full beta release of a desktop site/webapp I’ve been building for awhile. And one thing I realized is that the design/UX of the site works great for desktop and probably is too much for most smartphones (maybe not ipads) to really be that usable. So, it occurs to me ways that I could rearrange and simplify (greatly) the UX (the JS and the CSS, and some of the HTML) for a better mobile experience.

Figuring out how to arrange a site more vertically (for mobile smartphones) and with less complication (more touch-friendly, instead of mouse oriented) is doable, and not really the point of this post. The point of this post is, given these two different site experiences, how should I serve them to different devices?

It’s clear that a smartphone (~320×480 type screen size) probably should get my mobile-optimized UX design. This means that there’s a whole bunch of CSS and JS for my desktop site that doesn’t need to be served to those devices (because that would be a lot of wasted bandwidth). Conversely, the mobile site will certainly have some CSS and JS that will only be for the mobile-optimized experience, and would be wasted/ignored for the desktop-optimized site.

But, what about the trend of “in-the-middle” devices like tablets. It’s pretty clear that a lot of them are nearly as capable as their desktop counter-parts. Capability aside, though, my primary concern is, will my desktop design UX be appropriate on a tablet? My guess is, yes, it’d be more appropriate than my slimmed-down mobile site UX design. So, for tablets, and for desktops, the default behavior should be the full site, and for the much smaller screens, the mobile design should be the default.

Notice I said default. I mean it. I’m only seeking to optimize the choice of the default experience. On BOTH versions of the site, a link will be present which will let someone manually toggle to change to the other experience. If my guess or default is wrong, the user will be able to switch. And do so with a cookie (if possible), so that the switch is remembered from then on.

So, what it comes down to is, I’m basically wanting to fork the two site versions based on screen dimensions (and to some extent, PPI resolution). The two site versions have some overlap, but it seems like there’s enough that’s unique to each, that one is not really a sub-set or super-set of the other. And for the sake of this discussion, let’s just assume that my desktop site is 300k (including ALL resources), my mobile site is 50k, and the overlap between the two is about 15k (content the same, some JS the same, a few images the same, etc).

So, what are my options?

  1. Full UA sniffing on the server, serving only one version of the site (300k) or the other (50k)
  2. Serve a big combined site (~335k) with content/css/js for both sites all being sent, and use CSS3 media-queries to simply show/hide various bits of content from each type of device/computer as screen geometry dictates. (AKA, “responsive design”, “responsive …”, etc)
  3. JavaScript logic served at first page-load, to determine screen geometry, and then take appropriate action to load the appropriate site content/css/js. (300k or 50k)

Pros/Cons

For (1), the obvious con is having to maintain a full UA sniffing. Why? because the server doesn’t know the screen size (not in the UA string). So, I’d have to construct (or use existing) UA sniffing logic for all the various mobile browsers… and moreover, I’d have to account for tablets in that checking, too. If the iPad were the only tablet, that wouldn’t be so bad. But there’s now dozens of different tablet models on the near horizon. That means lots of complicated UA sniffing to correctly identify each one/type.

And, it means committing to keeping up that UA sniffing for all new types of “in-the-middle” devices, making decisions individually based on each. For instance, is a 7″ device big enough? What about a 5″ or 6″ version of the same device (will it’s UA even be different)? What about the 9″ or 10″ versions? That’s going to mean LOTS of testing and maintenance overhead to get that right and keep it right going forward. Ugh.

But the big pro is, if the UA sniff (aka “guess”) is correct, the user only downloads exactly what’s necessary for their device. Mobile users get only 50k, and Desktop or “in-the-middle” users only get 300k.

For (2), the obvious con is the larger size of the full combined set of resources (335k). For a desktop, that’s about 12% more than it really needs. For mobile, though, that’s about 570% more than it really needs. Are there tricks to reduce the unnecessary loading? Sure. But the point is, a lot of HTML, and a lot of JS, and at least some CSS, will get loaded unnecessarily, especially in the mobile case, where bandwidth is likely to be more of a limiting factor. This just doesn’t feel like the right solution.

Another con is that media queries have good, but not universal, support. Namely, no IE supports it until IE9. That means all mobile IE’s are left out of the party. Unless you use something like Respond from Scott Jehl, which patches IE6-8 (and probably others) for media-query support, specifically for width/height geometry. But that adds a little extra weight (3.5k before gzip). So, it’s something to consider.

Of course, clearly the huge pro is that you avoid all UA sniffing and all the terrible junk that comes along with it.

For (3), the obvious con is that for non-JavaScript (like mobile devices that don’t have JS enabled), they’d basically be totally left out. Of course, a <noscript> tag could probably use some redirect (meta tag or manual <a> link) to give such a user a way forward. That’s workable, but it’s less than ideal. Then again, do I even care if my non-JS visitors can get to my site? For some sites, they don’t care. For me, however, I do care. I probably need a non-JS solution.

The pro is, like with (1), only one version of the site is served. And even more likely to be correct than in (1), with a lot less work/maintenance.

Bottom line, none of these 3 options is really great. I’m sure a lot of sites employ something like them for this type of functionality. But they all seem like they’re sub-optimal, for various reasons.

So what should I do?

Let me just say up front, I’ve not fully decided, nor do I really know for sure the best answer. This post is basically just to explain my experimental/explorative thoughts on the topic, and to solicit feedback from the community on what they think.

I got to thinking, what if CSS3 media queries could be used to do the checking on the screen’s size, and without any JavaScript, set a cookie that would let the server know which site version to serve, on the next refresh.

So, here’s how I might accomplish that.

  1. On first request to server, check if a cookie is set for site version. If so, respect it, and deliver the proper site directly. If not, use basic UA sniffing to identify mobile webkit and a few other well known mobile browsers. Don’t worry at all about device type, just identify common mobile browsers. If it seems like a mobile device from this coarse guess, serve up a “check” page. If not, assume the best, and serve up the full desktop site. Again, set a cookie for next time.
  2. In the “check” page, have a few bits of inline <style>, using CSS3 media queries, to do the screen geometrics testing. In each block, have it make a background-image request, with a particular parameter in it, indicating to the server the screen size category. The server then sets a cookie appropriately. In theory, only one of these two requests should go out, and if cookies are enabled, then it should identify it fairly reliably.
  3. Include a meta-refresh tag, and JavaScript redirect (just in case), and lastly an <a> link for the user to follow to refresh the page. If the cookie setting worked, this refresh should now serve the appropriate version of the site.

Gotchas

This idea is not perfect, by any means. There’s plenty of pitfalls.

For instance, if the browser doesn’t support cookies, this won’t work. Then again, for *my* site, I think I want to require cookies, so perhaps that’s not a deal breaker. I could detect cookie-setting failure, and display a message to the user that the site requires cookies to proceed. Or I could just default to either version of the site if the cookie setting failed, and just let the user figure out that it’s not gonna work as expected, in some respects.

Also, there’s the case where on mobile, there was a redirect that happened. This is an unfortunate extra delay/bandwidth/etc. But, I’m hoping that this refresh/redirect that occurs is less penalty than shoving 570% too much HTML/JS down the pipe on the first view.

What about if the browser doesn’t request background-images? Perhaps the CSS could also use content:after to create an <img> tag to force the request.

How do I force the meta-refresh/JS redirect/link clicking to “wait” for the cookie setting to occur after the background-image response comes back? For JS, this is easy, just poll for the image to finish loading. For the meta-refresh and the link clicking, not so much. There’s a few quirky ideas I could explore, but I’m not really entirely certain how to force this part to work correctly. But I’m also not convinced that it has no solution. And remember, it might only fail if the user doesn’t have JS… so as a fallback, the meta and links could always force one version (regardless of cookie), whereas the JS waits for the cookie, and does a refresh.

I’m sure there are other pitfalls I’m not realizing yet. I’d love to get some feedback from you, the reader. Am I crazy? Is this over architecting? Does this have promise? Will I fail?

Please, though, keep in mind a few things when providing feedback:

  1. Having already built the full site, and at least sketched out what the mobile site will look like, radical/significant changes to the design of either are not only impractical, but irrelevant. Please don’t comment if this is your suggestion. The spirit of what I’m asking is, making the best with my current situation, which is basically two site versions.
  2. UA sniffing is, in my opinion, generally evil. I want to avoid it as much as possible. I only introduce it in the above idea because it helps the “guess” and reduces to some extent how many people get the “check” page (and its delays, thereof). And, of course, the simple basic UA sniffing I’m talking about is orders of magnitude easier to write/maintain compared to full-blown UA sniffing.
  3. I am forking primarily based on my intended UX for small screens vs. big screens. I’m not forking for JS vs. non-JS, or because of low-powered/incapable devices, etc. I’m only forking based on screen geometry, because of its direct correlation to usability of layout.

That’s it. I hope to hear some great ideas. Thanks!

This entry was written by getify , posted on Wednesday March 23 2011at 10:03 pm , filed under Misc, Performance Optimization and tagged , , , , . Bookmark the permalink . Post a comment below or leave a trackback: Trackback URL.

15 Responses to “Desktop vs. Mobile… an exploration of site delivery”

  • Thomas says:

    Regarding the second option: Why not use responsive enhancement? CSS for desktop browsers and the corresponding larger background images would only be loaded when the visitor has a large screen (or is using IE).

  • getify says:

    @Thomas-
    Images are only part of the problem. I have a bunch of JavaScript, HTML, and even some other CSS, for the desktop site, that I do not want to shove down the pipe of the mobile device if the mobile device is just, by virtue of the media query, going to ignore that content. It wastes bandwidth to do so.

  • What about a three-pronged approach?

    While it kind of sucks, what about starting with your completely mobile html, JS, and CSS, then using a php script from Detect Mobile Browser or some other basic desktop UA sniffer to conditionally serve up your non-mobile HTML. Then use a javascript sniff of browser dimensions to serve up your non-mobile JS, and finally use responsive enhancement and @media queries to serve up your non-mobile CSS?

    You end up bloating the desktop download marginally with the added mobile JS and CSS, but provide the most minimal download for the mobile sites.

  • getify says:

    @materialdesigner-
    I suppose I could approach it like that. But I think your suggestion has some of the pitfalls that I mentioned above in wanting to avoid:

    1. wasted bandwidth for desktop (not terrible, but 12% waste is definitely unfortunate and I’d like to avoid)

    2. using the “detect mobile browser” UA sniffing would still require either them or me to make sure I keep maintaining it for proper recognition of desktop browsers. This isn’t as difficult as keeping up with mobile, but it’s still less than desired.

    3. The JavaScript detect for screen dimension (ostensibly to correct for “in-the-middle” devices like tablets) requires JavaScript (what if they have it turned off?), and it does the bloated download from (1) on a “mobile device” which very well might have limited/metered bandwidth.

    I’m not convinced there’s a perfect solution to this problem, given what I’ve seen so far. But I’m thinking the right solution will be some combination that tries to balance a few positives and negatives to the best extent possible. That’s what I’m hoping to figure out.

  • Maybe it’s because I’ve been working in a SaaS application for too long, but unless you’re basically just a content provider, I think there needs to be a distinction between the desktop and mobile UIs.

    I’ve just found that found the UI demands of a mobile interface are just so drastically different than that of the desktop version of our app, that trying to combine the two doesn’t benefit anyone. It makes the code more bloated, harder to debug, etc.

    While using UA sniffing is a pain to maintain, one benefit is you most browsers have tools that allow you to customize the UA so it’s easy to test your mobile in your desktop browser.

    I’ve been meaning to look into media-queries as just a detection method, but it does introduce redirection overhead.

    1) User hits page
    2) If no cookie, redirect to detection page
    3) Page runs, detects UI to serve
    4) Save cookie
    5) Redirect back to the original URI, but serving the correct correct UI for their browser

    Depending on the mobile user’s connection, those redirects can slow down responsiveness for that first page view–which may or may not be a problem depending on your needs.

    However, we all know how difficult it is to maintain accurate results w/pure UA sniffing, but it for the vast majority of cases works well enough.

  • I think that supporting browsers with cookies / js turned off is like supporting IE6 – ie a waste of time.

    Also, I read somewhere that something like 99% of browsers had js enabled.

    So, option #3 is choice.

    Detect the screen size and UI API, and then serve specific js and css.

    Also, I would have three main branches: smartphones, tablets and big screens.

  • Yoav Weiss says:

    The main problem I see with that approach is that the first visit to your site (arguably the most important one – first impression and all) will be slowed down by a redirection that will take place only after a background image was downloaded. That’s 2 extra RTTs you’re adding. It will also probably show a flash of unstyled content (redirection link) to your users.
    On top of that, the redirection will be triggered by some timeout (meta refresh) or polling (JS) which means you’d be wasting some extra time there, as well as a risk for race conditions when the JS redirect is off.

    All in all, I’m not a fan…
    I think that the cookie solution could be combined with a redirection-less JS solution:
    * Detect screen size using JS and load appropriate content using XHR
    * Add a fallback that includes
    – meta refresh redirection
    – media queries that load bg images
    – Add appropriate cookies to bg images

    That way you’d benefit from all worlds, optimize for the most part of your users (with JS), while enabling access to everyone.

  • getify says:

    @Yoav-
    Thanks for your feedback. Let me make a few comments in response:

    1. The redirection would only occur if the “check” page was sent first, which would only happen if the simple server-side UA sniffing “guessed” that this was possibly a mobile browser. So, if it’s done right, this delay would not occur for desktop users, which arguably would be my more important audience anyway.

    2. I thought about suggesting a JS-based XHR load for HTML content, and dynamic script and CSS loading… the problem is, this completely defeats any SEO. Now, granted, again as I said in #1 just now, that would only be for likely/guessed mobile users, so it shouldn’t hurt actual search engine SEO too much.

    But the other problem I have with the load via XHR approach is that is rather significantly alters how the page is assembled… For instance, in most browsers, you can’t just inject HTML (loaded via XHR) into the page, if there are <link> or <script> tags in it, because those tags will be ignored. So, you’d have to parse out <script> tags for instance, and forcibly load those in a dynamic fashion. Is this doable? Yes. But it just makes the mobile site more error prone in the long run, as it’s being assembled less fundamentally from basic HTML parsing compared to its desktop counter-part.

    But, I agree with you that there are definitely some issues with my solution. I don’t think we’ve found the right one yet. Just trying to iterate on some ideas to get more info to make the tradeoff’s decision.

  • Levi DeHaan says:

    Aloha Kyle,
    I just had a thought, since this is to be an application, you could probably get away with a load screen, like a little logo that shows up on the screen. this could cover the load times etc.. and provide some extra eye candy, 1-3 seconds is all it needs to determine and do a lot of things. when it loads up you can scale the image based on screen size from 0, so it always “grows” to the correct size. and while its doing that you could load other things if you like. just a thought :)

  • Yoav Weiss says:

    @Kyle – First, if the mentioned solution is only for unrecognized UAs, that is better then applying delay to all users. (as long as you don’t forget UA spoofers have feelings too :) )
    Regarding XHR, you’re right. XHR for content is a bad idea, But since the content is anyways identical between the 2 site display versions, XHR (or simple DOM scripting) can wheel in the difference between mobile and desktop versions. That should be SEO safe, since diffs are in scripts ans styles.

  • No problem Kyle, any time.

  • Thomas says:

    @Kyle

    You may have misunderstood my approach: CSS files for desktop browsers are not shoved down the pipe of the mobile device since they’re loaded depending on screen size.

    Example:
    @import url(desktop.css) screen and (min-width:600px);

  • Jake says:

    The link on your check page is an easy solve with two links (to desktop or mobile) and just set the cookie on the landing page. The meta-redirect is still a big problem. Is there anything besides JS that is blocking that I’m forgetting (that you could put before the meta tag)? You could have unique identifiers in the url for the background image and that blocking resource. The server can hold back the blocking resource until it closes the connection on the “cookie image”. Then release the blocker and redirect/refresh.

  • Peter Bremer says:

    Hi Kyle,

    I can understand your problem, I’ve been there also, a lot. I would suggest you try to read as much as possible on Lazy Loading, Progressive Enhancement and Feature Detection.

    You should start with a minimal operational website, that is optimized for search-engines, screen readers, character terminals, age-old phones, small-screen devices, IE4, etc. Luckily, these “devices” all have a lot of the same requirements. Don’t use anything fancy, just simply Plain Old Semantic HTML and only the minimum amount of images. This version should be around 10-20k download.

    After that, layer your enhancements. Begin with attaching a very simple CSS file (again only a few kB), for browsers that have disabled JavaScript support. Next use JavaScript to dynamically load enhancements, based on supported features. Finally use more advanced techniques like Conditional Comments and Media Queries to further enhance the user experience. (Conditional Comments and Media Queries are evaluated as they are loaded instead of after loading, and thus avoid the Flash of Unstyled Content.)

    For content, use AJAX to dynamically generate additional HTML when supported. Infinite Scroll is a good example where AJAX is used to enhance a user experience that requires clicking through pages on less-capable devices.

    On the server side, you don’t need to keep separate files for all these layers. Use query parameters to indicate which version you’re requesting, for example:
    <link rel="stylesheet" type="text/css" media="screen and (max-device-width: 480px)" href="css.php?mobile" />. I would advice against using cookies, since you can never be sure exactly what a visitors “first page” will be, plus many users may have cookies disabled or their proxy filters them.

    The overhead when using these techniques should be minimal (less than 5% of the total download), and because you’re using progressive enhancement with feature detection, no “unneeded” code will be downloaded.

    While this method could be significantly different from what you may have in mind, you do not need to radically change your design. You can introduce these enhancements step by step as time allows. Any good website will require constant attention anyway, to follow the constantly changing requirements from the visitors. A few years ago not many people would consider building a phone-optimized website, while now many visitors react when a website is NOT optimized for their phone…

Leave a Reply

Consider Registering or Logging in before commenting.

XHTML: You can use these tags: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

Notify me of followup comments via e-mail. You can also subscribe without commenting.