What’s wrong with GUIs

GUIs are so pervasive in today’s computing and development environment that some people have never seriously used an alternative method of interacting with a computer.

Yet I see so many places where the GUI is inappropriate and just plain counterproductive.

When developing a system, I do everything I can in an emacs shell.

Apart from the advantage of the powerful editing and searching facilities available, the biggest advantage this gives is in capturing a time ordered history of stimulus and response.

While experimenting and/or learning with a system under development, you are going to try a bunch of commands. Having history there means you can search back through results for things of note, snarf a chunk of output and filter it to hide the chaff, or sort it, or post-process it into a formatted report, or plot it in a graphic, or whatever.

This is especially powerful for working with dynamic languages, where you interact with your system as you are extending it. Once you’ve achieved something significant, you can simply cut and paste the command sequence into a permanent script, or a makefile, or whatever.

And not least, you also have text you can paste into a buffer for documentation. You may need to provide information to co-developers, or customers. Or you may need to do the same or similar thing in a week’s time. I any case, you can just look at the transcript doc to see the detail of how it was done.

I’ll often issue the odd ‘date‘ command during the interactive process, just to give some documentation on how long something took to run or how long it took me to work something out.

To do the same things with a GUI, you would need a lot of screen captures, or you need to write some inane sequence like

select menu blah, in the dialog check options blah and blah, then press button blah, then select menu blah…

Although the problem with that is the danger of missing a step or getting something out of order. So to do it properly, you really need to video capture the process.

I can’t stand videos when a text document would suffice. You see more and more of this now on everything from news sites to on-line tutorials. You go to a web site, and even if the item is technical, there is a good chance that the link is for a video of a presentation, complete with annoying ums and aahs and errs… It’s beyond me why anyone would prefer this to a text.

And the plain audio transcript is just as bad. Sure, it doesn’t waste as much bandwidth to download, but it still wastes time to listen to. That might be fine for entertainment, but it’s a waste of time for documentation.

Now, please note that I didn’t say I don’t like graphics, and I’m not saying that a high res display + mouse isn’t a boost to productivity. For sure, graphical presentation can be very helpful in visualizing data or processes.

The problem I have is with the current obsession with using a graphical metaphor everywhere, which means for processes which are far more efficiently handled with simple text.


8 Responses to What’s wrong with GUIs

  1. fyngyrz says:

    Completely with you. I’m working on a knowledge base system right now; GUI would totally be in my way. I do it all in a shell on my Mac; closest I get to a “GUI” is midnight commander to throw files around and pick which ones to edit.

    Not only that, but as far as GUI’s go, there is far too much emphasis on “pretty”, and not nearly enough on “functional.”


  2. […] lire sur le sujet quand on est développeur: What’s wrong with GUIs sur le site https://crustyoldfart.wordpress.com/ convert this post to pdf. Partager : Ces icônes […]

  3. maleesha says:

    My daily job is done in vim via PuTTy. It’s a lot faster than what I would do with a GUI. I think GUIs is what made computers “for everyone.” I think with video and audio and flashy ads and this and that, it’s a little overkill.

  4. Marat says:

    To your comments about video documentation/tutorials:

    Being a computer programmer and knowing my way around the computer world I like video tutorials. Yes they take a bit longer to complete the task than reading, yes they use up more bandwidth, but what you have to realise is that 90% of people out there wont know where to start looking if you told them to go to View > Options > Advanced tab > Tick blah etc.

    But when they have a video tutorial explaining it, they can quickly and easily see exactly where to go and click. All they do is follow the mouse pointer, it goes into the top right hand corner, they follow. Some tutorials are more professional than others, but you really have to be pretty bad to make one that people won’t understand.

    In a world where everything is about more interaction, where websites these days aim to make users feels as comfortable as possible, video tutorials just really seem the way to go. Image having to complete a tutorial with 50 or more instructions (like some Photoshop tutorials) using just text. You’ll be spending half your time looking for the next button to click, slider to move and not to mention remembering what step you’re currently on.



  5. NikSan says:

    Hmmm… I agree that the graphics or the visuals are used in places where just text could work. There are some people who like to think the users as dumb, lazy people who would not want to read or process & understand the data for an action needed. Some people over-do the Usability thing and want everything represented in most easy way to understand.

    While trying to achieve this, they forget that they actually are making things complicated! I think we need to give the usage of graphics or any visuals used a re-thought and make things really Usable!

    Nice article 🙂


  6. Rob W says:

    Of course, a command-line interface presupposes an entire body of knowledge that you must have more or less *memorized* to be effective in any way. For people unaccustomed to them — read, almost everyone — command-line apps are dangerous (any non-trivial command is mostly opaque) and horribly inefficient (once you factor in the time to learn the interface and develop the attention to detail that entering your commands *perfectly* requires…). If you started up your dishwasher and it popped up a “dish” shell that was completely proprietary (and of course, all of the commands are dishwasher-related… and let’s say commands are submitted with *… enter will terminate the app) you wouldn’t be happy.

    Your point is still good… I’m just disagreeing with the solution. GUIs do exist for a reason — largely to make the options visible with minimal prior knowledge, and to allow for much more complex *state* handling — but the “transcript” aspect of text-based interfaces is one of the sacrifices.

    One stab at a solution: Photoshop’s history pane and undo implementation… each action you take on your project is listed in the history pane, and you can undo a whole chain of actions one at a time if you want. The transcript is only partly there (since the action in the list isn’t sufficient to know exactly what parameters etc. you used) but you *gain* the undo-redo that you don’t have in a command-line app (e.g., you can know exactly that you mistyped “rm *.o” as “rm * .o”, and when you did it, and the output — huh, .o not found. oh wait — and even how long it took, but you can’t undo it).

    I can imagine a framework for GUI apps that maintains a text transcript (possibly visible as you manipulate the GUI), that can be replayed or researched as required… w/ a command-line interface as well to let expert users go the fast way (direct command entry) once they’ve learned the system. With a library of possible commands, also, you could have type-ahead options, plus explanations when current application state doesn’t allow a given command, etc..

    Has anyone run across hybrid systems like that? There’d definitely be some overhead to linking every possible GUI action to a CL command, though — I imagine the value just hasn’t been enough to justify the work for the vast majority of applications.

  7. I think things are actually improving: Command-line-like user interface elements keep cropping up in GUIs. In the end, I think it comes down to the user interface being a database of its own (what commands are available? what can they be used for? what happened while I was away from the computer?) and that for getting to data, nothing beats query languages. I’ve written up some of my thoughts:
    “Semantic-Web-Backed GUI Applications”, Axel Rauschmayer

  8. I enjoyed your writing style and I’ve added you to my Reader. Keep these posts coming.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: