Relating GUIs to CLIs

This is a philosophical question really.  Lately I've been using both GUIs and CLIs for the same systems and got to wondering if there are "rules" or "standards" or "guides" that would tie the two together?  Otherwise, it seems that the trivial answer would be "no" - but that rather assumes that there IS NO glue between the two.  Is there?  Examples?

Here's a recent example:
I am working with PowerShell and was changing the font size in the ISE command window for a new monitor.  A couple of times the font size came back way too big - which seemed to have something to do with opening and closing windows etc.  Did the font size change at a fundamental level or somewhere in between?  Now then, generally this change is being done using the PowerShell ISE / Tools/ .. GUI..  So then I tried to find the font setting *using PowerShell* commands.  I wasn't successful .. but no matter.  That's one example of wondering if there's any sort of a tie that's documented for programmers?  In other words:
- if it's in the GUI then are there corresponding methods in the CLI?
- if it's in the CLI then are there corresponding methods in the GUI?  (I won't be at all surprised if the answer to this one is "no").  If the answer is "no" then how is the dividing line defined or described?  Or is it at all?

Here's another example:
Juniper networks' J-Web interface seems to me to be back-burnered.  It seems to have gotten worse over the years.  Changing from SRX2.. to SRX3.. is a big change in my view.  Everyone who is any good at JUNOS seems to be very CLI oriented.  There seems to be no glue here that would drive the J-Web design.

As you can see, I don't even know what to call such a "standard" or "guide" or "method".  Yet, I'm sure that folks have pondered this question.
What's it called?  Any good examples? etc.
LVL 27
Fred MarshallPrincipalAsked:
Who is Participating?

[Product update] Infrastructure Analysis Tool is now available with Business Accounts.Learn More

x
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

arnoldCommented:
A cli based validation is as instantaneous as you type. The GUI validation using a web ....
Nomenclature is possibly an all encompassing explanation how the same thing can be referred to by different vendors.
GUI I would agree in most cases was/is an afterthought
Otherwise, the design would be more intuitive.
0
Joe Winograd, Fellow&MVEDeveloperCommented:
Hi Fred,
I'm working on a response for you, but it's somewhat lengthy and could take a while until I finish. Regards, Joe
0
footechCommented:
I've never seen or heard mention of any sort of standard for parity between CLIs and GUIs.  I think it rather comes down to the application.  Either one could be the primary focus, depending on the developer.  A GUI is more likely to be primary if the focus is ease-of-use and being friendly to beginners, and also when an action doesn't have a strong need for being highly repeatable.  A CLI is more likely where the focus is scriptability and fewer resource requirements.

If both interfaces are present, it's great to aim for feature parity, but it may not make sense to devote resources to implementing everything in both.  I think it's pretty rare to have the CLI able to access customization settings for the GUI.

I'm having a hard time thinking of examples right now, but I've come across a number of items over the years where something was accomplishable via the GUI but not CLI, or vice versa.
0
Defend Against the Q2 Top Security Threats

Were you aware that overall malware worldwide was down a surprising 42% from Q1'18? Every quarter, the WatchGuard Threat Lab releases an Internet Security Report that analyzes the top threat trends impacting companies worldwide. Learn more by viewing our on-demand webinar today!

arnoldCommented:
The primary role is resource conservation, cli is the low impact, GUI was added to expand the audience who might purchase the product, but the complexity dealing with learning the flow ...
I.e. You gave to add the object, before you could ...
The GUI requires, in j-web, a web service component,
The GUI adds.

Often or at times, there are those that you either use one or the other, but not both. I.e. For simplicity, uniformity,, the GUI uses a specific naming convention to assist with validation. The cli allows the user ... The combination runs into situation if using the GUI that overlooks and thus alters when modified.

The only answer is it depends on the product and the comparison.
I.e. Cli or GUI in a managed switch might be symbiotic and fairly well worked out, while a more complex system firewall, IDS/IPS etc. as the complexity increases..
Routers.....
0
Fred MarshallPrincipalAuthor Commented:
footech:  At the moment, I have a hard time imagining something in the GUI that wouldn't be reachable via the CLI.  But the opposite, sure.
The model in my head right now might be a "specification" that says:
1) Here is what's reachable in the CLI with some identification method for what's in here and NOT reachable in the GUI.  Part C1 and Part C2 perhaps.
2) Here's what's reachable in the GUI Part G1  (which should match Part C1).

