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.
Wednesday, 27 November 2013
Gaps & ... Other Gaps
When producing a cross-platform solution, you could be lucky, & you're solving a problem that someone else has already more or less solved, so the cross-platform infrastructure gives you enough support to implement the whole solution (given enough libraries).
However, you could be less than fortunate, & all of the googling in the world won't come up with someone else's trailblazing through your problem.
This is when it's time to get creative. A good cross-platform environment will allow you to build your own modules of some sort that are effectively native. In effect, this defeats the whole purpose of having a cross-platform delivery model, but in the real world this is often necessary.
It also means that you will either still need the development environment for creating native apps (or at least libraries), or else you will need to be able to reach out to contractors or out-sourcers who can do that work for you. The good news is that you are now specifying a very tightly-defined piece of functionality.
For example, if you want to use the on-board voice recognition, then you need to get down into a native interface. For iOS, you theoretically can't access Siri. For Android, there often is a way, dependent on the device, to access such services. If you can define your new library's API, then someone else can provide that solution for you - & they'll be able to get it right, quote reasonably effectively, & give you a fair idea up front of how functional the unit will be. They can do that because they are concentrating on a given mobile platform, & because the unit of work is easy to understand.
The gap now is in co-ordinating the piece-workers with the architecture of the solution, managing their deliverables as a part of the project plan, & ensuring that there are agreed-on test cases for acceptance of those units.
That's the new gap.
Once upon a time, it was a matter of having a team that could work on a solution, & they would skill-share to ensure that the components all came together, integrating their tests from component up to UAT. Processes like CI/CD assume that work is continuous & centralised (on one development platform, not necessarily geographically co-located). Co-ordination becomes key once more - relationship management, project management, integration - & there is a rising importance in understanding testing - not just how to perform tests.
Cross-platform development is not a silver bullet, but it changes the game to focus your technical resources on what matters - the UX - & your management resources on what they're good at - relationships.
However, you could be less than fortunate, & all of the googling in the world won't come up with someone else's trailblazing through your problem.
This is when it's time to get creative. A good cross-platform environment will allow you to build your own modules of some sort that are effectively native. In effect, this defeats the whole purpose of having a cross-platform delivery model, but in the real world this is often necessary.
It also means that you will either still need the development environment for creating native apps (or at least libraries), or else you will need to be able to reach out to contractors or out-sourcers who can do that work for you. The good news is that you are now specifying a very tightly-defined piece of functionality.
For example, if you want to use the on-board voice recognition, then you need to get down into a native interface. For iOS, you theoretically can't access Siri. For Android, there often is a way, dependent on the device, to access such services. If you can define your new library's API, then someone else can provide that solution for you - & they'll be able to get it right, quote reasonably effectively, & give you a fair idea up front of how functional the unit will be. They can do that because they are concentrating on a given mobile platform, & because the unit of work is easy to understand.
The gap now is in co-ordinating the piece-workers with the architecture of the solution, managing their deliverables as a part of the project plan, & ensuring that there are agreed-on test cases for acceptance of those units.
That's the new gap.
Once upon a time, it was a matter of having a team that could work on a solution, & they would skill-share to ensure that the components all came together, integrating their tests from component up to UAT. Processes like CI/CD assume that work is continuous & centralised (on one development platform, not necessarily geographically co-located). Co-ordination becomes key once more - relationship management, project management, integration - & there is a rising importance in understanding testing - not just how to perform tests.
Cross-platform development is not a silver bullet, but it changes the game to focus your technical resources on what matters - the UX - & your management resources on what they're good at - relationships.
Saturday, 16 November 2013
The More Things Change ...
Once upon a time (& yes, I'm old enough to think of my earlier career as possibly mythical), we used to talk about "cross-browser" issues. Let's say around the year 2000, when the three major browsers were IE (which was getting behind in functionality), Netscape, & anything you could get to run on the Mac. At the time, it almost didn't matter what the browser was on the Mac, as long as you could demonstrate something.
The problem then was that there were lots of different implementations of the HTML standard & interpretations of how it fundamentally worked. There were also a lot of extensions that made HTML useful. It usually meant that you could not, under any circumstances, release a web site unless you either specified the browser (which meant you were stuck on an older version of IE), or else had tested on several versions of several browsers.
Then some **** (company) would release a new browser version just as you reached go-live for your website & marketing campaign, & you had to start testing all over again.
Those days were almost over when HTML5 started coming into the light. I think that we're not only back at square one, but we're worse off with Firefox & Chrome now major contenders in the browser market, but at least you're less likely to do much that's specifically targeted at the Mac - unless you want to.
What really becomes the problem is the cross-platform issues around phones, tablets, phablets, notebooks, airbooks, laptops, & any of a number of variations on the theme, with their different browser implementation engines, screen sizes & resolutions, aspect ratios, etc.
This nightmare just gets worse if you are responsible for launching a web site that caters for desktop & mobile, or else a multi-platform app.
Into this market come the cross-platform development solutions & multi-platform deployment solutions. The former let you build things that can be converted into native apps, while the latter let you build things for an indeterminate infrastructure (like a VM) that can be run on various devices.
This does not solve the problem, but it does make the development easier. Rather than trying to develop multiple solutions - often independently (different developers in different dev envs) - you develop the solution once, as a designer, & then hand this over to an integration/deployment specialist who just has to tweak the application to run on whatever platforms are needed.
Then you click the heels of your red slippers three times ...
This process changes the structure of the dev team. You end up with UX people working hand in hand with DevOps types. You often have platform-based non-technical testers at the end.
This is very different from the traditional position of having devs doing almost everything, & devs who work as testers doing the QA.
If you take the right approach, cross-platform development for mobile applications these days is not as bewildering as it at first seems, but it can't be done by just transferring existing dev models to new technologies.
However, if you don't change your ways, you will be stuck with the same problems that we had at the turn of the millenium.
The problem then was that there were lots of different implementations of the HTML standard & interpretations of how it fundamentally worked. There were also a lot of extensions that made HTML useful. It usually meant that you could not, under any circumstances, release a web site unless you either specified the browser (which meant you were stuck on an older version of IE), or else had tested on several versions of several browsers.
Then some **** (company) would release a new browser version just as you reached go-live for your website & marketing campaign, & you had to start testing all over again.
Those days were almost over when HTML5 started coming into the light. I think that we're not only back at square one, but we're worse off with Firefox & Chrome now major contenders in the browser market, but at least you're less likely to do much that's specifically targeted at the Mac - unless you want to.
What really becomes the problem is the cross-platform issues around phones, tablets, phablets, notebooks, airbooks, laptops, & any of a number of variations on the theme, with their different browser implementation engines, screen sizes & resolutions, aspect ratios, etc.
This nightmare just gets worse if you are responsible for launching a web site that caters for desktop & mobile, or else a multi-platform app.
Into this market come the cross-platform development solutions & multi-platform deployment solutions. The former let you build things that can be converted into native apps, while the latter let you build things for an indeterminate infrastructure (like a VM) that can be run on various devices.
This does not solve the problem, but it does make the development easier. Rather than trying to develop multiple solutions - often independently (different developers in different dev envs) - you develop the solution once, as a designer, & then hand this over to an integration/deployment specialist who just has to tweak the application to run on whatever platforms are needed.
Then you click the heels of your red slippers three times ...
This process changes the structure of the dev team. You end up with UX people working hand in hand with DevOps types. You often have platform-based non-technical testers at the end.
This is very different from the traditional position of having devs doing almost everything, & devs who work as testers doing the QA.
If you take the right approach, cross-platform development for mobile applications these days is not as bewildering as it at first seems, but it can't be done by just transferring existing dev models to new technologies.
However, if you don't change your ways, you will be stuck with the same problems that we had at the turn of the millenium.
Subscribe to:
Posts (Atom)