A Rare Interview With A Designer who Designs Command-line Interfaces
![alt text here](https://res.cloudinary.com/formidablelabs/image/upload/f_auto,q_auto/v1712582809/dotcom/envy/envy-social-green.png?w=2880&h=2048)
Before we dive in, you may wonder what a terminal application and command-line interface (CLI) are. For context, a terminal application is a computer program that provides a powerful way to perform various tasks efficiently. They are integral to many software development workflows, offering flexibility, speed, and precise control over system operations. With command-line interfaces (CLI), users (typically developers, system administrators, and power users) input concise text-based commands to be handled; navigate file systems, copy data, and manage applications to name a few.
For years, terminal and command-line applications have followed a familiar pattern: developers identify a need, code a solution, and release it for free, often as open-source software.
While this fosters a vibrant development community, user interface (UI) design can take a backseat. This lack of focus on UI can hinder user experience, making even powerful tools less accessible and intuitive.
Recently, one of our open source teams developed Envy, a tracing library and accompanying web application.
Envy will trace the network calls from every application in your stack and allow you to view them in a central place. Whether you are running a Node.js backend, Express, Apollo, or even a Next.js server, Envy will capture it all.
But, for developers who prefer the efficiency of developing directly in the terminal, constantly switching back and forth to the browser can disrupt their workflow.
Building A Solution
Our team set out to build a terminal application for Envy with two main objectives
- Gain experience writing code in Rust: it’s one of the most admired programming languages, and we’d like to understand why
- Create a full-featured terminal application: this is the first-time our team is building a TUI application, so we can learn a lot
![alt text here](https://res.cloudinary.com/formidablelabs/image/upload/f_auto,q_auto/v1712582820/dotcom/envy/Envy-Terminal-UI_Original-Trace-View.png?w=3584&h=2240)
We wanted to take a less common approach and involve our experienced UX design team early in the development process. This allowed us to prioritize user needs and create a terminal application with a thoughtfully crafted UI that balances power with accessibility and intuitiveness.
We asked Gaby, one of our Senior Product Designers, to overhaul the interface. The results were transformative: our clunky layout became an intuitive application.
![alt text here](https://res.cloudinary.com/formidablelabs/image/upload/f_auto,q_auto/v1712582800/dotcom/envy/Envy-Terminal-UI_Timing.png?w=1058&h=768)
In light of this transformation, we’d like to share an interview between Gaby and Scott, one of the main developers of the application.
How do you approach designing for an unfamiliar medium, such as this?
Research is so incredibly valuable when designing for situations like these. My first source was open investigation through reddit and design resources, followed by specific terminal app recommendations from colleagues. Right away, I understood the keyboard-as-navigation experience; how quick and game-like the interactions feel. Once I got my footing, I considered how to translate the existing UI and keep existing functionality intact. I also began to inventory all the screens that would have to be re-structured entirely.
What did you prioritize in the terminal application over the browser application?
The web experience, designed by Ryan Srofe is extremely effective and fluid — and I was fortunate to have this foundation as a resource. In it, different views are revealed with familiar UI elements like tabs and expandable accordions. Because of this, users can easily toggle, navigate or close tabs based on their needs. In the terminal space, these tools are not available — so I had to editorialize. I had to group content into categories: “persistent” vs “hide/show”. The conclusion that I reached was something like this. “Traces” “Request Body” and “Response Body” were assigned to the “persistent” category, and everything else went into the “hide/show”.
The pop-out and close customization is a unique design feature. What inspired that decision?
The central design conundrum for Envy terminal experience is this: how do we present all the information the user wants without creating a cluttered mess. The answer is: only show the user what’s relevant to them. How do we know what’s relevant to them? We don’t have to know; we simply have to give the user the tools to customize our tool according to their needs. This is how I came to the pop-out/close feature. This simple mechanism allows the user to expand or contract the amount of data visible at any time. This gives the user what they want, and leaves out what they don’t need.
![alt text here](https://res.cloudinary.com/formidablelabs/image/upload/f_auto,q_auto/v1712582806/dotcom/envy/Envy_MVP.gif?w=1122&h=720)
What are your thoughts on the state of “terminal design” today?
The terminal development space seems incredibly niche — and also free-ing. There’s a sense that this is a space that cannot be easily monetized, and therefore function and purpose prevail. I’m not an engineer, but I get the appeal of this very off-road space. Having only worked on this project for a short time, I can’t say that I have much perspective on “terminal design today”. I can say that it feels quirky and inventive in a way that the early web used to be. I hope to see more terminal applications that appeal to a broader public.