Paul Saunders, Operations Director for Conduce Software and Conduce Consulting wonders ‘what next?’ for these familiar and useful devices

The launch of the Apple iPad in the spring of 2010 triggered a wave of demand for consumer technology in business. Now, only three years later, many business users ask themselves what they ever did before the iPad’s radical new interpretation of the tablet computer was ever conceived. Certainly the iPad has changed information technology for flight operations, either directly through the availability of a cheap option for electronic flight bags and personal electronic devices; or indirectly by influencing the design of software and hardware alike. Today, the iPad is on the shortlist for any new mobile hardware implementation and iOS compatibility is expected to be a cost of doing business in the software development world.

Three years on from the launch of the iPad, we are anticipating yet another iteration of the iOS operating system; another batch of new iOS devices and the first batch of early adopters are already embarking on device replacement programmes.

Furthermore, these same early adopters are looking at ways to roll out devices to other parts of their business. I spent those first three years advising operators on how to adopt iPads, now I am revisiting those same businesses to look at their next generation business cases. They want to know how to take their adoption to the next level. What new use cases are going to provide a similar level of business improvement? How can they improve their return on investment? How can other areas of the business (with pilot envy) also get in on the act?

Here, I’m going to explore some of those frequently asked questions and provide some observations on how operators, software vendors and content providers can take their adoption and support of iPads to the next level.

Hardware

What’s occurring these days in the tablet market? Despite seeing their market share dwindle from almost 100% in 2010 to around 52%, Apple’s iPad is still a force to be reckoned with and a benchmark for other tablets. Although Android, and of late Windows tablets are proving more and more popular, the iPad has a seemingly unassailable dominance in the flight operations sector. This is largely thanks to a broad choice of EFB apps, increasingly compelling case studies and regulatory acceptance. Many operators it seems are wary of breaking new ground with new devices entering the market when the iPad is tried and tested with proven hardware and software. Users and consumers are still finding the iPad to be the most attractive device when compared with the alternatives. This is backed up by the most recent study which found that over 80% of tablet internet traffic is coming from iPads. This indicates to me, that there are a lot of older iPads still in circulation and once in the hands of users are frequently used. I personally have access to a variety of devices for testing and developing purposes, and my tablet of choice is my trusty iPad2 which is almost two years old now and still going strong. Apple’s annual release of a new version of the iOS operating system helps to breathe new life into aging hardware and there is always a new generation of apps to promote user interest due to the thriving developer community. In fact the pending release of iOS7 will support all but the first generation of iPads, so existing operator deployments of the iPad2 will see yet another year of hardware usage without enforced replacement.

Windows 8 has finally started to make an impact on the EFB market, with early promise somewhat hampered by the confusion over Windows RT versus the fully featured Windows 8 Professional. However the relatively straight forward translation of existing Windows software, coupled with the launch of business-friendly hardware, such as the Panasonic ToughPad, and the usual contenders, from the likes of Lenovo, Asus and Acer, has led to Windows 8 being considered a viable option for use in the cockpit once again. All that remains now is for some of the legacy Windows software to be redesigned with a more consumer friendly and touch optimised interface.

Software

It never ceases to amaze me how tolerant most users are of mediocre software. Any software that is presented on an iPad with a lick of the iOS paint brushes seems to be manna from heaven for flight crew when compared to some of the legacy rubbish their desk bound colleagues have to put up with. The impact of intuitive software on our industry is phenomenal. The promise of slashed internal support and training costs have been realised by early adopters of the iPad, not to mention the intangible benefits reaped though usage efficiencies and through human factor improvements.

