asked on 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.
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.
PowershellWindows OSFonts Typography
Last Comment
Joe Winograd
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
I'm working on a response for you, but it's somewhat lengthy and could take a while until I finish. Regards, Joe
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.
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.
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.....
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.....
ASKER
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.
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.
ASKER CERTIFIED SOLUTION
THIS SOLUTION ONLY AVAILABLE TO MEMBERS.
View this solution by signing up for a free trial.
Members can start a 7-Day free trial and enjoy unlimited access to the platform.
ASKER
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.
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.
SOLUTION
THIS SOLUTION ONLY AVAILABLE TO MEMBERS.
View this solution by signing up for a free trial.
Members can start a 7-Day free trial and enjoy unlimited access to the platform.
SOLUTION
THIS SOLUTION ONLY AVAILABLE TO MEMBERS.
View this solution by signing up for a free trial.
Members can start a 7-Day free trial and enjoy unlimited access to the platform.
ASKER
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.
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.
SOLUTION
THIS SOLUTION ONLY AVAILABLE TO MEMBERS.
View this solution by signing up for a free trial.
Members can start a 7-Day free trial and enjoy unlimited access to the platform.
SOLUTION
THIS SOLUTION ONLY AVAILABLE TO MEMBERS.
View this solution by signing up for a free trial.
Members can start a 7-Day free trial and enjoy unlimited access to the platform.
ASKER
arnold:
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? :-)
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.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.
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.
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? :-)
ASKER
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?
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?
SOLUTION
THIS SOLUTION ONLY AVAILABLE TO MEMBERS.
View this solution by signing up for a free trial.
Members can start a 7-Day free trial and enjoy unlimited access to the platform.
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.......
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.......
> 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
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
ASKER
> The process of recording macros in Excel is an example of matching the two automatically isn't it?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.
Sorry...not understanding that one.
> 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
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. :)
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
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. :)
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.
A cli will be using rename filename filename2 versus opening up explorer, locating the filename. Select, change name.
ASKER
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.
From this exchange so far, it seems that the answer is "no" and, so, "there is no name for this" kind of specification.
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
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
ASKER
Thanks! It's interesting that there's no agreed approach or method. But then we're a small population.
You're welcome, Fred. This has been a very interesting thread! Regards, Joe
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.