The real problem with unified communications

People don't need fat, complex clients to do all their communications; they need a way to make their communications portable across devices and locations

tin can phone communication communicate caller businessman

The notion has been around for 20 years and gone nowhere despite incessant promotion by the tech industry. That notion is unified communications, which seeks to create single computer-based system to handle all communications a person might do: phone, video, chat, and document sharing.

Ironically, that very unification makes unified communication an unwieldy nonstarter. You have to buy a one-size-fits-all service (whether locally hosted or in the cloud), then ensure that every participant has the compatible tools at all times. That's simply not portable, which communications need to be.

Issuing a USB headset for every work and home PC -- or a wholly new type of phone station -- is only the start. Everyone needs the same or compatible client software and a big, fat data pipe. In today's offerings, Mac users are often left out in the cold -- same goes if you're on a tablet or smartphone.

If you use cloud-connected software tools like those in Microsoft Office 365, you know how incompatible its components are from platform to platform -- unusably so. This is after more than a decade of work.

On the other end of the spectrum, systems from providers like Cisco and Avaya typically have high dependence on proprietary equipment that limits them to conference rooms or office-bound staff. Either way, you get a solution that doesn't fit the real business world.

One answer is to create wholly compatible and consistent unified-communications apps on the four major platforms people use today: Windows, OS X, iOS, and Android. So far, no one's done that for real.

Microsoft is the only major provider that seems willing to try, via its Lync platform. But as with Outlook, Office, and OneDrive/SharePoint, it's doing so over a timeframe of many years, creating huge compatibility gaps. That means the more mobile, multiplatform. and location-flexible your workforce, the less use you'll get out of it.

I believe we need a different answer: to treat this not as a unification issue but as a distributed issue. The approach favors portability of communications, at least the core communications. Thus, you can reliably communicate from a client's office, your home PC, your smartphone in an airport lobby, your tablet at Starbucks, and so on.

The way to get there is not via a bunch of fat, unwieldy client apps such as what Microsoft now provides; even if they all did the same things, they'd be unusable for most people. Instead, we should think of these as services for a population whose clients and locations are distributed unevenly.

On a smartphone, having separate messaging, phone, and videoconferencing apps makes more sense than having a unified tool; such context switching fits the small-screen, limited-input model of a smartphone. On a tablet, there's more flexibility, though with the popularity of small tablets, I'd err on the side of functional separation over unification. After all, tablets have fewer input options than computers, which the bigger screen doesn't address. That input limitation has a huge effect on usability for multifunction tools.

On a PC, unification is more possible, but is it really useful? Would I need, for example, Outlook to handle my Lync chats, phone calls, or videoconferences? I don't think so. Already, Outlook's integration of calendar, tasks, and email is problematic because of the window switching involved.

Maybe it would make sense to run each of those communications methods in separate windows as if they were separate apps -- mimicking the multiwindow usage of PCs today. But stuffing all those functions in one window is overwhelming. 

We all know that, of course, and when we do a conference call (especially with video) we're reminded of the fact. We often spend 10 minutes or so setting up the meeting rather than getting to the meeting itself for the simple reason that it's too complex and confusing.

Instead, people tend to dial in with a regular phone, then see if they can connect to the video portion or shared screen afterward. That behavior is telling, and it should inform how unified communications should be done: as distributed communications.

Treating the unified communications challenge as a distributed communications challenge would also let us move forward faster. The solutions would be partial, but in an intelligent way. Plus, we can still link among services, as we do today for calendar entries in our emails and for dial-in info in our calendars. Those could be smarter, but they're a more reasonable place to start than the über-app.

Smart incrementalism based on feature, not platform, would be a useful shift for the unified communication industry: 

  • Let's solve the "one phone number and address book whatever I'm using" problem first to handle the most common need.
  • We've already done so with text chat, in the sense that nearly all chat services work across platforms, though not so much with each other. Better chat integration would aid collaboration with outsiders, but at least we can chat reliably within our organizations.
  • Videoconferencing tools are fairly universal now in terms of platform support, but their capabilities are highly variable, especially on the initiator end. That means you can probably join a conference for basic audio and video, but not host one unless you are at a computer. For a good next step, make hosting a universal function, then worry about the bells and whistles, like showing all cameras in one view.

If a single provider can solve all these issues over time, we get the advantage of unified user account management and easier switching of the conversation from one mode to another. But both gaps have existed for years and clearly aren't gating factors. Instead, multiplatform compatibility and ease of use are the gating factors.

The separation of functions may not solve every communications issue, but it would be a big step forward into letting us communicate effectively across a range of devices and environments.

Copyright © 2015 IDG Communications, Inc.

How to choose a low-code development platform