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.

DAB digital radio prototype

The BBC’s Audio and Music’s R&D team are are currently working with Shulze & Webb to prototype Olinda. Olinda is a DAB Radio that as Matt Webb says:

  • “Radios can look better than the regular ‘kitchen radio’ devices. Radios can have novel interfaces that make the whole life-cycle of listening easier. At short runs, wood is more economic as plastic, so we’re using a strong bamboo ply. And forget preset buttons: Olinda monitors your listening habits so switching between two stations is the simplest possible action, with no configuration step.
  • This can be radio for the Facebook generation. Built-in wifi connects to the internet and uses a social ‘now listening’ site the BBC already have built. Now a small number of your friends are represented on the device: A light comes on, your friend is listening; press a button and you tune in to listen to the same programme.
  • If an API works to make websites adaptive, participative with the developer community, and have more appropriate interfaces, a hardware API should work just as well. Modular hardware is achievable, so the friends functionality will be its own component operating through a documented, open, hardware API running over serial.”

The physical radio is being designed and developed by Matt and Jack Schulze. However, clearly to deliver on these objectives there also needs to be a central repository to coordinate the network of friends and their listening behaviour. And this is being delivered by Radio Pop another prototype developed by Tristan and Chris which as Chris explains is:

“At its core is a database which stores radio listening, upon which we can build various views. By introducing friends lists, schedule information and the ability to simply bookmark, or ‘pop’, a particular point in time, Radio Pop generates a great deal of information about listening habits. We purposefully kept the database very simple and specified an input and output API so that the repository could be accessed using web and desktop widgets as well as through the Radio Pop web site.”

Radio Pop

Check out Tristan blog to find out more about Radio Pop and its development :).

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.

Basic organising unit of the web

In Pages are the Problem Khoi Vinh questions the current naming convention of the ‘basic organizing unit of a Web site‘ i.e. a page as in Web pages.

A Web page and a printed page are so materially different from one another that it’s almost ridiculous to use the same terminology to describe them. It’s nearly as counter-intuitive as using the terms “episode” (for a television show) and “issue” (for a magazine) interchangeably.

When Web designers think of a page, we tend to understand that it’s a page in name only, and that in fact its true nature is as a container for content, features and behaviors. But the idea of a page has such a deeply rooted connotation in centuries of printed matter that Web novices tend to think of Web pages as simply finite blocks of text and images, with functionality and interactions as only superficial garnishes.”

As discussed previously it seems to me that we need to design systems that separate the storage, retrieval and presentation of information. And the notion of a ‘web page’ doesn’t help this cause because it infers that is that storage and presentation are synonymous – much like a real paper page in a book. A ‘web page’ implies that a resource is ‘baked’ into a page and published.

In seems to me that rather than ‘web pages‘ we should think of ‘views‘ and ‘resources‘ Where views are like windows onto sets of retrieved resources, so that a single piece of information can be accessed via multiple views. Resources are stored centrally before being aggregated into one or more views e.g. aggregations, contextual views or a canonical view of the resource; and in whatever format is required.

Search for… not visit…

Jakob Nielsen previously (1999) suggested that we are likely to see the end of domain names as more and more people used search engines to find what they are looking for:

It is likely that domain names only have 3-5 years left as a major way of finding sites on the Web. In the long term, it is not appropriate to require unique words to identify every single entity in the world. That’s not how human language works. […]

New addressing schemes are likely to be introduced with better support for ambiguity and the ability to find things without knowing the exact spelling. Search engines and directories are an early attempt, but we can surely do better.

Obviously this hasn’t happened yet – and companies continue to pay large sums of money for domains and advertise their products and services via the URL on TV, posters and radio. And until last night I had never seen anyone try anything different.

But last night a TV advert was run by the UK Department of Transport to help people reduce their Carbon Dioxide emissions. The campaign is called ‘Act on CO²‘ and the advert ended not with a URL but with the instruction:

Search the web for ‘Act on CO²’ for more information”

Which returns on Google, Yahoo the campaign’s site top of the search pile and on Ask, A9 and Microsoft’s Live Search the site in the top few.

This is really interesting. They could have gone and registered a new domain (and risked link rot) or publicised the URL ( – but I guess they realised that its not a great URL to read out (nor remember) and in any case most people will search for it – so why not just reinforce that behavior and tell people to that instead.