Workflow Progress Page

A way for users to easily understand and view the tasks and progress of customers' workflows

One of our summer interns, Morgan Langenhagen, describes her summer project of designing and creating the Workflow Page, which shows the progress of a customer’s data through the Amperity platform.

Overarching Goal

During my internship at Amperity, I designed and engineered a Workflow Page to help customers understand how data flows through the Amperity platform. The page shows the overall progress and status of each task within the platform. Every time I mention a “workflow” I’m referring to a group of these tasks that facilitate a continuous flow of data by ingesting a customer’s data, formatting and stitching it together, and creating a full customer 360 with predictive insights to deliver it back to the customer by an agreed upon time. This commitment to processing the customer’s data and delivering it back by a certain time is called the delivery promise and is typically once a day, so these tasks are very time sensitive and one failed task could result in missing the delivery promise.

The Workflow Page I created pulls together this task information in one central location. Progress bars show the overall progress of the tasks in completing the delivery promise, the delivery promise schedule is displayed at the top, and grids clearly show the tasks and their corresponding information, which is especially useful in pinpointing which tasks have failed.

Example view of a tenant's workflow

This Workflow Page eases two major pain points for users. Some users didn’t have a way to see and understand their workflows because they don’t have access to the internal backend systems where most of the task information is stored. Another challenge is that information is in several different locations, namely Airflow and Glow, a custom Amperity service that acts as a translation layer between Airflow and the application. Airflow contains all the tasks and in what order they are performed based on relationships and dependencies, and Glow has the status of each of those tasks. For a user to understand the progress of tasks in the workflow they would have to look back and forth between Airflow and Glow.

Glow/Airflow Split-Brain

The Workflow Page eliminates the need for a lot of this time-consuming and tedious searching for information.

Delivering Iterative Customer Value

One of the biggest challenges I faced with this project was deciding my approach. I was given a new page and had to decide what information I wanted to present, how I would display it, and the order in which I would create the UI components and progress towards an end state. Being a brand new intern and given a blank slate, I was challenged with so many questions like Where do I even start? Do I start in the frontend or the backend? Do I want to show the tasks or the progress first? Which workflows do I want to show? How do I even make a progress bar in the UI? and so on.

Two core concepts that helped me make these decisions are customer value and iteration. I prioritized which features to develop first by deciding which ones would deliver the most customer value. When I developed these features, I broke the problem down into the smallest possible tasks to work on that would deliver customer value so I could ship changes regularly. This way I was adding value more often, was able to get feedback along the way, and could easily iterate on any changes I wanted to make.

For example, I decided the progress bars would add the most customer value and was therefore the first feature I worked on. The progress bars first required work in the backend to filter, sort, and format task information for the requested workflow, and then that task information had to be represented in the user interface. While the progress bars are visually appealing, they were tricky and time consuming to create. I didn’t want that to delay me from displaying the information and delivering customer value so I decided to start by simply displaying the status of the tasks in text. While this is a bit of an eyesore, it got the job done and I could then move on to create the progress bars.

A major benefit of iteration was that I was able to gain feedback along the way. For example, the way I understood tasks, and consequently the way I designed the progress bars, was that failed tasks halted the workflow. This is true for some failed tasks, but others are non-blocking. This was brought to my attention soon after deploying the progress bars so I was able to make this change. If I had worked on creating the whole page at once and deployed it with a week left in my internship, I might not have had time to make any changes.

Modern UI Design

Amperity engineers are shifting away from using Reagent, an interface between ClojureScript and React, and towards using Helix, which was designed by Will Acton, an Amperity engineer. I wanted to touch on my experience with Helix because it’s mostly what I used in the frontend and made my life so much easier by avoiding unnecessary tedium that comes with using Reagent.

Helix makes reading and writing components in ClojureScript easier and provides a simpler, more efficient API for building ClojureScript components than Reagent does. Helix has two import macros:

  1. defnc macro: a ClojureScript function that returns a React element and takes care of a lot of the conversions to a JavaScript object
  2. $ macro: takes a component and props that you define using the defnc macro, compiles it to a React function and returns a React component

Here is an example of how you would print, “Hello, World!” using Helix:

(defnc example
  [{:keys [name]}]
  (d/div "Hello, " name "!"))

($ example {:name "World"})

And this is how you would print, “Hello, World!” using Reagent:

(defn example
  [name]
  [:div "Hello, " name "!"])

[example "World"]

Takeaways

I really enjoyed working with Amperity this summer and it’s so rewarding to see my work progress from a blank page to a very useful tool that Amperity has been seeking to implement for a long time. I’m so grateful to have worked with such a driven and engaged group of engineers on the OWL Team and for my mentor, John Rush, who gave me continuous guidance, support, and advice. I’ve learned an incredible amount about engineering, the general operations of a company, and even some life skills along the way - I couldn’t have asked for a better experience.