Topology Builder Genesis

Configurable computer network topology mapper with static diagramming support.  

Watch the Presentation

Background

Incorporate static diagramming tools into a functional cloud network map

After the success of Topology builder version 2, more users adopting it, with a plan to release the tool outside of Cisco sellers, additional features were required to cater to user goals.

According to internal user signup tools, the number of new users went from 10,422 to 31,867. The number of topology projects created increased from 21,316 to 56,863, and with that we had a lot of user feedback on what features were missing.

Solution

A version 3 of Topology builder with many additional features  acquired through consulting with new user types. These included, but was not limited to:

  1. Error handling with console log
  2. Configuration with terminal
  3. Continuous deployment
  4. Introduce diagramming tools
  5. Multiple user edit

This case study will focus on static diagramming tools.

Team and Tools

Role
Lead UX Designer

Delivery
Remote

Team
Antony - Lead UX Design - Table config view
Fadzie - Product Mangement
Barry - Project Mangement

Tools
Figma - Wireframe + UI Design
Miro - User flows, Requirements Analysis
Ipad Adobe Sketch - Rapid Prototyping

Collaboration Style

  • Daily UX check-ins - UX team
  • Bi-weekly project check-ins - PO, PM, Software Engineers, Super users
  • Kick off meetings - Business stakeholders, management
  • Monthly User review sessions

Scope & Constraints

Inventing a new type of diagramming tool that has static and functioning items at the same time, proposes usability challenges and learnability for the users.

Without existing platforms to measure up against, it's unclear how such a solution will be received.

Process

Discovery

Users & Audience

Feedback

Feature Request Tool

Using Topology Builder feature request forms, users gave insights to what they wanted. The feature request UI had a voting system, so we could determine the most upvoted requests. This made it easy to prioritise.

Diagramming Features

Import & Export

Enhancements

Most upvoted features looked as follows:

User Interviews

Contacted some of the users who left their emails and invited them to interviews to deeper understand the requirements and include them in the iteration section of the design cycle.

Motivations

  • Achieve a sale with collaboration with client
  • Clarify solutions for partners
  • Teach students how to modify and create own solutions

Frustrations

  • Unable to add notes to diagram
  • Want to extend diagram annotations further
  • Unable to show a full solution without adding configurable items
  • Can’t share
  • Unable to personalise diagrams with branding

Personas

Key Users

Other Users

dCloud Operations, Admins, Demo Developers, Lab Builders, System Engineers

Design and build computer topologies, networks, solutions and showcase them to customers, make a sale

Desired Features

Diagramming

• Add images, labels, and other items to show a complete solution to clients.

• Adding non-configurable boxes and lines

• Labelling certain elements would make diagrams more clear.

• Users want to be able to draw boxes and lines to make the picture richer.

• Adding images and icons is desired.

Differentiate what is configurable and non configurable

Design

Define Requirements

Assessed the business requirements, listed user problems and proposed solutions.

Problem
Solution Idea

Add Labels

Text tool

Draw boxes

Box tool

Add static images

Upload and insert images

Need to see difference between diagram types

Figure this out. Maybe different view types

Rapid Prototyping

For this case study, I will present the section on being able to distinguish the difference between functioning and static assets, as they look the same. How can we make this easily distinguishable for the user.

Views

Menu Tools

Drawing Tools

Wireframes

By using the rapid prototyping ideas, wireframes were created.

Problem: Users need to be clear on what is a static drawing vs a configurable asset.
Challenge: Both can look identical.

View of the Screen

Combined mode, general screen layout

Everything on diagram.

Thoughts & discussion
  •  Can see entire drawing. 
  • Hard to differentiate visually between drawing and a functioning asset since look exactly the same.
  • Tool menu is too large and confusing.

Need to prototype ways to access different views so the user can contextually edit the diagram. Aims:

  • User knows which type of diagram they are accessing
  • User can switch back and forth
  • Once user is familiar and has learned how the tool works, then they can work in the combined view

