After the GUI

Some time ago (perhaps five or six years ago) I watched a demo of a new version of Microsoft's Visual Studio. The new version (at the time) had a new feature: the command search box. It allowed the user to search for a command in Visual Studio. Visual Studio, like any Windows program, used menus and icons to activate commands. The problem was that Visual Studio was complex and had a lot of commands -- so many commands that the menu structure to hold them all was enormous, and searching for a command was difficult. Many times, users failed to find the command.

The command search box solved that problem. Instead of searching through menus, one could type the name of the command and Visual Studio would execute it (or maybe tell you the path to the command).

I also remember, at the time, thinking that this was not a good idea. I had the distinct impression that the command search box showed that the GUI paradigm had failed, that it worked up to a point of complexity but not beyond that point.

In one sense, I was right. The GUI paradigm does fail after a certain level of complexity.

But in another sense, I was wrong. Microsoft was right to introduce the command search box.

Microsoft has added the command search box to the online versions of Word and Excel. These command boxes work well, once you get acquainted with them. And you must get acquainted with them; some commands are available only through the command search box, and not through the traditional GUI.

Looking back, I can see the benefit of changing the user interface, and changing it in such a way as to make a new type of user interface.

The first user interface for personal computers was the command line. In the days of PC-DOS and CP/M-86, users had to type commands to invoke actions. There were some systems (such as the UCSD p-System) that used full-screen text displays as their interface, but these were rare. Most systems required the user to learn the commands and type them.

Apple's Macintosh and Microsoft's Windows used a GUI (Graphical User Interface) which provided the possible commands on the screen. Users could click on an icon to open a file, another icon to save the file, and a third icon to print the file. The icons were visible, and more importantly, they were the same across all programs. Rarely used commands were listed in menus, and one could quickly look through the menu to find a command.

Graphical User Interfaces with icons and buttons and menus worked, until they didn't. They were adequate for simple programs such as the early versions of Word and Excel, but they were difficult to use on complex programs that offered dozens (hundreds?) of commands.

The command search box addresses that problem. A program that uses the command search box, instead of displaying all possible commands in icons and buttons and menus, shows the commonly-used commands in the GUI and hides the less-used commands in the search box.

The search box is also rather intelligent. Enter a word or a phrase and the application shows a list of commands that are either what you want or close to it. It is, in a sense, a small search engine tuned to the commands for the application. As such, you don't have to remember the exact command.

This is a departure from the original concept of "show all possible actions". Some may consider it a refinement of the GUI; I think of it as a separate form of user interface.

I think that it is a separate form of interface because this concept could be applied to the traditional command line. (Command line interfaces are still around. Ask any user of Linux, or any admin of a server.) Today's command line interfaces are pretty much the same as the original ones from the 1970s, in that you must type the command from memory.

Some command shell programs now prompt you with suggestions to auto-complete a command. That's a nice enhancement. I think another enhancement could be something similar to the command search box of Microsoft Excel: a command that takes a phrase and reports matches. Such an option does not require graphics, so I think that this search-based interface is not tied to a GUI.

Command search boxes are the next step in the user interface. It follows the first two designs: command line (where you must memorize commands and type them exactly) and GUI (where you can see all of the commands in icons and menus). Command search boxes don't require every command to be visible (like in a GUI) and they don't require the user to recall each command exactly (like in a command line). They really are something new.

Now all we need is a name that is better than "command search box".

Programming languages and the GUI

Programming languages and GUIs don't mix. Of all the languages available today, none are GUI-based languages.

My test for a GUI-based language is the requirement that any program written in the language must use a GUI. If you can write a program and run it in a text window, then the language is not a GUI-based language.

This is an extreme test, and perhaps unfair. But it shows an interesting point: We have no GUI-based languages.

We had programming before the GUI with various forms of input and output (punch cards, paper tape, magnetic tape, disk files, printers, and terminals). When GUIs came along, we rushed to create GUI programs but not GUI programming languages. (Except for Visual Basic.) We still have GUIs, some thirty years on, and today we have no GUI programming languages.

Almost all programming languages treat windows (or GUIs) as a second thought. Programming for the GUI is bolted on to the language as a library or framework; it is not part of the core language.

