Mobilism: Muddling Through the Mobile Web

by May 17, 2011

In his Muddling Through the Mobile Web presentation at Mobilism in Amsterdam, Netherlands Bryan Rieger analyzed the complexity of context and content on the Web and proposed some immediately actionable and bigger picture solutions. Here are my notes from his talk:

  • Previously the best practice was to build separate mobile sites. But now several older ideas like progressive enhancement are coming back as options and new ideas in the form of responsive Web design are emerging. There’s also the idea of “One Web” -having a single set of URLs for your content. Which in principle is great.
  • But there are still many unanswered questions? What do you do horizontal images (for example)? What about when style-sheets and scripts aren’t suitable for devices? Every style-sheet is not supported, desktop scripts typically aren’t suitable for mobile devices.
  • What about things like video-formats that can’t be detected? Progressive enhancement mark-up can cover things like codecs but not bandwidth or screen size variations. The biggest problem for handheld video playback is pulling down high-bit-rate HD files with pixels that don’t display.

This is Hard

  • There are a lot of ways to try and detect browser features and adapt content. Yiibu tried a number of content filtering and transformation prototypes.
  • DOM filters: Start with your content, use WURFL to get a device ID, and get the device width, then find all images in the DOM and adjust all IMG tags to server what is most appropriate for the device.
  • Media queries on the server: tried to build variants but realized they were moving too close to XSLT, then experimented with XSLT-which also didn’t work.
  • Did learn two things with al these experiments: responsive design and one web is really hard; everything we thought about the Web is wrong.
  • In hindsight, the problem is obvious. We started out with devices that enabled more content on them (desktops), but now we have limited speed/display devices that allow people to do “more” in the real world. But we are still constrained by human factors.

Content & Context

  • How do we make our content meaningful in our context? Two bad word here: content and context.
  • Context is set of circumstances that govern what we are doing. Determining a device context is often much easier and often more productive than trying to guess a user’s context.
  • A device context consists of device features (screen size, touch, canvas, SVG, etc) and device constraints (screen size, no touch, poor Javascript, isMSIE, etc)
  • How do we detect features? How about a combination of client and server working together. The server (and device database) cover first run (what to send). The client manages further feature detection.
  • Clients are good at telling you what features they support when they tell the truth. But there are many cases when they are wrong.
  • The biggest problem we have is first load. Server has a lot it can send down to you but it doesn’t know what to send down. Using WURLF you can find what to send, then send only the right stuff.
  • Use Javascript to test the features of the device and set what you need. Update a cookie with a device profile and use it later to determine what to send the next time, then save the profile on the server so you can data mine it later.
  • The device context (or profile) is defined via features & constraints. But only if those features and constraints are actually relevant to you.

Thinking Beyond Today

  • What if what we have today isn’t actually what we have today? What if we had started with a more constrained set of device first? How would we have thought about design moving forward? What if we designed content in the same way we design software? MIT logo (for example) can be rendered in many different variations.
  • Most Websites today are built using a CMS with some webpage templates into which we add content. When content is added it is done without context.
  • We treat our assets as rubbish with no value. It has become secondary to everything else. Screen scrapers that apply styles are the new generation of readers. Surely we can do better with our content?
  • PDF files are a database for content. Combine that with Postscript and now you have a programming language. It is designed to render faithfully everywhere. It’s a database and an application. But PDF is not terribly adaptive.
  • Web design is software design. You need to take device context into consideration when designing. That won’t always be a screen.
  • CouchDB runs on mobile devices and servers. It is a document-centric database and Javascript that creates views. Node.js does not have data storage behind it but it helps you bring things in and filter DOM.
  • Start with the content, typography matters. Think relatively (use ems and %). Then use variables in CSS with Sass or Stylus. Sass allows you to add variables to CSS.
  • Microformats and data-attributes (HTML5) can be used to add meaningful structure to content. Structure makes content usable in new ways.
  • Images can be applications (use Google charts API). Using HTML5, CSS, and SVG can be used to render images as applications.
  • It is not necessary to change and survival is not mandatory either.