I’ve been doing a lot of research for an upcoming project recently and considering various approaches for design and build and had some great conversations with a wide range of people and a few things keep cropping up so I figured I’d note down a few observations. Please forgive me if I’m telling you how to suck eggs, this is as much a “note to self” post as an open one.
“Mobile first” design
Yes, it has the word “mobile” in the name. However, it seems pretty clear that if you discount the “mobile” bit many of the principles are just sound design practice and it becomes nothing more than a simple guideline everyone should be working anyway. Here are some guiding principles any project should have. Sound familiar?
- Lean, optimised code and assets
- A content first approach to design
- Well considered source order
This really isn’t “mobile first design”, it’s good design practice any time. No matter what your belief or client requirements are for a site.
The separate mobile and desktop argument
For as long as I can remember Jakob Neilsen has wound up anyone who’s tried to make the web look nice. From his “Flash – 99% bad (Oct 2000)” article all the way up to his recent “Mobile site vs full site (Apr 2012)” research, he often has a knack for a headline but it’s easy to forget that underneath the troll like headlines, he does actually do more research than almost anyone else out there and draws conclusions from data.
I certainly subscribe to responsive design as a philosophy and methodology but having had a couple of great discussions with @peteduncanson in the office recently talk certainly turned to cases where mobile specific sites were potentially a more technically and economically viable solution than a single responsive build.
It’s not something I discounted entirely but even working on a large scale ecommerce site at work I felt responsive was the right tool for the job. However, moving up a notch to sites with millions of visitors a day where every byte literally costs ££ in bandwidth, there may be an economy of scale saving to made by stripping everything back.
To avoid confusion, I don’t buy into the idea of content being stripped back and serving a “lite” version to “mobile” users.
I’m extremely pragmatic when it comes to the web. I like an elegant solution but I like a working solution more. I feel following some bloggers/authors/speakers/tweeters that from time to time, the elegant solution is somehow “sold” as being better than a working one and anything less than idealistic perfection is not tolerable. Talk is often very cheap in the face of client launch dates and expectations.
Responsive is not a panacea, it was never meant to be
Most people have probably reached the conclusion themselves that responsive design isn’t a panacea for every project but I’m a big fan of the 80/20 rule which is probably more like 95/5 for websites these days although where resource permits, there may be assorted business and use cases but the examples I’ve seen so far tended to be extremely big, high traffic, high resource sites.
Right now, this is how I think about web design
It’s … a series of best guesses on how to apply a set of rules and techniques that change faster than the terminology used to describe them with the aim of making something accessible to more than 7 billion* internet enabled devices (of varying screen size, power and performance) that we currently know about and an unimaginable variety that we don’t. Web design is…
I’ve spoken to a few folks on Twitter including the very talented @RichardShepherd as I’d said recently I couldn’t immediately think of a site where responsive design couldn’t be used because at its core, I feel responsive design is not a design tool per se (in terms of all the media queries, asset optimisation etc) but is actually just a new name for most of the fundamental design guidelines I mentioned above.
I still think a well considered content strategy and clearing of clutter and legacy features will get you a long way but I think there are a few cases where benefits may be available on a larger scale.
It’s all just a little bit of history repeating
A lot of this current mobile first phase of web design feels a bit familiar. I’ve been doing this long enough to remember when IE6 was the best browser and we had dial-up connections.
Many of my peers have been doing it longer than me and while the code we write has changed, things like testing against slow connection speed are back (there’s an app for that) on the minds of older developers and are fresh and exciting to the ones who’ve only ever worked on a high spec mac and broadband.
We’re in one of the great cycles of the net, we had optimisation for dial-up, we’ve done big flash sites, holding pages and 2mb preloaders, we’ve done masses of keyword riddled junk copy and SEO link farms, we’ve done the web 2.0 gradient buttons and we’re back to the optimisation part again for different reasons but we’re here anyway.
Speak to a lot of developers and they’ll also wonder what all the fuss is about abstraction, object orientated css etc is. The principles have been around for a long time and I guess it’s great that us designers are finally looking to developers to help bridge the gap from crayons to servers. Much of it is old methodology applied to the front end. It’s great but not new. Want to learn a bit more about writing lean, DRY code for the front end? Speak to an experienced back end developer. It’ll open your eyes.
What’s the “right” tool for the job?
There isn’t one. Remember when you meet a client and you say something along the lines of “yours is a unique project” or “as an agency we treat all projects as unique” etc? Why should there be a tool or methodology that’s so general it fits every “unique” project? Don’t try to stick to a rigid process, adapt.
Think about your project, select what you feel is the best solution for that unique product/project and what will help it ship and start working for the client.