For some languages, the explanation is obvious: the language existed before GUIs existed (or became popular). Languages such as Cobol, Fortran, PL/I, Pascal, and C had been designed before GUIs appeared on the horizon. Cobol and Fortran were designed in an era of magnetic tapes, disk files, and printers. Pascal and C were created for printing terminals or "smart" CRT terminals such as DEC's VT-52.

Some languages were designed for a specific purpose. Such languages have no need of GUIs, and they don't have any GUI support. AWK was designed as a text processing language, a filter that fit in with Unix's tool-chain philosophy. SQL was designed for querying databases (and prior to GUIs).

Other languages were designed after the advent of the GUI, and for general-purpose programming. Languages such as Java, C#, Python, and Ruby came to life in the "graphical age", yet graphics is an extension of the language, not part of the core.

Microsoft extended C++ with its Visual C++ package. The early versions were a daunting mix of libraries, classes, and #define macros. Recent versions are more palatable, but C++ remains C++ and the GUI parts are mere add-ons to the language.

Borland extended Pascal, and later provided Delphi, for Windows programming. But Object Pascal and Windows Pascal and even Delphi were just Pascal with GUI programming bolted on to the core language.

The only language that put the GUI in the language was Visual Basic. (The old Visual Basic, not the VB.NET language of today.) These languages not only supported a graphical display, they required it.

I realize that there may be niche languages that handle graphics as part of the core language. Matlab and R support the generation of graphics to view data -- but they are hardly general-purpose languages. (One would not write a word processor in R.)

Mathematica and Wolfram do nice things with graphics too, but again, for rendering numerical data.

There are probably other obscure languages that handle GUI programming. But they are obscure, not mainstream. The only other (somewhat) popular language that required a graphical display was Logo, and that was hardly a general-purpose language.

The only popular language that handled the GUI as a first-class citizen was Visual Basic. It is interesting to note that Visual Basic has declined in popularity. Its successor, VB.NET is a rough translation of C# and the GUI is, like other languages, something added to the core language.

Of course, programming (and system design) today is very different from the past. We design and build for mobile devices and web services, with some occasional web applications. Desktop applications are considered passe, and console applications are not considered at all (except perhaps for system administrators).

Modern applications place the user interface on a mobile device. The server provides services, nothing more. The GUI has moved from the desktop PC to the web browser and now to the phone. Yet we have no equivalent of Visual Basic for developing phone apps. The tools are desktop languages with extensions for mobile devices.

When will we get a language tailored to phones? And who will build it?

Microsoft Should Leverage Envy

The low acceptance of Windows 8 (and specifically the "Metro" interface) shows the difficulties faced by Microsoft. The Windows desktop is a popular -- although perhaps not well-liked -- interface, and changes must be introduced at a pace that is acceptable to Microsoft's vast number of customers.

"Metro" is not the first change Microsoft has introduced to Windows. The first change, arguably, is Windows 1.0 with its tile-only, rudimentary display. Windows 2.0 and Windows/286 made some changes, but the next big interface change was with Windows 3.0. After that, Windows 95 introduced a number of changes, including the "Start" button.

All of these changes were accepted heartily by Microsoft customers. (Yes, there were a few dissidents, but only a small percentage of customers.)

Windows Vista and Windows 8 introduced similar-scale changes to the interface, yet received cooler receptions. Why?

I have an some ideas. They involve innovation.

Should Microsoft innovate? Specifically, should it introduce new user interfaces?

I think the answer is "no". Perhaps Microsoft should be a follower in user interface design. Rather than blaze new territory, Microsoft may be more successful in copying other (innovative) concepts.

