The developers narrative

The topology view is part of Red Hat OpenShift’s developer perspective, which takes a unique approach to providing an application-centric visual representation of projects. This could potentially help reduce stress for developers and provide them with a more insightful perspective to innovate. Here’s how we’ve approached improving the developer perspective as a user experience. This feature was chosen as a runner up for the Core77 awards(2020) in the interaction design category, and also won the community choice award.

The topology view

Before diving deeper into the solution that the topology view brings to the table, let’s get better acquainted with the problem first.

As a common practice, developers could only look at all the components of their application together as a flat list. This wasn’t ideal for visual hierarchy, especially because a list flattens a significant factor of the components in the overall application structure.

Fragmented probing is the only practical way to understand the relationship between the two components. And due to the broken nature of the probe, the bigger picture is often thrown to the wind. This workflow further inflates the complexity of the already strenuous job of a developer.

With the topology view, developers have a more holistic view of their overall application structure. The goal here is to help boost efficiency by condensing complex task flows into simple visual interactions.

Design insights and the topology view

OpenShift’s alignment with the open source community and our customers’ willingness to participate in feedback conversations has allowed our team to engage with many developers over the years and gather insights into the developer mindset. The design team for the OpenShift developer perspective took what we believed are the most relevant insights and used them as a baseline for creating the interactions found today in the topology view. The three most important of those are:

• Providing immediate feedback.
• Designing a developer-friendly fail-soft approach.
• Providing concrete visual feedback for abstract data.

Provide immediate feedback

Not being able to see immediate feedback for their actions has been an everyday struggle for developers on various platforms. This brings in an extra delay in their process as they have to take additional steps to validate their syntax before moving on to the next step. The topology view solves this problem with the following design approaches:

• Adding a resource — When a user adds a new resource to their application, a component is added to the topology graph, providing feedback regarding their action and its status.

• Scaling up/down, starting rollouts and recreating pods — In Kubernetes, to increase or decrease the number of replicas of a workload a user wants to run, there needs to be scaling up or scaling down. While scaling, the pod goes through a set of transitional phases before it gets up and running. Similarly, while starting a rollout or recreating a pod, there are many intermediary transitional stages that the pods go through. Topology allows users to see the real-time status of those stages through an animated visual representation.

• Connecting a database to an application — A user can add a database to their Node.js application through the topology view by merely dragging an arrowhead of a connection handle.

Developer-friendly fail-soft approach

With every push to the production branch begins the anxiety of breaking the code. To ease developers of this worry, the operations must be made fail-soft — like Lego blocks, rather than failing with an error message, every interaction attempts to do something sensible even when presented with out-of-range inputs.

• Adding resources in context — While the users are in the topology view of a given application, performing a right-click provides them with an option to add a resource. However, depending on the visual area where the action is initiated from, the options for the resource type that could be added varies. This brings down the chances of deploying any irrelevant resource type for a given application.

• Determining connection-type — The topology view allows for creating a connection between any given pair of resources by simply dragging a handle from the origin nodes and dropping it over a target node. It can help reduce the cognitive load on the developers by doing a smart assessment of whether an operator-managed backing service is available for creating the intended binding. In the absence of an operator-managed backing service, an annotation-based connection is created.

• Role-based access control (RBAC) — To further bring down the developer’s distress, the role-based access control (RBAC) implemented in the developer’s perspective of OpenShift adds an additional check on the actions available to a user. It provides meaningful segregation of tasks and responsibilities for the user based on their role in the team to avoid overlap and conflicts. However, restricting actions might become a source of frustration in certain cases if the cause isn’t communicated very clearly. Framing the appropriate error messages can play a crucial role in creating an engaging console experience. Instead of simply stating the failure of a performed action, the message also clearly communicates the reason and provides the alternate solution, if any.
• Finding workloads on the topology graph –– Enhancing the potential of the topology graph allows users to customize and de-clutter their view as they set out to perform more focused tasks on large projects. “Find” is one of the new features introduced with the release of OpenShift 4.4. It allows developers to highlight the relevant component on the graph, while still maintaining the context, to be able to make a better judgment regarding its relationship with other workloads in the application.

Concrete visual feedback for abstract data

While writing the code for an application, a developer has to deal with manifestations of various kinds of information and data in the command-line interface.

The visual fatigue caused by the monotony of characters in code can very easily result in oversights that might be difficult to reverse later. Studies show that humans are much more responsive to visuals rather than abstract data. Translating the crucial data into perceivable and actionable visuals can save time for the developers. This allows them to identify the area that requires immediate interventions and take the appropriate actions with ease.

• Displaying event sources — The topology view shows elements from Knative Eventing, namely event sources, which helps give a developer quick insight into which event sources will trigger their application by looking at it visually.
• Representing hierarchy and groupings on topology view — With the help of visual demarcations, a hierarchy is maintained in the topology view for the resources in use under an application. The grouping of nodes into visual groups when needed (such as application, Knative services, Helm workloads, and Operator backed workloads) and the nesting of those groups provides a tangible idea of the depth of the application structure.

A brighter future for the developer experience

The topology view of the OpenShift developer perspective is a redefined approach to application development that demonstrates many possibilities of what the future could be like. It is a great example of how a thoughtful design approach, assisted by the combined power of containers, microservices, API-driven integration, and DevOps automation, is helping developers achieve more and with less time and stress.

By using context-based visualizations to assist the developer, the topology view interface frees up their time to focus on other tasks. This could very well be an onset of a more productive and innovative era in application development for cloud-native, microservice deployments. Besides making it easier for the developers, this simplification of tasks, and automation of the infrastructure managing and monitoring front, should also reflect positively on the developer experience, security, stability, and business value side.

Learn more about application development with OpenShift. To provide feedback, join our OpenShift Developer Experience Google Group to participate in discussions or attend our Office Hours Feedback session. Or, drop us an email with your comments about the OpenShift Console user experience.