Build a command line option into your next user interface.
Some of you techies may be reading this and thinking, “Yes! I live in a command window all the time on my computer.” Well, I’m not really thinking about you as my target audience. I’m talking more about applications used by everyday people outside the IT industry.
Hear me out.
This concept first hit home for me some years back while working on a content management system. My team had built this shiny, new GUI with a backend database for managing user education content. The GUI was quite extensive, with a main screen plus many dialogs for maintaining the assets in the system. A number of teams across the company used the system quite effectively. But then we needed to on-board a new team habituated to an existing system that used a local source control system, an XML editor, and a command window. Commands were entered to do things like check out a topic, open a topic in the editor, and view source control history.
The new team began trialing our nifty GUI-based system, and we very soon heard complaints that the team’s productivity was going to take a big hit once they adopted the system. And for this team—who were always under the gun to get content updated and published—productivity was a huge concern.
It took me just a few minutes while sitting with a writer from the team to totally understand their concerns.
In the previous system, they could have a topic checked-out and open in the editor in seconds just by typing a single command. Using our GUI, the steps necessary to accomplish the same goal took quite a bit longer: They had to navigate a hierarchy tree to find the topic, followed by separate steps to check-out and open the topic in the editor.
Now you may be thinking that the GUI had to be simpler to use than remembering many sets of command syntax. But remember, we’re talking about folks that worked with their content hour after hour, every day. It was nothing for them to memorize the syntax for a set of commands since repetition leads to memorization.
I ended up getting approval to build a command line interface option to the system run from a Windows DOS command prompt. The set of commands started out small, focusing on core functionality. But the library grew significantly as team members started using it and liking it. They just kept begging for more! The GUI lived on of course, as it did offer the complete set of features for the system. But, it was amazing to see how popular the command line interface became with our users.
Long before GUIs became mainstream, command lines were king. But even after GUIs came along, some command line interfaces survived and are still alive and kicking today. One of the most prominent and heavily used applications that still rely on a robust command line interface is Sabre, the largest systems provider for airline bookings in North America.
If you’ve ever travelled by air in North America, you’ve probably been on the other side of the airline counter from a customer service representative using Sabre. Now think about it—was the person using a mouse and clicking around the screen? No, they were using the keyboard, typing away like crazy and being very productive in getting to the data and information they needed to help get you on your way.
Why does a command line interface work so well in the case of airline reservations? The reason is that the airline customer service representative uses a relatively small set of commands over and over again, to the point that they have memorized the syntax for these commands. With the command syntax memorized, it is faster and more efficient for the person to let their fingers fly over the keyboard to interface with the system.
Here is an example. The screen shot below shows the following command:
If you break this down, it is an inquiry command to look for flights on the 12th of November from Cleveland (CLE) to Orlando (MCO). (I’m not positive what the 07A represents but I would venture a guess that it means to look for flights departing around 7AM.)
Now compare this with a GUI (see screen shot below) to accomplish the same inquiry. Think about how you must use the keyboard and mouse to interact with the UI elements presented in this dialog. There is no way you can interact with the GUI faster than typing at a command line.
To be clear, we are talking about how effective a command line is for a frequent system user, not the casual consumer looking for flight schedule information. The GUI is no doubt the best interface option for a consumer to find flights, but for the airline customer service rep that searches for flights hour after hour each day, the command line option is going to be a more efficient interface, hands down.
Another example involves a less technical user group: horse show secretaries. I’ve been involved with horse shows—managing, competing, and judging—for a number of years. Being one of those IT guys, I’m always interested in the software used by the show office. I’ve seen some systems that I thought were very non-intuitive for a novice user, but I attribute that to my critical eye when using any software product.
Here, as with airlines, there are scenarios that would be well-served with a command line option. For instance, one of the most common things a rider will do in the office is to add or drop a class.
A typical situation is that a rider will come into the show office and say something like, “My trainer told me to add class 126, and it starts in 20 minutes!” The show secretary will instruct the rider to fill out an “Add/Scratch” form: The rider writes down their horse’s entry number, the class number, and circles the word “Add.” Similarly, to drop a class they use the same form, supply the same information, but circle the word “Scratch.” The rider drops the form in a basket, heads out of the office, gets on their horse, and hopes the show secretary processes the request before the class starts.
Now, if the show secretary was not busy when the rider came in to add the class, she could have just done the work right away, but it is rarely the case that the secretary at a horse show is just sitting around looking for something to do.
If she is busy doing something else in the system, you can imagine there would be a number of steps to perform to close out the current dialogs in-use, then bring up the screen where a horse can be added to a class. But what if, with a keyboard shortcut, the show secretary could pop into a command line and simply type
>add 57 126 and press the Enter key? In this case, the command would result in horse number 57 being added to class 126. A scratch could be just as simple
>scr 57 126
Below is a screen sample that shows a command line option built into the GUI of a popular horse show management system (see lower-right section of the screen). Adding and scratching is a very common function executed by the show secretary, so memorizing the syntax for add or scratch would happen very quickly. With a command line option, regardless of where they are in the system, they could quickly drop to the command line and execute any number of common functions.
A key tenet of a command line option in an application is that the commands and their syntax must be simple and intuitive. In the above example, you are adding a horse, represented by a number, to a class, also represented by a number. So the syntax is very simple and easy to remember.
You really have to look for the right functionality to offer a command line option. Two basic questions can be asked:
- Is it a commonly used function?
- Are there a small number of data elements necessary to accomplish the task?
For example, here is a dialog (see below) to add a horse into a system. Clearly, this task would be best accomplished with a GUI since there are far too many data elements involved with getting a horse into the system. Memorizing the command syntax would be impossible. Also, horses are typically added before a show starts so this function would be classified as non-common, especially once a show has started.
As I mentioned, I also judge horse shows and I built an application designed to be used by show jumping judges. I hadn’t thought about adding a command line option to my application, but then I really started thinking about some common tasks that would be excellent candidates for a command line. The judge is not only keeping track of results for each horse/rider, but may also be operating the timing equipment and may even be announcing over the PA system. That gives the judge little time to do anything that would distract them from their core responsibilities.
I’ve spent hours tuning the user interface in my application to be very intuitive and easy to use but this means that some functions will be buried on a screen that takes a couple steps to access when needed. So I started thinking. What if I had a command line always visible and quickly accessible where the judge could type in something like:
>view ss 175
This could quickly open the score sheet report for class 175 in a browser window. After thinking about it some more, I came up with 16 functions that made sense to offer as a command line option. All the functions have very simple syntax and helps the judge execute items quickly. Here is a screen shot of my judging application with the command line at the bottom of the screen.
Seems I’m not alone in my thinking here. For all intents and purposes, a command line has appeared atop the ribbon bar in Office 2016 apps. The Office team has named this the “Tell Me” feature. The feature is described on this blog post:
Tell Me is an entirely new way to find the commands you need. Just type what you want to do in the Tell Me box at the top of Word, PowerPoint, Excel, and Outlook, and you will get a set of results that let you take the desired action directly from within those results.
In any Office 2016 application, you press Alt-Q to get your cursor right in the Tell Me box. Once you use this new feature, you’ll see that it really is a command line on steroids, but it does serve the main purpose of providing quick access to certain functionality.
In conclusion, I hope this gets you thinking about the user interfaces you’ve designed in the past and ones that you’ll design in the future and ask yourself this question—is there some functionality where a command line option would be beneficial to your users?
Command lines always scared me, but having used them with jumper judging I wouldn’t go back to doing it any other way. I can have it done by the time the horse has come through the in-gate. Fast, efficient. That’s how we like to roll in judging circles. 🙂
Good insight! I have seen Airline booking folks even in travel desks of companies furiously typing it out instead of using GUI. I used to think this was to ensure that the system worked with even low connectivity needs but there is more to it 🙂 Thank you.
This article is very timely for me as I am designing an interface to be used by a relatively small group of people on a regular basis and have designed a sort of interactive command line for adding products to a basket. The command line is then backed up by a traditional e-commerce interface below for novice users.
No way is this a crazy idea. Been in this game a long time and for speed you can’t beat cmd line, green screen interface. We recently built an editor – based on material design etc and guess what, half the users switch to the code editor. Now I know this isn’t the same as cmd line but people just want to get things done as quickly as possible. How about we just make forms easier to use? How about we use more natural language in our interfaces? Like this http://www.jroehm.com/2014/01/ui-pattern-natural-language-form/
This is not such a crazy idea as you may think. I started working with computers during the DOS 2 times. GUI was the shiny thing back then, and I used to ogle at the Macs in magazines. However after using the GUI for a long time, I found it easy to type the name of the program I was seeking in the Ubuntu Unity interface. That set me thinking about a natural language command line interface to execute commands. The more I think about it, the more I am gravitated towards it.
Like some of the other readers that have commented, I don’t think this idea is as crazy as you/one might think. I haven’t been a heavy CL user but that’s because I’m pretty new to this technical computer stuff (however, I am slowly starting to use it more and more often).
So, even though I’m a fairly light user I do understand the efficiency gains that come from memorizing common commands to get repetitive things done – now that I think of it, I don’t know why more developers (& designers) don’t implement a CL into their products (even if it’s sort of hidden away from the average user). I think it might have something to do with the creators not completely using their own products, so they don’t fully understand the wants of their loyal/frequent userbase maybe?!,
Soon you’ll be finding that your IT people are calling the shots and that a healthy portion of the backend no longer has a GUI.
P.S. When you go with standard (or maybe the word is ‘popular’) cms’s, the UI and most everything else ought not to be so hard to follow. Maybe the problem was a DIY approach.
Comments are closed.