Getting the Message
Over the past several months I’ve been using Cisco Spark and Unify Circuit for projects and communications. Here’s a few take-aways from the experience.
- I get it. There’s a reason why messaging apps (Facebook Messenger, Line, WeChat, Hangouts, Snapchat, and more) are taking over consumer comms. They are efficient. More immediate than email, and less disruptive than a phone call.
- They foster collaboration. There is something about messaging that invites messaging. After a phone call we are done talking. Never ending email replies are annoying. Messaging is so simple and efficient that people have more to say.
- Efficient. I have used this word in the two points above so let me explain further. Email, like the letters before them, are more formal with more components. Emails have an opening salutation, a body, a close, a signature line, and often include both file and graphical attachments. Messages don’t. Messages say “Fire!” and emails say “Dear Sirs, your house if on fire, please consider taking appropriate action such as contacting the local fire squadron or perhaps dousing the flames with water using your hose. I hope you contain it soon. Your neighbor.”
- Messages are self-organizing. Messages arrive and go into the proper unit (container, room, space, etc.). This is impossible to mimic with email rules. Messaging containers are highly versatile and can be created by people or subjects, and can be easily shared. The container can be recurring weekly or annually. It just works.
Neither service was integrated with my desk phone, but both offer integrated communications. They both richly integrate with their own UC platforms (Unify OpenScape and Cisco Call Manager). Circuit also supports a SIP integration to third party systems, though I’m unsure how to integrate with a third-party UCaaS provider.
In addition to Unify and Cisco, integrated workstream messaging and UC solutions are available from Mitel, Fuze, Interactive Intelligence, RingCentral – and soon from BroadSoft. Workstream messaging becomes a workflow hub, so it makes perfect sense for it to be integrated with the UC experience.
Regarding shared content, posting within these applications is marginally better than email attachments. It’s nice because people, content, and comms (real and async) are all in one place. For collaboration on documents I prefer single version solutions such as Office/OneDrive and GDocs/GDrive because of improved (single) version control. Also, since most email systems restrict large attachments something is needed, so it may as well be the workstream messaging application. It’s odd that email servers restrict attachment sizes – everything else on the web gets bigger, but email seems determined to become obsolete.
I use Chrome with both services, though Spark is optimized for FireFox. That will change, or perhaps even has changed with Google’s intent to support H.264 video. That fiasco had to do with video codecs not audio, so technically Spark should have worked in Chrome for audio calls, but Spark largely ignores voice. This is subtle because video with the camera off is effectively voice.
A big philosophical difference between the two has to do with presence. Circuit provides presence information and Spark doesn’t. Circuit takes the evolutionary approach from IM. Many people find presence indicators familiar and reassuring.
Spark is attempting a revolutionary approach and wants to redefine the experience. Cisco believes the notion of presence is obsolete because we are all mostly always online due to our mobile devices. Not to mention the fact that keyboard activity has little to do with availability.
To make up for no presence, Spark came up with something I think is better: read-receipt notification. We send emails and text messages, but never know if/when they were read. Spark indicates if a message has been seen. That’s really what presence was all about anyway – but indirectly. If I know the message was received (can’t meet for dinner) then I can go about my business. Otherwise I might keep trying to communicate via other channels.
Regarding Circuit vs. Spark. There are far more similarities than differences. The layout and usage is nearly identical. They both support persistent messaging + real time communications. They both work with clients and browsers and utilize WebRTC technologies. They both offer search and file share. Overall, Circuit is more mature. It just had/has more features though Cisco has been improving Spark quickly. For example, Circuit had mentions and search – though Spark has them now. Circuit also supports threaded conversations. Sometimes delinquent replies can be hard to associate in Spark. That said, I think Cisco has big plans for Spark as both an application and a platform. I think Cisco is heavily focused on architectural issues for undisclosed capabilities.
Circuit has been overall more intuitive. That might be a result of all that upfront work they did with Frog Design. For example, when I changed my email address/loginID it was as simple as updating my Circuit profile – no assistance needed – no history lost. I continue to use my old address/loginID with Spark because as far as I can tell it’s impossible to change it.
Before I conclude let me offer a reminder of why I call these apps workstream messaging. I don’t like “messaging” as it’s too vague. Messaging can apply to SMS, consumer apps from Messenger to Skype, IM, and unified messaging – all of which are different. I use “Workstream Messaging” to describe applications intended for enterprise communications. These applications are similar to consumer-based messaging tools which are taking over the Internet. They deserve a different name. The key is workstream messaging is integration into enterprise systems such as directory, communications systems, and key applications. They also have to be compliant with security policies, encryption, and data control.