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

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.

Design for wombling

In the 1970s the Wombles were Britain’s great engineers. They designed, built and fixed stuff by focusing on what was available and what worked, rather than using the proper stuff. There are lessons here for both software engineers and interaction designers.

Take Backpack. One of the great things about Backpack is that you can easily use it to do so many useful things and it neatly fits around your workflow rather than making you work around its workflow. And I bet that the 37Signals designers never imagined all the ways people might use their applications – and of course they didn’t need to, they just needed to design a system that let people womble. To work the way they want and support them in doing so.

The advent of SMS messaging is an even more stark example. According to Cor Stutterheim from CMG SMS wasn’t even designed for customers:

It started as a message service, allowing operators to inform all their own customers about things such as problems with the network. When we created SMS (Short Messaging Service) it was not really meant to communicate from consumer to consumer and certainly not meant to become the main channel which the younger generation would use to communicate with each other.

But because it was reliable, flexible, convenient and cheap the technology was repurposed and used by mobile ‘phone users in their millions.

SMS was the triumph of the consumer- a grassroots revolution that the mobile industry had next to nothing to do with and repeatedly reacted to. This is in stark contrast to the top down technology and industry led approaches to other nonvoice services such as WAP. (ref)

And away from consumer products we have the ubiquitous TCP/IP. Although it wasn’t designed to support the Internet as we now know it TCP/IP is the backbone for much of our social and business life. TCP/IP is able to be flexible and useful because the hosts and not the network are responsible for reliability. The network only enforces interoperability. This means it’s possible to join almost any network together, no matter what their characteristics. In other words its extensible, scalable and decentralised.

As Nick Gall in the Podcast TCP/IP and Shipping Containers argues if you want a system that is extensible, scalable and decentralised you need a solid, but basic underlying architecture. Too much architecture in the framework, and you’re locked in, without sufficient freedom. Too little, and you have neither interoperability nor room to improvise. In other words the users of the system can’t womble.

The balance between simple, formalised, underlying structure with a high degree of overlying freedom is critical. Too little structure and you are left with an inaccessible, chaotic system. Too much structure and you have a rigid product that can’t be easily molded into something else.

So what are the characteristics of systems that Wombles will be able to use in unexpected ways? I think they include:

  • Independent subsystems tied together by a light weight, solid framework
  • Defined and enforced interoperability between subsystems
  • Platform neutrality
  • General purpose simple interfaces
  • Flexible user journeys and workflow
  • Accessibility
  • Open standards, open source, open protocols and open APIs
  • Data neutrality
  • And designed to respect that the data belongs to the user not the system

But I also suspect that the system itself can’t be built be ardent Wombles. If the system has be cobbled together then there’s a risk that it will lack the flexibility and structure necessary to allow its users to Womble – providing the light weight but solid framework may prove too difficult, or enforcing interoperability too cumbersome.

Photo: Flickr Hack #1 by Thomas Hawk. Used under licence.