A Critical Look at Cisco Spark

Cisco Spark is one of the most important solutions in our space for a number of reasons. First of all, Cisco is our market leader and is putting all of its eggs in the Spark basket. What started out as an experiment with the persistent team messaging workflow is becoming the core of the entire Cisco collaboration world. Cisco phones are now Spark phones, running on the Spark Cloud. Cisco’s purchase of Acano, the biggest event in the collaboration world in 2015, has Spark written all over it. Cisco has even announced a $150 million fund to support developers working on integrations for Spark. In other words, Spark is a big deal.

But it all starts with its persistent team messaging application. The Slack phenomena has made it clear that people like the persistent team messaging workflow. It greatly reduces email use, and does a much better job than email of contextualizing conversations and enabling a more real-time, back and forth project workflow. With this in mind, I wanted to take a closer look at this aspect of Spark. To be clear, this isn’t a review of the full feature set of the Spark Cloud. This is merely my thoughts on some of the nuances of the chat application after several weeks of use.

Room Sorting
Spark has 5 ways to sort your rooms. All, Important, Unread, 1-to-1, and Favorites. Obviously, clicking “All” displays your complete room list and “Unread” just shows rooms with new messages. So far so good. 1-to-1 is private messaging. Treating private messages as a room type is a bit unintuitive, and causes other issues which I will address below. This leaves two categories, which is where the confusion begins.

The concept of favorite rooms is simple enough, and a common UI technique. By right clicking any room title, or clicking the star icon in the room sidebar, you mark a room as a favorite. This adds the room to your favorite list so you can find it easily. Simple enough, and intuitive enough. But then we have important rooms. Similar to favorites, important rooms go into your important list so you can find them easily. But is it obvious to the casual user why we need both favorites and important rooms? Does it not seem a little redundant and confusing? Wouldn’t most users consider their favorite rooms to be important? And wouldn’t most important rooms belong on a favorite list for easy reference? Why do we have both? There is an answer, but it just isn’t something I would expect the casual user to understand. It turns out important rooms are more than just rooms that you want to flag for a special list, important rooms are rooms that get notifications.

I would love to see a much more robust system for classifying and sorting rooms. It would be great if I could create categories of rooms. Lists of rooms for internal team communications, external facing rooms, temporary project based rooms, permanent office infrastructure rooms, etc. The Spark developers are exceptionally agile and on a leading pace for adding new features, so this might be on the roadmap. So for now, let’s focus on making sense of how the “important” room category relates to notifications.

Notifications
I have several issues and concerns with how Spark handles notifications. While the system is functional, it is not intuitive. First of all, when you right click a room, you get a mini-menu with three choices (see above). Leave the room, favorite the room, or display notifications. If you click display notifications, the room is added to your important list. So why doesn’t the dropdown box say “make important” rather than “display notifications”? That would be more consistent. If we are going to address notifications by making a room important, we should be consistent throughout the UI.

This inconsistency carries on to the room sidebar on the right, where room details such as members and shared files can be found. In the sidebar there is a checkbox to make the room important, but nothing about notifications. Why is the very same setting/feature called notifications in one context, but called “mark as important” in another context. This is bound to confuse the casual user. Even the Cisco Spark developers seem to recognize the fact that the connection between importance and notifications is something that has to be explained to the user. Check out this explanation that pops up when you mouse over the “mark as important” checkbox.

If your UI requires mouseover text with this much detail, then your UI is not intuitive enough. You can’t expect a casual user to parse all that to determine the connection between importance and notifications. The devs are clearly working backwards here. They have created a workable notification system and are trying to explain it to their users. They need to reverse this methodology and start with user expectations and design Spark to work that way. So how would a user expect to set notifications? They would expect to find notifications settings in the sidebar of each room with a choice of how notifications should be handled for that room. A user is not going to think, “I want notifications for this room, I will mark it as important.” If that is how users thought, the big mouseover text shown above would not be necessary. If a user goes to the Cisco Spark help page to get clarification on important rooms they will find the following information.

