A common pain point of both our Customers, as well as our internal Applications Engineers, has been the ability to be able to see an understandable history of commands that have been run both via the UI and terminal.

The previously available History panel did show a history of all requests sent, but it did not show useful info for the corresponding responses, and relied on users being able contact support to proceed with troubleshooting specific commands.

This didn’t make it very easy for non-developer users to understand which commands resulted in failure.

Background

As part of a team hackathon led by one of the Engineering Leads, we sought out to create a better way for users to understand the commands that were sent. Previously, the history panel displayed only request sent as a result of using the Control Panel UI.

The previously implemented history panel displayed the variables sent via requests, and often resulted in a message to contact support if a request failed. It did not display responses for successful commands, and the way it identified which commands were in progress definitely did not meet WCAG 2.1 text color contrast standards.

Planning

Since this was meant to be a team-wide hackathon, we worked together to identify the strategy we would use when making UI and back-end decisions. A couple of days ahead of the actual hackathon, I (the designer) initiated a meeting between myself, the Product Manager, the 2 Engineering Leads (front end and back end), and the QA lead to go over the ask and identify a rough strategy for us to follow so that we could make the best use of the developers’ availability on the day of the hackathon.

We got together to discuss the core parts of the history panel that we would be focusing on the following goals:

• Readability, including more useful formatting of requests and using WCAG 2.1- compliant color contrast ratios.
• Filtering, allowing users to drill down to specific time periods in order to help with their troubleshooting.
• Efficiency in re-sending certain commands or copying a set of commands and responses to send to customer support when it was necessary.

Hackathon Day

On the day of the hackathon, I came prepared with designs to iterate on based on identified requirements.

These designs employed iconography to draw attention to failed or in-progress commands, and also employed a more human-friendly way of identifying when a command was sent and what it was meant to do.

Through discussions with the 9-person team, we identified changes to these initial mockups that addressed the aforementioned goals. We would do away with the tabs and allow all commands, regardless of the originating source, to show up in the history panel. So whether the request was sent via the UI, via a terminal, or via an integration, they would all show up in this panel.

Users would be able to expand specific commands to see their corresponding respons(es).

Users also had the option of resending requests or copying them based on what they whether they were testing something or looking for troubleshooting help from support.

Additionally, users would be able to use filtering capabilities to avoid having to manually scroll through lines and lines of commands to find the specific items they were looking for.

Results

Since being implemented, the updated history panel has been useful to both internal QA teams, as well as external customer teams in better being able to identify the source of unexpected errors and validate integrations.

We continue to frequently receive feedback from our customer-facing teams about how much of a difference this has made to the overall impression of the Control Panel and RTR’s products as a whole.