insightful post on gui design, and why it can be faster than the command line

[urlwolf]

http://blog.garlicsi...guis-kick-clis-asses



Really, this is spot on.
Might be a good read for people here, who have to deal with GUIs and sometimes make their own.

[tomos]

I dont know hardly anything about the command line; but using a piece of software intensively, I find the interface is extremely important.

So a very big +1 to the combination of a good GUI with good/flexible keyboard shortcuts 

[JavaJones]

Good article. Lots of counter arguments in the comments, some of which are reasonable and valid, but mostly seem to just be CLI fans whinging about how much better CLIs are. I'd love to see an impartial productivity test between equivalent CLI and GUI systems for the same tasks. Obviously depending on the task one or the other would be better, but I'd be willing to bet at the least that there'd be no clear overall winner, it might even end up with the GUI winning. I don't see CLI winning overall though.

- Oshyan

[steeladept]

I would bet you are right Oshyan.  I find a well defined and built GUI MUCH more productive than the command line, but due to unimplemented features for whatever reason, the command line tends to be more flexible/powerful.  This combination gives it it's only productivity boost over GUI in my opinion and that assumes you know all the commands, switches, etc.

If I were to guess based on my experience and totally partial testing , I would say the GUI would win hands down as long as it is properly designed with all the same commands, switches, etc AND implemented with any/all common input methods available.  That means keyboard shortcuts as well as mouse interactions, and maybe even lightpen and/or touchscreen depending on the application and it's intended target platform(s).  It really is hard to compete with a button push using a mouse vs. a 25 character string....

[JavaJones]

There's also gestures to consider.

I think CLIs have a definite place, so for me it's more a matter of "what's the rite UI for the job?". The issue I have really is anyone casting one or the other as *the* better solution *all the time*. I just don't see how that can be true.

- Oshyan

[Stoic Joker]

I think CLIs have a definite place, so for me it's more a matter of "what's the rite UI for the job?". The issue I have really is anyone casting one or the other as *the* better solution *all the time*. I just don't see how that can be true.

-JavaJones (September 07, 2011, 09:25 PM)

+1 - I do 99% of any network trouble shooting from a command prompt. Configuration OTOH is all via GUI, which is due to the article's point of being able to scan past (see) all the other settings involved and assess their correct-ness.

The right UI for the job varies based on the job most assuredly

[40hz]

+1 w/ StoicJoker and JavaJones.

For some people it's: GUI if you can; CLI if you must.

For others it's: CLI if you can; GUI if you must.



Geek posturing aside, a well designed GUI is a major productivity booster for one-off and small day-to-day things. Especially when it serves as a memory jogger for things you don't do often enough that you remember the exact command syntax.

For me, the fundamental difference is that CLI will always be more flexible. Because no GUI can anticipate every scenario.

And the single biggest advantage CLI holds is that it's scriptable. And that alone is what guarantees the continued existence (and need for) the command line.

Generally, that flexibility is less an issue in the Windows world, where user-generated scripting isn't a widely practiced art. Or at least not on the desktop level.



It's a totally different story in the server room. But everybody knows BOFHs like me and JJ and Stoic are evil six-fingered mutants. So they don't allow us to have our own GUIs. For obvious reasons. (see above)

In the NIX world however, scripting is a very important productivity tool. So users, who are serious about getting all that the Unix derivatives have to offer, soon make the modest effort that's required to learn basic shell scripting. Those that really miss a GUI sometimes also wrap a quick & dirty visual interface around a collection of commands so that the user isn't even aware that the GUI they're running is just a wrapper. In the Windows world, the well-known Super media file utility does exactly that.

The other big advantage to CLI (for me at least) is that it can be scheduled. Because a CLI command is not "interactive" (i.e. it just does the one thing it it says) once it's written - it's written! And once it's saved, it can be easily scheduled (via scheduler, chron, etc.) to run at set times or in response to a system event. For people like me who spend far too many hours in front of a monitor, anything that let's me quickly and easily pass important (but boring and repetitive) work off to a machine is a godsend.



GUIs generally don't let you do that. They're 'interactive' critters. Kinda like one of our dogs. It has to be his time, and his time alone, if you want to play with him.

So while I think the author of the article has made some interesting points, I don't think he made a convincing case for his core argument that CLI is no longer necessary or desirable.

Just my tuppence.

[steeladept]

Great points, and I don't disagree.  Truly, in my experience, ANY GUI is just a CLI wrapper anyway.  There is no such thing as an interface doing something, it is just buttons, sliders, etc, that pass commands and/or arguments to a CLI interpreter to do the work anyway.  At least that is the perspective I was coming from.  That doesn't make GUI scriptable or schedulable (necessarily) but it does make it easier to use.  CLI is ALWAYS scriptable or schedulable, at least to a certain extent, whereas GUI programs need to provide object/method documentation before they can be scripted or scheduled.  While this *should* be trivial (if time consuming), few GUI programs actually go that far, and it is unfortunate.

