Dave Shea on mobifying the web

Brian LeRoux: Dave, tell us a little about what Mobify does, and what you're doing with them?
Dave Shea: Mobify's name is essentially our mission statement: we want to mobify the web. We have a few ways we're doing that; if you've heard of Mobify in the past, it's likely due to our Studio product that allows anyone to quickly adapt an existing website for mobile. We also have a stellar customer service team that helps our customers build mobile sites. They build with the same framework that powers Studio, our open source JavaScript library called Mobify.js. And all of this work is sped up by our CDN and automated performance optimisation platform.

I've been at Mobify for a little over a year now and my role is VP of user experience. I lead design on the product team, which means prototyping, designing, implementing and testing new features. Some days I'll focus on bigger picture strategic stuff, other days I'm pushing pixels, and still other days I'm getting my hands dirty coding up new UI bits.

BLR: In the olden days of web yore, you coined CSS Sprites in this awesome A List Apart article. Has mobile changed how you approach on sprites?
DS: When I wrote that article I saw them as a pretty neat technique for making design workflow easier, but I was only dimly aware at the time that there was a much more important performance benefit at work. Delivering multiple assets in a single file tends to get them out there quicker: your files sizes are often lower, and the reduced HTTP requests lead to significantly faster delivery of your site.

After seeing what large companies like Google and Amazon did with the technique a few years ago I started dabbling in rolling up more and more of a site's UI in sprites. It felt like the right way to do it.

But, I've actually been thinking lately that sprites might be nearing the end of their natural life. High-DPI images complicate their usage; it's certainly possible to sprite up @2x assets, but it's rather fiddly to roll out. And forget about using sprites in a responsive situation where your image size isn't set in fixed pixel dimensions. That just plain doesn't work.

The images we'd traditionally bundle up as sprites can now be accomplished in other ways. CSS3 effects can do a lot of that styling for you, there's far less need to use images for interface elements these days. And web fonts are a neat combination of both low-bandwidth vector imagery and multiple assets consolidated into a single file, so they're a real performance win on both counts.

I don't think we're past the sprite era yet, but I'm catching glimpses of it on the horizon.

BLR: What tools are you using these days? What tools does your team use to collaborate?
DS: Most of my work is done in three apps: a classic design app like Photoshop or Illustrator, a code editor (Sublime is the current hotness) and a web browser. How I use them is probably the more interesting question.

All this talk about moving design out of Photoshop and into the browser is fine, but seems a bit misleading. You can't yet get away with totally ditching your image editor. My process is evolving -- for new work I usually start in a sketchbook and move to Photoshop for some pixel work, but lately I've been trying to keep that to a starting framework rather than final production-ready work.

My goal is getting into the browser as soon as possible, then iterating. If I need to improve the visuals of an element, usually that means taking screenshots back into Photoshop for further refinement. Other times I find myself making a bunch of changes in my browser's inspector and then copying the results into Sublime. All depends on which tool seems easier; Photoshop still wins out for when I need new visual direction, but increasingly I'm relying on WebKit inspector for day-to-day tweaks.

Collaboration-wise, we obviously use GitHub. I used to check in my changes on the command line, but I've taken to Tower lately. Given our feature branch and PR review process, or submodules, or any of the other wonderful stuff we're doing daily, I'm finding I'd rather not have to worry about syntax when I have the bigger problem of merging a few dozen conflicts staring me in the face.

We used to use GitHub issues for our bug tracking, and a combination of README files and GitHub wikis for documentation. But we've since moved to Jira and Confluence for the sake of having all company issues in one place. Good luck getting your sales and finance guys on GitHub is all I'm saying. (GitHub Issues is still my favourite issue system though. I really liked cross-referencing by issue #, and being able to reference an issue directly from the commit message.)

BLR: So where does client side adaptation fit in the whole responsive design world?
DS: Well, let's start by defining our terms. Everyone reading this already knows what responsive is. We're good there. Adaptive feels like it's still a bit nebulous though; I'd characterise it as any approach that allows document manipulation beyond what CSS alone provides. That includes things like DOM reordering, resource control, image resizing, and so on.

There are a few different ideas that would qualify as adaptive under that definition -- older proxy-based mobile site convertors, server-side adaptive techniques like RESS, or client-side adaptive techniques like Mobify.js. While Mobify's Studio used to use the proxy method, we're pretty sure it's not the future so we dropped it a few years ago.

RESS and client-side are what I'm a lot more interested in. Both are best when treated as additions to your responsive work -- leave the layout to the CSS, then adapt where necessary.

Here's a list of stuff you can selectively adapt for mobile devices that will help out a responsive site:

• Remove elements that shouldn't load instead of just hiding them with display: none
• Reorder an element's position in the DOM
• Replace an element with a different type of element (useful for refactoring UI controls)
• Adjust which scripts and images and web fonts load
• Swap out images with pre-rendered optimised versions

BLR: Everybody likes to say 'mobile first' but are there still times/places where this philosophy doesn't make sense?
DS: When you have to support IE8.

I don't actually have a better answer for this one. I'm only starting to formulate thoughts about mobile first as a design philosophy. (But, I will say that you only have to learn about IE8's lack of media query support once.)

BLR: What devices do you use to test and target when you start working out a new design?
DS: So far I've been treating device testing the same as I've always treated browser testing -- as a last pass once the major design decisions have settled down. I guess I've always been too lazy to think premature optimisation was a good idea, but I think when you're just testing for layout you can still get away with it.

I've seen the downsides of that approach of course. A device simulator doesn't give you any indication of performance, which is relevant when you're designing interactions and UI animations. I've had to go back to the drawing board with design ideas because initial device testing showed a menu flyout or view transition was super klunky.

We have a decently-stocked browser lab at Mobify with 40+ devices covering most point versions of iOS and Android, a few Blackberries and Windows Phones, and a few outliers like webOS and Firefox OS. We don't use all of them for every project, but we're well-stocked when we need to test.

BLR: You work with all sorts of mediums. I've seen you do simple print design, logos, to packaging. Has mobile changed these mediums, or how you approach them, as well?
DS: Not really. I have successfully fought off a few requests to add QR codes to packaging design though.

BLR: Bonus round! What is your current favourite beer?
DS: For lighter beers, I think Pilsner Urquell gets my nod. There's a lot of history behind that one, it's exemplary for the Bohemian pilsner style, and it's awfully refreshing. I love a good German pilsner too.

For bigger beers, Gouden Carolus Van de Keizer Blauw is at the top of my list. Westvleteren XII is great, but the hype is hard to live up to.

A handful of my favourite European breweries, in no particular order: The Kernel, Meantime, Fyne Ales, Mikkeller, Evil Twin, Brewdog, Ayinger, Brasserie Dupont, Cantillon, and I better stop there otherwise I'm going be here forever.

Photo by Tom Coates