My plan was to compile all the excellent feedback received here and in other places on the debate whether it is best to develop mobile applications for the browser or native to the device (platform). I gave you a glimpse into my preference a few weeks ago with the teaser called - Mobile Application Development: Native or Browser. We will come back to this topic next week with a summary post but in the meantime I wanted to take the conversation in a slightly different direction… yet still related to the decisions around the development of mobile applications.
Ultimately the decision on what and how to develop your mobile application is a strategic one; one that should be based not on the currents of opinion (analysts and vendors) or on the noise around us (blogosphere and marketing). Instead, this decision should begin and finish with the mobile user. I realize this is nothing new … but hang in there.
When considering decisions around mobile application development I have noticed an unfortunate pattern. There is one thing that is being overlooked too often.
When trying to understand mobile workers, most people will mention the importance of location, presence, coverage, whether or not they are power users… and yes they will mention context. So far so good right? Well let’s dig deeper.
Location refers to a users place in space. As in geographic space. Presence refers to availability and whether or not others can see if the user is available. Coverage refers to network coverage and whether the user’s device is in or out of coverage. Regular vs Power Usage typically refers to how much and how often a user uses his device. Context typically refers to a user’s surroundings and their interactions with those surroundings.
These and other criteria that popped into your head are all good and valuable things to cover.
However, if we want to talk specifically about mobile workers the conversation cannot revolve around any one of the above points. Instead it needs to focus on one thing:
the mobile worker as part of a process that adds value to your organization
It may sound harsh to some. If it does you are not getting what is being said here. We are not forgetting that the worker is also an individual, but instead we are focusing on the main reason why that individual works in an organization (profit or not-for-profit) and gets paid. They get paid to add value. Your mobile application strategy needs to revolve around that one fact…
A worker exists in an organization to add value… even if mobile. A mobile application needs to add value to the mobile worker. The analysis therefore needs to focus on the work that the worker performs.
We will develop this topic further in the coming weeks (after I get some more mobile banking posts under my belt).
In the meantime please take a look at IT Business Edge writer Carl Weinschenk’s article with a similar title as this post and which makes reference to one of our articles.
Similar Posts:
- Mobile Application Development: Native or Browser
- Collection of tiny mobile apps for your iPhone (or my Personalized Enterprise Gateway)
- 13 Things To Remember When Integrating Mobility (Or How To Avoid Process Peddlers)
- Twitter’s Mobile Strategy
- Mobile Strategy and the iPod Touch
- Mobile Advertising and Productivity
- Mobile Applications and Loyalty
- App Store Market Data (from AppsFire)
- Moving Beyond Wireless Enablement (Canada)
- Of Context and Content
{ 1 trackback }
{ 2 comments… read them below or add one }
Hi -
Great insight. Thanks for writing about this topic. This is precisely how eM approaches all custom mobile development and I’d love to see others adopt this mindset as well. It takes a bit more time up front to clearly understand the goals of the user and how the solution will improve their job and productivity specifically, but in the end both the users and decision makers are happier for it.
Thanks for dropping by Tom. It is amazing how many times I have actually seen the business process be the last thing that is looked at. First comes the ‘great’ idea for an application, then comes the development and at the end they try and figure out how to integrate it into the workflow.
Crazy stuff!