|
There has been a lot of buzz surrounding the productivity gains that softphones can deliver. Yet most of the people I speak to still prefer to use a hard phone over a softphone. Over the last few years, those enterprise softphones now available on the market have been designed to mimic the functionality available on standard office phones. Designers have even gone so far as to make their softphones actually look like traditional desk phones: BIG, BLACK, and CLUNKY. Just mimicking the hard phone is not enough to realize true productivity gains. Softphones, along with the underlying communications architecture, should be built to be leveraged as services in an enterprise architecture.
While incumbent vendors have put thought into how best to transport the bits that make up the phone call, theyve done little to change the phone and phone call paradigm itself. Specifically:
Not enough thought has been put into how employees perform their jobs and the application interactions that take place leading up to and during a phone call.
The introduction of softphones has not improved the interaction between people and the phone system. The process of reading a phone number off of an e-mail or Web site, and then punching it in digit by digit into the phone remains the same. The only difference now is that a mouse is used to punch the number into the softphone, which has arguably made the task harder. People are not quite as dexterous with a mouse as they are with their fingers.
Softphones are little more than pictures of telephones on the screen. Furthermore, they completely take over your screen and application focus. When it rings, the softphone jumps to the forefront of your screen interrupting what you are working on. This can easily cause accidental answering of a call followed by fumbling with a headset.
Because a softphone is really just a hard phone disguised as a PC application, the limitations of the hard phone still remain. Just as you are physically tied to your black phone for the entire call, softphones keep you physically tied to your PC for the entire call.
The Softphone As A Service
The majority of calls you make during the work day involve reading a telephone number from a computer screen and then physically punching the number into your phone keypad. Thats an inefficient way of working!
You might argue that my new $500 color screen VoIP phone has a built-in browser! OK, so with the 12 DTMF (Dual Tone Multi-Frequency) buttons and the left/right/up/down arrow on that phone, try to navigate to your favorite Web site, select the contact us option, highlight a telephone number and hit the call button. Is this how you really want to use your phone? There is simply not enough real estate on the phone screen, the browser doesnt render the HTML correctly, and the UI buttons on the phone are no match to a mouse and keyboard for gathering and entering information. Your PC has access to all the information you use during work communications (i.e., the Internet, enterprise applications, corporate directories, e-mail clients, and personal contact lists). So, wouldnt it make more sense for your softphone to interact with all these applications?
We are beginning to see softphones integrating with single desktop information sources used in everyday work processes from some of the larger vendors (i.e., e-mail and CRM). In the future, though, it should be expected that softphones will have a standardized point-and-click-to-dial interface from any enterprise business application, not just desktop applications.
It should be possible to initiate a call directly from any application without needing to punch in numbers or copy and paste a number. A softphone user should be able to point-and-click to dial a URI (Uniform Resource Identifier), name, number, or alpha-numeric sequence. Softphones do not need to be stand-alone desktop applications. It should be possible to deploy a softphone as a portlet in enterprise Web applications. Well-designed softphones and their underlying communication platforms will provide the interfaces that allow enterprises to treat voice and video as Web services in an SOA (Service Oriented Architecture). Examples of services to be leveraged include dialing the phone, voicemail, conferencing, call forward and call hold. Making these telephony features part of the SOA allows applications to easily provide talking, listening, and seeing capabilities without carrying all the baggage of TAPI, CTI, etc.
Dialing from applications is only as powerful as the directory sources that can be referenced. The arbitrary text that is highlighted and clicked-to-dial in an application needs to be converted into a format that the communication platform understands this may end up being a URI or a standard telephone number. The process of navigating to an on-line information source to convert names into useable phone numbers should become the responsibility of the softphone, not the user. This will increase the power and accuracy of click-to-dial and, if combined with Web services and an SOA, would open the door for the largest directory of all the Internet to be queried automatically in everyday work communications. Imagine harnessing the power of Google or any enterprise data source as a directory for your softphone!
As the number of directory sources grows, so too will the likelihood of duplicate matches there are a lot of John Smiths in the world. The softphone should enforce rules as to how duplicates are handled. Users should be able to configure priority schemes for directories. In time, the softphone should be able to examine behavior patterns and make the appropriate decision on how a duplicate entry is handled (i.e., when a duplicate is returned, automatically call the person with whom you had the most recent interaction).
Directories available to a softphone should not be limited to a local directory or the directory stored on the communications platform. Softphones that only provide directory look-ups against a vendors proprietary directory should not be considered for enterprise deployment.
Taking Control Of The Screen
Softphone designers could learn some lessons from the usability features of new IM and e-mail applications, such as Skype and Microsoft Office 2003. There is no need for a large softphone screen to appear during every piece of communication. Communications should be just another feature built into applications, like spell checking. Furthermore, just like spell checking, softphone communications should be simple to use and not demanding on the users attention. Subtle notifications, fading dialogs, and a minimalist set of options are all that are necessary in a softphone GUI. More thought should be put into how softphones will be deployed on enterprise desktops. Softphones should leverage enterprise authentication systems (Radius, Active Directory), require no user configuration, and provide easy inventory tracking and upgrade mechanisms.
Increasing Portability Between Devices
The nature of the phone system, since its inception 130 years ago, forces interactions with it to be very fixed. By that, I mean the telephone system forces you to remain tied to the specific phone you are on for the duration of that call whether you want to be or not. In the beginning, you were tied by the physical wire connecting the mouthpiece to the phone and the phone to the phone network. Today, cellular technology allows us to roam through the office and outside the office while on a call. But despite this flexibility, you are still tied to your cell phone, even when it doesnt make sense, such as when you are sitting next to your office phone. Why waste the cell minutes? Ever had a call drop because cell coverage is poor in your office? The fixed nature of being tied to the device that you initiated the call with still remains. Todays softphones continue to keep users fixed to the hosting computer. If you accept an important call at 5:25pm on your softphone, but need to leave your
office to catch the train at 5:30pm, the only option you have is to hang up momentarily and call back from your cell phone.
Wouldnt it be nice if the click-to-dial features were made available to employees, regardless of the device they end-up talking on (desk phone, cell phone, home phone, softphone)? Signaling and media are two distinct parts that make up a VoIP call. There is nothing that says that the signaling and media must go to or come from the same device. Device A can do the signaling, which may say to use Device B for the media. Furthermore, if the softphone uses SIP (Session Initiation Protocol), mid-call mechanisms can be provided that can change originating and destination locations of media streams. This enables a change as to how we interact with and view the telephone system.
Softphones should not be limited to replicating the minimal set of functionality offered by a desk phone. They should be able to control and manage the media device being used for a call and help provide SIP extensibility to any phone the user has added to his/her SIP profile. Just because a call is answered on a desk phone does not mean that the called party should be tied to that phone for the duration of the call. A softphone, in conjunction with an intelligent SIP communication platform, can provide enhanced portability to break the fixed nature of traditional phone systems.
Conclusion
Before widespread adoption of softphones in the enterprise can occur, the issues of usability and usefulness as a desk phone replacement must be addressed. Softphones should seamlessly integrate with and provide instant communication from enterprise applications and directories. A softphone should also be viewed as a dialer and control device, regardless of the phone device the user ends up talking on. Softphones should blend in with the desktop, and should integrate with the interactions that take place with other applications. Its not enough to just provide traditional telephone features in a softphone. The services that softphones provide should be available in your SOA registry for all applications to use. Addressing these issues will lead to a greater adoption of softphones, because of the productivity gains they will allow. IT
Fergal Glynn is Systems Architect at BlueNote Networks (news -alerts). For more information, please visit the company online at www.bluenotenetworks.com.
If you are interested in purchasing reprints of this article (in either print or PDF format), please visit Reprint Management Services online at www.reprintbuyer.com or contact a representative via e-mail at [email protected] or by phone at 800-290-5460.
|
SUBSCRIPTIONS
TMCnet LOGIN
WEBINARS
