Command line or GUI

30 Mar 2009 - 11:34am
5 years ago
14 replies
1372 reads
Anonymous

hi all

I was wondering what could be the possible circumstances where a command line interface would be more suitable or better than a GUI.

I am working on redesign of a product having a command line interface and as of now it seems users are pretty comfortable with that.

any thoughts ?

thanks

Ananya

Check out the all-new Messenger 9.0! Go to http://in.messenger.yahoo.com/

Comments

30 Mar 2009 - 12:53pm
Caroline Jarrett
2007

Ananya Vetaal

> I was wondering what could be the
> possible circumstances where a
> command line interface would
> be more suitable or better than a GUI.

Anecdote: my husband retired last year from his job as a UNIX sysadmin. He
loathed all GUIs, and not just because he'd learned VI (which he calls
'vomit inducer' so you can see he's one for a turn of phrase).

So a typical update on a typical machine with a typical GUI might be six
clicks, one typed entry, and three button clicks. No problem.

Only, he's got to do it across anything up to a couple of hundred machines.
Hands up anyone who wants to click through a GUI six hundred times doing the
same thing in 100 places. Not to mention keep track of which of the 100
places has been done or not - while also dealing with customer support
issues, hardware breakdowns, bosses who love to interrupt to reset the
priorities given a whole 10 minutes ago, etc.

What he wanted was a command line interface that let him write some scripts,
e.g. in a Korn shell, to automate all that and track it. No CLI, no scripts,
he's one grumpy bunny.

Substantive point:
You'll find that many programs resort to CLIs, or line-by-line models, when
the going gets tough. Think about when you want to edit HTML directly and
when you want to do it WYSIWYG.

Hope this helps

Caroline Jarrett
www.formsthatwork.com

30 Mar 2009 - 1:27pm
Anonymous

Hi Ananya,

As Caroline points out, CLI can (in some cases) provide speed and management efficiencies for specific activities. There is more to it too.

I am also a former infrastructure junkie with an addiction to VI and command-line tools. Which as an aside, is why I became interested in HCI/IxDA in the first place... these tools are inconsistently designed and require a steep learning curve. It is very clear no one had the user, or even a human, in mind when they built these tools ;)

I would add that a combination is often a suitable compromise to consider. Limited advanced tools for the command-line commandos and clean, effective interfaces for everyone else. Depending on what goals and objectives need to be accomplished this can work very well.

As a student, I worked on a un-necessarily complex CLI-based network monitoring tool that only the core engineers could figure out. After a bit of research I found that most of the use cases didn't require command-line knobs and could be effectively accomplished through a sexier interface but in the case of the more advanced (less frequent) needs of the engineers.

Another option is to start people off using "training wheels" within an interface and graduate them to the more advanced CLI-based tools. This helps ensure that the experience isn't daunting for new users and, in general, provides for a better experience.

With all that said, CLI tools won't be going away anytime soon but as more and more people realize it doesn't have to be that way, these tools will become more mainstream friendly.

30 Mar 2009 - 1:57pm
milan
2005

I think CLIs are a good solution where the users knows exactly what to
do with which command, where there is no exploration needed, and where
the activity includes repetitive tasks that can be automated via the
syntax.

also have a look at mozilla ubiquity, that seems to introduce the return
of the command line for all users. I also know a lot of mac users who do
almost anything with spotlight, instead of using menus or icons.

milan

--
milan guenther * interaction design
||| | | |||| || |||||||| | || | ||

+33 6 67 11 13 83 * www.guenther.cx

30 Mar 2009 - 2:54pm
Alan James Salmoni
2008

IMHO, it depends upon the frequency of use over a long period of time.
If something is going to be very regularly used and (as Caroline
pointed out) can save work by being scripted, users will often invest
the time needed to learn a CLI. Jobs like system administration can be
made a lot easier with a CLI. As I said in another thread, a former
lecturer of mine mentioned some research she did way back when which
showed sys admins performing more efficiently with a CLI than a GUI.

