yiibu

This site is a proof of concept for many of the ideas described in Rethinking the Mobile Web.

You can test many of our site’s adaptive capabilities by simply resizing your desktop browser window. Certain capabilities—related to content adaptation—are however best viewed on a mobile device. Please read about our approach and content below for details.

The content on this page outlines our approach back in September 2010. Please see Pragmatic Responsive Design, which outlines our most recent approach (Sept 2011) and a case study of a new responsive web site we designed for Nokia.

The approach

The site is designed using (what is rapidly becoming known as) the ‘mobile first’ principle. Also incorporated are elements of responsive design. (Some people are now calling this approach Mobile First Responsive Design).

• The base content and default presentation are mobile, and optimized for the very simplest devices first. We've defined this as 'basic' support.
• Devices with small screens and media query support are served an enhanced layout—and occasionally—more complex content. We've called this 'mobile'.
• Finally, the layout and content are enhanced to reflect the 'desktop' context.

On the first visit, the server checks for a 'properties' cookie containing specific browser 'feature support' results (obtained from tests carried out by a little bit of JavaScript). Devices that don't supply a 'properties' cookie, or have JavaScript disabled are always served the basic version of the site.

The mark-up

We’ve tried to write the simplest, cleanest, most semantic markup we could come up with given our overall goals and design. The markup includes very few non-semantic elements and a minimal number of classes and ids (and we're still planning to remove some more). We also designed the content to be as inherently flexible as possible. This initial step (combined with the ‘mobile first’ approach) enables us to immediately support a large number of legacy devices and ensure that even edge-cases (like the fabled internet enabled toaster) will be able to render most of the content.

We've also incorporated many of the new HTML 5 structural elements. We also (opportunistically) chose to use the HTML 5 doctype to see if it might be possible to serve it to all devices—even those that would typically require an XHTML MP doctype.

The style sheets

We have three style sheets. A ‘basic’ style sheet that is served to all devices. In practice, this is the only stylesheet which devices that are less than 240 pixels wide or don’t respond to media queries will use.

The second ‘mobile’ style sheet is aimed at today’s smartphones. It is triggered by media queries on devices that are between 241 pixels and 640 pixels. This style sheet enables us to tweak the size of controls for touch manipulation (and we will use it to further enhance for this group at a later date).

The final style sheet is aimed at displays over 640 pixels in width. The iPad and most desktop computers will fall into this category. This style sheet introduces a more complex layout and web fonts (actually mobile gets fonts as well right now but we're fixing that this week).  IE is also targeted with conditionals and served (only) the desktop layout (we'll address IE mobile in a future update).

The content

The content goes through a variety of adaptations and we plan to continue experimenting with this as it's already proving quite handy. Here are just a few of the current adaptations:

• Alternate content is served for certain images (we will explain why and how in a future article). Some of our image adaptations can be tested by simply resizing your desktop browser window. Others will require a page refresh (on desktop browsers only).
• Alternate markup is served for complex content such as tables. Point your mobile browser to pages 2-4 in A Practical Guide to Nokia Browsers for examples of this type of adaptation. In this case, we’ve provided a ‘basic’, ‘mobile’ and ‘desktop’ version of the content along with a link to a much larger dataset on Google Docs (which we realize is not yet mobile compatible).
• Speaking of 3rd party services…we were horrified to see that each SlideShare embed adds well over 500kb to the page, (and doesn't work on most mobile devices anyhow) so we created our own lightweight HTML slide show (very basic, expect it to evolve soon) which by our count works on well over 100 devices (lots of Nokia smartphones, Android, iPhone and Blackberry). Here as well, we serve alternate sizes for smaller devices although as the size decreases, so does legibility.
• And speaking of graphics. We had experimented with SVG fonts on mobile (currently using TrueType (ttf), WebOpenFontFormat (woff) and Microsoft's Embedded OpenType (eot) based fonts which are served only to desktop browsers), but discontinued use of them after consistently crashing mobile Safari. We have not yet experimented with SVG for content, but we plan to do so very soon.

Still pondering…

This is a work in progress and there’s still lots to do. We will be adapting and documenting this approach in detail over the coming months and are keenly aware that for each problem, there may be multiple solutions. Sometimes the simplest solution comes from taking a good look at your content so we're keen to do this rather than focus entirely on the technology. Here are just a few things we’re still working on:

• We’re adapting content in a variety of ways. Some are working really well, others not so much. We’d like to experiment further.
• We want to see where the various approaches breaks. Will certain large devices accidentally receive the mobile layout? Will some devices get the wrong content. And when this happens, is the experience still acceptable? (We’re already finding this on certain proxy browsers that are serving the 'mobile' styles but the 'basic' content. So far, the experience isn’t really affected).
• How do we deal with 3rd party content such as Slide Share, Flickr embeds and social media bookmarklets? Many of these link to massive script libraries that shouldn’t be served to small devices and degrade poorly if the scripts fail.
• We’re guessing there are some/many bugs in IE (desktop and mobile) that we haven’t found yet :-).

Supported browsers and devices

At the moment we can confidently state that this site works beautifully on most modern smartphones, many legacy smartphones, and most tablets and desktop browsers.

We’re keeping a log of all supported browsers (in the form of a Google Spreadsheet). Browsers are tagged in green if the site works beautifully on them. Orange means there are minor problems (that we think we can fix). Red means there are significant problems. We may not be able to fix these as they often relate to low browser spec or significant bugs. Some ‘green’ browsers have the odd cosmetic quirks. These have been noted but as long as they don’t affect the overall experience, the browser still gets a pass. 

We plan to test on lots more devices and are still sorting out how to best involve the community in this (if the community even wants to be involved :-))

Update: In response to initial queries from the community, we're also writing an article to explain our testing choices and the significance of each browser from a market share point of view. We should have this information up mid November (pipe dream...) as soon as we can.