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?
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?
IJ: Is that server-side swapping of images expensive?
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.