On the other hand, people will often stick to inefficient strategies
even when a much more efficient one is demonstrated to them. One
colleague of mine tested this and found that there was a trade-off in
terms of mental activity - users were sometimes willing to give up
time to use "think" less. Another (purely anecdotal) example
featured people being shown how to use Excel to add up a list of
numbers and then reverting back to a calculator when asked to do it
again with a slightly altered list. So quite often, users will prefer
a GUI even when there are known advantages to learning a CLI. As
designers, we have to remember that the most efficient design in
(say) terms of the KLM doesn't always meet user's needs.

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Posted from the new ixda.org
http://www.ixda.org/discuss?post=40758

30 Mar 2009 - 2:50pm
Dave Malouf
2005

I love the concept of Ubiquity and its "predecessor", Enso.
Enso was a great example of empowering the desktop for "experts" by
taking advantage of the "appendix" (a latent evolutionary organ you
just don't need any more) of the keyboard the "caps lock".
Brilliant. The other big advance is the specific implementation of
the type ahead functionality within a CLI.

Ubiquity is a tremendous evolution of the CLI concept, but taking it
further in important ways. From the End User perspective it is what I
have been describing as CLI with GUI support. The other component is
the developer framework which makes creating ubiquity commands pretty
easy.

Now, enough rah rah.
This is just an observation within a single space--Twitter.
I have noticed that Twitter has been conceived as a CLI. This is b/c
it has to all be doable from the SMS API client. Makes sense.

However, if you look at the eco-system evolution 2 things have
happened:
1) Supporting the CLI are the amazing user driven markup additions
like "#" and "@".
2) Almost every major API client has invented a way to do in GUI what
previously was purely CLI.

I think #1 is just fun and interesting.
while #2 is telling about CLIs and their overall utility in the
market place.

This is my way of saying that I would be cautious to ONLY have CLIs
(to the point that someone said earlier about choosing). And if you
do have CLIs enable an API system that allows an eco-system to expand
over time. CLIs afford markup, so let it happen.

-- dave

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Posted from the new ixda.org
http://www.ixda.org/discuss?post=40758

30 Mar 2009 - 3:14pm
Andrei Herasimchuk
2004

On Mar 30, 2009, at 12:50 PM, dave malouf wrote:

> Ubiquity is a tremendous evolution of the CLI concept, but taking it
> further in important ways. From the End User perspective it is what I
> have been describing as CLI with GUI support. The other component is
> the developer framework which makes creating ubiquity commands pretty
> easy.

Agreed.

Another important concept that goes hand in hand with this is that
things like Ubiquity work because they embrace modality. That is, you
enter a mode to scope the context to deliver a certain set of
functions in specific ways. The mode doesn't have to be a locked out
mode, but can easily be more ephemeral, like with Ubiquity.

Modality in the past has often been thought of as a bad thing.
Unfortunate really because modality is actually a fairly important
interface concept in designing software and digital products. Knowing
when and where to use modality is the trick, and maybe its time for
folks to dive back into the old desktop app days to see what types of
modality worked and what didn't and start bringing those things back
into the general software design language again.

The biggest danger or hurdle Ubiquity has solve is basically the same
as a UNIX CLI or what Enso had to handle: The threshold where the
number of textual commands or services overwhelms one's ability to
remember the entire list of commands via text. Ubiquity will more than
likely have a better shot at this since it also has the benefit of
context (as defined by the URL in the browser) to create the first
level of scoping the problem.

--
Andrei Herasimchuk

Chief Design Officer, Involution Studios
innovating the digital world

e. andrei at involutionstudios.com
c. +1 408 306 6422

30 Mar 2009 - 3:33pm
Angel Marquez
2008

Okay, so, how about this:http://www.humanized.com/about/