Important: Shows rooms you’ve marked as important, as well as: 1-to-1 rooms with activity within the last week, rooms where you’ve been mentioned within the last week, and rooms that you were added to within the last week.

This explanation only raises more questions. Some rooms become important automatically? If I am added to a room, that room is important for a week? How does it stop being important? Does it uncheck itself after a week? What if you wanted it to stay important? You then have to recheck it? Does it matter whether or not you use the room? Will it stay important if you work in there, but uncheck itself if you never use it? What about rooms where you have been mentioned within the last week? Does it matter whether you go in and read the mention, or will it uncheck itself as important after one week regardless? Again, is any of this the way users would expect notifications to work, or is it a system that seems logical to Cisco developers and now has to be explained to the users?

My next concern about notifications is in regards to how the notifications themselves actually work. Cisco Spark does a great job of managing notifications between your desktop and mobile devices. No need to get into the weeds here, but they obviously put time into figuring this out, and if you want notifications, they will appear in the place that makes the most sense based on how you are using Spark at any given moment. But there is one glaring omission from the notification scheme. There are no email notifications.

I understand Cisco’s hesitancy to create email notifications. Spark is marketed as a way to reduce email spam, so having Spark generate its own email spam would be counter to the entire philosophy behind Spark. But as a long time Slack user and persistent team messaging analyst I can say that email notifications are a huge part of why Slack is so “sticky” with users and Spark is not. I sometimes forget to load up Spark, I forget that it exists, and so do the people in my Spark channels. My Spark friends are not nearly as responsive as my Slack friends. A big part of this is email notifications. If you were to get an email saying that you have Spark messages, you would click it and suddenly be back in Spark. To be clear, I don’t think Spark should simply copy the Slack email notification methodology. It is actually too spammy, sending notifications every hour. I would recommend Spark send a daily email if, and only if, a user has new unread messages or mentions in selected channels and has opted in for email notifications. I strongly believe that if Cisco makes this feature available to a test group of users, that group will have higher adoption and usage rates than a control group without email notifications.

Final nit on notifications. In the image above, the right half of the circle (with the number 6 in it) is colored gray. If the room was important (notifications on) it would be colored yellow. This provides a nice and easy way to scan through your list of rooms to see which ones have notifications enabled. The problem is that it is extremely unintuitive and there is no explanation for these colors anywhere within the UI. I only learned what the colors mean by going to the Spark website and reading the FAQs as research for this article. Again, this is an example of the Spark developers coming up with something useful that has to be explained to the users. If we were to survey 100 typical Spark users and ask them if they knew why some of their rooms are gray and some are yellow, I would be surprised if half of them knew the answer. A UI element, no matter how well designed and intentioned, is not helpful if users do not understand it.

Private Messaging and Named Rooms
Cisco Spark addresses private messaging through its 1-to-1 rooms. As I mentioned above, I have a few issues with this dynamic. I believe private messaging should be treated differently than rooms. Mixing my private conversations in with my rooms is confusing and oddly limiting. The 1-to-1 list should be replaced with a contacts list, and clicking on that contact should open a private messaging session with that person. The private message sessions should look and feel different than regular Spark rooms so users feel comfortable knowing that they are in a private session, and that no one will be added to the room. Spark does protect the privacy of its 1-to-1 rooms. Although they look and feel like regular rooms, they are locked down and no additional people can be added. Unfortunately, this is how the system is oddly limiting as I will now explain.