The success of the early versions of Windows was, I believe, driven by envy. In the mid-1980s, we Microsoft customers knew the DOS text interface, and we coveted the Apple GUI. We really, really, wanted a graphic user interface. (It didn't have to be the exact Apple GUI, but it had to use graphics.)

The competition between Microsoft and Apple gave us advances in Apple's GUI and later in Microsoft Windows. But Microsoft was not the innovator; Microsoft followed Apple, and the strategy worked.

One can argue that Windows Vista and Windows 8 "Metro" are copies of Apple's products. Windows Vista is a shinier GUI with lots of gadgets (or are they "widgets"?) and "Metro" is the iOS interface with a Microsoft twist. Why are these innovations rejected?

I think the reason is a lack of envy. Compared to Windows 7, the Apple MacOS X and iOS GUIs are nice, but they are not that much nicer. Windows users are not envying the touch interface, the sliding icons, and the single-screen apps. The impression I get from Windows users is that the Apple GUIs are nice but comparable -- not superior.

By making Windows Vista a copy of MacOS X and Windows 8 "Metro" a copy of iOS, Microsoft exchanged perfectly good GUIs for different GUIs that while just as good are not significantly better. For users, this means effort to learn the new GUI with no corresponding gain in productivity or social status. It is any wonder that they are annoyed?

I think Microsoft got "Metro" half-right. I think that it is the right choice for their phones and tablets. But I think Microsoft is selling the wrong aspects of "Metro". Instead of pushing the GUI, they should be pushing the easier administration aspect. This is the innovation that people will envy.

For the desktop, I think Microsoft should build a "Metro"-like box that lives in the Windows desktop, complete with access to the Microsoft App Store and easy installation (and updating) of apps.

Microsoft's customers are a picky (and loud) bunch. When they are envious of another company's GUI, we'll know. The trick for Microsoft is to be ready to deliver that GUI quickly. If they reduce the prominence of "Metro" but keep it as an active part of Windows, I think Microsoft will be in a good position.

GUIs considered harmful

It's tempting to create a solution that uses a GUI program. Most people are comfortable with GUI programs and uncomfortable with command-line programs, so they prefer the GUI solution.

The problem with GUI programs (most GUI programs) is that they are not automatable. You cannot drive them to perform a task. GUi programs cannot be (easily) plugged in to other programs. The GUI is the end of the line, designed to be used by a human and nothing else.

The ability to use a program within a larger system is a good thing. We're not omniscient. When designing a program (and thereby automating certain tasks), but we also choose to leave some tasks to the human in from of the GUI.

For example, the task of deleting files (in Windows) can be performed in the Windows Explorer program, a GUI program. I can select a set of files, or a directory name, and instruct Windows Explorer to delete those files. For normal files, Windows Explorer performs the task with no other action from me. but if any of the files are write-locked (that is, flagged as read-only), Windows Explorer will ask me about each file before deleting it.

The folks at Microsoft added a button to the "are you sure about this read-only" file to tell Windows Explorer that I was sure, and that I was also sure about other files marked as write-locked. But this is an after-the-fact behavior, and only comes into play after the first write-locked file has been encountered. (Also, there is no way to tell Windows Explorer in advance that I want this behavior. If one of the files is write-locked, Windows Explorer will trip over the first one.)

The command-line command in Windows to delete files (DEL) on the other hand has options that can remove write-locked files, and you specify them in advance. With one action, you can tell the command-line shell that you are serious about deleting files and don't ask you any silly questions.

Command-line programs can often be used within larger systems. In Windows (and MS-DOS), one can use batch files to execute a series of programs. Unix and Linux have similar (although more powerful) concepts with their shell programs. And all of the major operating systems support redirection to accept input from a file instead of a keyboard.

Not all GUI programs are evil. Microsoft has done a rather good job of usable GUI programs. Their programs are often designed with two layers, a Gui layer and a lower layer that can be used by other programs. Sometimes this layer is a command line, sometimes it is a COM interface. But the work has to be done, the design has to allow for "bimodal" use.

It's all too easy to design a GUI program for the moment, implement it, and lock out any future increases in automated capabilities. A GUI program prevents others from automating tasks and often freezes the developer at a specific level of automation. A developer of a GUI program is in a comfortable position, with some (perhaps most) of the work being automated, and an expensive proposition for additional automation (changing or re-writing the GUI program). Once in this position, the developer ceases to think about improvements to the program -- the program is "good enough" and the developer convinces himself that the remaining work isn't that onerous. This is not a good place to be.

I don't advocate the elimination of GUI programs. They can be effective. But they can also lead to a stifled mental state.