I think right after I posted how I use UI's and CLI together in
a harmonious way that converges when and how to use both in an effective
manner someone posted a link to these guys. I'm not trying to single you out
humanoidz; but, modes cause misery written on a computer, posted on the
internet, to a blog makes me think you don't get it.

Maybe it's just the way you are framing it or maybe....

That whole 'humanize' thing doesn't make sense to me. It's give and take
with some friction for any long lasting bond between any constituent parts.
If user experience is going to always assume users are static rather than
dynamic and make things that do not evolve are they really humanizing or are
they creating barriers between progress?

And morphing interaction design into some we do it for the user thing...I
think my original interest and the reason I found the IxDA is because of my
want to make the design process not s*ck so much and bridge that gap of
ambiguity between dev team members. Yea, I'm all for the user; but, if you
can't get one clear line of communication across the titled dev sphere what
is the point..?

I think natural language search engines is the term I heard around the first
.com fizzle doing what is resurfacing and being mentioned here. If you could
capture the input and organize it based on relevance on the fly you could
use a beefed up ajax input form field to aid you in your command line
interaction search activities...

On Mon, Mar 30, 2009 at 1:14 PM, Andrei Herasimchuk <
aherasimchuk at involutionstudios.com> wrote:

>
> On Mar 30, 2009, at 12:50 PM, dave malouf wrote:
>
> Ubiquity is a tremendous evolution of the CLI concept, but taking it
>> further in important ways. From the End User perspective it is what I
>> have been describing as CLI with GUI support. The other component is
>> the developer framework which makes creating ubiquity commands pretty
>> easy.
>>
>
> Agreed.
>
> Another important concept that goes hand in hand with this is that things
> like Ubiquity work because they embrace modality. That is, you enter a mode
> to scope the context to deliver a certain set of functions in specific ways.
> The mode doesn't have to be a locked out mode, but can easily be more
> ephemeral, like with Ubiquity.
>
> Modality in the past has often been thought of as a bad thing. Unfortunate
> really because modality is actually a fairly important interface concept in
> designing software and digital products. Knowing when and where to use
> modality is the trick, and maybe its time for folks to dive back into the
> old desktop app days to see what types of modality worked and what didn't
> and start bringing those things back into the general software design
> language again.
>
> The biggest danger or hurdle Ubiquity has solve is basically the same as a
> UNIX CLI or what Enso had to handle: The threshold where the number of
> textual commands or services overwhelms one's ability to remember the entire
> list of commands via text. Ubiquity will more than likely have a better shot
> at this since it also has the benefit of context (as defined by the URL in
> the browser) to create the first level of scoping the problem.
>
> --
> Andrei Herasimchuk
>
> Chief Design Officer, Involution Studios
> innovating the digital world
>
> e. andrei at involutionstudios.com
> c. +1 408 306 6422
>
>
> ________________________________________________________________
> Welcome to the Interaction Design Association (IxDA)!
> To post to this list ....... discuss at ixda.org
> Unsubscribe ................ http://www.ixda.org/unsubscribe
> List Guidelines ............ http://www.ixda.org/guidelines
> List Help .................. http://www.ixda.org/help
>

30 Mar 2009 - 3:51pm
Angel Marquez
2008
30 Mar 2009 - 3:52pm
Andrei Herasimchuk
2004

On Mar 30, 2009, at 1:33 PM, Angel Marquez wrote:

> Okay, so, how about this:
> http://www.humanized.com/about/
>
> I think right after I posted how I use UI's and CLI together in a
> harmonious way that converges when and how to use both in an
> effective manner someone posted a link to these guys. I'm not trying
> to single you out humanoidz; but, modes cause misery written on a
> computer, posted on the internet, to a blog makes me think you don't
> get it.

Locked out modality where everything else on the screen is off limits
until the mode is dismissed causes misery.

