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

Thank you for reading 5 articles this month* Join now for unlimited access

Enjoy your first month for just £1 / $1 / €1

*Read 5 free articles per month without a subscription

Join now for unlimited access

Try first month for just £1 / $1 / €1

The Creative Bloq team is made up of a group of design fans, and has changed and evolved since Creative Bloq began back in 2012. The current website team consists of eight full-time members of staff: Editor Georgia Coggan, Deputy Editor Rosie Hilder, Ecommerce Editor Beren Neale, Senior News Editor Daniel Piper, Editor, Digital Art and 3D Ian Dean, Tech Reviews Editor Erlingur Einarsson and Ecommerce Writer Beth Nicholls and Staff Writer Natalie Fear, as well as a roster of freelancers from around the world. The 3D World and ImagineFX magazine teams also pitch in, ensuring that content from 3D World and ImagineFX is represented on Creative Bloq.