Separated Views - Design 1: Botton strip

A strip at the bottom to switch

Thoughts & discussion
  • + Bottom row view switcher
  • + Easy to view snapshot
  • +  Easy to change
  • + Separation of tools in different views
  • - Takes up too much space
  • - Tools menu completely clogged
  • - Bottom area probably needs to be kept clear for additional features such as terminal

Separated Views - Design 2: Navigator Zoom Tool

Thoughts & discussion
  • + All view elements placed in the same area
  • + Compact and  doesn’t take up real estate
  • + Non disruptive to future features
  • New UI type so needs to be learned

Separated Views - Design 3: Top Menu

Thoughts & discussion
  • + doesn’t take up diagram real estate.
  • Some diagrams can have really long titles or we may need to add additional buttons and options, so perhaps it may not be right place especially if we need to add more buttons in the future.

Swapped Views

Master - All in one
Config - Functioning Cloud Networking Assets
Drawing - Static Images and text

Tools Menu

With new diagramming elements, the tools menu needed to be expanded to include additional elements. This also needed to be contextual. Two ideas were prototyped, they would look like this in the each of the different views:

Combined
Config
Drawing

Menus in context

Combined
Config
Drawing
Thoughts & discussion

Menu 1 - all in one

  • looks like a lot of stuff
  • Hard to tell which is what

Separate menus for different views

  • + Nice that specific menu is  shown only for that diagram type
  • +  Keeps it concise , avoids confusion
  • + Less space

Greyed out menus

  • + Combined screen, items are separated = less messy and clogged
  • + Shows what is available for the specific screens

Drawing Tools

When an item in the diagram is selected, a right hand panel pops up to edit the settings. I prototyped this for a static item and it was apparent that it's hard to differentiate between a config and a static item. Example below:

VLAN line connection setting

Line drawing options

To separate drawing items from setting items, a top bar for drawing option was designed. This helped clarify to the user which type of line they had selected.

User Testing

The designs were tested on a couple of calls with users and stakeholders. They tried out an interactive version of the wireframe. The tests included the following tasks:

  1. Draw a box
  2. Label something
  3. Draw a line and change it's properties
  4. Change a network line connection settings
  5. Switch views

Key Findings

  1. It was easy for them to switch views, but they preferred either the zoom tool or the navigation method as they felt the strip took up too much room on a small screen, even though it was the most clear method.
  2. Having diagramming options pop up on a top bar rather than the right panel did in fact make it clear to them what type of line/item they were editing.
  3. The tools menus didn't have much importance, both versions were clear enough.

Visuals & Interactions

Justification

From the user testing with a vision of future developments, the following were decided:

Zoom tool switch view

  • It takes up the least amount of room
  • Is contextual to elements around changing the view on screen, it's all in one place
  • No future features required for that area. The strip and the top nav may require other features such as terminals, long text, and additional icons. The zoom tool is at present complete

Contextual Tools Menu

  • With more future features, the menu may become really big. Separating them out leaves room for growth and more space for the diagram.
  • Contextual change provides a focus on the type of diagram that is being edited.

Asset Tools Panel

  • Top bar was the easy choice as it separates networking elements from static drawing elements
  • Separation of panel views helps users contextualise

Final Design

Cisco dCloud team switched their visual style to Magentic UI Design. This design was used to mock up the final design

Screen Layouts

Drawing Tools

Interactive Prototype

Please view full screen mode.

Outcomes

Thoughts

The diagramming tools were very well received. Not only were the users happy but the business saw the potential of how we could use it to bring in more profit and innovate further in global networking infrastructure.

I think we could work on the visual style to make it more appealing, despite conforming to the UI kit.

Future

There are many new diagramming features that are being worked on to be incorporated into this tool. It is one of a kind in the world, thus having the potential to be sold as standalone software to other companies.