Defining a technical architecture and workflow
Once you have made your decision about the development route, you will need to set about defining and building a technical architecture and workflow to support regular production of mobile learning and communications programmes.
If you have chosen to go for a web-app only, HTML5-dependent route, this will be a relatively simple business. The tools and skills you will need are generic ones. To publish web apps you can make them available to your target learners and market them in much the same way you would any other e-learning programme, from a technical point of view.
If you do not wish to self-author, LINE has a template-driven production framework known as the Responsive Content Framework (RCF) that produces cross-platform learning and communications to run on any device or desktop.
If you have chosen to use native or hybrid apps as the basis of your strategy for mobile however, the rest of this chapter will give you a good idea of what is involved.
It is equally possible that you will want to cover all three of these bases in setting up your provision of mobile learning and communications. We have also taken this possibility into account in what follows.
Device-centric or app-centric?
One of the determining factors in defining your technical architecture will be the culture within your organisation around mobile devices.
Time was, a mobile phone came with the job – like a company car – and employees would be largely dependent on the IT department to decide what precise mix of devices, computers, laptops etc. they used at work.
Now more and more employees are keen to use devices they have purchased themselves for work purposes. Many organisations have formalised this shift in Bring Your Own Device (BYOD) programmes. Others prefer to retain control of the hardware that connects to the organisation’s secure servers and networks, and operate a via media known as Choose Your Own Device (CYOD).
All organisations need to exert some control over learning and communications content. This often contains confidential information, or commercially sensitive intellectual property, access to which must be effectively managed. Organisations also have a duty of care when it comes to handling the confidential personal data of employees. Depending on whether you have a BYOD culture, a CYOD culture, or one where all computing equipment is mandated, you will choose to control content at the device level or at the app level.
Device-centric approach
It almost goes without saying that if the organisation supplies the device, it has a greater degree of control over the content that gets used on it. You can keep ‘black lists’ and/or ‘white lists’ of particular web resources that can or cannot be visited; allow users to download certain apps and not others. Your strategy for publishing and distributing apps under this approach is to put yourself firmly in the driving seat. You can delete apps on target devices at will, delete accounts when employees leave the company, data-lock particular apps, and so on.
From a technical architecture point of view, the type of distribution software you will want to invest in if you take this approach is a mobile device management platform (MDM).
App-centric approach
In a BYOD environment, however, users would not be happy with their employer having this amount of power over their self-supplied device. In this case you would manage the applications that belong to you as an organisation, and only those applications. Here, though, it is perfectly possible to exercise a high degree of control; allowing or denying access to the app at will, updating content and controlling permissions flexibly.
Rather than an MDM, this approach would call for a mobile application management platform (MAM). Think of it as your own proprietary app store; an iTunes for your enterprise alone.
Native and hybrid mobile apps: authoring, publishing and delivery
Fig. 1 gives an example architecture and workflow for publishing and managing apps at scale, based on our proprietary LINEstream platform. Though it may look complicated at first sight, this arrangement in practice provides simple authoring and publishing routines that also provide maximum control over content.
There are one or two things to say about this diagram before explaining the process of creating an app.
Firstly, it shows a level of technical integration with the development partner that most sophisticated tools require, although the more powerful and sophisticated the platform, as in the case of LINEstream, the more ‘invisible’ this integration will be, since most of it happens automatically and ‘under the hood’.
The API (application programming interface) is the software that manages this integration in our example, providing the interface via which different entities in the architecture communicate.
It should also be said that, notionally, the whole of this architecture could sit within the organisation concerned, on the organisation’s network servers. However in practice, given the specialised nature of this technology, it makes more sense for elements of the architecture to be supported and maintained by the provider and supplied on a SaaS basis.
Authoring workflow
The process of creating an app begins with the authoring tool (the technical name for this is the application population tool or APT). This contains templates with which you, as the author, create and sequence screens to create a learning or comms programme. The content assets (images, text, videos, sound files, etc.) that you assemble to produce this programme are stored in the content management system (CMS). In this example, the authoring tool communicates with the CMS via the API.
The tool should allow you to preview the app during authoring. This will probably happen in a device simulator, viewed on a desktop PC, which gives a fairly accurate picture of how the app will look and behave on your target device or devices.
When you have made all the changes you need to create a releasable iteration of the programme, it is time to go for a build.
The authoring tool – once again communicating via the API – instructs the build server how to put the programme together, drawing the correct assets from the CMS. The CMS not only holds content assets but also users, groups, sub-groups and permissions; the information that controls who can view and edit the content, important for security.
The programme now has to be packaged for the particular device or devices on which it will be accessed. This happens according to information held within the application framework or client-side tools (CST) and selections made within the authoring tool which determine the instructions carried out by the build server.
Using this information the programme can be compiled and packaged as an app, and output as a file of appropriate type – e.g. as a .ipa file for iOS, or a .apk file for Android.
Via the API it can now be published to an MDM or MAM for distribution within your organisation, or if desired, to a commercial app store such as Apple’s App Store or Google Play.
Getting your app to this stage where it can be published can take as little as two to five minutes with LINEstream, although less sophisticated tools may require some human intervention at the supplier end and will thus take longer.
Distribution considerations
LINE sometimes manages the distribution of apps on behalf of clients, and sometimes this is done by the client in-house. Our experience with both routes leads us to make the following comment about MAM and MDM suppliers.
This is an emerging technology area, and a lot of these providers are young, start-up companies. They can’t necessarily guarantee the same level of support as more mature companies so it is worth looking closely at SLAs. Also be aware that different providers will give different levels of management information. These are important considerations when choosing your MDM or MAM platform.
Another thing to consider about distribution is the question of scale. You should consider how many people are going to be using an app before releasing it. If you have a target audience of 80,000 people for instance, on an in-house MAM, and all of them access the app at the same time, you may well have a crash on your hands. Large companies often stagger releases to different parts of the audience for this reason.
If you wish to release an app to customers, on the other hand, you might want to use one of the well-known commercial app stores. This certainly gives you greater reach and accessibility, but be aware that you will face restrictions. Apple, for instance vets all the apps that appear in its App Store. This imposes a time delay, and its decisions (to which there is not much chance of appeal) have sometimes been described as ‘arbitrary’.
Updating and maintaining currency
Within architecture such as the one shown in Fig. 1, updating content once it has been published is not difficult. You don’t have to go back to square one! With a two- to five-minute publishing turnaround, changes can be made quickly – if someone points out a typo in the initial release, for instance, or if unexpected events call for a quick restatement of company policy.
An app publishing workflow of this kind provides automatic updating of the app. In LINEstream, for instance, which produces hybrid apps, users receive a notification and can then download updates in settings – they don’t necessarily have to go back to an app store and download a new version.
Creating cross-platform programmes
So, what if you want to produce not only native and hybrid apps, but also web apps? Can you still have the power and convenience of the authoring tool, with its template driven production process?
With a slight change to the architecture in Fig. 1 that is completely possible. Using the same authoring routines, communicating with the CMS via the API as before, but without the need for a build server or application framework, a programme can be compiled and packaged for desktop delivery through the browser via a web location. Content still needs to be pulled and built, but it doesn’t need to be wrapped in a native wrapper. This gives the possibility of creating a version for desktop alongside the app version.
If you don’t wish to self-author, it is also possible to get your provider to create learning or communications programmes for you using your authoring tool.
Security
In general, native and hybrid apps are more secure than web apps. At a very basic level, it is not possible to access the content without an app being installed, and you are able to control who gets to install an app, and also to revoke the ability to access it from a given device if circumstances make that necessary.
Security is an important consideration in defining your technical architecture, however, because responsibility for security is distributed between different entities (this is another reason for choosing a trustworthy and well-established development partner).
As already mentioned, the CMS holds information on users, groups, sub-groups and permissions; the information that controls who can view and edit content. Authors have to be registered and granted a permission to edit or review. For end-users, security managed by the application framework itself (CST), but the distribution system – MDM or MAM – also has a part to play; monitoring and freezing the app and associated data if a device is lost or falls into the wrong hands.
An app itself will have layers of security:
- The ability to access the app
- A pin/password and/or user name
- Memorable information
Always remember, however that once code is in the wild it cannot be secured. You would have to think very hard about putting critically confidential data on a mobile.