Our perception of nirvana is impacted mightily by current conditions. For people who live in third world countries, for example, merely having running water or reliable electricity can be a life-altering boon. Meanwhile, those of us who are more accustomed to the creature comforts of life consider slow internet or a poorly seasoned meal worthy of public scorn (even if we add the hashtag #firstworldproblems).
So how is the current state of networking impacting its user base?
A new normal
Perhaps the most insidious effect of poor conditions is that prolonged exposure can actually cause us to reset our baseline for normal. When we are subjected to extended periods of great or even long periods of suck, we adjust our expectations.
In networking, this means that our current normal has been forged through diligent neglect of actual user experience for decades. It’s not so much purposeful behavior by the incumbent networking players so much as placing focus elsewhere. For at least the last few decades, the future of networking has always been defined by the next protocol or knob. That is to say that the focus for product development has always been about bolstering device capability.
With the focus on what a device can do, there have been precious few cycles dedicated to engineering how a device does it. We have landed on the CLI as our tool, which is actually fine. But we have paid very little attention to how that tool can be used.
How bad is it?
If our entire industry has been focused on capability over usability, just how bad have things gotten?
Consider for a moment that people get excited about OpenStack. The OpenStack ML2 plugin does VLAN provisioning. Think about all of the configuration that is required to make a device function, and then consider that we collectively think that solving the VLAN provisioning problem is a big step forward.
I don’t mean to unnecessarily attack ML2. It absolutely is a useful thing to have. But when we look at the entirety of the networking user experience, solving the provisioning problem for one edge policy construct is hardly enough to declare victory.
Network engineers have essentially been living their lives in IT’s third world. Running water and sustainable electricity are looking pretty good right about now.
A step too far
There are downsides to lowered expectations. Sometimes, the alternative to third world is just too different to be consumed. Imagine sleeping on a desert island for years (as in the Tom Hanks movie Castaway). Your first night back in your home, you might actually prefer sleeping on the floor to relaxing in your pillow top king. Comfort is as much familiarity as it is plush mattress.
So it is with networking. We have become CLI jockeys, so accustomed to manipulating configuration knobs that fancy UIs seem unnecessary and unwanted. In many cases, the emphasis on the UI represents a step too far for most people managing networks today. We sacrifice familiarity to embrace the new UI. But with that familiarity, we also sacrifice usability.
It’s not surprising that some of these efforts that demo so well don’t survive long in the wild.
Less about the wrapper, more about the workflow
The thing to keep in mind here is that the wrapper is actually the least important thing. Whether a UI really sings during a demo is almost irrelevant outside of the sales cycle. The best UIs are the ones that understand the actual workflows they are being used to execute. They fit the network engineer like a glove on a hand, allowing the two to behave almost seamlessly. At times, they almost intuit what the network engineer wants to do next.
For example, when you provision something, the very next thing you do is verify that the step was correct. You might ping an interface, or look at a counter, or view some protocol state. In these moments, the UX is less about the window that shows this to you and more about the workflow that captures validation as a natural next step after provisioning.
In another example, perhaps there is an alarm that indicates an interface is down or some loss threshold has been reached. The very next thing you will do is begin troubleshooting. Again, the wrapper is not so important as the steps it takes to actually capture meaningful information, correlate that information, and take appropriate action.
The point here is that the UX is determined more by the workflow than by the UI. In fact, the best UI is dependent more on a user’s context (where they are performing adjacent tasks).
Familiarity breeds success
SDN is mostly about workflow automation. But SDN is also new. There are lots of new companies and new products, each bringing to market their interpretation of how control ought to work in a next-generation network. The needle through which all companies must thread their solution is quite narrow. You need to create a user experience that is better than existing, largely CLI-based solutions, but not so different that it is not familiar to users.
Visualization will certainly be a part of SDN networks, but even there, how you visualize flows and paths and whatever else needs to be done in a way that is familiar but better.
The bottom line
The networking industry has created hordes of network engineers whom we have disappointed so much that their expectations for a better world are tempered with cynicism and skepticism. We can lament the behavior that got us there, but ultimately we have to build products for these people. If we really want to make their lives better, we need to focus on workflows and familiarity, eschewing some of the fancier things that might otherwise be done because you need to solve third world problems before you take on the first world ones.
[Today’s fun fact: Arachibutlphobia is the fear of getting peanut butter stuck to the roof of your mouth. I am guessing arachibutlphobes don’t like Reese’s much.]
The post Networking’s UX victims appeared first on Plexxi.