I might make the distinction between "users" and "coders" in the sense that only coders will be scripters and that users need constant context for what they might be doing - some of whom might be more "visual" in how their brains work.  The -whatif in PowerShell is there for a reason  :-)

A more complete model might be:
1) Here is what's reachable in the CLI (Part C1) with some identification method for what's in here and NOT reachable in the GUI (Part C2).
2) Here's what's reachable in the GUI (Part G1) and what's NOT reachable in the CLI (Part G2).

And, the question you raise is how these sets overlap.
Everything is covered by C1 and G1.
I originally assumed that G1 is completely contained in C1 and that they aren't equal (so C1 reaches more things via C2 which would be the nonoverlapping part of the CLI wrt GUI - and there would be no G2 at all).

But if C1 and G1 both have nonoverlapping subsets C2 and G2 then one would be forced to use one or the other at times.  That is, they could be required to use both if their endeavors dictate.

I'm sorry if this "treatment" seems a bit abstract but It seems to me that it leads to architect visibility into these things - which would be pretty important.  But I've never seen or heard of such a thing.
0
Joe Winograd, Fellow&MVEDeveloperCommented:
Hi Fred,
I'll give you my opinion on the various questions in your post.

> wondering if there are "rules" or "standards" or "guides" that would tie the two together?

You are correct — the trivial answer is "no". Of course, it's likely that a programmer would call the same code in both the CLI path and the GUI path, but there's no defined "glue" between them, other than the programmer calling the same functions and subroutines in both the CLI and the GUI. A popular technique is to get the parameters for a run via the CLI or the GUI, and then proceed to common code, but there are often differences between the features/functions of the CLI and the GUI.

> if it's in the GUI then are there corresponding methods in the CLI?

As mentioned above, not always — sometimes yes, sometimes no.

> if it's in the CLI then are there corresponding methods in the GUI?

Same answer as above.

> If the answer is "no" then how is the dividing line defined or described? Or is it at all?

The documentation and/or Help will define/describe what features/functions are in the CLI and GUI.

> Any good examples?

Yes, lots! Here's an EE article that I wrote about a CLI for Nuance's Power PDF Advanced:
Batch Conversion of PDF, TIFF, and Other Image Formats via Command Line Interface to PDF, PDF Searchable, and TIFF with Power PDF Advanced

In this case, the GUI has the same capability as the CLI, i.e., a batch converter:

bartch converter in GUI
But there are many features in the GUI that are not available via CLI.

Another example is the extremely popular (free!) IrfanView software:
http://www.irfanview.com/

It has both a GUI and a CLI. The CLI is documented in a file called i_options.txt that is stored in its install folder. There are many features in the GUI that are not available in the CLI, although, as CLIs go, IrfanView's is robust.

Last example is from are my own program portfolio. I've written many programs that offer both a CLI and a GUI. One of them is called CopyRenamePDF™. Here's the section from the Quick Start Guide documenting them:

cli gui doc
In this case, the CLI and GUI have identical functionality.

Regards, Joe
0

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
Fred MarshallPrincipalAuthor Commented:
Joe:  Thanks!  You've highlighted an important aspect of this question: "there's going to be a bunch of code that will be used no matter what".
This departs from a more "interface centric" viewpoint and is, I'd say, more "code concentric".  It surely makes sense to look at it that way.

