I'd like to start a brief new series on building a mobile app. I think nowadays people think of mobile apps as a destination, a place in and of itself. A target for specific types of content. A place where specific types of content are created and made available. That may have been true several years ago when the mobile problem space was in its infancy, but it's not true now.
Take games for instance. 30, 20, and even 10 years ago an electronic game was predominantly self contained. You had a disk, you copied the bits to memory, and you interacted with those bits in memory in a fixed location. But over the last 10 years even games have changed. You now interact with bits running on other peoples computers and on server farms throughout the world. The game you start with is often not the game you end up with as levels and secrets are unlocked and downloaded. Today, if you were to sit down and write a mobile game you may start by thinking about which devices you are going to support, or what type of game play you want to offer. But it's no longer enough to ask those questions alone.
We're now at a point in time where everything is connected. But we still think about mobile as an end in and of itself. But that's the wrong way to think about it in my opinion. I'm not saying that you should ignore the unique challenges that the mobile problem space throws at you. I'm just saying that when tackling those unique challenges you have to come from a different frame of mind.
Mobile needs to be thought of as a conduit for transient data. Data has no ultimate home. It moves and changes with us. Different contexts provide different aspects and insights. The data's meaning and relevance changes given the context from which we choose to consume or create from. Our data is part of a larger ecosystem for which mobile is just one end-point.
Today we think and talk about that ecosystem in terms of The Cloud. The predominant conversation around the cloud is as a final resting place for our data. I don't think that's the cloud's intention, but it's easy to approach it that way after decades of thinking about software that way. But I think that's an incorrect way to think about it. The Cloud is important, necessary even. But it's not a resting place for our data. The cloud is the glue that allows our data to be forever transient and disconnected.
Once you understand that you can start to see mobile for what it really is and can be in the correct frame of mind to start thinking about building a mobile app. When you understand that a mobile app isn't an end in and of itself but is instead a medium from which to consume and create transient content you can begin to ask the correct questions that will make your app relevant and useful to your consumers.
So what is the mobile problem space? It's trying to present content on a variety of screens, with a variety of inputs, in an occasionally connected state. It's dealing with a variety of hardware in such a way that the user doesn't have to think about it. It's about ecosystems that have their own user interaction paradigms and feeling familiar and friendly.
The mobile problem space is also about thinking about efficient data usage. But also thinking about how we can consume data in small chunks during brief periods of time, like while we're standing in line or sitting in a waiting room, while also having the ability to immerse ourselves for hours.
The mobile problem space is about presenting data in such a way that the important stuff jumps out at you while still giving you the ability to explore and immerse yourself in discovery. It's about understanding that we expect an app to remember the state of our data and the context around how we were interacting with it regardless of how long it may have been between uses or reboots. It's about being interrupted and multitasking.
As you can see, understanding the mobile problem space needs to begin well before you consider technologies and platforms or programming languages and data storage.
Take games for instance. 30, 20, and even 10 years ago an electronic game was predominantly self contained. You had a disk, you copied the bits to memory, and you interacted with those bits in memory in a fixed location. But over the last 10 years even games have changed. You now interact with bits running on other peoples computers and on server farms throughout the world. The game you start with is often not the game you end up with as levels and secrets are unlocked and downloaded. Today, if you were to sit down and write a mobile game you may start by thinking about which devices you are going to support, or what type of game play you want to offer. But it's no longer enough to ask those questions alone.
We're now at a point in time where everything is connected. But we still think about mobile as an end in and of itself. But that's the wrong way to think about it in my opinion. I'm not saying that you should ignore the unique challenges that the mobile problem space throws at you. I'm just saying that when tackling those unique challenges you have to come from a different frame of mind.
Mobile needs to be thought of as a conduit for transient data. Data has no ultimate home. It moves and changes with us. Different contexts provide different aspects and insights. The data's meaning and relevance changes given the context from which we choose to consume or create from. Our data is part of a larger ecosystem for which mobile is just one end-point.
Today we think and talk about that ecosystem in terms of The Cloud. The predominant conversation around the cloud is as a final resting place for our data. I don't think that's the cloud's intention, but it's easy to approach it that way after decades of thinking about software that way. But I think that's an incorrect way to think about it. The Cloud is important, necessary even. But it's not a resting place for our data. The cloud is the glue that allows our data to be forever transient and disconnected.
Once you understand that you can start to see mobile for what it really is and can be in the correct frame of mind to start thinking about building a mobile app. When you understand that a mobile app isn't an end in and of itself but is instead a medium from which to consume and create transient content you can begin to ask the correct questions that will make your app relevant and useful to your consumers.
So what is the mobile problem space? It's trying to present content on a variety of screens, with a variety of inputs, in an occasionally connected state. It's dealing with a variety of hardware in such a way that the user doesn't have to think about it. It's about ecosystems that have their own user interaction paradigms and feeling familiar and friendly.
The mobile problem space is also about thinking about efficient data usage. But also thinking about how we can consume data in small chunks during brief periods of time, like while we're standing in line or sitting in a waiting room, while also having the ability to immerse ourselves for hours.
The mobile problem space is about presenting data in such a way that the important stuff jumps out at you while still giving you the ability to explore and immerse yourself in discovery. It's about understanding that we expect an app to remember the state of our data and the context around how we were interacting with it regardless of how long it may have been between uses or reboots. It's about being interrupted and multitasking.
As you can see, understanding the mobile problem space needs to begin well before you consider technologies and platforms or programming languages and data storage.
No comments:
Post a Comment