But it is interesting that an entire product that is based in modality
like Ubiquity and Enso is somehow not "modal." Even as defined by the
creators. It's entirely modal. It maybe an ephemeral and dynamic type
of modality that is using context and source material in an attempt to
make the interaction more natural, but its still modal. The way we
changed the palettes to pop-up and stick (which became the basis for a
lot of the CS3 changes later on) in Photoshop all those years back was
something I termed "semi-modal" and is similar in concept as to what
Ubiquity uses, in that you lock keyboard and interaction into a thing
on the screen until that thing is dismissed. But it is still modal.

I think it's the nature of past modality and its uses that people want
to run away from it instead of embracing it and evolving it. For
example, choosing a tool -- any tool -- in Photoshop is a "mode." Is
that bad? Hardly... it's what makes the entire pixel editing model
work in the first place. Choosing tools is the entire basis for a lot
of desktop applications and that type of modality has its place. In
the analog world, picking up a hammer is similar to a mode, as opposed
to picking up a saw.

As for not getting it... I'm going to ignore that comment and the
manner you stated it.

> Maybe it's just the way you are framing it or maybe....

My definition and use of modality comes from my work on desktop client
applications, where even then arguably people thought modality meant
"dialog boxes that lock you out of doing anything else on the
computer." In fact, modality simple means that there are modes. When
you choose a tool you are setting the mode for how all of your
interaction with the mouse and keyboard work.

--
Andrei Herasimchuk

Chief Design Officer, Involution Studios
innovating the digital world

e. andrei at involutionstudios.com
c. +1 408 306 6422

30 Mar 2009 - 4:00pm
Angel Marquez
2008

Adhering to a language and communicating is modal. Going from friend to foe,
lover to leaver, all modes...

Go ahead and ignore, I'm rude, I know, it's a mode I wish I could control a
little more.

Anyways, I'm playing SKATE II and the modes are amazing. I thought Tony Hawk
on PS2 could not be competed with; but, I think the control mappings for
this game are just as satisfying and a pleasurable challenge.

If you are going to design interactions and information architecture you
must know what activities go with what mode in the defined system. It's a
must not a should.

On Mon, Mar 30, 2009 at 1:52 PM, Andrei Herasimchuk <
aherasimchuk at involutionstudios.com> wrote:

>
> On Mar 30, 2009, at 1:33 PM, Angel Marquez wrote:
>
> Okay, so, how about this:
>> http://www.humanized.com/about/
>>
>> I think right after I posted how I use UI's and CLI together in a
>> harmonious way that converges when and how to use both in an effective
>> manner someone posted a link to these guys. I'm not trying to single you out
>> humanoidz; but, modes cause misery written on a computer, posted on the
>> internet, to a blog makes me think you don't get it.
>>
>
> Locked out modality where everything else on the screen is off limits until
> the mode is dismissed causes misery.
>
> But it is interesting that an entire product that is based in modality like
> Ubiquity and Enso is somehow not "modal." Even as defined by the creators.
> It's entirely modal. It maybe an ephemeral and dynamic type of modality that
> is using context and source material in an attempt to make the interaction
> more natural, but its still modal. The way we changed the palettes to pop-up
> and stick (which became the basis for a lot of the CS3 changes later on) in
> Photoshop all those years back was something I termed "semi-modal" and is
> similar in concept as to what Ubiquity uses, in that you lock keyboard and
> interaction into a thing on the screen until that thing is dismissed. But it
> is still modal.
>
> I think it's the nature of past modality and its uses that people want to
> run away from it instead of embracing it and evolving it. For example,
> choosing a tool -- any tool -- in Photoshop is a "mode." Is that bad?
> Hardly... it's what makes the entire pixel editing model work in the first
> place. Choosing tools is the entire basis for a lot of desktop applications
> and that type of modality has its place. In the analog world, picking up a
> hammer is similar to a mode, as opposed to picking up a saw.
>
> As for not getting it... I'm going to ignore that comment and the manner
> you stated it.
>
> Maybe it's just the way you are framing it or maybe....
>>
>
> My definition and use of modality comes from my work on desktop client
> applications, where even then arguably people thought modality meant "dialog
> boxes that lock you out of doing anything else on the computer." In fact,
> modality simple means that there are modes. When you choose a tool you are
> setting the mode for how all of your interaction with the mouse and keyboard
> work.
>
>
> --
> Andrei Herasimchuk
>
> Chief Design Officer, Involution Studios
> innovating the digital world
>
> e. andrei at involutionstudios.com
> c. +1 408 306 6422
>
> ________________________________________________________________
> Welcome to the Interaction Design Association (IxDA)!
> To post to this list ....... discuss at ixda.org
> Unsubscribe ................ http://www.ixda.org/unsubscribe
> List Guidelines ............ http://www.ixda.org/guidelines
> List Help .................. http://www.ixda.org/help
>

