A Terminal for the Graphical Age

Nick Mitchell
The Graphical Terminal
4 min readJun 10, 2019

In this article, I will argue that an agreeable reinvention of our beloved ASCII terminals is possible, so long as we are respectful of what makes plain old ASCII so endearingly attractive. This post introduces Kui, a terminal that augments the wizened terminal with CLI-driven visual experience.

In the world of Kubernetes, navigating from list views to detail views is common and awkward in a terminal. Kui renders ASCII tables as simple HTML, allowing for rapid exploration of the list contents.

I am a big fan of simple and fast ASCII art, and a user of terminals since the green screens and VT-100s in the dark and wondrous basement of Evans Hall at U.C. Berkeley. I am also a programmer and part-time designer who has grown weary of the limitations of the 1980s. Yet I, like the legions of developers and systems operators around me, continue to use, with diminished relish, those lovely glowing green characters. In spite of their distant origins, going on 40 years ago, and the constraints of the technology of that time, the magic of ANSI control codes have remained one of the best tools we have for providing a streamlined and highly productive environment.

Pugnacious obstinacy? After all, there are more modern alternatives, such as the browser-based dashboards that seem to orbit around every new tool chain and cloud platform. Kubernetes has its dashboard; OpenShift has its console; Tekton and Kiali do as well; Travis and Jenkins, too. All offer a rich, graphical experience. I am presented with forms to fill, and pleasantly clickable links to facilitate the cumbersome navigational tasks that seem to pervade modern development.

Still, I use them all in a very limited form. Why? I have only a few constraints on my terminal, but they are fairly inviolable. Two constraints are foremost in my mind: 1) a terminal must be fast; and 2) it must be flexible enough so that I can mold it to my needs.

Terminals, and terminal-based tools are fast, generally operating with task-to-task latencies well below the point of human annoyance.

Browser-based consoles are comparatively quite slow. For example, to extract the logs from a container of a Kubernetes pod, you can either use the kubectl command line or the graphical consoles offered by your cloud provider. This is the kind of task that needs to be fast, because it is common to do a bit of hunting and pecking through a variety of logs, before the desired log entries are found.

An unplanned adventure into log exploration with kubectl might easily take 60 seconds of command execution, copy/paste of long auto-generated resource names, mental parsing of YAML output (or ingenious crafting of command line filters), before one arrives at even the first log file. Using a cloud provider’s console, in my experience, is actually a bit faster here, in spite of the inevitable page load latencies one must endure with a browser-based experience; but the task completion time still creeps easily into the 40-second range. This is 40–60 seconds for a task that should be in the fast inner loop of daily development!

Terminals are flexible, allowing me to customize fonts and colors, craft command aliases, custom-tile my desktop with windows and tabs, and mix and match console tools in infinitely complex ways.

If my needs happen to align with the set of scenarios captured by a browser console, my tasks will be pleasantly smooth. If not, I am almost certainly blocked. This leaves us with often over-designed consoles, embellished with enough features (and the tabs stripes and top headers and left headers, etc.) to create a captive audience. Consoles will never do everything, yet face the irony of being too cumbersome for the few tasks where graphics can truly benefit my daily experience; it only takes as long as 40 seconds to get the logs out of a graphical console, because I have to navigate through 3–4 levels of complex navigational structure.

With a plain old terminal, I am not forced into a web designers world of a common denominator. I can create my own.

Q. Are we stuck with ASCII art or slow and inflexible (and myriad!) consoles?

A. I think not. Kui is our answer to this dilemma. Kui is an open-source terminal that offers fast visual assist where it matters, and gets out of the way when decades of enduring goodness is good enough. It is just a terminal, to the extent that you type commands into a prompt, and the terminal gives you back answers. It is a standalone application that runs on your laptop. You have access to your local filesystem and your years of carefully crafted aliases. It is very fast. Task latencies closely approach that of the underlying platform. In response to certain commands, you are provided with graphics, within a few hundred milliseconds. That task of acquiring the logs from above? You can easily accomplish this in 8–10 seconds using Kui.

I think Kui speaks fairly well for itself. See the animated GIF above, and the screenshot and video directly below. In our next blog, I will dive into some examples in more detail. For example, I have recently prototyped support for Tekton pipelines, and will blog about this experience soon.

Coming next: “Visualizing Kubernetes in a Terminal”

The Kui terminal modernizes terminals by adding graphics and streamlined navigation
Kui in motion

Kui came from IBM Research, but is open to everyone. It is Apache-2.0 licensed, and has a powerful and flexible extension and packaging mechanism. Join us on GitHub, or download a prebuilt binary.

The entirely personal views of Nick Mitchell, nighttime hacker and daytime hiker.

--

--