Conversationware

There is more to being effective than just being efficient.

It’s been at the back of my mind that we ‘communication technology people’ are still only part way through making life easier, helping us all contact people more quickly and efficiently, and reducing the cost of doing so.

But once that job is finished, how are users helped to be more EFFECTIVE once the conversation is in progress.

A far more elegant description of the difference between efficient and effective can be found in this article from the boss of Parlano

Nick muses that we lack an ROI model for this collaboration technology, but it seems obvious that getting a purchasing decision should be easier once the tools to measure effectiveness are in place.

But, perhaps instead of tools we just need a new breed of business analysts who enjoy a challenge, whilst being given a full remit to change by those in charge.

Lots of people are working on this aspect of micro and macro productivity and Parlano have an interesting proposition which blurs the line between real time and messaging with group productivity around topics.

When I chose the name for this blog, it was partly because the word conversation does allow for extended communications around a subject over a sustained period via multiple modes and channels.

To sum up then, Unified Communications is just where we start, to enhance and speed connectivity…and as I comment, we can lead the horse to water more quickly, but effectiveness will need yet further ‘tools’. 

I admit to being interested in such toolkits, before I get any comments from colleagues, many thanks.

This post is incomplete, but then so is the industry

I’ve mentioned before that the key to understanding Unified Communications (all of it) is the software interfaces presented to the user. (You may notice I don’t mention voip at all in the following, it’s about users).

Unless the user is going to adopt functionality, there is almost no point deploying it…..and by definition the more interfaces there are, the more difficult adoption will be (how many training course will users go on).

Once the required interfaces are defined, it’s so much easier to put the technologies in the right place, or in the right box, so to speak, and so I have been framing business requirements around the GUI.

The reason I’m bothering here is that I have met with customers who have in front of them very interesting new products - but they overlap so much, and so how does one decide?

It can be as tricky as hell, as current comms software technology on offer includes

Messaging

• Email
• Voicemail
• Fax
• Text Messaging

Real Time Conversation interface,

• Instant Messaging - are you at your desktop
• Telephony - are you on the phone
• Conferencing, Audio dial in, dial out, desktop sharing, webinars
• Video conferencing, are you at your desktop

You can see overlaps wherever you look with UC - but there will be ‘at least’ two interfaces for users - as the ‘button’ requirements are different for messaging, to that of real time.

Messaging buttons; - Address, Send, receive, store, mark as urgent, copy, forward, and so forth

Real Time buttons; - Receive contact, Make Contact, whether IM, call, or video, include someone else in the conversation, transfer, desktop share, present, record, and so forth

• Messaging interfaces are reasonably well defined
• Real Time Conversation interfaces are in their infancy
• Personal Contact Handling isn’t well defined

However, for framing Unified Communication discussions and decisions, each user will probably have at least the first two initial interfaces for personal productivity.

A third interface should exist, but doesn’t yet (?)

Personal contact handling

• This doesn’t yet exist as a recognised ‘desktop based user interface’ category - although network based Grand Central is a good start in showing what will be possible
• Call routing and handling, where should calls go, onto which device, at what time
• Planning - willingness to engage, calendar integration, - Iotum is interesting
• Call processing, what happens to the caller if you can’t take the call
• More loosely defined is a meta directory, routing and capture application such as that delivered by Corebridge - because contact information pervades around all communications solutions, (and existing applications).

It isn’t clear where functionality to control personal contact handling will be interfaced by the user, - most of the above is handled at premises based system admin level currently - but it makes sense if all features to determine the inbound call routing for today, all end up in one interface, (if not provided by a single backend system) to be controlled by the user instead of Admin.

This interface could yet still be provided by a hosted system provider, overlaying and complementing existing site number and mobile number implementations - instead of replacing them completely.

The final interface, enabling existing applications with (the same) communications

As well as providing the primary interface for specific channel technology (show me all my received faxes, calls, emails) All the technology channels above ‘may be’ suitable to ‘enable’ an existing user interface, by line of business - Email a Contact, Fax a contact, Call a contact, record a contact, Text a contact

By way of a small example, although fax is a single technology channel above and sounds simple enough - fax integration can get interesting when requirements appear on the horizon to integrate into Exchange Outlook, or Lotus Notes, then to the telephone system (TDM or IP), then to unified messaging (forward the fax to a local machine) then SAP or Oracle line of business applications, then back end integration to hard copy Multi Function Devices and onwards archiving to the industry flavour EDM.

Nobody said it was simple.

At this point, Microsoft Sharepoint usually comes up in the conversation as a replacement interface to all the existing applications, so UC takes on another interface….and so it goes on, much to the user’s consternation.

There’s a play on words about ‘users’ being addicted to existing interfaces, but that would be cheap.

How to choose

Enabling lots of interfaces with a technology flavour tends to point towards best of breed technologies instead of an all-in-one UC solution.

Generalising: wide ranging applications just don’t go very deep in my experience, and ultimately they don’t generate enough ROI, and therefore sales, to justify the development resource to integrate into every interface (converge) that may be required in every industry.

All in one solutions, may be fine in small organisations where the user requirements are very focussed and not wide ranging.

In larger organisations with wider ranges of activites, each messaging ,or real time conversation, ‘technology’ should support the most possible interfaces you can think of, (and multiple interfaces concurrently).

This almost defines a best of breed requirement for each technology - particularly when in a sector that is in acquistion mode - and if you are adopting UC, it won’t be long before you’re in a sector likely to be acquisition minded according to some sources -technology adopting sectors see most acqusition.

So when you acquire a major competitor next month and have to incorporate whatever they are doing into what you’re already doing, you want multi-interface communication products.

