
GUI vs CLI: Operation vs Expression - mef
http://blog.vivekhaldar.com/post/8950163616/gui-vs-cli-operation-vs-expression
======
ugh
"Expression" as the author defines it seems to be very narrow. Users of
Photoshop or InDesign or Illustrator or Maya or Logic or Premiere Pro most
definitly do express themselves, even though they are operating a GUI. GUIs
are widely used for expression. Does the author want to suggest that CLIs
would better serve the needs of all who want to express themselves?

~~~
rmc
_Users of Photoshop or InDesign or Illustrator or Maya or Logic or Premiere
Pro most definitly do express themselves_

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.

~~~
ugh
I don’t understand. You also seem to think that the author picked a horrible
analogy?

~~~
rmc
No, I think the analogy is apt. I think you're looking too shallowly and only
looking at GUI/CLI, and thinking that Photoshop, being a GUI, fits into that
world. Whereas Photoshop has more in common with CLI tools than many GUI
programmes.

~~~
ugh
Wow. Just wow. What a completely absurd redefinition of what is a CLI and what
is a GUI. No true Scotsman, anyone?

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.

~~~
burgerbrain
Have you ever seen a professional autocad user? How would you define that? A
blurred line between the terms CLI and GUI is not a True Scottsman. It's an
observable reality.

~~~
ugh
I’m quite confused. Everyone seems to disagree with me by vehemently agreeing
with me. As you yourself say: Expression is not reserved for CLIs. GUIs can
allow for it, too.

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.

~~~
burgerbrain
Basically I am disagreeing with the validity of the discussion in general.
There aren't agreed upon meanings for either term, so there isn't much point
in going forward.

------
ArbitraryLimits
Are we really having the GUI vs CLI holy war on HN? Here's how to deal with
this question.

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.

~~~
tikhonj
This is basically exactly what Emacs does--every single GUI action, be it a
keyboard shortcut, a menu item, a mouse click or even a touch gesture[1] maps
directly and very unsubtly to an elisp function. This means you can go from
just using Emacs like a normal text editor do doing really complicated things
with elisp in a relatively straightforward way.

[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.

~~~
ArbitraryLimits
Invoking emacs from the command line is my go-to method to format code that
I've generated from another program.

------
Cushman
Not to overstretch the metaphor, but it's not that black and white. Something
as simple-seeming as manual shifting on your car can change your experience of
driving completely, making you much more aware and attentive of what's really
going on between your ass and the road. It makes you a real part of the
vehicle's decision making process. (The description I like is "It's like
having a conversation with your car.")

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_?"

------
zokier
Funny that as an example of unbounded UI he shows _GUI_ version of Emacs.
Overall I feel that his division between GUI and CLI is rather arbitrary.

------
unwind
I like this, never thought of it that way.

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. :)

~~~
vidarh
I think part of the resistance you'd meet to labeling piano keys is that
you're highly unlikely to be able to play well if you depend on looking at the
keys, as it slows you down too much to be able to play anything but the
slowest pieces, whereas you can write well (though arguably not type well) on
a keyboard while still looking at the keys.

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.

~~~
recoiledsnake
You can always buy this with blank keys.

[http://www.newegg.com/Product/ImageGallery.aspx?CurImage=23-...](http://www.newegg.com/Product/ImageGallery.aspx?CurImage=23-830-001-TS&ISList=23-830-001-Z01%2c23-830-001-Z02%2c23-830-001-Z03%2c23-830-001-Z04%2c23-830-001-Z05&S7ImageFlag=1&Item=N82E16823830001&Depa=0&WaterMark=1&Description=Das%20Keyboard%20DASK3ULTMS1%20Black%20USB%20Wired%20Standard%20Model%20S%20Ultimate%20Keyboard)

But I learn to touch type with a regular keyboard.

------
jpalomaki
"Physical interfaces (and by extension, GUIs) cannot combine at will to create
new behavior."

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.

~~~
jcromartie
We've already seen it over and over again: once a GUI is actually combinable,
it may as well be a CLI or code.

~~~
andrewflnr
Do you mean that once a GUI is combinable, it will be as hard to understand as
CLI? That makes sense to me; infinite potential combinations will always be
harder to understand than a limited set of actions.

------
andrewflnr
I don't think he thought it all the way through, but I do think the author is
onto something. A very important aspect of any kind of interface is to what
extent it lets you combine and compose actions. But a) the line is not the
same as the GUI/CLI line and b) it's a matter of degree.

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.

------
techdmn
Maybe there isn't much progression after you learn how to drive a car for
normal people. :) Perhaps similar to lack of progression after learning how to
email or browse the web for most users. Sure, you can only move the wheels,
pedals and gear selector in certain ways. Isn't this equally true of the
mouse, keyboard and guitar? And how is a steering wheel visually suggestive to
those unfamiliar? Or the pedals? Sure, you can't pipe your car without making
physical changes. But hacking a fuel-cut-defender is still hacking. I guess I
just dislike using a car, guitar and EMACS as an analogy. Other than hardware
vs software, they are very similar to me. I'm familiar with all three, and the
one I'm least likely to modify is my guitar.

------
EGreg
Why not combine the two?

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.

------
jamesrcole
"Physical interfaces (and by extension, GUIs) cannot combine at will to create
new behavior."

'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.

------
ippisl
Great textual interfaces also try their best to externalize knowledge. That's
part of the reason behind DSL's , Object-oriented-languages and good API
design.

And because they're better at this, they're more useful than GUI's in many
cases.

------
malingo
Don't forget about <http://news.ycombinator.com/item?id=1971200>

------
thomasz
FYI: Typography is totally fucked on win7+chrome <http://imgur.com/7Ad0d>

~~~
recoiledsnake
It was probably tested only in Lynx+Hurd.

/joke

------
recoiledsnake
This is not even wrong.

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...](http://www.shortcutmania.com/Microsoft-Word-2007-Keyboard-
Shortcuts.pdf)

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...](http://www.youtube.com/watch?v=_CK94zCXsKI&feature=related)

~~~
jerf
When you start scripting with macros or automation tools, you've just left the
limits the GUI imposes for a CLI environment, with all that entails. That's
not a disagreement, that conceding the point.

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.

~~~
recoiledsnake
In other words, GUI apps can and do incorporate CLI elements. But CLI apps
cannot incorporate GUI elements like click-to-select. So would it be accurate
to say CLI apps are more limited than GUI apps? Or is the point in the article
about forcing people to use CLIs so that they have to know about the more
powerful features(or give up trying to use the program)?

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.

~~~
jerf
Too strong. You've defined "GUI" as something that can include CLI elements,
but then turned around and defined CLI as being unable to include GUI
elements, so you end up in a tautological circle.

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.

~~~
recoiledsnake
A GUI interface can include CLI elements because it is technically capable of
showing a CLI interface.

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.

~~~
jerf
"If a CLI interface can include a GUI, can you use it over in a SSH terminal?"

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.

------
010100101
When people use #hashtags in Twitter is this like a command on the command
line?

Do you think there was much debate at Twitter over whether users would be able
to understand and effectively use #hashtags?

~~~
jmmcd
Great example. Before Twitter, Google had already begun the re-education of
the masses to use text-oriented interfaces with things like "label:" in Gmail
search and "filetype:" in Google search.

