Graphical command lines

Bruce Byfield speculates that:

The average computer user is no longer interested in exploration, but in getting their daily tasks done with as little effort as possible. For many, changing word processors is a large step, let alone changing interfaces. And both Windows and OS X encourage this over-cautious clinging to the unknown by hiding the command line away and promoting the idea that everything you need to do you can do from the desktop. The truth, of course, is that you can almost always do less from a desktop application than its command line equivalent, but the average user has no experience that would help them understand that.

Clearly there is nothing inherently wrong with users wanting to use their computers to get their daily tasks done, after all, for most people computers are little more than tools. Tools to be used to achieve something. It’s also true that the command line – the Shell or Terminal – provides a much quicker interface for getting the job done. The question then is why don’t more people use the command line not less? Bruce suggests that:

The truth is, learning the command line is like learning to touch-type: in return for enduring the slowness and repetitiousness of learning, you gain expertise and efficiency. By contrast, using a graphical desktop is like two-fingered typing: you can learn it quickly, but you don’t progress very fast or far. To someone interested in results, the superiority of the command line seems obvious, but, when instant gratification and fashion is your priority, the desktop’s superiority seems equally obvious.

I’m not so sure its that straight forward. Sure to touch type requires learning, but at least the keys are all there, exposed in the interface so to speak. You don’t have to memorise what the keys are or how to use them. With Unix you need to memorize the command names, since they are not easily discoverable through the interface – and once you’ve done that – you need to remember the command’s various options. How do I go about untaring a gzipped file again? ‘tar -xfvz’ silly me!

The reason that less people are using the command line is because, although its quicker and more efficient, the commands aren’t memorable and the syntax is brittle and unforgiving.

Graphical User Interfaces leave behind the power and versatility of language – an icon or menu isn’t as powerful or flexible as language. And the dominance of Google is evidence of this. Google lets you simple ‘find what you want’ whether that’s a thing, parcel, stock price, answer to a calculation, or whatever. Google is so much better at doing this sort of thing that I don’t bother using Bookmarks for public website anymore. And nor is this functionality now restricted to the web – both OS X and Vista now come with powerful, integrated search engines. With the addition of a little metadata I don’t even bother ‘filing’ documents anymore – I just search for them – its much quicker.

But “typing what you want to find” isn’t “typing what you want to do”. However, for Mac users at least, this is also possible with applications like Quicksilver.


Quicksilver is a sort of hybrid GUI-Command Line interface. It gives users the advantages of a Command Line – speed afforded by direct input via the keyboard and the power of language – with the advantages of a GUI – visual, exposed options. This means that not only does Quicksilver lets you open an application or file by typing its name but also giving you direct access a wide range of other commands: emailing a selected file, tagging a file with metadata, skipping a song in iTunes, moving or renaming a file.

Interaction designers have largely ignored this hybrid interface (with some obvious notable exceptions) – which seems a shame since when it is used – it provides a wonderfully speedy and intuitive interface.

Google Mashup without the map

James and Joe are using the Google Maps API to give users a novel interface to explore a portfolio of work; rather than using it to provide a mapping interface. This is interesting not just because of what James and Joe have done, but also because it demonstrates an alternative use of the Google Maps API. Bravo!

Google Mash-up without the masp

As with all Google Maps – the interface allows users to pan and zoom – as well as adding push pins with additional information – text, images or video.

Wabi-Sabi – Design to age

We’ve recent returned home from camping in France, along with a fairly large number of caravaners. I mention this because I noticed that caravans and campervans don’t appear to be designed to age gracefully. I’m not talking about whether or not they are ‘design classics’ but rather that they aren’t designed to easily allow user modification nor to keep their looks as they age and pick up the inevitable scratches, nicks and general wear and tear. They appear to have only been conceived up to the point of sale – working on the assumption that they will remain perfect forever – with no apparent thought for how they will be affected by use. That’s just silly. Stuff should be designed to take into account general wear and tear.


The Japanese have a useful concept to encapsulate this idea – Wabi-sabi (侘寂). Wabi-sabi acknowledges three core principles: nothing lasts, nothing is finished, and nothing is perfect. In other words aesthetics is founded in the acceptance of transience – that beauty is in the imperfect, impermanent, and incomplete.

It seems to me that the same ideas should be applied to our technology products. Too many of our technology products are designed like hi-tech caravans. Lovely and shinny at the point of sale (not that caravans are lovely, but you know what I mean!) – but they don’t stand up well to wear and tear, and they don’t let users easily modify the system to work the way they want to work. They appear to have been designed without thought for how they will age nor how their users might wish to hack the system – to womble – to use the system in unexpected ways.

For software products this means designing small components loosely joined together by a lightweight framework, that support open standards, protocols and APIs; with interfaces that are simple yet flexible enough for users to create their own journeys and workflow.

But Wabi-sabi also tell us something about how to build software. The acceptance of a state of ongoing imperfection implies that attempting to design a solution upfront will be doomed to failure. Instead we should embrace the idea of the perpetual beta, evaluate what works in the real world and modifying the system as a result.

Photo: Stone Tiles, by abundanceguy. Used under licence.