It’s plain that in these unforseen circumstances, functionality needs to be priced in a modular fashion, according to the interfaces required and the inherent value of doing so (each interface is it’s own individual case for each technology).

So, am I proposing that in order to have fewer user interfaces, there is a need for more technology boxes and management?

It’s debatable I suppose, but probably.

I’ve seen non specialist technology suppliers integrating essentially as ‘lip service’ to get the original deal, and then support evaporates over the period, especially when the next app needs enabling, and you have to start looking to replace again.

I’m lucky enough to see the best of breed technology I supply stick over a very much longer period.

If I’ve missed anything then it’s likely to be mobile - but that’s a longer conversation.

It’s been a long day, but is there anything else I haven’t thought about?

I have been asking some VOIP experts why companies should bother with VOIP at all, given the complexities, cost and security concerns (you don’t need voip for unified communications). Martyn Davies at Dialogic bothered to answer

Here’s his view. Telco Innovation is the answer. So, I’m still not sure about VOIP for business.

The picture quality isn’t great, but I was walking along at the time with my qtek PDA. I was suprised to see today that British Telecom are still training people to climb telephone poles.

They even have a cordoned off section so that up to 50 people can be up their own pole at once. I missed the best picture by an hour, so I must presume the trainees left up there in my picture were having to do it all over again (poling laggards?)

Why wouldn’t they be training people, but I was working with one of the most advanced VOIP solutions company in the UK onsite today. Myself and a colleague were extolling the advantages of a truly remarkable combined Unified Communications solution set - it was a nice counterpoint.

Click to Dial allows you to locate a number in some contact database and call it, but if the user is then handling the ongoing conversation on their telephone device - this precludes all other potential channels of communication - and it misses the point.

By Contrast, UC is about delivering a single user interface for Real Time Conversations - and these conversations need handling tools. See the picture below.

We’re all getting used to conversations being started in any of multiple modes, including IM, Telephone, Audio, Web, Video and Desktop conferences. The challenge is a consistent and single interface to handle the conversation

We might want to

• put people on hold
• mute them
• invite someone else either by IM phone or email (or by clicking their name)
• Consult with another colleague separately on a different channel 
• drop a specific person
• start a desktop share or make a presentation
• Record the whole thing

The tool also needs to do two things - show whether someone is at their desk, or not, and show when they’re on the phone (that defines presence for me). The first one is simple, the second can be approached in any number of different ways.

The ultimate goal is to share this information with people that you choose, in any organisation and whatever phone device you happen to be using. 

Have you seen a single interface to handle all of those conversations? Not many people have as yet, but it doesn’t stop them claiming to have a UC solution

My Teamwork from Alcatel Lucent has the best conversation GUI that I have seen and it also solves a lot of the problems that desktop installed solutions would have by being completely browser based, meaning that anyone can join in with any channel of communication.

It also covers a little of the other two aspects of UC, by which I mean incoming call handling and application integration.

VOIP services and softphones are often ‘too difficult’ for me to comprehend, so I’m pleased Intel has patented the softphone and I’m unlikely to see too many more of these around. I share a lot of the sentiment in this quote -

“I have always wished that my computer would be as easy to use as my telephone. My wish has come true. I no longer know how to use my telephone. - Bjarne Stroustrup, the inventor of C++

I’m far better off with software interfaces that don’t need any instructions - like my ipod. I hope the interface Intel come up with is a good one.

Unified Communications is taking us away from being reliant on feature rich telephony  devices like proprietary IP Telephony handsets and corporate mobile devices.

I’ve been looking at the concept for a while and On Accenture’s Trivergence blog, Andy Zimmerman coins the “trivergence” phrase, I can link to the explanation.

The reason I picked it up is that one of the key aspects of this trivergence (type of convergence) is to abstract a user interface to any application, away from the devices that you use, onto the network, and accessible via the PC screen or browser.

To a degree I guess this has been happening since the demise of the typewriter, but this will continue into disruptive communications solutions. Perhaps its why Gartner warn against buying handsets with screens.

As an example, the Ipod is easier to stuff full of music when using iTunes, rather than navigating and downloading from a website from a screen measuring 2 inches square.

Further, he relates

About two years ago, when Accenture’s Innovation Center was researching Trivergence, we mocked up an application that transferred certain cellphone controls from the handset to a PC display, which we dubbed a SoftPanel. In focus groups, cellphone users were asked to perform a set of tasks (managing contact lists, sifting through voice mail, buying ring tones, etc.) first on the cellphone itself and then on the SoftPanel.

The results were unambiguous. Nearly 100% of respondents said they preferred using the SoftPanel for these tasks. It was clear to almost everyone that there should be a seamless integration between the PC and the handset – with each device doing what it does best, and doing it on a regular basis.

 Also he says

one of Accenture’s analysts sent me these comments from a discussion on cellphone usability:

“Mobile devices are still not intuitive enough for average users to navigate, and consumers do not have the time or interest to go through carriers’ service catalogues to figure out just exactly what is available to them.

“As carriers continue to layer on services, discovery mechanisms on mobile handsets are critical to enabling users to access desired applications and services with the simple touch of a button.”

Personally, I use Google Reader because I can access the pre-configured reader and articles when on the train through a browser. It is an example of application control being browser based rather than being developed specifically for each device individually. The application persists across whicever device I happen to be using, and this only succeeds if the application server is browser based.

Another post from the Trivergence blog, around Grand Central, shows how a very feature rich call control of an inbound telephony service has been abstracted from telephone devices all together by being browser based.

We’ve all used dozens of phone devices in our time, perhaps future phones will be simpler instead of more complex.