I hope it was obvious, but the productivity gains I spoke of in the previous post only referred to interactive programs.  If you are doing repetative work, a script and scheduler make you orders of magnitude more productive, if for no other reason than you don't ever have to do that again unless/until the script breaks/fails.

[rjbull]

As an old-time DOS person, if I had to do something once... GUI.  If I had to do it repeatedly, make a batch file wrapper for CLI tools and just run the batch, or indeed via a scheduler.

And as I understood it, early versions of Windows were just a GUI wrapper for DOS anyway 

[Stoic Joker]

It's a totally different story in the server room. But everybody knows BOFHs like me and JJ are evil six-fingered mutants. So they don't allow us to have our own GUIs. For obvious reasons. (see above)

-40hz (September 08, 2011, 09:30 AM)

Forget somebody?

My version of the BOFH DIY Excuse Generator:

Step One. Generate Excuse.
Just run Excuse.exe (CLI...) For particularly unintelligent users, adding (any switch) the optional fourth
parameter may help to clarify that this isn't a situation that should be celebrated...

Example: Inherent Software Corruption
Dumb Example: Inherent Software Corruption - Error

-----------------------------------------------------------------------------------
Step Two. Compose a story to backup this Excuse.
Remember, the more outrageous the story, the more likely
the user is to NOT understand it - and therefore believe it.

Unbelievable Explanation (for above excuse) "Well it appears that part of our
software is corrupted - possibly because of some hardware error"
Believable Explanation:
"It seems that the Inherency of the Software is corrupt - not the actual software
itself. We're looking at getting some artificial Inherency in to solve the problem..."

-----------------------------------------------------------------------------------
Step Three. Get the user to become part of the problem.
Example "..But the Artificial Inherency costs about 50 bucks a user.
If you could just send us the money, we'll get you sorted out"
Another Example "..But the Artificial Inherency isn't Right Hand User Compatibl
e - I dunno, it's Welsh or something - so you're going to have to type with your
left hand for the next 2 hours.."

-usage

Have fun with it (I have).

 

[JavaJones]

40hz, the SUPER example is a great one because it - and even more so Media Coder - are great displays of what happens when you try to encapsulate significant amounts of CLI functionality in a GUI. In that case they're encapsulating *multiple* CLI programs so the problem is even worse. SUPER simplifies things considerably, removing many of the more flexible options in the interest of simplicity and is, in my opinion, the better for it for most users, i.e. they disallow putting certain kinds of content into certain kinds of media containers because most players won't play them once output. With the CLI apps themselves you could of course do almost any kind of container and codec combination you wanted. Media Coder does a bit less to reduce complexity and the interface is quite cluttered as a result. And still, even in MC's case, you don't have a comprehensive view of all options. So it just illustrates the flexibility of GUI vs. CLI, at least in certain tasks. That being said for the occasional video or audio transcoding I do, SUPER and MC are by far my preference.

I am quite curious to see how much could be done to better integrate scripting with GUIs. There are in fact GUIs specifically designed to *create* scrips, and those are quite an interesting cross-over in the considerations of this thread. Being able to expose your app's underlying functions with through scripting, even if a CLI is not available, is a very good thing IMO. I wish more apps did this. We'll be adding scripting functionality to Terragen at some point, so that should give me an interesting inside look as it is mostly a GUI-driven app (though many people would call the GUI more akin to a CLI in power, flexibility, and complexity/difficulty).

- Oshyan

[rjbull]

I am quite curious to see how much could be done to better integrate scripting with GUIs. There are in fact GUIs specifically designed to *create* scrips

-JavaJones (September 08, 2011, 01:29 PM)

mouser's Drag and Drop Shell Robot is sort-of related.  I felt that the real work lay in figuring out the command lines of the programs, and I'd then have put everything in a batch file, so the idea of using drag + drop to feed in files didn't quite gel.

[40hz]

It's a totally different story in the server room. But everybody knows BOFHs like me and JJ are evil six-fingered mutants. So they don't allow us to have our own GUIs. For obvious reasons. (see above)

-40hz (September 08, 2011, 09:30 AM)

Forget somebody?

-Stoic Joker (September 08, 2011, 11:33 AM)

@Stoic - Ah indeed! I am truly remiss in not including you with the

BOFHs

mentioned earlier.

I will edit my original post to correct this inexcusable oversight. 

[Stoic Joker]

Thank you.