• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
Why Separate Mobile & Desktop Web Pages?

Why Separate Mobile & Desktop Web Pages?



Why Separate Mobile & Desktop Web Pages?

Why Separate Mobile & Desktop Web Pages?




Total Views
Views on SlideShare
Embed Views



0 Embeds 0

No embeds


Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
Post Comment
Edit your comment

    Why Separate Mobile & Desktop Web Pages? Why Separate Mobile & Desktop Web Pages? Document Transcript

    • http://www.lukew.com/ff/entry.asp?1390Why Separate Mobile & Desktop WebPages?September 1, 2011 by Luke WroblewskiAs use of mobile devices continues to skyrocket across the globe, wereseeing more ways to tackle the challenge of creating great Web experiencesacross multiple devices. But which approach is right for any given project? Inan effort to help answer that question, Ive compiled the reasons we opted touse a dual (separate mobile and desktop) template system to build our start-up, Bagcheck.Im a big proponent of Responsive Web Design so I often get asked why webuilt a "separate" mobile experience for Bagcheck instead of using fluid grids,flexible images, and media queries to deliver a responsive Web solution to ourmobile audience.For us site performance and speed of development were crucial. So many ofthe decisions we made were designed to make both of these as fast aspossible. (We were a start-up after all!) As part of our focus on performance,we also had a philosophy of "just whats necessary". This meant sendingthings to devices (and people) that didnt actually need them made ussqueamish. We liked to optimize. With a dual template system we felt we hadmore optimization of: source order, media, URL structure, and applicationdesign (more on each of these below).We built Bagcheck as a command-line interface first. From there we createda mobile Web experience, then followed on with a desktop Web experienceshortly after. This process probably influenced our development approach aswell.Its also worth noting that, while competent in code, I am primarily a designer.So Ive focused on design considerations and tried to include ample links tofolks more versed on the technical side of things in this article. If you havemore resources or implementation ideas... send them my way!Source OrderAt its core, Responsive Web Design is about serving the same HTML to everydevice and adapting its presentation (mostly through CSS) based on the
    • specific capabilities of the device being used to access it. HTML markup hasa source order, which (mostly) defines how a Web page is rendered by abrowser. While HTML elements can be repositioned using Javascript andCSS, doing so reliably across a wide range of devices can be challenging.Consider the simple example of a site-wide navigation menu. On devices withlarge screens and mouse/keyboard input, its quite common to position thistype of menu at the top of a Web page because: Theres enough screen space available so actual content isnt likely to be pushed off screen. Theres often a need to communicate whats available on the site through a set of key categories or actions. Its potentially quicker to access these top-level categories or actions when they are aligned with the edge of the screen/browser.Since global navigation makes sense at the top of a Web page, it tends to come first in markup source order. On devices with small screens and touch input, however, it often makes sense to position the same global navigation at the bottom of a Web page because: Theres not a lot of screen space so global navigation menus can quickly push actual content off-screen. Instant access to content usually trumps navigation tasks on devices with small screens and low bandwidth. (It probably does on all devices but mobile constraints emphasize the need most.) Ergonomic factors make it easier to hit touch targets at the bottom of the screen (especially with one handed use).So on mobile devices, global navigation makes sense at the bottom of a Webpage, which means the menu markup is likely to come last in source order.When you are serving the same HTML though, source order cant bechanged.With the dual template approach we used when building Bagcheckwe were able to serve different markup and thereby a different source orderto mobile devices. Which, as you can see in the images below, easilygenerated a more optimal user interface for each experience: mobile anddesktop.
    • There are also solutions that can achieve a similar effect without servingdifferent HTML. Box-direction (part of the flexible boxes CSS specification)can reverse the order of an item list without affecting source markup order.You can also try to use display:table to reorder the display of content andnavigation in response to screen real estate. These methods might be abetter fit for you —depending on your needs.MediaAnother tenant of Responsive Web Design is flexible images (and videos).When set to expand to fill the size of their container, flexible images can resizethemselves based on the space available within a browsers viewport.In large viewports, a flexible image can fill more space by being displayed atits original (large) size. In small viewports, the same image can take up a lotless space by being displayed at a reduced size. In order to achieve thiseffect, the browser needs large images, which look good when scaled up ordown.The problem is large images have large file sizes. Though not every Webbrowser will display them at full size, theyll all download them at full size,which can quickly add up to poor performance unless: You use a combination of CSS Media Queries and background images to
    • not display and not load images intended solely for larger viewports. This method does not work for any images specified with image tags only those specified with CSS image backgrounds, which can limit the utility of this approach. You employ a solution like Responsive Images that relies on Javascript to replace small (performance optimized) images in HTML mark-up with larger ones as viewport size increases. Browsers with Javascript or cookies turned off will just display the small images. You experiment with ideas like using the noscript tag to prevent unneeded images from loading. You use a server-side solution to detect the device accessing your site and only send down whats necessary.Underlying each of these solutions is the same philosophy: give each deviceonly what it needs using media queries and background images, JavaScript,or a server-side solution. This philosophy can dramatically cut down file sizeand increase performance.For example, our mobile optimized template for category pages on Bagcheckused a single compressed 50x50 pixel image (averaging 3KB) for each itemlisted. The desktop optimized template used a 200x125 pixel image(averaging 15KB) and a second 50x50 image (averaging 3KB) for each item.On a page with 20 items thats a 300KB difference plus 20 less http requests,which has a big impact on performance. But because we had a separatemobile template, we went one step further and only displayed the first tenitems in the list on mobile (with an easy option to see more) saving another30KB.
    • In total, a category page on the desktop had 360KB of images while the samepage on mobile only had 30KB of images. Thats a pretty big difference.But optimized images arent just about file size. Some images can bedesigned explicitly for small screens, not just scaled down to fit them. This isespecially important when the details (or animations) in an image matter.Once again we can set our mobile-specific HTML templates to only referencethe images explicitly designed for mobile devices.
    • The same system can be used to optimize videos as well. On all devices, wewanted simple video playback that works with a single click/tap. So while ourdesktop template embeds video files directly on the page and our mobiletemplate only displays a thumbnail, both start to play the video with a singleaction. Using just a thumbnail in the mobile experience, however, makes itfaster to load and provides more control over layout/pixel size.
    • URL StructureSource order and media arent the only things we might want to optimize formobile use. In some cases a distinct URL structure can have a significantimpact on performance or usability on small screens and slow connections.(Seeing a theme yet?)For example, the Bagcheck desktop experience has all the information abouta list of content, its comments, updates, and likes at a single URL. We bundleall of these sections (or modules) into a single file then load each sectiondynamically (as people request them) without a page refresh. While thiscreates a smooth transition on the desktop, it adds up to a lot of bytes onmobile.So the mobile Web experience uses a different URL structure. The same URLloads the same initial content but each sub-section (comments, updates, likes)is a separate page with a unique URL as visualized in the image below.
    • In this modelbagcheck.com/bag/7811loads the same content on mobile and desktop butbagcheck.com/mobile/bag/7811/updatesbagcheck.com/mobile/bag/7811/commentsbagcheck.com/mobile/bag/7811/likesare mobile-only URLs. With this structure, we once again optimize forperformance by breaking large files into smaller ones. Its also worth notingthat we set these mobile-specific URLs to "nofollow" so search engines dontindex them.Application DesignURL structure can also help optimize extended interactions on mobile.
    • Organizing lengthier tasks or multi-step/modal applications across severalpages on mobile devices allows people to manage one aspect of an involvedinteraction at a time. Interactions that happen through modal dialogs or acrossmodules/panels on large screens often make more sense as separate pageson smaller screens.Device capabilities can also differ significantly between modern smartphonesand desktop/laptop computers. For example, accurate (10-50m) locationinformation is usually available on mobile devices but less so ondesktops/laptops. The availability of this information can dramatically changethe design of an application interface.The dual template system we used to build Bagcheck allowed us to optimizelengthier interactions and take advantage of device capabilities within ourapplication interfaces. We enabled barcode scanning in the mobile experiencebecause its easy for people to point their mobiles built-in camera atsomething. We also reorganized our rather non-linear list creation tool into aseries of focused, shorter tasks on mobile.Doing It AgainWhen we designed and built the Bagcheck mobile Web experience (aboutnine months ago), a desire to optimize source order, media, URL structure,and application designs made separate mobile and desktop templates a great
    • fit for us. But we also learned a lot along the way including a few new ideason how to tackle the same issues.But Ill save that for another article...