Interview: Filament Group on HTML5 and Design

On 14 October I spoke with Todd Parker (TP), Mat Marquis (MM), and Patty Toland (PT) of the Filament Group about their experience with HTML5 and other Open Web Platform technology in work for the Boston Globe.

IJ: Tell me about Filament.

TP: Filament group is Boston-based design shop. We are big proponents of using Open Web standards, making sites easy to use, and ensuring accessibility. We've written a lot about the use of open standards. We have even written a book on "Designing with progressive enhancement", which is how the Boston Globe came to contact us.

IJ: What is progressive enhancement?

TP: Progressive enhancement is an approach to web development that strives to deliver a usable, accessible experience to the broadest range of web-enabled device all with one code base. We always start with "plain, semantically rich HTML", working on the assumption that it will work everywhere. Then we improve the experience by adding other features on top with CSS, Javascript, and so on. This approach lets you reach more devices, and works particularly well for reaching mobile devices. We also advocate "responsive design" (a term coined by Ethan Marcotte). Responsive design refers to adapting the results to device capabilities, taking into account factors such as screen size, input method, and so on.

IJ: We faced a lot of these issues during our W3C site redesign project. I'm curious how easy you find it to write responsive code.

TP: It's only been this year that the responsive design approach has started to really work.

PT: The proliferation of tablet and phones has been an important driver from the client perspective. There is a strong business case for more flexibility, rather than targeting specific devices. Our clients have begun to make this a requirement.

IJ: One topic we addressed in the W3C site redesign was fluid layout -- content reflows if the browser window changes size -- rather than choosing a fixed width. Any thoughts on that?

MM: I think that fixed width layout is a bad holdover from imposing print expectations on the Web.

TP: But responsive design is more than taking a mobile or desktop layout and simply stretching it to fill the browser window. Many older sites would do that, and end up with long line lengths that are hard to read, or big gaps around images. The nice thing with responsive design is that each component is fluid, and furthermore is part of a flexible grid.

IJ: Please explain.

TP: The flexible grid means that you can adjust and optimize the global layout depending on client factors such as screen width. For instance, you can go from 4 columns to 3 to 2 depending on the size of the browser window. There are certain "thresholds" when, for instance, you would change the number of columns from 4 to 3 to 2. Layout is fluid within those thresholds. In practice, we start with a single column approach for mobile, and then, for clients with more horizontal space, we start putting things side-by-side.

MM: We might use seven thresholds, for example. But ultimately the design depends on the real content needs. There are no fixed rules simply based on widths. You need to account for typography and the nature of the content.

IJ: Are there libraries that you use that you've found to be indispensable?

MM: jQuery certainly makes things easier.

TP: One thing we came up for the Boston Globe was a polyfill for media queries on Internet Explorer. We use "respond.js" but to improve performance we had to invent or refine a number of things.

TP: We are big believers in the idea that the Web should be available to everyone. What we try to do is present content in the best possible way. We don't make assumptions like "you may not want to see a photo on your mobile device." That's overreaching.

IJ: How do you manage user preferences, for say, downloading a thumbnail or a larger photo?

TP: One way is to pull things in through ajax once we detect a mobile device. For some devices we don't download all content automatically. For instance, the Boston Globe has some beautiful photos. But they may not be useful on a mobile device. So we do the following: in the source of a page we have a link to a mobile-friendly version of the photo. When you first request the page, we determine your screen size through Javascript, and we choose which image to serve (thumbnail or high-resolution) depending on the screen size. This is a server-side technique, and in the end there is only one HTTP request for the image.

IJ: Is that server-side swapping of images expensive?

MM: No, it's a minor operation on the server. And much better than browser sniffing which makes maintenance more difficult as the number of devices goes up. We do have an architectural issue though: recently browsers started pre-fetching content. We use cookies to keep track of screen size information when the client fetches a page, but the pre-fetching behavior for images bypasses the cookies. We would love a better solution than using cookies.

IJ: Are there any new features of HTML5 or other specs that you like in particular, such as video?

MM: Working with HTML5 video will be good. I love this particular fallback pattern for html5 video: if video in html5 is not supported; falls back to flash, which can in turn fall back to an image.

IJ: Are you using any APIs in particular?

MM: We'll take all the APIs you can throw at us. We are using local storage, app cache, which are really cool. We are doing it in a way where there's still a solid baseline service, but if your browser is enabled, you can save a bunch of content offline (in this case, Boston Globe stories). However, there are some challenges with app cache. I would like to speak with someone involved in that area. I'd like to see more documentation of app cache.

IJ: Are your clients talking about Web on TV?

TP: We are super interested in this, and we've started some conversations but nothing I can discuss just yet. There is an even wider range of devices to consider, for example wristwatches.

IJ: What's not working for you in the Open Web Platform, or what's missing?

MM: I don't recall that we ran into any walls. However, there are issue with native form widgets. You never know how your form markup will be rendered by a browser - it's too unpredictable. There needs to be a better way to style native widgets. For instance input/range is often rendered as a slider. But a lot of the time the sliders have no labels, and the look very different across browsers. What we have to do most of the time is to use an HTML thing like type="range" and progressive enhancement. Or, take a meter bar. Today we know that Chrome gives us a lime green progress bar with a set width that we can override, but only by using a proprietary set of selectors—there’s no way to anticipate how other browsers will handle their default styling for these elements, and without a sense of how they’ll render these elements we can’t override those styles in a future-friendly way. It would be great to have some guidelines around the styling of these new elements, so developers would have a sense of how things will work going forward.

TP: These widgets are black boxes to developers, like the "select" element used to be.

MM: Maybe they could be namespaces. We'd just like to see a plan to make them easier to use and more predictable.

IJ: That's all for today. Thank you all for chatting with me.