8 ms·
GUI vs CLI: Operation vs Expression
- ugh 15y ago"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?
- 4ad 15y agoCars vs. musical instruments to GUIs vs CLIs is an analogy, it won't work in all scenarios, but I think it's a pretty good analogy for explaining how CLIs work for people that have never used them or think they are antiquated.
- ugh 15y agoIt's a bad anology if it excludes the majority of expression, though, isn't it? I'm not talking about some corner case here. Software seem too malleable to me to characterize it in such broad strokes.
- super_mario 15y agoYou are taking the "expression" too far. We are talking about expression at the time of doing, not at the by-product of doing. GUI constrains you, it limits your expressive ability to tell the computer what to do. CLI is extremely expressive, it allows you to tell the computer what to do in very elaborate way, not only by having more options available for each command, but also by allowing you to combine things in ways GUIs simply can't allow for. 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.
- CJefferson 15y agoAre you suggesting that there could be a CLI for creating and altering graphics, which was even 1% as effective as photoshop?
- keenerd 15y agoSure. Check out the Lisp repl that is built into AutoCAD.
- JoachimSchipper 15y agoI'm not the grandparent, but I use TikZ to "programmatically" create graphics in LaTeX. It is much faster and looks much better than what I produce in the GIMP. (See e.g. http://www.texample.net/tikz/examples/. http://www.texample.net/tikz/examples/.) 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.
- super_mario 15y agoNo, I'm not. If you read carefully you will note that I'm talking about your expressive ability to tell the computer what you want it to do. Not about your ability to express yourself through a medium like video or images. 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.
- stonemetal 15y agoOk so I want to select the pretty green color from a photo for future use. In MS paint it would be two actions select the color selection tool and select the color. How do you do that from the CLI in more expressive way?
- recoiledsnake 15y ago>man paint 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.
- rmc 15y agoUsers 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 15y agoI don’t understand. You also seem to think that the author picked a horrible analogy?
- rmc 15y agoNo, 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 15y agoWow. 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 15y agoHave 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.
- agumonkey 15y agoIn the case of Maya (and his cousins like Houdini, [ex]Shake...) every gui action is a word in an embedded DSL/bindings api (mel script, hscript, python). Maybe Adobe products too, but the javascript parts aren't a cultural feature of the application. Maya is as macro-capable as Emacs, you operate buttons, open the console log, copy the last instructions and drag it into a toolbar to have a new operation. 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 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'
- ugh 15y agoYou are talking about possibility. I have no doubt that it’s possible to manipulate images, sound and videos with CLIs. The question is whether that would be the optimal way.
- gbog 15y agoWhen I worked with Photoshop, after a while most of the time was spent in a shitty point and click batch instructions editor, it should have been a text file in Vim.
- marshray 15y agoSure, a Graphical User Interface is likely the best interface for doing by-hand manipulation of graphics. 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?
- ugh 15y ago“But is a Photoshop-like GUI the best UI for anything else?” 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.
- marshray 15y agoAll this suggests that Photoshop/by-hand image editing is a special case where the GUI is at its best. It'd probably be useful to pick some other examples to discuss.
- ugh 15y agoAlright then. Is it possible to be somewhat systematic about this? 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.
- unwind 15y agoI 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. :)
- ippisl 15y agoPiano wizard uses color coding to teach playing the piano and reading notes.It's seems pretty successful at that. http://www.musicwizard.com/Music/Home/index.cfm http://www.musicwizard.com/Music/Home/index.cfm
- vidarh 15y agoI 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 15y agoYou can always buy this with blank keys. 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 http://www.newegg.com/Product/ImageGallery.aspx?CurImage=23-... But I learn to touch type with a regular keyboard.
- ippisl 15y agoGreat 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.
- jpalomaki 15y ago"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 15y agoWe've already seen it over and over again: once a GUI is actually combinable, it may as well be a CLI or code.
- andrewflnr 15y agoDo 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.
- ilaksh 15y agoWhat it says is just completely untrue.. there are examples in this thread, such as Maya.. any form builder is based on combining components on a screen.. these same types of forms are coded by hand by web developers (like myself), yet contain no additional functionality. Components can also be combined, linked and configured with GUIs oftentimes more efficiently than integrating libraries. Colored ASCII code and command lines are great and I use VIM and bash constantly these days, but its just ignorant and irrational to try to say that is the best way to express yourself on a computer. 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.
- zokier 15y agoFunny 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.
- thomasz 15y agoFYI: Typography is totally fucked on win7+chrome http://imgur.com/7Ad0d http://imgur.com/7Ad0d
- recoiledsnake 15y agoIt was probably tested only in Lynx+Hurd. /joke
- deleted 15y ago[deleted]
- jamesrcole 15y ago"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.
- deleted 15y ago[deleted]
- techdmn 15y agoMaybe 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.
- Cushman 15y agoNot 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?"
- recoiledsnake 15y agoThis 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-Shortcuts.pdf http://www.shortcutmania.com/Microsoft-Word-2007-Keyboard-Sh... or http://www.asap-utilities.com/excel-tips-shortcuts.php 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=related http://www.youtube.com/watch?v=_CK94zCXsKI&feature=relat...
- jerf 15y agoWhen 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.
- ArbitraryLimits 15y agoAre 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.
- cooldeal 15y agoA lot of programs already do that. Eg. http://www.gregshackles.com/2010/01/scripting-iis-7-with-powershell/ http://www.gregshackles.com/2010/01/scripting-iis-7-with-pow... and even things like Excel. 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.
- ArbitraryLimits 15y ago"A lot of programs already do that." 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.
- tikhonj 15y agoThis 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 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.
- malingo 15y agoDon't forget about http://news.ycombinator.com/item?id=1971200 http://news.ycombinator.com/item?id=1971200
- andrewflnr 15y agoI 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.
- 010100101 15y agoWhen 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 15y agoGreat 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.
- EGreg 15y agoWhy 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.