With the continuing rise of mobile devices in the enterprise, it’s easy to focus on building apps or a website that allows users of mobile devices to access their important corporate processes. The problem is that businesses get stuck between the rock of “one size fits all”, and the hard place of having to develop separately for each device of ecosystem. What’s needed is a multi-channel approach, to develop a single process that can be deployed intelligently to any device.

Why We Need Multi-Channel

These days, we have users accessing data from many different device types and architectures. These can be anything from mainframe terminals, through traditional laptop and desktop PCs, tablets and smartphones across several operating system ecosystems, web browsers and of course and ever-increasing range of social media.

At the same time, users have never had such varied data to access, or so many back-end systems to access it on. Data could sit in big enterprise CRM and ERP systems, or in publicly available cloud services; it could reside in the corporate data centre or elsewhere, on a modern system or a legacy one.

HTML 5 has been suggested as the answer to this data access challenge, but while I have nothing against HTML (especially for consumer and amateur websites) I do not believe that it is a magic wand for all our mobility challenges as it does not allow us to consider the context in which our users try to complete tasks. This is why I believe we need a multi-channel approach: because multi-channel allows us to consider the context for our users.

Context is critical when designing a mobile workflow, because the variety of experiences can be so much greater than on a desktop. With a traditional business PC, even a laptop, we can be fairly certain that the user has a keyboard and mouse input, that they have a screen size of at least 14”, and that they are sitting fairly comfortably. These assumptions allow us to include a certain way of working that involves multiple applications and browser tabs open simultaneously, small buttons, an ability to drill down into reports… but once we allow mobile devices into our workflow that is no longer possible.

Our user could be about to board a flight, and trying to action any last-minute alerts. They could be sitting in a cafe, or on a train, with some time to work but limited patience for fiddly controls. They could even be sitting at a desk with a big screen, mouse and keyboard, expecting to do some serious work with pivot tables, because allowing mobiles into the workflow does not mean that the PC has to leave. This array of contexts has to be taken into account, and a multi-channel approach is the best way of achieving this.

Some Definitions

Before we go any further, I want to define a few terms, and clarify what we do and don’t want to worry about when developing for mobile:

  • Devices are the tools used to complete a task: the PC, the iPad, the Galaxy S4, the Nexus, and so on. We really don’t want to consider the device beyond setting rules for that type of device, based upon the contexts in which we expect it to be used.
  • Platforms are the ecosystem that the devices sit within, for example iOS, Android or Windows. Again, we don’t want to have to worry about this, and in particular we don’t want to have to develop separately for each ecosystem.

So what does matter?

  • The channel is a touch-point with the user within a workflow, meaning how the interaction actually takes place. As such, a PC, tablet and smartphone can each be considered channels, making the channel useful as it allows us to assume a context from the type of device and develop accordingly.
  • Finally, context is where, when, how and why a user is trying to complete a certain task, and this can tell us a lot about how they want to do so.

This means that user experience is paramount, and that what we really want to do is deliver functionality in a way that is informed by the user’s context.

The System Is Broken

This concept of context being key shows us just how badly the current system of enterprise mobility is broken: we have two worlds, the users and the enterprise IT, which are opposed to one another.

Users want to use their mobile devices for work, and this really does mean their devices: since the BYOD revolution users have come to expect that they can bring their device of choice to the enterprise and use it for work; certainly very few will be amused when handed an aging Blackberry!

Interestingly, these devices originated as consumption devices for consumers: I specify consumption as well because while a powerful gaming or media desktop PC is certainly a consumer device; mobile devices were originally seen as being purely for the consumption of content.

When the iPhone was launched, it was seen as being a toy for accessing Facebook; the iPad was seen as a toy for watching cat videos on Youtube, and Android was seen as being even less suitable. And yet here we are, all happily doing real work on these devices and looking at ways to make them even more productive.

Meanwhile, the enterprise is traditionally very stringent, relying on defined processes, structured data sitting in well-ordered databases, all wrapped up in layers of governance and control, with every change needing to be escalated. Is there any way to bridge the gap between these world views?

It is helpful to consider what we are trying to achieve, which is making the same functionality available across different channels, is a way that is adapted, integrated, and ready to support multiple device types.

Therefore, we have single business processes which have to be interacted with in different ways: on the smartphone we want to know what to action now, on the tablet we might spend a bit more time analysing what we’re seeing; and on the PC we are happy to open multiple workflows and get a deeper view of our data.

