GUI vs CLI: Operation vs Expression
blog.vivekhaldar.com
blog.vivekhaldar.com
Software seem too malleable to me to characterize it in such broad strokes.
We are not talking about end products of this communication between computer and person, its output which could be images or software you created with the computer and which also allow you to express yourself in the more broader sense.
Of course, I'm drawing graphs and geometric objects, not trying to do "photo work" - but CLIs can be an excellent interface to some kinds of graphics.
By the way, there are some great CLI tools (like ImageMagic) to manipulate images from the CLI and these are indispensable for batch editing large collection of images and other applications (image analysis), but I was not referring to that.
Zillion lines of text scroll by
swear
>man paint | less
go through 10 pages of text before finding the /pickcolour command
>paint /pickcolor /x 123 /y 843
how the pixel position was found is left as an exercise for the reader
option pickcolor not found
curse and rerun the man and scroll through all the pages again
realize it's /pickcolour and not /pickcolor
>paint /pickcolor /x 123 /y 843
red gets selected
after more furious rtfm'ing and Bing'ing(on Lynx of course), realize pickcolor uses coordinate calculation from the bottom right and not top left
When you need to do this again in a month, forget the command and the spelling and repeat all of the above again.
Anyone can pick examples that make the discussion go nowhere. That's why this discussion never feels like it makes any progress.
That's my point - just because it's the wrong tool for some hyperspecific job doesn't imply anything useful in general.
But if you really want to pursue the analogy, we could in fact come up with a command line that selects the green color value from a certain area of an image a lot easier than one could edit a non-image file using MS Paint (though I've seen that done too).
GUIs can be and are widely used for expression. I already listed many examples that touch on wide array of human creativity and creation.
I’m not trying to bring down CLIs. I take issue only when people claim that GUIs are not for expression.
Why does Photoshop have to be good at word processing in order for it to be a valuable tool for expression?
But Photoshop is an example of something that's particularly good for the GUI. It's not representative of most things that people do when they're interacting with a computer.
GUIs and CLIs are for expression.
He pushes this topic by talking about Unboundedness vs Boundedness and Internalization vs externalization. What he seems to fail to realize is that internalization and unboundness are not properties inherent to CLIs nor is externalization and Boundedness inherent to GUIs. Those properties are a function of how you designed your application and user interaction not the medium by which it is accomplished.
But in those programmes, the GUI is more like a keyboard of a CLI than the actual programme. The GUI controls are used as tools to use on the main area, the drawing area. A graphical programme like photoshop presents you with a massive empty whitespace for you to draw in. It doesn't tell you where to draw, or what colour to draw. It allows you choose any colour you want. Once you paint some red, you can then paint any other colour.
In this way the programmes you list confirm the "unbounded, "lack of constrains" and "newbie unfriendlyness" of the CLI.
A newbie doesn't know what commands to type into bash, and they don't know what colours to put down first in photoshop.
It is just not an apt analogy if it requires you to claim that Photoshop is more CLI than GUI. That’s so freaking absurd.
Well, I guess I should have picked up on that when reading your last paragraph where you imply that everything that’s hard to use is also a CLI.
I’m not trying to bring down CLIs here. What I don’t like, though, is how the author of the article tries to bring down GUIs to prop up CLIs. That’s just not necessary. GUIs are used by so many people to express themselves and it’s patently absurd to claim otherwise.
Long ago I used Autocad regularly for work. When someone gets really productive with it they tend to use one hand on the keyboard for selecting menu items and typing short CLI commands and the other for picking points and dragging selection boxes.
That kind of interface really does attempt to combine the best of both worlds, but at the expense of a big learning curve.
I'm sorry but the basic premise of GUIs being limited and CLIs not is just completely wrong.
Plus the underlying reactive dataflow model is like a limited mathematical language. The gap between GUI and CLI is short here. So even without relying on text, you still can build operators (Houdini does this to a great extent, even the skeletal system is build out of user-level geometric primitives)
Some software that took the growable GUI a step forward is Luxologic Modo, here GUI tools are combinators that you sequence in a `toolpipe` to suit your needs, kinda like building a function out of lower level ones.
I agree with jpalomaki (http://news.ycombinator.com/item?id=3154076) there's room for different and more linguistic GUI.
To finish on a blurry note : text doesn't exist, bytes lead to intepretation/action aka a function of the application model, I see no real reason that visual interactions can't be made 'linguistic'
But is a Photoshop-like GUI the best UI for anything else?
Furthermore, don't some of those high-end packages you listed include a CLI component too?
It isn’t. Why should it? Is a hammer the best tool for anything but hammering?
“Furthermore, don't some of those high-end packages you listed include a CLI component too?”
I’m not sure how that’s relevant. I have no issue with CLIs or the way the author characterizes them. CLIs can be wonderful tools.
It'd probably be useful to pick some other examples to discuss.
Things that humans create with software:
– Text
– Images
– Sound
– Video
– Algorithms†
All those elements can be glued together in different ways. Images and text, for example, can be glued together to create a magazine or newspaper layout. Text, images, sound, video and algorithms can be glued together to create a video game. Separate software for gluing stuff together is quite common. (You don’t really write and edit texts or edit images with InDesign but you bring texts and images together.)
Maybe I’m wrong about this but it doesn’t seem to me as though GUIs are the exception or a special case. They seem to be quite common.
—
† I’m not sure about this one. I think it deserves an extra category even though most people use text to create them. It seems wrong to me to put novels and algorithms in one category, it would be a disservice to both.
There are different ways of looking at this. In some way video and images are one and the same – you get video from glueing images together. It seems, however different enough to deserve its own category. Algorithms seem similar to me.
Maybe you can help with this, the author certainly didn't.
Let me try:
Firefox vs. Lynx
IDE vs. makefiles/make/compile
Word. vs Latex
Excel vs. ????
Outlook/Gmail vs. Pine?
Does one of those encourage expression over operation? Probably the closest is Latex, but still I don't see how it would be more expressive than what someone who spends equal time learning Word would accomplish with Word.
Because Lynx (except for its dump mode) and Pine address characters on the screen in two dimensions, I consider them to be graphical programs. They are just very limited graphics. There is a difference between a program which displays text on the screen and a program which prints its output to stdout.
Now, a lot of what I do is adding (and tweaking!) effects and filters bound to shapes, selections (most often based on shapes) and layers, it would be harder to create an efficient CLI to _draw_ arbitrary shapes, but I don't used Photshop for that anyway.
1) Design a nice DSL to express whatever it is you want your users to be able to command.
2) When you build the GUI, have all the gestures correspond to a particular DSL expression.
3) Add a shell where the user can type arbitrary expressions in your DSL (and for that matter, load files with DSL commands and execute them).
You're done. People who want a GUI have one, people who want a CLI have one, and there's a nice clean upgrade path from the GUI to the CLI. In fact, that's where this approach really shines: when a GUI user decides he needs to automate something, you can give him a single clear expression to type for each gesture he's used to making, and at first he'll probably just memorize those and use your product in exactly the same way with the CLI as with the GUI. Once he gets used to the CLI itself, he'll probably start tweaking the basic expressions you gave him and eventually feel comfortable enough to write his own. It's a nice security blanket for people who are basically learning to program to have a set of magic spells they're confident they can use no matter what.
But the argument here seems to be that forcing users to use the CLI will make them use the more powerful features that they won't otherwise use with a GUI that's good enough for them. Or something like that. The useless analogies in the article don't help.
That's my point - in my book this is a solved problem. The GUI vs CLI thing tends to be a religious argument, which (in computing) always means that you actually want both.
I agree the original article is pretty nonsensical, I was just trying to prevent my having to read an overly familiar argument again.
[1]: https://github.com/greboide/emacs-gestures
Coincidentally, I don't see how Emacs is a CLI program, even if it does have a text-only mode: the text-only mode just draws the GUI elements with text the way other programs draw them with pixels. Of course, it's a tool heavily optimized for power users, but that's a different story.
And that from what seems like a trivial change, just a single extra degree of freedom; one that most find just an annoyance. To bring it back around, it's possible to bridge the gap, providing a powerful and easy-to-use interface. But it will probably mean a lot of your users asking rightly, "But couldn't you just do that for me?"
The appropriate answer is something like, "Yeah. I could also just go to the store and get your groceries for you, and you'd never have to leave the house. Do you want to be cargo, or do you want to drive?"
If you're missing this aspect, musical instruments (to take one example that I sometimes wonder about) can easily seem designed to be "hard" to use. Compare a computer keyboard, with its clear labels, to the (to a newcomer) totally opaque grouping of the keys on a piano.
Now, I still think the keys could be labelled without any threat to the possibilities of expressing one's creativity, but it's a bit less annoying, having read this. :)
As a teaching tool, labeling can work for both, but as a crutch for people who are less than proficient, labeling does not work well for someone trying to play the piano. There's a greater need for getting to a certain level of proficiency if you wish to play the piano than if you wish to use a keyboard.
http://www.newegg.com/Product/ImageGallery.aspx?CurImage=23-...
But I learn to touch type with a regular keyboard.
Or should it say that we don't yet have good enough GUIs that allow combination at will, to create new behavior? I don't think it is correct to say that this is impossible.
It's difficult to image what this would mean for GUIs, but maybe we could get some ideas from the DSL stuff for example Microsoft and JetBrain were doing some years ago.
What I think is going on is that people are rationalizing the way they work and also, and this is the main thing, rationalizing a general feeling and stigma for programmers associated with A) using a graphical interface and B) doing anything that isn't inside a terminal and/or classical text editor window. "Real" programmers use bash and emacs/vim/TextMate or whatever. If you're not editing textual source code, you must not be programming. If you're not programming, you're not a real programmer.
I think this is the primary idiocy holding back not only software development but also quite a lot of potential business productivity gains from custom software.
What is programming? Is it wiring up vacuum tubes? Punching cards? Entering assembly code? Manipulating pointers? Generating Rails apps automatically from the command line? I think that programming shouldn't be limited to ASCII text. People who think that should educate themselves about things like knowledge representation and reasoning, components, program generation, dataflow, structured editing, intentional programming, anything Jonathan Edwards put out, etc.
TLDR: you're a bunch of retards. BTW contact lenses were invented in 1887 and MacBooks are completely overpriced.
TLDR2: the number 1 and number 2 things holding back software development are source code and CLI.
A CLI could easily just be a set of five commands with no options that are roughly orthogonal. There is not much potential for constructing powerful, expressive commands, nor much of a learning curve. Just memorize the list. On the other hand, you probably don't need to look far in this thread to find an example of a GUI that allows powerful combinations of commands/effects/etc.
Depending in the design of the interface, there can be different degrees of combinability. I think the main point of the article should be (if it isn't) that what degree you want depends on the domain the interface is for, whether it should allow an infinite variety of actions.
Apparently this got lost in his stereotypes. By CLI he meant roughly Unix, and by GUI he meant a point-and-click GUI. There are many more possibilities in between.
CLIs can benefit from autosuggest, a lot. I don't want to type too much or risk making typos. So they should suggest the legal choices, and order them by most common first (or maybe alphabetically). For those who don't like the autosuggest popping up automatically, you'd have a setting to establish a key combo to bring it up. Also, it's nice to underline possible spelling mistakes, and be able to hyperlink words to lists of related locations when I click on them.
Meanwhile, GUIs can include a "drop into CLI mode".
If we have a GUI that has a CLI mode with autosuggest, I would think this is the best of both worlds. Often times, I just want to design a COMPONENT, and then go right back to using the GUI.
'Physical' doesn't seem to quite capture the distinction he's after.
He uses a guitar as an example of an interface where you can combine at will, and it's a physical interface.
And because they're better at this, they're more useful than GUI's in many cases.
/joke
I don't know where to start. Sure, training people in Latex will eventually make them churn out better looking documents than Word, but the initial training costs and learning curve are going to be really high for the average office worker for who Word with the ribbon is overkill.
I am all for being against conventional wisdom, but surely someone would have done some experiments on these lines to unlock the creative expression of their employees? There are even a bunch of companies who allow and provide facilities for napping since they believe it helps be more productive. What's stopping them from switching to CLIs exclusively?
Also, he ignores the power of macros(VBScript is very powerful) and keyboard shortcuts in GUIs. Watch an occasional user of Office vs. a pro user and you can see the difference clearly. How many here can profess to know about every feature or shortcut in Word or Excel? Just see http://www.shortcutmania.com/Microsoft-Word-2007-Keyboard-Sh...
or
http://www.asap-utilities.com/excel-tips-shortcuts.php
Same with IDEs, you can automate a lot of tasks if so choose to spend your time on it and rarely even use the mouse. You only hit a wall in the most simplest of applications(same as CLI), for complicated applications, there's a ton of room to explore.
It makes more sense to rant against programs/devices(browsers, pdf readers, watching movies) that encourage consumption versus the programs/devices that encourage creation(photoshop, IDEs, writing HTML in notepad). That's the only way the analogy of driving a car vs. playing a guitar makes any sense.
I can't fathom why the author is trying to turn that argument into a CLI vs. GUI argument that superficially sounds plausible but just falls apart with a little scrutiny.
Since the author has mastered the car UI, I am looking forward for him to execute this move http://www.youtube.com/watch?v=_CK94zCXsKI&feature=relat...
Nothing stops a "GUI app" from having a CLI or vice versa, though I observe that generally an app can be fairly cleanly identified as considering one or the other the "primary" interface, with the other a clear afterthought/second priority.
Or does he mean it's a good thing to replace the car's interface with a bunch of strings like a guitar that allow you to steer, brake and accelerate and change gears and this will allow for more creative driving? As I said, the article is not even wrong.
A "CLI app with a GUI" is something like emacs in X11 or gvim, where the GUI is clearly a second-class citizen/afterthought, but it is there. Alternatively, you can look at something like the various Linux apps for ripping DVDs, which are mostly nothing but GUI shells around various transcode and mplayer commands, and it shows. To the point that I once bashed one of them into doing what I wanted it to do, rather than what it wanted to do, by exploiting a command-line injection in the so-called "GUI" to inject a command-line parameter that superseded one of the earlier ones the program jammed in without asking me. (Subsequently I scripted up a simple rip that meets my usual use case, but the GUIs are nice when I want to save subtitles or something and it's harder than just one mencoder call.) Considered as a system, these are GUIs around underlying CLI apps that do the real work.
If a CLI interface can include a GUI, can you use it over in a SSH terminal? Or on a Linux box without X(or the equivalent) and all it's bloat being installed? Or on Windows 2008 Server Core? You're pretty much redefining CLI at this point and cutting away some of it's advantages too, like being able to run on very low power devices like routers etc.
Yes, you can use every bit of functionality in all the software I cited over SSH, you just don't get the GUI. (Excepting anything purely GUI-specific, like opening a new window in emacs, but that's a small set of targeted commands.) That's why I cited those examples as CLI apps with GUI overlays. I could cite some others, too, like fetchmailconf, a GUI for fetchmail that is optionally used for configuration of an otherwise fundamentally CLI app. Unix is full of these things.
Not all macro and automation systems are text-based. Automator and Photoshop actions both let you create user-defined behavior by combining primitives while still taking advantage of the discoverability and spatial layout of a GUI.
There is a time for operation, and a time for expression.
Most interface debates are misinformed because they are
about creators complaining about operation interfaces, or
operators complaining about creation interfaces. We need
both. But we also need to understand when."Creators" don't use machine opcodes or punch cards anymore.
We already have Latex to substitute for Word and Lynx to substitute for Firefox.
Are Photoshop users creators?
On the other hand some users have a need to do batch processing and in that regard Photoshop is surely limited. Also, Photoshop is so god-damn effective in 80% of the tasks that most users never learn the mechanics of useful effects like smart-sharpening (just an example), which is really bad because the same techniques for doing a manual smart-sharpening can be used for lots other effects.
Do note that Photoshop does have scripting support, but I don't know if it is an afterthought or not (and this does matter).
Are Visual Studio users just operators of an IDE?
We already have Latex to substitute for Word
Latex is still the only general-purpose solution for producing high-quality documentation that is consistently rendered well across devices and that can be properly translated into PDF or whatever format you want without splitting hairs. It's also much more productive for expressing mathematical formulas.
Lynx to substitute for Firefox
However, I still don't see professional designers / developers using WYSIWYG tools for writing HTML, like say, Dreamweaver. They may draw the layout in Photoshop, but writing HTML? That's done by hand, unless you're speaking about incompetents. That may change but after more than 20 years after the web was invented, the fact that no WYSIWYG editor is capable of being good enough for the task truly speaks volumes.
Latex is awesome if you stick to the (very sensible) defaults. It basically creates beautifully typeset documents for people who have no idea about typesetting. (That’s a good thing, by the way.) It’s not all that great if you want to go very far beyond that and in that respect InDesign runs circles around it.
Different tools are good at different things.
Latex (or more specifically, TeX) was groundbreaking for its kerning and typeface support. It still has the most extensive system for unambiguously typesetting complex mathematical equations. It appeals to a certain kind of person who wants to have a canonical source in plaintext controlling layout. But you're kidding yourself to say that it is the most flexible and powerful tool for typesetting on the market today.
And many of them create awesome games, OSes, applications and websites that hundreds of millions of people find useful and enjoy. Funny how an open-ended tool works, isn't it?
>Well, actually Microsoft has yet to create a replacement for Latex.
They have EPS.
>This comparison is not fair because HTML itself was meant to be rendered in a graphical interface.
So you mean GUI is for consumers and CLI is for creators? But is Photoshop CLI or GUI? What about Eclipse?
Do you think there was much debate at Twitter over whether users would be able to understand and effectively use #hashtags?