A friend of mine - who qualifies as a Domain Expert - was talking to me about getting some development skills so that he could implement his ideas. My first thought was along the lines of "don't do that! there are enough devs to do the implementation, if only you can tell them what to build!"
This is not meant to be a metaphor, but the same applies when it comes to mobile development. You shouldn't need to learn about every mobile platform to deliver your application.
Admittedly, there are some applications that are low-level wizardry that need to be implemented natively on a mobile device, at which point you have to make some hard decisions on which ones, etc. There are also a lot of applications that are primarily channels to the customer - a way to reach the mobile customer at their convenience. This usually has nothing to do with the type of smartphone they happen to own.
That's what cross-platform development is all about. You take the essence of the solution away from the technology - separate the "what" from the "how". If you have a clear understanding that what you need to deliver to the customer is a user experience that makes their lives better, then that forms the basis of the solution definition, the design, & the QA/UAT.
There are admittedly some applications that are almost wholly within the realm of the device - like many games - but most of the useful apps connect the mobile user with the rest of the world. The price of broadband is coming down, so this connectedness is becoming more important. The increasing use of cloud data & services shows this.
The mobile experience is about getting access to the user's stuff in the easiest way possible, without having to carry it with them.
If we accept this, then the device-specific implementation becomes a matter of tweaking that experience to take advantage of hardware or platform capabilities - such as built-in voice recognition or text-to-speech, which might not be available on all platforms. Aside from this kind of feature, the capabilities of smartphones differ usually in the way of degrees - screen size, resolution, etc.
The approach to developing a channel to your mobile customer should be multi-tier - the UX (which includes any business logic), the device-specific tweaks, & the connection to services. The more of the UX that you can deliver independent of platform, the better.
Even if you simply use a cross-platform solution to prototype "this is how the user story must work", then you're well ahead of trying to mock up prototypes for every platform you want to target.
Getting back to my friend - as a domain expert, his talents are best applied to describing what the system does - the user stories - because that's how he can determine if the end product is what he expected (not by developing the solution himself).
In the general sense of developing solutions for mobile users, the domain expertise is still in the user story - the art of making lives easier. If you know how to do that, then you can ensure that your product is as useful as you had hoped, regardless of the platform you're delivering to.
Sunday, 15 December 2013
Wednesday, 4 December 2013
Divide or Conquer
I've seen three approaches recently to the generic problem of reaching as many smartphone users as possible. I should start by saying that Windows 8 has not really made enough of an impact to make it a contender as a distinct delivery platform, & Blackberry seems to be a complete market failure, so I will limit this discussion to the big two - Android & iOS - & leave it to the reader to imagine a world where there are four platforms to worry about.
Technology decisions should be almost an after-thought because, in an agile environment, these things can change. Next year, there might be a fantastic cross-platform environment suitable for another product or the next release - or the providers of the current platform could discontinue support of their product or make the conditions of use commercially non-viable.
The important thing is not to become the expert in a technology, but to be able to define your business needs for a technologist to implement - & for those same needs to be implemented by another technologist next time, if need be. That technologist could be an external contractor or the internal development team.
The definition of the product needs to be conveyed in terms of end-user value (why would they use our product), brand alignment (why would they want our product), functionality (how would they use our product), & product direction (what is our product - or user base - going to be tomorrow). The acceptance of the marketable product needs to reflect this, regardless of how it was created.
You could say at this point - "So, what's changed?"
Having to support multiple platforms does not change the fundamentals of product development. To create good product - even in the mobile space - you have to want to create good product. Once you've worked out what that is, the rest is just a matter of implementation - easy :)
- Outsource. If you don't have the skills in-house, then farm out the development to experts who do. If you're going to go to that trouble, then you farm out the development to distinct experts, effectively solving one problem twice, & hope that they magically come up with the same solution.
- Insource. Some organisations think it's better to bring the experts in-house, either by hiring people to work on the project long-term, or else getting in contractors who are experts. If you rely on new people to define & develop your solutions, you will end up in a position no different to the above - two solutions taking twice as much energy with the hope that they will be the same.
- No-source. When a solution (or prototype) for each platform exists, scrap both & start from scratch with a cross-platform solution that guarantees consistency of UX. Although this makes sense on the surface, jumping into this position from the get-go is not the answer - you first need to determine if it can be done that way.
Technology decisions should be almost an after-thought because, in an agile environment, these things can change. Next year, there might be a fantastic cross-platform environment suitable for another product or the next release - or the providers of the current platform could discontinue support of their product or make the conditions of use commercially non-viable.
The important thing is not to become the expert in a technology, but to be able to define your business needs for a technologist to implement - & for those same needs to be implemented by another technologist next time, if need be. That technologist could be an external contractor or the internal development team.
The definition of the product needs to be conveyed in terms of end-user value (why would they use our product), brand alignment (why would they want our product), functionality (how would they use our product), & product direction (what is our product - or user base - going to be tomorrow). The acceptance of the marketable product needs to reflect this, regardless of how it was created.
You could say at this point - "So, what's changed?"
Having to support multiple platforms does not change the fundamentals of product development. To create good product - even in the mobile space - you have to want to create good product. Once you've worked out what that is, the rest is just a matter of implementation - easy :)
Sunday, 1 December 2013
To Dance with the Devil
One of the big differentiators between native Android & iOS mobile app development is how much of the process is monopolised. This is an important point for many companies who want to start mobilising their product - especially if they already have something web based.
Android is an open platform. That means that almost anyone can get the tools (several to choose from) to create an app, use open source libraries to support the development, & quickly & easily launch the resulting product onto the unsuspecting world for the total price of a cheap laptop (more or less) - & simulation means that you can get away without buying a phone.
To do the same thing for an iOS app, you need the right kind of hardware, essentially only one dev environment, enroll in Apple's dev program, & jump through hoops to get your app approved so that other people (the general public) can use it. There are no corners to cut.
If you're thinking from the point of view of a start-up, Android is easy. If you're thinking in terms of targeting iPhone/iPad users, you don't have the luxury of making the decision about your dev environment, tools, etc, at all.
The consequences are that almost anyone can create an Android app & distribute it from their bedroom, but creating an iPhone app at least takes the commitment of capital outlay & following a process, which is less likely for a teenager to do.
This is all native mobile app development so far.
You would think that cross-platform solutions would try to go down the Android path, rather than the Apple path, but that's not necessarily the case. Often the tools needed to build or deploy the app are the key elements in the business model for cross-platform solution providers. If you don't have the right tools, the rest becomes a struggle.
PhoneGap (Cordova) & Rhodes (RhoMobile) offer hosted dev environments (at a price). Titanium, although a free dev env, is limited compared to its big brother, Appcelerator.
Deploying a PhoneGap app to a mobile device is like hosting a web page - if you have the host environment on the device, then it's easy to load up a new app. However, if you bundle the hosting environment, then you're distributing a native app (via iStore/Google Play). Your end-users would need to commit to the run-time environment (equivalent to installing a Java RE on your PC) for you to avoid dealing with Apple as well.
Flex, Sencha, & Rhodes are like using a whole new technology to be multi-platform - not necessarily an obvious commitment for a start-up.
What am I saying here? The gap in cross-platform development is large. You will always have trouble jumping it alone, & that first step into the void is the most important one.
Choose your travelling companion wisely, based on how far they're travelling in the same direction (what functionality they support), & how likely they are to still be there when you get to your destination (their commitment to the technology).
Going with a "brand" is often the smartest way forward, rather than trying to go it alone because it's "cheaper". Basically, there are no silver bullets & it's often better to just bite one.
If you must have apps (which is a decision only you can make), never lose track of why you need them (what you're trying to achieve), to stop you from using alternatives like responsive design web content.
Android is an open platform. That means that almost anyone can get the tools (several to choose from) to create an app, use open source libraries to support the development, & quickly & easily launch the resulting product onto the unsuspecting world for the total price of a cheap laptop (more or less) - & simulation means that you can get away without buying a phone.
To do the same thing for an iOS app, you need the right kind of hardware, essentially only one dev environment, enroll in Apple's dev program, & jump through hoops to get your app approved so that other people (the general public) can use it. There are no corners to cut.
If you're thinking from the point of view of a start-up, Android is easy. If you're thinking in terms of targeting iPhone/iPad users, you don't have the luxury of making the decision about your dev environment, tools, etc, at all.
The consequences are that almost anyone can create an Android app & distribute it from their bedroom, but creating an iPhone app at least takes the commitment of capital outlay & following a process, which is less likely for a teenager to do.
This is all native mobile app development so far.
You would think that cross-platform solutions would try to go down the Android path, rather than the Apple path, but that's not necessarily the case. Often the tools needed to build or deploy the app are the key elements in the business model for cross-platform solution providers. If you don't have the right tools, the rest becomes a struggle.
PhoneGap (Cordova) & Rhodes (RhoMobile) offer hosted dev environments (at a price). Titanium, although a free dev env, is limited compared to its big brother, Appcelerator.
Deploying a PhoneGap app to a mobile device is like hosting a web page - if you have the host environment on the device, then it's easy to load up a new app. However, if you bundle the hosting environment, then you're distributing a native app (via iStore/Google Play). Your end-users would need to commit to the run-time environment (equivalent to installing a Java RE on your PC) for you to avoid dealing with Apple as well.
Flex, Sencha, & Rhodes are like using a whole new technology to be multi-platform - not necessarily an obvious commitment for a start-up.
What am I saying here? The gap in cross-platform development is large. You will always have trouble jumping it alone, & that first step into the void is the most important one.
Choose your travelling companion wisely, based on how far they're travelling in the same direction (what functionality they support), & how likely they are to still be there when you get to your destination (their commitment to the technology).
Going with a "brand" is often the smartest way forward, rather than trying to go it alone because it's "cheaper". Basically, there are no silver bullets & it's often better to just bite one.
If you must have apps (which is a decision only you can make), never lose track of why you need them (what you're trying to achieve), to stop you from using alternatives like responsive design web content.
Subscribe to:
Posts (Atom)