The specification question gets to what's reachable.  If everything is reachable, as in your example, then  the question is moot.  
They key here is "how do you know?".  How DO you know?  I suppose an application that is focused on processes that makes it easier.
(And, of course, I'd not venture into purely graphical things like freehand drawing).  

Arnold:  I'm sorry to disagree that GUI was/is an afterthought as it's purely essential in many cases.  Perhaps you meant J-Web or something more specific like that?  

My own perspective is this:
I can learn to use a particular CLI but it takes time.  So, I better be going to use it fairly often or need to be scripting in order to take any of that time.  I still fight with getting *context*.
If there's a GUI for a router or a switch or .... then I can generally wind around the proprietary jargon to get the settings I need pretty quickly.  If I'm forced to use a CLI then there might not be time for that.
If I need to write a script then I'm in a different mode already.

But, the purpose of this question was more about product design and how the ideas are conveyed or specified amongst the players .. if at all.
0
arnoldCommented:
Correct, the context of what you are looking at is what dictates the resource allocation.
GUI tools that run on the appliance where storage resources, system memory are a valuable, expensive commodity as in security appliances.
If not mistaken, Cisco with asdm to a point overcame in part by providing a desktop application. That juniper has not, though they provide a web portal where you can enter the information of your network, interfaces, etc. and they generate the cli commands to achievE the configuration.
Including configuring a cluster config....

The audience dictates, I.e. Retail routers, firewalls for ease of use include GUIs with ...
More advanced, include clis with GUI of some ..

My guess on devices, the common/standard features are included in GUI, where more customized, complex scenarios achievable via cli, or in jweb's console editor pasting in ........
0
Joe Winograd, Fellow&MVEDeveloperCommented:
> there's going to be a bunch of code that will be used no matter what

Exactly! It's hard to imagine that any program with both a CLI and a GUI wouldn't have at least some functionality (executing the same code) in common, although it's a possibility — a program can do anything that the programmer wants it to do. :)

> The specification question gets to what's reachable.

Yes, that's a key point, and the only answer is in the doc/help.

> How DO you know?

Again, the doc/help. I had no idea what the IrfanView CLI could do until I read its i_options.txt file.

> I can learn to use a particular CLI but it takes time.

Yes, but it can also take time to learn a GUI, especially for a robust program, such as GIMP and Photoshop. For example, I do a lot with the Xpdf utilities (command line only). Here are several EE 5-minute video Micro Tutorials that I've published on them:

Xpdf - Command Line Utility for PDF Files
Xpdf - Extract Images from PDF Files
Xpdf - Convert PDF Files to Plain Text Files
Xpdf - PDFinfo - Command Line Utility to Retrieve Page Count and Other Information from PDF Files
Xpdf - PDFdetach - Command Line Utility to Detach Attachments from PDF Files
Xpdf - PDFtoPNG - Command Line Utility to Convert a Multi-page PDF File into Separate PNG Files
Xpdf - PDFfonts - Command Line Utility to List Fonts Used in a PDF File

You don't have to watch all the videos — just take a quick look at the steps underneath the videos and you'll see how simple the CLI calls are. For example, the PDFtoText call can be this easy:

pdftotext input.pdf

That's it! Sure, there are options, but that simple call will convert the input PDF file to an output text file, with the same file name as the PDF and a file extension of TXT. Probably as easy to use as any GUI, unless the user is totally Prompt-averse.

> I better be going to use it fairly often or need to be scripting in order to take any of that time.

As already mentioned, in some cases it will take as much time to learn a complex GUI.

Regards, Joe
0
Fred MarshallPrincipalAuthor Commented:
Joe:  Thanks!
Yes indeed, there are GUIs that are harder to learn and there are also varieties of ways to learn a CLI.
I had been rather focused on GUI interfaces that one might find in networking equipment but the graphics apps are good examples with more complexity!  And Wireshark isn't a bad example either I suppose!

To push back a bit re: doc/help, I was thinking more of the architectural decisions.  Doc/help seems a bit too fine-grained for me - at least in that context.  It's more like: "here is what it does" and the rationale or intent may be more elusive.  I was thinking more along the lines of:

1) Here are the fundamental operations which *MUST BE IN BOTH* CLI and GUI.
2) Here are the operations which at least MUST BE in the CLI.
3) Here are the operations which NEED NOT be in the CLI.
4) Here are the operations which at least MUST BE in the GUI.
5) Here are the operations which NEED NOT be in the GUI.

These are decisions which may not be evident or intended.
This is not to say that I know how to do it without difficulty.
One approach might be to start with an existing set such as the i_options.txt file and line them up with the GUI.
And then do the opposite starting with the envisioned or existing GUI.

Now that I think about it, some time ago I parsed a UI (it was a canned menu of short, single display lines) during its design process so we could envision the choices and the context we would be presenting the user. A GUI of choices and entries would be similar I suppose.  So, that's certainly doable.