30 Mar 2009 - 11:23pm
jet
2008

Alan Salmoni wrote:
> made a lot easier with a CLI. As I said in another thread, a former
> lecturer of mine mentioned some research she did way back when which
> showed sys admins performing more efficiently with a CLI than a GUI.

Speaking as a sysadmin of one sort or another for the past 22 years,
that's because only a chump does tasks that the computer could do for
you. Why should I manually scan a list of hundreds of processes and
click on checkboxes for the ones I want to terminate when I can "simply
do" something like this:

sudo ps -ax | grep -i "naughty_program" | awk ' { print $1 } ' | xargs
kill -9

One sweet spot these days, IMHO, is package management on linux using
apt. There's the power-user CLI interface for people comfy with the
shell and there's also a user-friendly GUI interface (synaptic) that is
up there with OSX in ease of use.

--
J. Eric "jet" Townsend, CMU Master of Tangible Interaction Design '09

design: www.allartburns.org; hacking: www.flatline.net; HF: KG6ZVQ
PGP: 0xD0D8C2E8 AC9B 0A23 C61A 1B4A 27C5 F799 A681 3C11 D0D8 C2E8

31 Mar 2009 - 8:39am
Jared M. Spool
2003

On Mar 30, 2009, at 9:50 AM, dave malouf wrote:

> 2) Almost every major API client has invented a way to do in GUI what
> previously was purely CLI.

How much of this is because the twitter CLI is clumsy, particularly
because it uses the same channel as the data? (Anyone who has been
bitten by the oops-that-was-supposed-to-be-a-direct-message problem,
raise your hand.)

Jared

1 Apr 2009 - 9:34am
jet
2008

Something I forgot to ask earlier....

Ananya Vetaal wrote:
> I am working on redesign of a product having a command line
> interface and as of now it seems users are pretty comfortable with that.

Why are you redesigning it?

If the users are comfortable with the interface and there's no outside
requirement to change the interface to a GUI resolve other issues, why
change from a CLI in the first place, why not improve the CLI? Are
there new features that might benefit from a GUI or marketing
requirements that a GUI might support?

--
J. Eric "jet" Townsend, CMU Master of Tangible Interaction Design '09

design: www.allartburns.org; hacking: www.flatline.net; HF: KG6ZVQ
PGP: 0xD0D8C2E8 AC9B 0A23 C61A 1B4A 27C5 F799 A681 3C11 D0D8 C2E8

1 Apr 2009 - 10:49am
Carl Klutzke
2007

Not to be too obvious, but software development environments seem to work best with a CLI / text based interface. People have tried to create visual programming environments before, but they're too cumbersome.

It's a tradeoff between flexibility and simplicity. CLI interfaces are hard to learn because the commands are not apparent from observation of the interface. But anything that approaches the complexity of natural language has more commands than can be effectively depicted in a GUI.

If you have users that are familiar and comfortable with a CLI, for the sake of your personal safety, do not take it away from them. They've invested the effort to learn it, and once learned a CLI is generally more efficient to use (your hands stay on the keyboard the whole time, you don't have to worry about finding click targets).

Syndicate content Get the feed