Thinking in Commands

We have a command line feature that is far along in its development. It is ready for commands.

The goal of this page is to encourage the writing of many commands, and the right kinds of commands.

Why a Command Line?

Why have a command line? Though we live in an age of graphical user interfaces, many developers spend a good deal of their time typing at keyboards. The design of editors like vi and emacs predate the GUI, but these editors are still heavily used today and I'm certain that at least a part of the reason for that is the great keyboard support they have.

Every time I need to reach for my mouse, it slows me down. But, there are only so many finger-twisting key combinations I can remember. Features also need to contend for relatively scarce available key combos, especially when you factor in key combinations used by add-ons.

Plus, let's say that someone wants to create a new feature for developers. Getting a UI together and wiring it up to the rest of the UI is a big task. With a command line, these features can first be exposed and tested via commands with more UI added incrementally as the desired behavior is reached.

One more benefit to a command line: developer tools have a relatively small set of functions that are used all the time, and many functions that are used less often. Screen real estate is not cheap, and many developer tools have giant toolbars and context menus and menus on tabs and other devices all designed to hold the many, many features developers demand. A command line provides a natural place for these secondary functions.

At the same time, commands can be hard to learn and discover. So, Joe Walker built a command line that helps with discovery of both the commands themselves and their parameters. And, it's a command line that is built to handle today's needs, as it can handle more than just plain text.

What Does It Mean To Think In Commands?

When working on developer tools features, work through common use cases for the feature and figure out how you can step through:

• without using the mouse
• instead using commands that are straightforward, consistent and provide the greatest help to the user

An Example

These are not real commands. This is for illustration purposes. In fact, this example illustrates some of the kinds of command patterns we need to work out.

Imagine that I'm looking at this web page. I want to know what font-family is in use on the h1 headings.

highlight h1

This command opens the page inspector with all of the h1s highlighted.

highlight --first h1

This command highlights just the first h1.

style property font-family

The "style property" command can give me information about a CSS property. The "font-family" property name should have been autocompleted for me. The result of this command is the font-family used on the element (ideally it would be exactly what you see when you expand the font-family property in the style inspector's property view).

Or, an alternative,

style property --open font-family

opens the style inspector property view and expands and highlights the font-family in that context.

The Alternative

Without these sorts of commands, I would likely have reached for my mouse to select the element, open the style inspector and switch to the property panel. And, this would have been true regardless of which browser developer tools I was using.

More Resources for Building Commands

Joe has written general documentation for creating commands.

Also cool: the graphical command line interface (GCLI) project can be used in your own projects in web content!