You’ve been there, you have a killer new idea for the web and can’t wait to start iterating. Naturally you jump in head first and start coding,
"rails new my_killer_app"
You plan to add mobile apps as well but that will come later, you need to get your site up ASAP.
But can you afford to put off your mobile strategy? With the sales of smartphones and tablets now officially eclipsing the sales of PCs, the desktop browser is slowly moving away from being the central part of a service. Development teams need to step back and refocus. A new project should not begin in the browser, it needs to start out as a platform.
In late 2009, Luke Wroblewski wrote a now famous blog post titled “Mobile First”. In the article he proposed that development teams should design their web site for a mobile device first and use that as a basis for your desktop site. At that time the iPhone 3GS was king and Android version 2.0 was just announced, smartphone adoption was on the rise and there were steep projections for the future. It was time to rethink the way we designed for the web.
The book and presentations that followed were mostly focused on the user experience which for the most part is handled on the client side. But what about the server side, how do you properly build out a service that can be accessed by any device, not just smartphones but also eReaders, set-top boxes, blu-ray players, smart TVs, or any other device that is running a modern day OS?
Today’s web projects need to be centred around a platform. Too often development teams focus on building a product, they build a set of features to solve a specific problem. To create a platform you need to take a step back and take a more abstract view of the solution.
So what does it mean to build a platform?
The purpose of a platform first design is not to create something that CAN be built upon, but to create something that is MEANT to be built upon.
Taking these steps should set you on the right path.
1. Separate the User Experience from the services
Client-side and server-side teams are very different. Creating a great user experience that will get people talking requires designers and developers with a special skill set, many iterations, and a lot of end user feedback. A server-side team also requires a specific skill-set for handling tasks such as database optimizations and e-commerce transactions. The codebase and deployments for each team should be split so each team can iterate on them independently, you need a services oriented architecture.
By splitting your front-end and back-end into separate “apps”, client-side updates can be published multiple times per day while server side updates work at their own pace without interfering with each other. A mobile team can also begin developing the mobile components in parallel with the web development since they will be consuming the same set of services.
2. Plan for a third-party developer program from day 1
There is no better motivation to keeping your house clean than knowing that someone is coming over. If you treat your APIs like they will be used by an external party, you are more likely to be on your best behaviour. If you don’t plan on having a third-party developer or affiliate program, separating your client side and server side teams will have a similar effect.
Keeping a clean and thorough interface to your services is crucial to maintaining your Velocity. Development teams should not be slowed down by uncertainties or implementation details, integrating with a service should be no more difficult than working within one’s own codebase.
3. Be your own development partner
As the saying goes, “eat your own dog food”. The client side applications should only access the server side via Http methods, no cheating. This is a given if you are building iPhone or Android apps but this should include web apps as well.
Being strict on a services oriented design takes a lot of discipline, but by doing so you are ensuring that any functionality that might be useful in an app is available to all front-end developers. This will set you on the path for simple third-party integrations, mashups, or more of your own innovations.
So whether you are a startup that’s iterating on a new product, or have an existing product which now needs mobile integration, take a step back and rethink your architecture. By thinking platform first, you set yourself up for infinite possibilities on the client-side.