Mobile First Website Development

What is mobile first?

Put simply Mobile First means you start designing for the smallest, least capable device your customer may be using. Whether you're starting a completely new project or adding a new feature to an existing site you start with mobile. Once you have the experience figured out on the smallest, least capable device you plan on supporting you move up from there, this normally means phone -> tablet -> laptop/desktop. I like to take this one step further and design a "Basic" site that utilizes the bare minimum CSS and no JavaScript at all so you end up with something like Basic -> Mobile -> Tablet -> PC. I've found this ensures that no matter what device, connection speed or any other factor that I haven't considered comes up, the basic functionality always works even if it doesn't look so great.

What mobile first is NOT

Mobile first does not mean you fully develop something only for mobile, release that and then start over again potentially providing a completely different experience and/or functionality for other devices. This is a common mistake that many businesses make and don't even realize, take a look at this article on Forbes: Why Mobile-First May Not Be The Best Strategy After All

Now this author and the CEO he interviewed for the article have completely missed the mark and don't even realize it. You DO NOT build completely separate teams that will then build completely separate systems each with their own unique experience and functionality. You build individual components that are integrated together in the best way possible for each experience, starting with ... Mobile First. To be fair this is so common that even a company as huge as Facebook regularly gets it wrong leaving out or hiding very important functionality in their mobile app and website. I can't tell you how many times I've congratulated someone on an important life event only to get bombarded with notices that other people also commented on the same post and Facebook decided that their mobile users didn't need a way to disable notifications. This feature used to be there for all experiences and it felt like it would get removed or hidden around the same time I would comment on a post like that so I ended up just not using the mobile experience at all.

Why mobile first?

In case you haven't heard mobile devices are on the rise and in some countries are already more common than "regular" computers. If you're one of those people that needs facts to back up a claim here's a link to more numbers than you should ever need:
The Future of Mobile: 2014 [Slide Deck]
The Future of Digital: 2013 [Slide Deck]

OK, now that we all agree mobile is of ever increasing importance to the success of your site why does the order matter?

By designing for the least capable device you get a very efficient focused design right from the start. You're probably not going to come up with requirements to load some huge chunk of information that wouldn't even show on a high powered, full size desktop, you're going to figure out how to design an interaction that gets the user as close to what they're interested in with the least amount of taps or clicks. Once you have this worked out for mobile scaling up is easy, you may change the layout to make it look better once you have more space or present other components on the screen at the same time but the core functionality will be there for all experiences on all devices.

The design process should actually speed up, you have so little space to work with that you don't waste time trying to figure out what to stick in whitespace left over. The most important feature is put front and center and there's just no room left for useless filler and when you move up to a larger screen then you decide if it's worth cluttering the UI with something else or not.

When is mobile first a bad idea?

Really the only good argument for not doing mobile first is you have zero mobile users and the same amount of interest in getting and supporting them in the future. This may be the right choice for your organization or you could be shooting yourself in the foot only to watch your business wither as you lose customers.

A common argument you will hear for not doing mobile first is a need to support older browsers on older systems, now at first this may make sense until you actually think about it and realize that these "old" systems are less capable than a phone. This means you probably shouldn't be doing too much client side in terms of CSS or JavaScript because you need to support some very old browsers running on hardware that may have less CPU and memory than the smartphone in your pocket. So if you go up to the opening paragraph you will see that I've said you are designing for the smallest, least capable device. There are techniques to handle this and if you know in advance that a large number of your users are stuck on very old systems then this should be one of the factors in every project right from the start. In my opinion this argument against mobile first actually adds another reason why this process works, the assumption that all PC's are more capable than mobile phones or tablets is just wrong.

As it turns out all the processes and practices needed to make this work repeatedly are already pretty well known. To explain how they all work together deserves an entire post of it's own but if you're ready to change your process now and adopt Mobile First for your website all you need is to use Progressive Enhancement and Responsive Design along with it and you're on the right track.

Of course there will always be edge cases and you may find that you want to develop a Single Page App (SPA) optimized for each device rather than try to make one that works for all of them. In my humble opinion even this has a better solution than 3 or 4 independent complex Apps all targeted at a specific device because the cost of building and maintaining all of them needs to be offset by the returns you get. I've hinted at the approach I would actually take earlier on but this is another topic I feel should be fully explained in order to be properly understood and appreciated. As with any process there will inevitably be scenarios that it just doesn't work for so use some common sense and don't try to make it fit if it's not right to begin with.

Proper TDD - The case for simple tests

I've been trying to evangelize Test Driven Development (TDD) for quite a while now and come to the conclusion that in order to really appreciate it you need to fully commit to doing it properly. It won't really hit you the first day, first week and may take more than a month but at some point you will hit that moment when it just feels wrong to write code without first writing a test for it.

During a code review once I saw a very simple test for some very simple code and was asked by my peer reviewer what is the point of this?
I hadn't written either the code or the test and looking at both I didn't see the need for the test at all, it wasn't until afterwards I realized that the original coder was most likely doing TDD properly though. If you don't start with a breaking test then you're not doing it right so even very simple code should have at least one test.

Since that day I've taken on some very complex projects and continued my quest to convert fellow software developers over, without much success but I'm still trying. I have also written code using TDD in less than a day that I'm pretty sure would have taken me well over a week to finish and debug had I not followed TDD from the start.

I found this free talk by one of the best proponents for TDD there is, Uncle Bob and he does a great job of explaining this along with a Code Kata to show how TDD is really done: Advanced TDD by Uncle Bob.

In this talk Uncle Bob mentions the The Transformation Priority Premise and this is very important to consider while practicing TDD so here's a couple links to help explain this further:
http://blog.8thlight.com/uncle-bob/2013/05/27/TheTransformationPriorityPremise.html http://en.wikipedia.org/wiki/Transformation_Priority_Premise

If you are a TDD convert please pass along these links to anyone you know starting out with TDD. If you're not a convert yet give it an honest try and don't give up when you're pressured to "finish quickly". If you stick with it you will have solid reliable code that breezes through QA so any of that  time you feel is lost writing your tests will be recovered by time you don't have to spend hunting down hard to find bugs.