GUIs: the long road ahead

A (moderately heated) phone debate just reminded me of my major issue in the GUI vs text manipulation tool dispute that has transpired from numerous previous musings at other times, which I keep having to rediscover. I decided to write it down this time in order to end the cycle.

My problem with GUIs is that they all blow chunks.

That is not to say that I believe this to be inherent. However, contemporary GUIs are all too obviously created to allow the user to carry out just those operations that the GUI designer foresaw.

Commandline interfaces and text editors for heavy lifting such as vi and Emacs, on the other hand, are rather abstract. They offer powerful and generic tools for manipulating text streams, leaving it up to the user to combine these tools into a chain of actions that accomplishes his task. This way, given tools free of artificial restrictions, it is possible to achieve effects never foreseen by the authors of any of the tools involved.

A trivial, but excellent example is a command like wget ftp://server/disc.iso -O - | cdrecord dev=0,1,0 which downloads an image of a CD-ROM from an FTP server and burns it to disc directly (without even a temporary file involved). How would you do that using a graphical download manager and a graphical burning application? The answer is, most likely, you can’t. The download manager will have to have CD burning functionality, or the burning application will have to support downloading the image to burn from an FTP server. (The latter is, of course, the more likely scenario.) This leads to bloated, bug ridden applications with enormously complex interfaces which still don’t ever quite do exactly what you wanted – jacks of all trades that can never hope to master any single one of them, like the CD burning application whose FTP download functionality will never reach the flexibility available in the download manager.

Graphical interfaces need to be built in a different way from how they’re currently done. The data being manipulated needs to be represented as abstract objects under the hood, rendered by a generic GUI that allows the user to graft any conceivable view onto the data on the fly, and to perform any and all available operations on it.

Like the heavy duty text editors, such a GUI would not be trivially easy to learn anymore, but would be effective and efficient. Like the heavy duty text editors, such a GUI would allow skills and experience acquired on a set of one kind of data to be applied to a set of any other kind of data.

But we’re a long way away from this, and in the meantime, Vim remains King In My World.

Referenced in The sorry state of usability, Grown up and boring.