But I've never seen a formal "method" mentioned.
0
Joe Winograd, Fellow&MVEDeveloperCommented:
Fred,
Your 1) through 5) clauses are great examples that should be in the design doc/specifications. I'm sure that plenty of times, one or the other interface is developed after the fact, but in a proper dev approach, one would define the features/functionality in the CLI and the GUI, and your clauses 1) through 5) are a valuable way of looking at it. Btw, here an interesting EE thread with an example of developing one of the interfaces after the fact:
https://www.experts-exchange.com/questions/28955505

The original tool, MediaInfo, is only CLI. I proposed building a GUI to front-end it.

> These are decisions which may not be evident or intended.

Very true! I suspect that most developers don't take the methodical approach to defining the features/functionality in the CLI and GUI, as your clauses 1) through 5) would require, and thus wind up with different capabilities in the two interfaces that weren't intended — and certainly not evident.

> This is not to say that I know how to do it without difficulty.

Same here — unless, of course, you take the approach of making the functionality identical, and simply gather the options/parameters differently — one way via CLI, the other way via GUI.

> One approach might be to start with an existing set such as the i_options.txt file and line them up with the GUI. And then do the opposite starting with the envisioned or existing GUI.

Interesting idea! Lock down one interface, then use it as the design spec for the other interface.

> But I've never seen a formal "method" mentioned.

Same here!
0
arnoldCommented:
the main issue is how the process is laid out.
I am not sure I understand, you are looking for a method to facilitate an construct of a CLI and a GUI in the means of design.
The issue is more to do with whether the GUI is simply an overlay of the CLI
The issue is more what is the primary function of the application. i.e. is it primarily geared towards GUI usage or CLI.

Lets take Joe, potentially the audience is more GUI oriented so much more effort and features were developed into it. Joe also wanted to provide some command line features to ...., which meant one either provides a separate CLI client, or as Joe did incorporate both in one, and using command line parameters to determine what the user is intending to do.

The target audience and ease of use is.

one can have an overlay of the other, i.e. GUI overlay for CLI... or have fully built with hooks, from the CLI passed arguments to execute the requested ....

As you noted, it depends on what is being worked on.
0
Fred MarshallPrincipalAuthor Commented:
arnold:
I am not sure I understand, you are looking for a method to facilitate an construct of a CLI and a GUI in the means of design.
 The issue is more to do with whether the GUI is simply an overlay of the CLI
 The issue is more what is the primary function of the application. i.e. is it primarily geared towards GUI usage or CLI.
I'd not say that "the issue is more to do with whether the GUI is simply an overlay of the CLI".  I tried to say: What is the architect's intent and how is that to be expressed?  Given that information or specification, it should facilitate the construct of BOTH the CLI and the GUI.
That said, I wasn't trying to go so far as to ask how to write a specification for the application - surely there's plenty of that around and plenty of different view as to approaches.  So, I guess one would have to have an idea of what the broader objectives are at the very least.
If you want to iterate, then iterate, etc.
Anyway, all the things you said about objectives would be encompassed I should think.  
How can you know what is being worked on without knowing what is being worked on by intent?  :-)
0
Fred MarshallPrincipalAuthor Commented:
Joe:  Well, I can imagine a process or a structure (like a database) that would line up all the functionality in some hierarchy perhaps and line up functions side-by-side in the hierarchy.
If one already has a GUI then one could start there and create a tree of operations.
Then, line these up with CLI commands.
If one already has a CLI then one could back-track it into a candidate GUI structure.

Freehand drawing tools would be an example of a GUI capability that wouldn't be readily made into a CLI operation.

Perhaps some regular expressions would be an example of a CLI capability that wouldn't be readily made into a GUI capability - except as perhaps an "embedded CLI-in-GUI thingy.

And, one might envision  whole subsets or branches of the tree that wouldn't "match" across to the other side.

The process of recording macros in Excel is an example of matching the two automatically isn't it?
0
Joe Winograd, Fellow&MVEDeveloperCommented:
> line up all the functionality in some hierarchy perhaps and line up functions side-by-side in the hierarchy

I can imagine that, too, but haven't seen it...yet. :)

> If one already has a GUI then one could start there and create a tree of operations.
> Then, line these up with CLI commands.
> If one already has a CLI then one could back-track it into a candidate GUI structure.

Yep!

