VeloCloud was an SD-WAN startup making it easy to provide business-grade network security and performance to branch offices. It was acquired by VMware in 2017.
As the first UI guy, I was responsible for both UI/UX design and frontend development. Fortunately, I succeeded in getting a couple other frontend developers on board to help carry the load! 😀
- Easy to configure
- Easy to deploy
- Provide visibility
- Provide troubleshooting tools
Most of us at VeloCloud already had plenty of experience with similar network device UIs. We understood that flexibility leads to complexity, so a key design goal was to balance that flexibility with simplicity.
We settled on a model where a device’s configuration was comprised of a stack with 3 layers. Each layer was mostly similar in the configurable options, but unless set, the options defined at lower layers were used. A given device’s configuration was the sum of all 3 layers.
Compared to our previous experiences, this seemed to strike a reasonable balance between flexibility and simplicity.
Sample Config Screen: Configuration UI showed an overview of the actual settings at that level, and also showed if settings at that level were overriding settings (or preceding, in the case of policies) lower levels. It also provided links to navigate to lower level settings in the stack.
Note the icons in the navigation tabs are either lit or unlit. When lit, it means settings or policy rules are defined on that screen. Here you can see the Default Profile defines device settings and a basic QoS policy, but nothing about firewall or VPN. If a device used a profile that didn’t override these settings, it would inherit these defaults. So, IT could define a broad set of defaults, override them with a named profile (perhaps based on region, or department), and likewise override settings on a specific device (not encouraged).
[TODO: Icons!]In lists of Profiles or Edges, those same icons are displayed as columns. That gives at-a-glance insight into what parts of a configuration are defined where. The icons also served as hyperlinks to the relevant configuration screen.
The idea was that a company could just ship our device to a remote branch. A person there with no IT skills at the branch would be able to plug it into their cable and/or DSL, and...there’s no step 3. The device would phone home to get its configuration, and from then on, it just worked. Welcome to the company network!
While there may not be IT staff on-site, IT of course needs to see and troubleshoot issues with remote site networks. A key aspect of the UI was providing visibility to support that.
Home Page: The starting point was a list of the deployed devices and their status. From here the user can quickly spot sites and devices that are down or experiencing problems. Clicking from here, the user can drill down into the details of the edge device.
Detail Views: The first details screen provided an overview about the device, including this visual showing the status of the various ports. The user can easily see the link status on the various ports. Each is clickable to view detailed link-specific status and statistics.
Quality of Service: Besides routing and firewall services, our device did a variety of things to handle performance issues. One reviewer said:
“At a couple of events, I’ve seen a fascinating demonstration where VeloCloud simulates a troubled link and pushes a video stream through it, both with and without VeloCloud impacting the flow.”
This chart was designed to show that off. The top bar shows an overall view of perceived network performance over time, alongside actual ISP statistics. Hovering over the chart provided more details about any given state on various performance metrics, and showed any actions the device took improve to improve perceived performance.
“Top 10” lists: These screens showed information about the top 10 (as defined by various metrics):
The list can be expanded to show more than 10, but the time series chart only ever showed the first 10 (any more would be of little use, given the dimishing returns, as can be seen from the subtle bar graph shown on any current sort column with numbers).
Functional cross-links: Note the links in the left sidebar, under the main navigation. From the very start, the UI was designed to make RBAC easier on the UI implementation. The upside of that is that it’s easier to remove screens for users who aren’t supposed to see or use them.
The downside is that breaking things down by function creates silos. Suppose you’re a user who is allowed to do most functions. You’re looking at a device, and realize you need to change a configuration setting. Now you have to go to Configuration, then find that device again. These cross-links were a band-aid fix, but they made it easier to bounce around silos without losing context. (And yes, there are better solutions! I would do this differently today, but it would require a more fundamental change in the UI. This is an example of the problem of being both designer AND developer. This was just a quick way to solve the problem.)
Most troubleshooting tasks are really covered by visibility: being able to see what’s going on with a remote device and its network traffic. Beyond that, we provided GUIs for typical network troubleshooting tools like traceroute or tcpdump. This philosophy also applied to configuration, where it should be easy for an admin to test configuration changes before deploying (we didn’t get around to that, but it was definitely a request from the field).
[TODO: Include black on white logo here] We crowd-sourced design ideas for the logo, but ended up going with one I’d designed. [TODO: Include some of my other variants.]