Building and designing software used to be a whole lot easier. Historically we’ve only had to deal with one platform, the desktop computer. At this day and age where most of us have multiple devices and are always connected to the Internet this no longer holds true. Building software have become more complex – way more complex!
We are no longer limited to the confides of our desktop computers for digital experiences. Digital is all around us in the form of Computers, Smart phones, Tablets and increasingly Smart TV’s. There’s even a whole slew of new devices waiting around the corner in the form of the Internet of things. That is everyday things that are connected to the Internet like scales, fitness tools and intelligent toasters.
Changing User Expectations
With access to all these devices, people are no longer satisfied with being restricted to just one. They want to do everything on the device that’s makes most sense for their current context.
The best computer is the one you have with you when you want something done Jakob Nielsen
Conventional wisdom says that mobile users are rushed and on the go. That’s a myth. People use their mobile phones in all kinds of contexts. Yes some of them are when they are rushed and on the go. But they also use them when they have some time to kill, or when they relax in the sofa at home after work. People even perform tasks on their mobile devices that’s not typically “mobile” tasks. See 40% of people use their phone in the bathroom and other interesting facts.
Building multi-device eco-systems
What this means is that we can no longer just think one application on one platform when we build software to solve a problem. We need to consider the bigger picture. How to solve that problem in a wider context. The future of computing lies in building eco-systems of applications for different devices that solves a particular problem.
But having to provide software on multiple devices. How do we design, build and maintain these without getting overburdened by the complexity and diversity?
I’ve been thinking long and hard about this and the answer I’ve come up with is this: Build a strong and easy to use API with an eco-system of simple clients using it.
The trick here is to put as much of the complexity as possible in the API and make it as easy as possible for the clients to use it. This way the API is the piece you invest most in and that will live for a longer period of time. It will provide a foundation on which you can build relatively simple clients around.
The core of my thinking is that you need to make it as easy and painless as possible to build the client applications. New technologies comes and goes, who knows what the next wave of connected devices will be? Smart watches, smart glasses or something else? Whatever it is we need to make sure that we can be on that platform with relative ease, without having to start from scratch.
I’ve been talking broadly about API’s here but what I advocate is to build a REST API.
REST is not a technology, it’s an approach. It relies entirely on HTTP for communication so it’s virtually technology agnostic. This is good. It doesn’t require you to use a specific technology to build clients. No matter what the technology, they will likely be able to communicate via HTTP.
Keeping it technology agnostic is a key aspect. Given that your API will live for a longer period of time, you can’t predict what new tech will be introduced, and you can’t predict which type of clients you will build a couple of years from now.
Use a simple Data Format
Just as you should invest in a solid API. You should invest in a robust data format. The format should be simple enough to not add a lot of overhead but capable enough to transfer fairly complex data models.
To sum it up.
- We need to start thinking about building eco-systems of clients on different platforms rather than just thinking one application.
- To keep the cost down we need to invest in a solid API and a reliable data format. JSON being my choice of flavor.
- To keep the API technology agnostic, REST is a good approach. Since it relies on HTTP for communication virtually any programming language can talk to it.
- Putting the complexity in the API lets us focus on simple clients that are relatively easy to build and maintain.
I hope that I’ve got you thinking about how to approach building software for this new diverse and ever-connected world.
What’s your thoughts about this? I love to hear them in the comments.