How Do We Use Devices Differently?

Even between the two most mobile device types, we see differences in use: we are more likely to use the smartphone for its sensors, while the tablet is great for augmented reality or light productivity tasks. Some key differences between device types are:

Input: Both smartphones and tablets are primarily touch-based, but we are realistically limited to one or two fingers or maybe a thumb on the smartphone, while on the tablet we might use two thumbs, or up to four fingers comfortably. Meanwhile on the PC we have keyboard and mouse input, and a big screen.

Frustration time: Unlike attention span (the time it takes to get distracted) this is how long we will stick at a task before deciding to do it later when we’re back in the office. On the smartphone this is between two and four seconds, or between five and ten on a tablet. This is linked to the screen size and input methods, and therefore on the PC we find that users will work more than ten seconds.

Location: The choice of device can tell us a lot about the user’s location. A smartphone means they are probably in a hurry, maybe walking to a meeting, while a tablet implies that they are sitting down, though not necessarily comfortably, and have some time on their hands. Finally, using a PC suggests that they are sitting comfortably at a desk and can remain there for some time.

Sociability: Different devices are easier to share; a PC has a large screen that can easily be shared, and the extra in/out ports mean that an external monitor can be connected if needed; while a tablet can be shared and a smartphone is far harder.

This is useful for a multi channel approach as it allows judgements to be made about what kind of actions users expect to take, for example on the smartphone they will want to use sensors, action messages but have very limited data entry, while on a PC they will be more willing to use pivot tables and do serious typing. This means that we need to focus on channels and processes, not apps and devices.

Why Application Platforms Are Needed For The Multi-Channel Approach

We want to use a single development effort to extend business processes intelligently to any device from different channels, and today’s enterprises don’t just want “an app”. On the contrary, they need secure, reliable access to any enterprise data with high availability; a native user experience (allowing use of sensors) and support for offline working; and they need to stay flexible to respond to emerging trends and ensure that their environment is future-proof.

Security and management functionality need to be built in, with encryption, mobile device management (MDM) support, and user authentication; they need to be able to monitor and control who accesses data, where, and when.

This means that we cannot just take the view that enterprise mobility means deciding on a set of devices or ecosystems; we have to support user context across platforms and devices, from a single development effort and with full back-end integration. Security, monitoring and management have to be built in. We need to use a development platform that can seamlessly build this functionality into the application.

Platforms are able to cater for context by taking a defined business process and building it into a presentation layer, which sets rules for how information needs to be presented across different channels. This means that the same application will display different data in different ways depending on the device it is accessed with.

Platforms Can Build In Offline Capability

Offline is very straightforward: it’s the ability to work without access to a network and data connection. However, such a simple concept still leads to some complicated decisions.

Offline access is needed for a variety of reasons, from inconsistent network coverage (especially indoors and outside of major cities), the time taken to acquire or upload live data, to the cost of international roaming charges for data and even the problems with limited data domestically. The internet of things is going to put increasing strain on networks, to the point that by 2020 we could be running just to stay still, and of course there are times (such as on flights) when there just isn’t a connection.

As for who can benefit from offline access, it’s not just frequent fliers but anyone who has to send a lot of reports to a central server that just aren’t time-critical. Consider a consultant who has to provide daily tracking timesheets of jobs worked on: this is critical information that the company will use to bill the client, but it only gets collated on Friday afternoons.

Rather than repeatedly accessing the secure server from a mobile device, with all the hassle that could entail, why not let the consultant record the timesheet in offline mode and connect to the secure server once a week?

Similarly, a key part of offline access is setting patterns, which are rules that tell the system how to deal with access conflict. There is a wide variety, which are used variously depending on the expectation of a conflict. The biggest challenge with offline is the sheer number and variety of databases which can be affected, and here again using a development platform is very useful.

Building A Multi-Channel Approach

In order to create an effective multi-channel strategy, start by defining the processes that need to be accessed through multiple channels. Once you have the process, consider the “windows” onto it: the ways in which information needs to be displayed.

Considering the context in which the user will be completing the process shows which sensors on the device can be useful, and this will also help you understand where best to keep data, whether this is temporary files, in progress data and the final record.

Now define the business logic: who is trying to complete the process, and what are they trying to achieve? Is this part of an existing process, and what integrations might be necessary? Finally, what touch points will the users have into the process, and what needs to happen in each one?

Once you have this information, it becomes far easier to fill in the expected platforms and channels, determine what offline patterns might be needed and how to manage security.