> Freehand drawing tools would be an example of a GUI capability that wouldn't be readily made into a CLI operation.

Agreed.

> Perhaps some regular expressions would be an example of a CLI capability that wouldn't be readily made into a GUI capability - except as perhaps an "embedded CLI-in-GUI thingy.

I've included a RegEx search in the GUI of many of my programs. For example:

FolderCommentColor Search
> And, one might envision whole subsets or branches of the tree that wouldn't "match" across to the other side.

True.

> The process of recording macros in Excel is an example of matching the two automatically isn't it?

Sorry...not understanding that one.
0
arnoldCommented:
I guess I am approaching your question too literally.
Commonly, the foundation is laid, either db structure, interactions, or the user interface and then everything is worked to accomplish the functionality.
Unlike physical structures where the foundation is known and is laid first, then the first floor, and on,y when everything related to structure is complete, the exterior is

Other than installers, and Joe's apps, I think it is less common to have a single app that has both GUI and cli components.
Case in point, ms SQL has the ssms as the GUI, and osql as the command line tool to access a db on a db server.

I.e. Since Joe kindly provided a tool that can be used as an example with the described functionality, let's say the next version has the drop and convert functionality, I.e. A small task, desktop link on to which documents in this case can be drop, a pop-up prompts the user what the intent, batch convert to PDF, etc......
The other, group document types, and the user can choose based on grouped items what to do or have all the documents listed, with each having a drop down selection on what should be done for each.

Validation is what adds complexity.......
0
Joe Winograd, Fellow&MVEDeveloperCommented:
> I think it is less common to have a single app that has both GUI and cli components.

I don't know if it is less common or not, but I do know that some apps have the same executable (the .EXE file) that represents both the CLI and the GUI, and it simply looks for command line arguments to determine if it is a CLI run or a GUI run. For example, some of the extremely popular NirSoft utilities are like that. Here's just one example — USBDeview:
http://www.nirsoft.net/utils/usb_devices_view.html

If you run the executable (usbdeview.exe) with no parameters on the command line, it brings up the GUI. If you run the executable with any parameters on the command line, it does not bring up the GUI. For example, consider this command line:

usbdeview.exe /stext allusbdevices.txt

That will not bring up the GUI. Instead, it will run and save the list of all USB devices into a plain text file and then exit — the user will never see the GUI. Regards, Joe
0
Fred MarshallPrincipalAuthor Commented:
> The process of recording macros in Excel is an example of matching the two automatically isn't it?

 Sorry...not understanding that one.
One uses the GUI with mouse clicks, etc. to create the recorded macro *code* - which isn't exactly a CLI result and, I guess, that's where this little analogy breaks down.
0
Joe Winograd, Fellow&MVEDeveloperCommented:
> which isn't exactly a CLI

Right! Macro creation and running are happening in Excel (the Excel GUI, if you want to call it that). A CLI call to Excel would be something like this:

"c:\Program Files (x86)\Microsoft Office\root\Office16\EXCEL.EXE" c:\temp\test.xlsx

That actually works, btw. It runs Excel, which opens the c:\temp\test.xlsx file — of course, you'll be in the Excel GUI at that point. :)
0
arnoldCommented:
With all due, notepad FILENAME or excel.exe filename is not what I would call a cli both cases opens up a GUI tool

A cli will be using rename filename filename2 versus opening up explorer, locating the filename. Select, change name.
0
Fred MarshallPrincipalAuthor Commented:
Thanks for the replies!
From this exchange so far, it seems that the answer is "no" and, so, "there is no name for this" kind of specification.
0
Joe Winograd, Fellow&MVEDeveloperCommented:
Hi Fred,
Well, this question has meandered into numerous paths, but if by "this kind of specification" you mean a document that has "rules" or "standards" or "guides" that tie a GUI and a CLI together, then your last post is correct in my opinion — the answer is "no" and "there is no name for this". Regards, Joe
0
Fred MarshallPrincipalAuthor Commented:
Thanks!  It's interesting that there's no agreed approach or method.  But then we're a small population.
0
Joe Winograd, Fellow&MVEDeveloperCommented:
You're welcome, Fred. This has been a very interesting thread! Regards, Joe
0
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Powershell

From novice to tech pro — start learning today.