The limitation is that Cisco Spark does not allow for contextually based 1-to-1 conversations. In the simplest of terms, it is impossible to create named rooms with only one other person, with the ability to later add more people. This is a little tricky to explain, so follow me as I describe a hypothetical scenario. Let’s say I have three new project ideas. I want to start project A with three of my co-workers. This is no problem for Spark. I create a room by inviting those three people and name the room “Project A”. But let’s say that I want to start Project B and Project C with only one of my co-workers. I can not create rooms named Project B and Project C with just myself and one co-worker. If I try to create a room with just myself and one co-worker it becomes a 1-to-1 room with no name. And you can only have one 1-to-1 room with each person. So if I am working on 5 separate projects with that one person, all of our communication on those 5 projects gets combined into our one and only 1-to-1 room. This is no better than my email inbox, with all communications in one bucket.

I want to contextualize my conversations with this person into 5 different rooms. I do this all the time in Slack. I have many named rooms with only one other person. When one of these rooms lights up with a new message, it is contextualized. Before I even read the message, my brain is thinking about that specific project and I am ready to process the information and respond quickly. The structure of my rooms in Slack is basically helping my brain sort incoming communications with this person into each project. If I want to review information on a specific project, I don’t have to scan through all my conversations with that individual, as Spark would force me to do. Even better, if one of these projects grows to the point where we want to add more people, we can do it at any time without risking the loss of private communications because these named project rooms are separate and distinct from our private messaging channel.

Not only would I like to have named rooms with only one other person, I would like to have named rooms with only myself. When Spark was first shared with the world by Rowan Trollope (in its earliest iteration as Project Squared), he made very convincing analogies between its virtual rooms and physical rooms. A physical room isn’t just a place to meet, it has counters, shelves and walls to keep meeting materials. Similarly, Spark rooms allow for uploading and storing files. I think this is very powerful and compelling. But let’s take that analogy as far as we can. I don’t need 2 other people to start a project in a physical room, so I shouldn’t need them to start a Spark room. With a physical room I can put a sign on the door designating it as a project space, put my files on the counters, and start working on the project myself before inviting my team. I should be able to do the same thing in Spark. Let me create as many named rooms as I want by myself. Let me create my entire business online before hiring a single employee.

I came across this limitation, ironically enough, in a Spark session with Rowan himself. We were tweeting back and forth about a technology idea and I wanted to take it to Spark. But I didn’t want to share my thoughts with him in our 1-to-1 room. My reasoning was that there was a small chance he would take to my idea, and want to bring in more of his team members to discuss it further. So I wanted to chat with him about it in a named room that could be expanded. I had to be creative to make this happen. I created a named room with my LDV team, then kicked them out of the room before inviting Rowan. The end result was that I got what I wanted, a named room with just Rowan, but Spark made me jump through several hoops, and take several extra steps, to make it happen. Where there is a will there is a way, but it would be great if Spark allowed me to do it more directly.

Message Editing
This is more of a wish list item than a critique of the existing workflow, but it is important enough that I am including it here. Spark allows me to delete messages, but not edit them. This should not be that difficult for the Cisco team to add and it is extremely desirable. Remember, this isn’t just real time communications, it is asynchronous persistent communications. My messages form the project history. If I add a new team member to a project, the first thing I will tell him/her to do is to scroll up in the Spark room for that project to get caught up to speed. I don’t want them being confused by typos or misinformation. I need to be able to correct my mistakes to avoid confusion as a project develops. The ability to edit mistakes is especially urgent since Spark is used heavily on mobile devices. The autocorrect function on our phones and tablets has a way of betraying us. It is often very amusing, but can create confusion. It is extremely frustrating to see a mistake and not be able to fix it, even for those of us who aren’t perfectionists.

While this article was highly critical, I want to make it clear that overall Spark gets a very high grade. These are minor, and easily fixable, workflow issues. The Spark Cloud is a leading enterprise grade audio/video/data communications platform. You can’t compare it head to head with Slack, which is a consumer grade application just now starting to develop towards the enterprise space. As I explained in a recent article, Spark is far more usable for communicating with externals, and that is just one of its many advantages. However, workflow is important and something I take very seriously and I believe the issues addressed here would make Spark more adoptable and usable.