This also demonstrates were CLI excels and where GUI's fall short. With the GUI your just stuck digging for the correct option and tab. With the CLI you can create aliases or shell scripts to make wrappers for complex CLI options. Not to mention building custom openssl.cnf configs.
Maybe that's also why visual programming never took off. There's just a sense of "power and control" that comes with raw text that's unmatched in GUI apps.
I agree with your point about CLI. At the same time, I wish we had more GUI *inside* CLI. For example, an interactive and pretty MAN page that's not just text, but has clear borders, boxes, buttons (with keyboard shortcuts), and uses different colors for different sections (e.g., command description, arguments, examples, etc.)
I think there's a strong case for a lot of systems having both a GUI and a CLI, because there are purposes each excel at, and a user may want to be able to switch between them depending what they are doing.
Funny, when I looked at this my first impression was how much nicer the (hypothetical) GUI looked to use, with all of the functionality easily discoverable without digging through man pages and rewriting your intentions in terms of obscure flags.
To clarify, I'm not saying the GUI is actually better. But I wish we could bring some of those conveniences to the command line experience (way better autocomplete and command discovery).
It really comes down to "is this a one-time task you're trying to figure out" or do you want the options set once and never touch it again in a script.
With the CLI at least you can cut and paste the options from somewhere else.
Microsoft solved this for a lot of their server stuff by having a "show me the powershell command" at the end of most wizards. If you want to write a script, going through this process is usually a good idea.
"Cut and paste the options from somewhere" is a questionable practice even when it's not part of a security-critical workflow. And yet I'd venture to say that most people who use OpenSSL do so with commands copy-pasted verbatim from the internet, specifically because of its obtuse complexity.
Set-and-forget still requires you to know what to set.
At first glance, it would be better with more separation of sections rather than cramming it all on one page. After a while it does become unruly, but it could be improved over time and after test case reports.
Some common functionality in tab ABC, and then opt-in for Headache Mode if necessary.
Another second order factor is that precisely because the GUI just puts it all out there visually, it creates encouragement to start imagining what can be eliminated/automated, or at least shoved behind "advanced options (rarely needed)". What can be sane modern defaults vs reinventing the wheel each time. There are a ton of options in OpenSSL almost nobody should ever use in 2022 including some genuine footguns. Without discipline, CLIs are easy to just keep adding to, and scripting may well encourage that in the typical nature of creating a dependent ecosystem that discourages breakage. Not that there can't be really bad ginormous GUIs too but minimalism has a bit more human psychology behind it there.
Of course, for precisely that reason there are lots and lots of examples (particularly under "modern" "clean/flat" design tastes) that go to the opposite extreme and remove too much, get too information light and hide or eliminate stuff that's genuinely very important. But in the specific context of security software at least the current best practices thinking is that the fewer knobs and dials the better. A huge amount is purely legacy from when there were many more tradeoffs to be made in available compute power/memory vs security, but that fell away long ago in settings that would make use of complex CAs anyway vs something simpler. Not that simple CLI/text configs can't be easy too, look at WireGuard.
This topic strikes a little close to home right now too since I just went through an incredibly frustrating period of trying to put together some internal CAs with modern best practices (like name constraints) and it was quite the maze to get through. And having done it (or at least Good Enough) it definitely didn't need to be that hard. Ah well. Although then again, my experience also highlights to the perils of GUIs at the same time: I would have just used something like the built-in web gui CA generator on OPNsense, except it's so simple it lacks name constraints. Which then led me back into the red in tooth and claw world of openssl and ca config files. So there's the binary of both, an over simplistic GUI and an over complex CLI. Perhaps there are better tools bridging that gap but my searching failed :(.
That makes me think... was your comment really necessary? Maybe it was my intention to let the reader draw their own conclusions. Maybe the expansion wasn't really necessary. I surely wouldn't have added another comment if there weren't the unnecessary downvotes.
I've got a visual memory. I'm going to remember some obscure sub-menu on a forgotten screen far better than a command I learn and expect to use exactly once when I inevitably need to find it a second time.
This does not demonstrate that at all. This just demonstrates how bad a UI can be, if no thought goes into it at all.
Not everything has to be visible all the time, settings can be grouped, and the user can be guided through the settings piece-by-piece, instead of just putting every option next to each other.
This does not have a GUI because making a good GUI is alot of work + the target demographic are more technical people that are able to use the CLI, so why put in all the effort?
Many of the settings are unnecessary, for example, input file format switch: I would prefer a computer to figure out this for me. And there is no need for all those "display X" switches because you can display everything at once.
The interpretation here is implying that this GUI exists to demonstrate good GUI design. It instead exists to demonstrate what it would look like if you directly mapped the APIs of OpenSSL into a GUI 1:1. This is not the ideal way to do that, of course, but I would argue that with really good APIs, if you did do something like that, it would wind up being quite passable.
How openssl is today is probably not so bad for what it is, though. The GUI design here might be doing it a disservice by intentionally not having as much hierarchy. But this is actually a really bad argument for why CLIs are better. That’d be like arguing that closets are better for organization than shelves because when you haphazardly throw everything from your shelves into your closet, your room looks cleaner when the closet door is shut.
An actual GUI for openssl tasks could be hugely more user-friendly than the one depicted here. If anything, it demonstrates that a GUI interface could be superior (for non-scripting use, obviously), because the depicted version is meant to illustrate the CLI experience.
CLI is useful for something you know and want to automatically reproduce. But it sucks if the thing you want to do is one-shot or too rare. You read the docs, few tutorials, type the command, aaaand the task is done, the knowledge is gone. I’d just sit there with a black screen if every time I wanted to change a wallpaper I’d have to type out something like `sudo desktopctl -X --ignore-duplicates -f aspect -c 180 ~/path/to/image.jpeg`.
A large part of what makes libsodium simple is that it does very little.
Some of doing little is great. It does not let you erratically mess with your encryption options, it does not let you apply a bad algorithm, and it does not let you use one algorithm for a task it's badly suited for (well, up to a point).
But some of it is just things the library doesn't do. You can't run a PKI with it, you can't deal with industry-standard file types, and your options for interoperability are just none.
It's really good to make those nice focused libraries that people can actually use. But that doesn't remove the need for kitchen-sink packages that will solve every problem under the Sun.
This is true, but a majority of projects are using this kitchen sink library, poorly, for roughly the same 0.2% of it. Not good.
Thankfully, the situation has improved; at least some old stuff has been moved off into a module in 3.x, and a lot of cruft has been cleaned up. But still, it’s hard to not want to pick a library with reduced scope, if you at all can.
Yes, except that the reordering behavior of multi-row tab controls always confuses me, and that there should be a way to “break out” individual tabs to see them side-by-side, maybe similar to an MDI interface.
True, but you use the wrong FFMpeg codec, or transcode an audio track instead of copying it to the output, no one is left dangerously insecure. You just have a bloated MKV :-D
There are plenty of ffmpeg interfaces, though. The most prominent is Handbrake. Of course, I don't think any of them try to expose every single option. The goal for them is almost always to create an interface that works for the 99% and let the 1% deal with the CLI
Both ffmpeg(1) and openssl(1) share that they're meant, or used to be meant, as examples/demos of the underlying APIs. No one was actually supposed to run an actual CA with openssl(1), for example. Both also share that some things are vastly easier using the API than bending over backwards thrice at full moon using the CLI, but because using the API has more friction to it, people generally stick to the CLI (almost) no matter how hard that'll make things.
Oh, and just like you have to know a ton about how media containers, streams and codecs actually work to use the ffmpeg API, you likewise need to be a crypto expert to use the OpenSSL API. Almost the same is true for their CLIs as well, though.
I'm less familiar with ffmpeg, but the openssl(1) command wasn't originally designed to expose the API. It was intended to provide very rudimentary examples for using the API, and perhaps operated as a useful development tool for contributors, but that's it. There were plenty of APIs it never exposed, and plenty API changes it was never updated to accommodate. And IIRC there were some breakages along the way.
This changed after the Heartbleed fiasco. One of the many criticisms of OpenSSL maintenance was that people had come to rely on the command utility for production despite the official lack of support. The libressl fork made long-term maintenance and backward compatibility promises of the command utility explicit. Subsequently, the reorganized OpenSSL project also adopted this mandate.
Still, I'm not sure you could say today that the command utility is now designed or intended to expose the API. For one thing, backwards compatibility is now the primary concern regarding the utility, but the underlying APIs have changed considerably (including in some cases wholesale shifts to a different model) as part of improvements efforts for the OpenSSL API, ABI, and overall implementation. So in some ways the utility is even more divorced from underlying OpenSSL architecture than before. And this shows in the ever increasing set of options which often don't directly map to the underlying APIs, or for which their implementation in the utility is complicated by interaction with older options.
The same is true of ffmepg. The api documentation even links to the source of the bins so you can read the example code. To pick on ffplay, I think it most clearly illustrates this - with the bare minimum rendering context to get video on the screen but clean code continously updated to reflect the api's best practices, and an invaluable resource when I was writing an embedded player for a game.
An FFMPEG GUI in the style of this OpenSSL one would be great if you are familar with the options but don't use the tool enough to remember the exact commands. It'll also let me explore interesting parameters that I can look up in the manual later to see if they apply to my application. Maybe the GUI could even have buttons that will open the manual page to that specific option. With the CLI I'll likely only grab the specific options I need from the manual and not explore as much.
No, I had the same thought. Moreover, a GUI/TUI would actually allow implementing some further usability improvements. And there could be a “save as script” option.
I was just wondering if this existed yesterday. LetsEncrypt is out there for real certs. I need a site cert for local development. Why can't I type my hostname and mash one button?
A team I worked on years ago had a build system with an insane number of options. Someone made a GUI that looked vaguely like this OpenSSL GUI does, only it didn't have a "Build" button, but a textbox that showed you the command line options you had picked (I think it could automatically save to a script as well).
It was such a useful tool. I've endeavored to recreate that a few times in other teams when I encounter a tool with a --help that's more than a page long. Really helps new people figure things out.
Heh, I once did the opposite and turned an infrastructure's asset management GUI/API into a CLI tool. It had a backend API which presented some decent typing and its nested structure, so it wasn't beyond impossible, just had to be massaged into a doctopt string.
It was, uh... It had a lot of options. It was immediately obvious that it was beyond useless because any use of the tool started with a search in the documentation, just as I would if I was just calling the API. No time saved and had an excessively small niche.
this highlights the difference: on a commandline it is syntactically easy to add lots of options, whereas the GUI has limits, but the GUI is easier to discover. for the commandline you need to read documentation.
Beautiful and educational. It’s a design activity very similar to building a good cheat sheet or study guide.
From an evolutionary standpoint our intelligence is heavily oriented toward navigation of complex terrain, to locate food sources and avoid danger. So translating this API into a structured layout makes it more suited to our natural learning faculties.
Does this exist? Because I want it. The only thing it needs is a couple extra buttons at the top like "Modern TLS Certificate" and it selects the right options, but then I can tweak it from there.
Just for fun, here's a list of things IMHO this one does right, and the wget one does wrong:
* They actually have an option for specifying where the output data goes, and it's right at the top.
* "Open..." buttons. OpenSSL doesn't ask you to type local filesystem paths directly into the thing.
* There don't seem to be any sentinel values in here. Every optional config option has a checkbox or radio button to turn it on, instead of some magic like setting it to -1.
* The spacing is a lot better. I don't see any places where the connection between checkboxes and their text entry fields is ambiguous, if you're willing to assume left-to-right, top-to-bottom associativity.
And here's a few things it still does wrong:
* Text boxes that won't get used should be grayed out.
* The text output and display options make no sense at this stage. Instead, allow the user to configure what they see after running. Output everything, and use various kinds of disclosure widgets to to filter the output.
* Multiple rows of tabs are bad [2]. These should be separate apps, like how LibreOffice Writer and Impress use the same backend but have separate start menu entries.
That wget GUI you are referring to and dragging through the dirt is a GPL Perl script from a lone programmer done in 2007 who did it out of personal motivation [1]. He provides his personal email address and asks for feedback through it. Have you contacted him?
It's fine to shit on proprietary garbage by huge companies which are involving UX experts into their development process such as Reddit or Facebook UI, but what you're doing is not cool.
I think notriddle’s comment is fine. They didn’t criticize the designer of the UI, just the UI itself. Their detailed UI critique helps other people reading the comments improve their UI design skills by prompting them to think how to avoid such criticisms.
Truly great GUI design is very challenging. I've used very few applications which I think have a truly great UI that beats the CLI in terms of the efficiency of presenting options in orthogonal and conditional ways (orthogonal: two features which don't interact at all can usually be programmed independently and appear in distinct locations, while conditional: options that are only valid if another option is set to a specific value).
The best UI I've worked with so far is Fusion 360. Like most 3d modelling tools it has a fairly steep learning curve, but it does a fantastic job of making your life easier. It has a bunch of UI dialogs for parameter setting (some of which are better than others) that do a good job with both orthogonality and conditionality. I really wanted to like blender but just about everything in it feels rotated 90 degrees to how I'd do it.
IIRC Fusion 360 has radial menus (https://help.autodesk.com/view/fusion360/ENU/?guid=GUID-6514...), and I think it was a major part of Maya or another one of the older modellers. I was never a huge fan and the mouse model still trips me up (imho, mouse-button-1 drags should rotate, and shift/alt mouse-button-1 pan and zoom, respectively).
Also, everything in Fusion 360 could be done in Qt5 without a lot of work, it's just that getting all the hints and the second level details (like maintaing the selection when you switch tools) is a real bear.
I work in industrial design and the use of Alias for surface modeling is quite prevalent (and has been for decades). It used to be called PowerAnimator, and marking menus were first added somewhere around the release of v6 (1995). Alias/Wavefront actually incorporated this functionality into their first release of Maya several years later, trying to innovate on the feature further with the use of hotbox menus [1][2].
Since Alias corp. was later acquired by Autodesk in the early 2000's, you can imagine Fusion 360 as being the symbolical evolution of it. Especially considering the current Alias UI has not changed much since 1999! [3][4]
If interested more on this topic, fun HCI bath-time reading: Gord Kurtenbach's 1993 dissertation on The Design and Evaluation of Marking Menus [5]. Not surprisingly, from Alias/Wavefront he went on to head Autodesk Research for most of the 2000's.
Cool, thanks- I had forgotten about Alias before Maya. I was introduced to radial when Maya came out (somebody demo'd in, I was interested by couldn't afford it).
I think of Fusion 360 as being more descended from Inventor (which defined a lot of my early expectations for 3d modelling). I'm only a hobbyist and I used Fusion 360 with large (mesh) surfaces (it got significantly better at meshes recently) and it definitely got clunky, although the performance is fine when working with parameteric brep objects.
I've been using Autodesk products (starting with 2D AutoCAD on a 286 running DOS) for quite a while (35 years).
Radial menus have the same problem(admittedly to a lesser degree) as icon fields(for example, a phone home screen, or most file explorers), they fail to be well sorted and as such are harder then they need to be to find things. A linear list with a search option, or better yet a table where you can sort by several attributes is a better option.
> I've used very few applications which I think have a truly great UI that beats the CLI in terms of the efficiency of presenting options in orthogonal and conditional ways
I can think of so many off the top of my head: Word, Excel, PowerPoint, Chrome/Firefox, Acrobat, Audacity...
And this is before you get into stuff dealing with pictures, like Photoshop or literally almost every modern game.
You can do most of these on the command line (see ffmpeg, imagemagick, etc.) but I'm pretty sure > 99.99% of people do not prefer a CLI version of such applications over the GUI forms.
IMHO the power of CLI apps isn't in their orthogonality or presentation, but ease of automation and composability, and the ability to cram a ton of features into a single interface without really caring about how easy it is to use for 99% of people.
Rather than listing several specific applications, what i'd do is generalize:
Word processors: are a real improvement over using ed at the CLI, or really any scripting tool, to process large amounts of human-readable text. Although in many cases, simple markup on simple text in a simple text file can be excellent.
Spreadsheets: for all that people complain about spreadsheets, they do a few things fairly well (cellular data model, dependency-graph-driven computations)
PowerPoint: I should have mentioned that "sheets/slides/presentation" apps are one of the best examples of this; features like "Align vertically" are a great example of where UIs make certain operations very intuitive and easy
Browser: I dunno, I prefer e-links :)
Music editing: Actually, the whole world of track-based video and music editing. This is a such a huge improvement over any other system (musicians and video professionals may disagree), specifically the ability to quickly view, cut and paste, and combine multiple parts of longer videos. A lot of this depends on a concept that only really became feasible once disk storage really became huge: https://en.wikipedia.org/wiki/Non-linear_editing
Composability and orthogonality go hand in hand- much of my argument rests on the idea that composing orthogonal features is trivial for UIs, whereas composing interacting features leads to combinatorial complexity and can really only be expressed in code (and possible visual programming- being used more and more commonly to give artists GUI control over complex code-like operations).
The automation is the last interesting bit- will visual programming ever become ubiquitious, so that most people doing automation don't actually drop down to some CLI/text interface/programming language?
Nobody will argue about the advantages of a WYSIWG text editor, file manager or spreadsheet over their CLI counterparts.
The problem is that for any of these kinds of applications it is possible to do either a great GUI, which enables maximum user productivity, or a bad GUI, which slows down the user.
Sadly, if I try to remember the best user interfaces for such programs, the award still goes to some ancient MS-DOS programs that I had been using 30 years ago, i.e. the Brief editor for programmers, the Xtree Gold file manager and the Lotus 1-2-3 spreadsheet.
Those programs did not have real GUIs, because they had to use the text user interface of MS-DOS, but they already had the most important features of any GUI, e.g. tiled windows, pop-up windows, menus, histories for any kind of user input, many kinds of visual selection, scripting, keyboard macros, and so on.
After you learned the keyboard shortcuts for menu commands and maybe you also developed your own custom keyboard macros, it was possible to perform any task on those ancient programs much faster than on any modern equivalent.
I am not sure which is the reason, but maybe those old programs were more efficient because the mouse was optional. You could use a mouse if you had one, but the programs were perfectly usable without a mouse.
I assume that because of that, the developers paid a lot of attention of how to ensure that every task could be done by pressing a minimum of keys.
Even if most modern GUIs are supposed to also support a keyboard-only use, in practice I always discover that some operations are either impossible or extremely awkward when not using the mouse. (when using just the keyboard, a graphic selection cannot be expected to work as well as with a mouse, but any kind of text selection should be as fast or faster)
A point-and-click user interface is supposed to be better for a casual user, who cannot be familiar with the complex keyboard-shortcut sequences that might be needed for performing a task at maximum speed. This was certainly true for almost all GUIs in the first one or two decades of their use, but many modern GUIs have a lot of very well hidden and hard to discover options, so being a GUI becomes no improvement over a CLI where you need to read the man page.
In conclusion, there is no doubt that GUIs should be better for many tasks, but in practice one encounters too many bad GUIs, for which it may be simpler to use ancient CLI alternatives.
> Nobody will argue about the advantages of a WYSIWG text editor, file manager or spreadsheet over their CLI counterparts.
I think you've never met a LaTeX fan.
Regarding spreadsheets and file managers: for simple tasks I agree they can be better than the command line. But for even a moderately complex spreadsheet I usually prefer a python script, and I've seen office workers spend literal hours doing something that could take me under a minute using the command line.
I wonder what versions of those GUI applications that you like have you used.
I was very content with the GUI of Word, Excel or PowerPoint of 20 years ago.
On the other hand I despise the recent GUI of MS Office, where many options are not grouped in a way that I would consider rational and it is frequently very difficult to discover where some options are hidden.
The same with Internet browsers. I was very content with the GUI of Netscape Navigator, then Mozilla.
Firefox was worse than Mozilla since the beginning and it became worse and worse, with various options becoming more and more hidden or disappearing completely. Opera had retained for a longer time than other browsers a traditional, more customizable GUI, but then it has also succumbed to the modern fashion of dumbing down the GUIs.
When the tabbed windows were introduced in the Internet browsers, that was a great improvement. However, with this exception, in my opinion the browser GUIs have become worse, not better, than the old GUIs, because I have lost control over many features that I could configure in the past, while other surviving options have become increasingly difficult to discover.
So if we refer to their current versions, most of your examples are for me exactly the examples of the worst modern GUIs.
So you are saying that MS Office products have 'truly great UI design'? You must be using a different version than me. The web-based version is full of bugs and the traditional desktop version is neither a good choice for well trained nor for complete newbies. Instead it is some kind of weird compromised.
To give an example of not so great design: One thing that bothers me every day is the dialog that comes up when you want to 'save as' a file. There are about 3 different versions you can go through, depending on, if you want to use Sharepoint/Teams, OneDrive or you local machine to save the file. They all have different capabilities (e.g. some allow creating new folders), appearances and some are only usable if you want to use a recently used location.
Granted MS Office certainly has not the worst UI design, but in my opinion, those applications are pretty far away from 'truly great UI design'.
Automation and composability are an important part of a UI. CLI tools also generally beat GUIs in speed. A hypothetical text2pdf runs almost instantly. Doing the same thing with Word can take 5 minutes.
Have the same feel when two months ago i switched from 10 years vim usage to intellij for code. The UI is so well designed, the "everyday's coder problem is so well understood in the UI layer its just a pleasure to work with this tool. The UI just reflect that. Everything is just so well organised. As a web UI developper, and despite material/responsive requirements i refer often to IntelliJ's GUI. Its just so well designed.
OpenSSL can have this kind of UI. Its just a matter of understanding user requirements.
240 comments
[ 2.7 ms ] story [ 229 ms ] threadI agree with your point about CLI. At the same time, I wish we had more GUI *inside* CLI. For example, an interactive and pretty MAN page that's not just text, but has clear borders, boxes, buttons (with keyboard shortcuts), and uses different colors for different sections (e.g., command description, arguments, examples, etc.)
To clarify, I'm not saying the GUI is actually better. But I wish we could bring some of those conveniences to the command line experience (way better autocomplete and command discovery).
With the CLI at least you can cut and paste the options from somewhere else.
Set-and-forget still requires you to know what to set.
Some common functionality in tab ABC, and then opt-in for Headache Mode if necessary.
Of course, for precisely that reason there are lots and lots of examples (particularly under "modern" "clean/flat" design tastes) that go to the opposite extreme and remove too much, get too information light and hide or eliminate stuff that's genuinely very important. But in the specific context of security software at least the current best practices thinking is that the fewer knobs and dials the better. A huge amount is purely legacy from when there were many more tradeoffs to be made in available compute power/memory vs security, but that fell away long ago in settings that would make use of complex CAs anyway vs something simpler. Not that simple CLI/text configs can't be easy too, look at WireGuard.
This topic strikes a little close to home right now too since I just went through an incredibly frustrating period of trying to put together some internal CAs with modern best practices (like name constraints) and it was quite the maze to get through. And having done it (or at least Good Enough) it definitely didn't need to be that hard. Ah well. Although then again, my experience also highlights to the perils of GUIs at the same time: I would have just used something like the built-in web gui CA generator on OPNsense, except it's so simple it lacks name constraints. Which then led me back into the red in tooth and claw world of openssl and ca config files. So there's the binary of both, an over simplistic GUI and an over complex CLI. Perhaps there are better tools bridging that gap but my searching failed :(.
Thank you for your time!
Not everything has to be visible all the time, settings can be grouped, and the user can be guided through the settings piece-by-piece, instead of just putting every option next to each other.
This does not have a GUI because making a good GUI is alot of work + the target demographic are more technical people that are able to use the CLI, so why put in all the effort?
I think that good UIs increase discoverability, add guardrails, and make operations easier for people with different levels of familiarity.
Neither the linked GUI nor the OpenSSL command line tool make the grade imo.
How openssl is today is probably not so bad for what it is, though. The GUI design here might be doing it a disservice by intentionally not having as much hierarchy. But this is actually a really bad argument for why CLIs are better. That’d be like arguing that closets are better for organization than shelves because when you haphazardly throw everything from your shelves into your closet, your room looks cleaner when the closet door is shut.
In theory it could be such a demonstration, but openssl's command line interface is... pretty bad, too.
Some of doing little is great. It does not let you erratically mess with your encryption options, it does not let you apply a bad algorithm, and it does not let you use one algorithm for a task it's badly suited for (well, up to a point).
But some of it is just things the library doesn't do. You can't run a PKI with it, you can't deal with industry-standard file types, and your options for interoperability are just none.
It's really good to make those nice focused libraries that people can actually use. But that doesn't remove the need for kitchen-sink packages that will solve every problem under the Sun.
Thankfully, the situation has improved; at least some old stuff has been moved off into a module in 3.x, and a lot of cruft has been cleaned up. But still, it’s hard to not want to pick a library with reduced scope, if you at all can.
But that doesn't mean the kitchen sink one is useless.
You should determine first what options are independent of other options, and which options aren't.
Oh, and just like you have to know a ton about how media containers, streams and codecs actually work to use the ffmpeg API, you likewise need to be a crypto expert to use the OpenSSL API. Almost the same is true for their CLIs as well, though.
They expose a C API as a Bash API. There is just no reason not to use the higher level one.
This changed after the Heartbleed fiasco. One of the many criticisms of OpenSSL maintenance was that people had come to rely on the command utility for production despite the official lack of support. The libressl fork made long-term maintenance and backward compatibility promises of the command utility explicit. Subsequently, the reorganized OpenSSL project also adopted this mandate.
Still, I'm not sure you could say today that the command utility is now designed or intended to expose the API. For one thing, backwards compatibility is now the primary concern regarding the utility, but the underlying APIs have changed considerably (including in some cases wholesale shifts to a different model) as part of improvements efforts for the OpenSSL API, ABI, and overall implementation. So in some ways the utility is even more divorced from underlying OpenSSL architecture than before. And this shows in the ever increasing set of options which often don't directly map to the underlying APIs, or for which their implementation in the utility is complicated by interaction with older options.
https://ffmpeg.org/doxygen/trunk/ffplay_8c_source.html
One that runs it, not so much.
It was such a useful tool. I've endeavored to recreate that a few times in other teams when I encounter a tool with a --help that's more than a page long. Really helps new people figure things out.
It was, uh... It had a lot of options. It was immediately obvious that it was beyond useless because any use of the tool started with a search in the documentation, just as I would if I was just calling the API. No time saved and had an excessively small niche.
From an evolutionary standpoint our intelligence is heavily oriented toward navigation of complex terrain, to locate food sources and avoid danger. So translating this API into a structured layout makes it more suited to our natural learning faculties.
Like others mentioned FFMPEG is even complex :-)
https://github.com/MichalGniadek/klask
https://github.com/chriskiehl/Gooey
https://www.reddit.com/r/photoshopbattles/comments/9w663a/ps...
Highlight tabs that had values set.
[1]: https://news.ycombinator.com/item?id=30797575
Just for fun, here's a list of things IMHO this one does right, and the wget one does wrong:
* They actually have an option for specifying where the output data goes, and it's right at the top.
* "Open..." buttons. OpenSSL doesn't ask you to type local filesystem paths directly into the thing.
* There don't seem to be any sentinel values in here. Every optional config option has a checkbox or radio button to turn it on, instead of some magic like setting it to -1.
* The spacing is a lot better. I don't see any places where the connection between checkboxes and their text entry fields is ambiguous, if you're willing to assume left-to-right, top-to-bottom associativity.
And here's a few things it still does wrong:
* Text boxes that won't get used should be grayed out.
* The text output and display options make no sense at this stage. Instead, allow the user to configure what they see after running. Output everything, and use various kinds of disclosure widgets to to filter the output.
* Multiple rows of tabs are bad [2]. These should be separate apps, like how LibreOffice Writer and Impress use the same backend but have separate start menu entries.
[2]: https://www.nngroup.com/articles/tabs-used-right/
It's fine to shit on proprietary garbage by huge companies which are involving UX experts into their development process such as Reddit or Facebook UI, but what you're doing is not cool.
[1] http://www.martin-achern.de/wgetgui
The best UI I've worked with so far is Fusion 360. Like most 3d modelling tools it has a fairly steep learning curve, but it does a fantastic job of making your life easier. It has a bunch of UI dialogs for parameter setting (some of which are better than others) that do a good job with both orthogonality and conditionality. I really wanted to like blender but just about everything in it feels rotated 90 degrees to how I'd do it.
That nobody uses outside of games.
And Fusion 360 basically had to write their own entire GUI engine to do all the stuff they wanted.
Infuriatingly, Fusion 360 doesn't provide a Linux version which should be stupidly easy to do since they wrote their own GUI.
Also, everything in Fusion 360 could be done in Qt5 without a lot of work, it's just that getting all the hints and the second level details (like maintaing the selection when you switch tools) is a real bear.
Since Alias corp. was later acquired by Autodesk in the early 2000's, you can imagine Fusion 360 as being the symbolical evolution of it. Especially considering the current Alias UI has not changed much since 1999! [3][4]
If interested more on this topic, fun HCI bath-time reading: Gord Kurtenbach's 1993 dissertation on The Design and Evaluation of Marking Menus [5]. Not surprisingly, from Alias/Wavefront he went on to head Autodesk Research for most of the 2000's.
[1]: https://books.google.com/books?id=7wEAAAAAMBAJ&pg=PT89&lpg=P...
[2]: https://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.86...
[3]: https://youtu.be/cVusw4JNK0s (1999)
[4]: https://youtu.be/323fmUgwMyI (2022)
[5]: https://damassets.autodesk.net/content/dam/autodesk/www/auto...
I think of Fusion 360 as being more descended from Inventor (which defined a lot of my early expectations for 3d modelling). I'm only a hobbyist and I used Fusion 360 with large (mesh) surfaces (it got significantly better at meshes recently) and it definitely got clunky, although the performance is fine when working with parameteric brep objects.
I've been using Autodesk products (starting with 2D AutoCAD on a 286 running DOS) for quite a while (35 years).
I can think of so many off the top of my head: Word, Excel, PowerPoint, Chrome/Firefox, Acrobat, Audacity...
And this is before you get into stuff dealing with pictures, like Photoshop or literally almost every modern game.
You can do most of these on the command line (see ffmpeg, imagemagick, etc.) but I'm pretty sure > 99.99% of people do not prefer a CLI version of such applications over the GUI forms.
IMHO the power of CLI apps isn't in their orthogonality or presentation, but ease of automation and composability, and the ability to cram a ton of features into a single interface without really caring about how easy it is to use for 99% of people.
Word processors: are a real improvement over using ed at the CLI, or really any scripting tool, to process large amounts of human-readable text. Although in many cases, simple markup on simple text in a simple text file can be excellent.
Spreadsheets: for all that people complain about spreadsheets, they do a few things fairly well (cellular data model, dependency-graph-driven computations)
PowerPoint: I should have mentioned that "sheets/slides/presentation" apps are one of the best examples of this; features like "Align vertically" are a great example of where UIs make certain operations very intuitive and easy
Browser: I dunno, I prefer e-links :)
Music editing: Actually, the whole world of track-based video and music editing. This is a such a huge improvement over any other system (musicians and video professionals may disagree), specifically the ability to quickly view, cut and paste, and combine multiple parts of longer videos. A lot of this depends on a concept that only really became feasible once disk storage really became huge: https://en.wikipedia.org/wiki/Non-linear_editing
Composability and orthogonality go hand in hand- much of my argument rests on the idea that composing orthogonal features is trivial for UIs, whereas composing interacting features leads to combinatorial complexity and can really only be expressed in code (and possible visual programming- being used more and more commonly to give artists GUI control over complex code-like operations).
The automation is the last interesting bit- will visual programming ever become ubiquitious, so that most people doing automation don't actually drop down to some CLI/text interface/programming language?
The problem is that for any of these kinds of applications it is possible to do either a great GUI, which enables maximum user productivity, or a bad GUI, which slows down the user.
Sadly, if I try to remember the best user interfaces for such programs, the award still goes to some ancient MS-DOS programs that I had been using 30 years ago, i.e. the Brief editor for programmers, the Xtree Gold file manager and the Lotus 1-2-3 spreadsheet.
Those programs did not have real GUIs, because they had to use the text user interface of MS-DOS, but they already had the most important features of any GUI, e.g. tiled windows, pop-up windows, menus, histories for any kind of user input, many kinds of visual selection, scripting, keyboard macros, and so on.
After you learned the keyboard shortcuts for menu commands and maybe you also developed your own custom keyboard macros, it was possible to perform any task on those ancient programs much faster than on any modern equivalent.
I am not sure which is the reason, but maybe those old programs were more efficient because the mouse was optional. You could use a mouse if you had one, but the programs were perfectly usable without a mouse.
I assume that because of that, the developers paid a lot of attention of how to ensure that every task could be done by pressing a minimum of keys.
Even if most modern GUIs are supposed to also support a keyboard-only use, in practice I always discover that some operations are either impossible or extremely awkward when not using the mouse. (when using just the keyboard, a graphic selection cannot be expected to work as well as with a mouse, but any kind of text selection should be as fast or faster)
A point-and-click user interface is supposed to be better for a casual user, who cannot be familiar with the complex keyboard-shortcut sequences that might be needed for performing a task at maximum speed. This was certainly true for almost all GUIs in the first one or two decades of their use, but many modern GUIs have a lot of very well hidden and hard to discover options, so being a GUI becomes no improvement over a CLI where you need to read the man page.
In conclusion, there is no doubt that GUIs should be better for many tasks, but in practice one encounters too many bad GUIs, for which it may be simpler to use ancient CLI alternatives.
I think you've never met a LaTeX fan.
Regarding spreadsheets and file managers: for simple tasks I agree they can be better than the command line. But for even a moderately complex spreadsheet I usually prefer a python script, and I've seen office workers spend literal hours doing something that could take me under a minute using the command line.
I was very content with the GUI of Word, Excel or PowerPoint of 20 years ago.
On the other hand I despise the recent GUI of MS Office, where many options are not grouped in a way that I would consider rational and it is frequently very difficult to discover where some options are hidden.
The same with Internet browsers. I was very content with the GUI of Netscape Navigator, then Mozilla.
Firefox was worse than Mozilla since the beginning and it became worse and worse, with various options becoming more and more hidden or disappearing completely. Opera had retained for a longer time than other browsers a traditional, more customizable GUI, but then it has also succumbed to the modern fashion of dumbing down the GUIs.
When the tabbed windows were introduced in the Internet browsers, that was a great improvement. However, with this exception, in my opinion the browser GUIs have become worse, not better, than the old GUIs, because I have lost control over many features that I could configure in the past, while other surviving options have become increasingly difficult to discover.
So if we refer to their current versions, most of your examples are for me exactly the examples of the worst modern GUIs.
To give an example of not so great design: One thing that bothers me every day is the dialog that comes up when you want to 'save as' a file. There are about 3 different versions you can go through, depending on, if you want to use Sharepoint/Teams, OneDrive or you local machine to save the file. They all have different capabilities (e.g. some allow creating new folders), appearances and some are only usable if you want to use a recently used location.
Granted MS Office certainly has not the worst UI design, but in my opinion, those applications are pretty far away from 'truly great UI design'.
OpenSSL can have this kind of UI. Its just a matter of understanding user requirements.