However I don’t believe that software developers have gone far enough to truly embrace the consumer experience that the iPad brings, nor have they gone nearly far enough with the adoption of innovative touch and gesture based interface design. With iOS7, Apple have set a benchmark with the exploration of gesture based user interface design borrowing heavily from the best apps like Clear (http://www.realmacsoftware.com/clear) or Mailbox (http://www.mailboxapp.com/)  and by abandoning their heavy utilisation of ‘skeuomorphism’ (the practise of designing user interface that resembled real-life items).

First generation iPad app developers simply ported their existing software to the iOS platform or replaced paper content and forms with an iPad version of the same thing. However, I believe that more astute users are expecting, and in some cases, crying out for a leap forward in software design for flight operations. Just because you’ve put your software onto an iPad, it doesn’t automatically make it any good. The explosion of consumer software in the past few years has amplified the demands and requirements of user goals alongside business and technical goals when it comes to software design for business. These requirements cannot be ignored going forward, because in a crowded market place, the user experience is increasingly becoming a differentiator for vendors with buyers choosing one vendor over another in the same way as they currently choose media content based on personal preference and not on necessarily on features or functions.

Context

Talking of content, isn’t it about time that content providers twigged that iPads and devices like the iPad are here to stay in the cockpit and that they changed the way they provided content accordingly? It seems to me that there has been almost no change in the way content is generated since the days of delivering data in paper format by hand. Even today the content being consumed on devices like the iPad are formatted and styled as if it is a facsimile of the paper format. How many pilots are reading on their devices flight manuals formatted into A4 or US Legal dimensions? How many pilots are being forced to synchronise an entire library’s worth of digital media? The latest generation of iPads have a 2048 by 1536 pixels screen, yet whilst app developers, web designers and media providers are producing responsive content designed specifically for this medium I don’t know any content providers going to the same lengths in our sector. Even seemingly mundane features, like search and document annotations are not being designed specifically for the technical and contextual constraints of the unique use case that an iPad’s usage in the cockpit presents. When will software developers realise that features that have been devised for use on a PC or a server will not work in quite the same way on a mobile device and that compromises or functional redesigns need to be made?

Context for mobile devices comes in two flavours: qualitative and quantitative. App developers hopefully consider the qualitative context of content when designing their solutions, meaning that they consider the end user and their exact use case. We are beginning to see simple and more intuitive designs creeping into mobile software (as I said before, any steps forward here are welcome) where the user environment and capabilities are being properly considered. However I do not yet see the quantitative context being fully evaluated by content providers. Quantitative context includes such factors as screen size, connectivity constraints, device capabilities and processing power. As tablet hardware specifications improve over the years, some of these constraints will be less of a factor, but in the mean time I believe that content providers should work harder to provide content that is tailored especially for tablets and users need to learn to expect some trade-offs in capability or scope of usage.

Integration

There are three types of integration worth considering when designing a mobile or tablet solution. These are:

• Tablet to Server – integrating your tablet with central enterprise systems;
• App to App – connecting two apps on the same device;
• Tablet to Tablet – connecting apps on different devices.

Tablet to server integration is simple in theory, but in practise is way more complicated than it should be. For one thing our industry is awash with data standards, but nobody seems to use them. Connectivity should be straight forward these days, but reliable networks are not as ubiquitous as you might imagine. Public facing web services, Application Programming Interfaces (APIs), and Software Development Kits (SDKs) are the norm in social media and consumer technology, but are still an alien concept for many aviation software providers. Add all of these factors to the overly strict policies of airline IT regimes and you have a perfect storm of circumstances that result in many integration projects simply failing. I instigated a project some time ago with a UK based airline to integrate flight schedule data with engineering data for a mobile application. It took over six months for the approval from IT to access the necessary information. By this time the project was finished and the requirement had been forgotten and abandoned.

If anyone tells you that it is not possible to integrate between two apps on the same iPad, they are either ignorant or a liar. The iOS custom URL scheme is very well documented in the Apple iOS software development kit and has been personally tried and tested. It works by declaring a custom URL scheme within the code of your app. This URL scheme can be called from a different app on the same device, launch the app and carry out particular functions. It is a simple feature to implement and, if the custom URL scheme is known to a third party developer, can be used to pass data back and forth with ease. Unfortunately, for this feature to be utilised it requires vendors to read the manual and to talk to each other, both of which may be somewhat akin to getting blood out of a stone.

A tablet to tablet level of integration is something of particular interest to flight crews whereby data or content could be prepared or researched by a co-pilot and then sent to the Captain’s device by a swipe or a gesture. In the past I have used inter-connected devices for consumer specific applications, like using my iPhone as a remote control for apps on my iPad such as iTunes or for presentation slides; so we know the technology is available and straight forward. For this kind of application you need some sort of connection medium, such as cable, Wi-Fi or Bluetooth. There are of course issues with implementing wireless comms in the cockpit and you may have a task on your hands to overcome the security concerns of the feds, but I’m sure it won’t be long before we see such applications in common usage.

How much does it cost to develop an app?

This is a question I’ve been asked dozens of times and there is only one simple answer…

It depends!

There are so many variables to consider whenever pricing any app development project. The most fundamental question is ‘what does your app need to do?’

Without a detailed description of the features and functions of a proposed app there is no way to possibly price any software development project. The more information the better!

• Which devices and operating systems need to be supported?
• Is the app a standalone utility or does it integrate with other systems?
• How many users will be using it?
• How are you going to deploy the app?
• … and so on, and so on.

Generally speaking with mobile application development, as with other software development, the cost of the project is directly proportional to the amount of time and effort required; which is directly linked to the complexity and sophistication of an app. However, asking a developer to produce an app which is a clone of an app they have already developed is a much simpler task than completely reinventing an app from scratch. My advice is to seek out developers who have already worked on similar applications to what you have in mind. It may be they have already developed a framework that will allow for the rapid rebranding and deployment of an identical application in a much shorter timeframe and for a much cheaper cost. One word of caution though; in such cases, developers need to ensure they do not break the terms and conditions of their Apple Enterprise Developer License.

More complex, enterprise level applications only expose a small percentage of the total application solution to the end-user. Many mobile and tablet apps integrate with other business systems or require management applications behind them to distribute content and synchronise with other systems. The bulk of the cost can lie in the development and hosting of these systems. However the cost of these integration and management layers are not duplicated if you wish to use the same app on other platforms. Therefore, if you build your app for iOS, it isn’t necessarily double the cost to re-platform the app for Android as you will continue to use the same back end applications.

So how much does it cost to develop an app? As an extremely rough guide here’s what you can expect to get for your money:

Less than $20,000

Not much! Less than £10,000 will only buy a limited standalone utility app. An app in this price bracket will possibly only support a single operating system or device. There will be limited design effort using standard operating system user interfaces.

$20,000 – $100,000

This will buy you a basic enterprise grade application. It may also be possible to buy an app with a pre-existing application frame work with simple content management or integration capability. Don’t expect to get multiple device or operating system support for this much. Consideration must be taken for the on-going support and hosting of any management layer that applications in this bracket rely on.

More than $100,000

This buys you a more complex bespoke application with potentially unique features developed especially for your requirements. Expect multiple device and operating system support or complex integration, distribution and management applications for this money. For applications of this level you should be also budgeting for software support, software assurance and other hosting and management fees. With almost limitless funds you are now in the realms of the most complex and sophisticated apps with cutting edge technology, bespoke design, multiple platform and device support and potentially mission critical and large enterprise level integration.

My advice to anyone embarking on an app design and development project is to not over complicate. Start small and do one thing flawlessly, then iterate. My final advice, as I always give with any information systems project, is to ensure that you KISSASS… ‘Keep it Simple, Stable, Available, Scalable and Secure!’