Delivering on Collaboration and UC: Widgets/Click to Dial

Widgets, AJAX and Reuse

In developing our SOAR applications, we wanted to keep in mind those core pieces that we needed to deliver:

Cross browser, cross device functionality:

If I am in a meeting, on a customer site and I need to know “the guy” who knows about a certain widget, I need to be able to pull that information from anywhere.

In addition, I need all my actions to also work when I find him or her: Click-to-dial must work regardless of where I am or what device I am using, for example.

This had to run, full featured, everywhere.

Reusable Components:

If we were going to build a “contact card” as an example, it was important that the card was reusable in any other web application we may want to right.

It also meant that the solution should be scalable – and so I put the app into layers with a heavy emphasis on AJAX and reusing components.

The result is that we now have presence bubbles and contact cards available to anyone else who simply wanted to embed a link.

Depending on use case it can literally be as easy as:

<A HREF="/api/contactcard?userid=john" TARGET="_blank">
<IMG SRC="/api/presenceicon?userid=john">
</A>

(We’ll talk security in further posts)

The result of designing the app in a *very* digestible way at the low end has allowed us to reuse components all all sorts of other apps, from FireFox Plugins that embed presence and contact cards on any webpage – wherever they find names or email addresses – to directory integration and other business apps. The upshot once again is that our tools were collecting usage statistics behind the scenes.

Youtube Example:

Click-To-Dial

So lets get into the oft underestimated Click-To-Dial functionality. This is a great example of a situation where something that sounds simple turns out to be anything but. We had to make some choices, so lets to through some of the options.

At Cisco we had several APIs to choose from in terms of delivering Click-To-Dial functionality, and in truth, we used most of them when all was said and done. I suspect you will likely do the same since its not easy to control the environment, and it is certainly not feasable to have all users on the system mandated to use one phone system, mobile phone and desktop application.

Initially we simply used the bundled WebDialer applicationt hat comes installed on every Cisco UC Manager. You simply point to the UC Manager web address, pass it a parameter for the number you wish to dial and the server does the rest by rendering a web page that allows tyou to select which phone to control, and dials it for you. Simple. Easy.

For a demo this works fine. Customers see the click-to and see that we can complete a call just fine… but don’t let your vendor stop there.

There are some additional issues we sought to solve as we rolled this out to the Cisco salesforce:

• What about cellphone usage, cant we just use Tel: URIs?
• What about if there not on a phone that is controlled by a UC Manager?
• What about using a “find me” type service instead of manually picking a phone to use?

We solved all these problems and more by making our “Contact card” a lot smarter.

If the contact card is serving up the Click-To button, it can learn a few things about you:

• What browser you’re on leads us to know if you have tel: URIs available – by OS. An iPhone browser does, for example. Firefox does not. By weeding out options based on the user’s device we can streamline and avoid them having to pick.
• We know based on your browser if youre likely in the office or not. Browsing from Android? Probably not at your desk.
• We know about you since youre logged into our system, and we have some good settings we can apply to you. (What is your default US Manager? Do you have Video?)
• We know if you have Single Number Reach enabled (A Cisco feature to allow multiple devices anywhere to ring simultaneously, while avoiding their voicemails – a big deal)
• We also can cross-link to your presence status and Outlook calendar, giving us more data.

The result of all this data is that our Contact Card can be a lot smarter than the average contact card, and is extensible with any other systems that support Web2.0 style interfaces.

So, when I click “Dial” on my iPhone, the first time, I am asked if I want to make the call locally (In which case I’m redirected instantly to a tel: URI) or whether I want the system to call me (In which case we use Dial-via-office functionality to connect the call) and afterwards, we save your setting.

YouTube Video: Using Click-to-dial on Mobile:

We considered getting very fancy, for example we can tell whether the iPhone was registered to UC manager as an endpoint and then automatically know whether the device was on a campus network or not. We can look at the last call logs to see what device you were on last. We can see your Calendar in Outlook. We can also see where you are based on E911 systems. If you have location enabled in the mashup we can also see where you are.  By looking at the “most recent event” across all of these inputs, we can make a pretty darn educated choice about the two or three options to give you when you click “Dial”. Just be aware that it can soon becomes a science project with diminishing returns. Don’t get me wrong, it demos absolutely fantastically, but we found that the endless permutations as the systems got more capable only clouded the user experience.

Bear in mind too that depending on your system, various functions have effects on other parts. For example, with our system a Call using WebDialer can be Voice or Video. Whatever the best medium is for either. If you use an IVR to do your dialout and connect to another user, your IVR may not (probably does not do) video, so you loose functionality. In addition things like conferencing from remote locations without the native clients we were leveraging becomes difficult too.

This click-to-dial thing sounded easy, didnt it?

So with the deployed system, we have a few standard options when dialing:

• Dial using webdialer when in the office.
• Dial using Dial-Via-Office (Callback) when you are not. This option allows you to answer on the most capable device including native clients on iOS, Blackberry etc.
• Present TEL: option to those on mobile phones as an option. (Got no data coverage?)

Your mileage will absolutely vary – but the key is here – know that it’s not a simple matter to deploy this type of functionality ubiquitously.

Back to index.