> Is it better to make up common rsync “recipes” for people to use, or is it better to let folks have access to ALL of the flags [...] and pick’n’mix what they want?
I think both. This is the hard part about GUI design -- it is pretty easy to make a list of 100 command-line options listed alphabetically on the man page, but for GUIs, people expect much more.
There should be some sort of logical grouping. One area of the screen would be options related to what is transferred, a second area is metadata, the third one is speed-only optimizations, fourth is logging and so on. Having "hardlinks" all the way on the left and "symlinks" all the way on the right does not make a good GUI.
There is a very wide variety of input elements, so checkboxes are are not the right solution all the time! For example, while having separate "--verbose" and "--quiet" options is fine for CLI, one would expect to see a drop-down or a slider in the GUI. This will decrease cognitive load because there are less things to read and there is no need to worry what happens if you check both.
Another great GUI feature is dynamicity -- take the metadata for example. A good design might have a dropdown: "everything", "nothing", "x-bit only", "custom". Most of the time, first three options would be fine, but "custom" will show entire new group of checkboxes.
... this was just my subjective design, based on how I use the program. If I were trying to do a popular product, I'd have to spend some time asking people / looking at the forums to determine which sets of features do people use. For all that I know, there is a super common case for "--group" without "--owner", and this is just me not knowing about it.
I would think there maybe a "command-line" version of GUI design: supply limited default buttons for common options, but allow user customization. For example, I would love to have the button from author's design but tune it specifically to my need including running a specific set of "command lines".
rsync do actually support profile via option aliasing. rsync uses popt(3) to parse its command line options and popt allows you to define aliases, so you can put something like this in ~/.popt:
rsync alias --sync -rpcLDvz --chmod=D0755,F0644
A call "rsync --sync foo@bar:baz/ baz" will expand the command into "rsync -rpcLDvz --chmod=D0755,F0644 ...".
The "program alias newopt opt" syntax is actually popt's thing (see Option Aliasing[1]) and it works with everything that uses popt(3) for its command line parsing.
> There should be some sort of logical grouping. One area of the screen would be options related to what is transferred, a second area is metadata, the third one is speed-only optimizations, fourth is logging and so on. Having "hardlinks" all the way on the left and "symlinks" all the way on the right does not make a good GUI.
This is exactly what Microsoft have done with its ribbon interface[1] which is actually a mix of menus and toolbar with most commonly used functions logically grouped and prominently displayed. These Ribbons also changes as the context changes. Frequently used functionality gets into quick access ribbon displayed. There is also context sensitive popup toolbar available on right click.
I think I would mind //graphical menus// less than the change to an always in your face ribbon.
What I loved most about the seriously ancient UIs, way back in the Win 3.x days and forward, was that not only were the options categorized, they also had prominently displayed (right justified instead of left) the keyboard shortcut you could memorize if you knew you were doing it frequently. Yes, that sort of still exists, but you have to go out of your way to do something extra to see it: these days you have to tap a modifier key while in the focus area of the menu.
> I think I would mind //graphical menus// less than the change to an always in your face ribbon.
The ribbon has always been collapsible / "auto-hidable" to just a menu bar (double-click the active tab; admittedly not entirely easily discoverable). It's very much a graphical "pull" menu in the classic sense in that mode and the two-step Alt+ shortcuts might feel a lot more understandable/close-to-home in that context, as it is just like menu bars have always worked (Alt+E,C or Alt,E,C for Edit > Copy as opposed to Alt+H,C or Alt,H,C for Home > Copy; and in Office the old menu shortcuts still work to this day if you have muscle memory of them, you just don't get visual feedback).
> What I loved most about the seriously ancient UIs, way back in the Win 3.x days and forward, was that not only were the options categorized, they also had prominently displayed (right justified instead of left) the keyboard shortcut you could memorize if you knew you were doing it frequently. Yes, that sort of still exists, but you have to go out of your way to do something extra to see it: these days you have to tap a modifier key while in the focus area of the menu.
In addition to the Alt bubble pop ups, hovering every ribbon command has always provided a tooltip with command name and description and in that tooltip has always shown the most direct shortcut key in bold if there is one. Maybe silly to use the mouse to discover the fastest shortcut, but it's roughly the same discovery process as classic menus. (For instance, Format Painter shows Ctrl+Shift+C and Ctrl+Shift+V as opposed to Alt+H,F,P.)
(Not to mention, Windows stopped showing Menu keys by default way back in Windows 95, and even stopped showing some menus entirely unless Alt was pushed over the years. So the Windows 3.x days where everything always had underlines and macOS-like right-justified keyboard keys were relatively fewer than the many years of push Alt to see keyboard stuff on Windows. The ribbon wasn't a big shift in that department.)
> The ribbon has always been collapsible / "auto-hidable" to just a menu bar
Sadly, this is no longer true in Outlook, at least in the version recently pushed to my work computer. The only two options now are the "simplified ribbon" and the classic ribbon (https://support.office.com/en-us/article/use-the-simplified-...). You can no longer hide the ribbon completely. I assume other Office applications will soon follow suit.
Both options for the ribbon still support collapse and auto-hide. It may be confusing that the switch between Simplified and Classic Ribbon is a Caret button that looks like it should handle collapse / auto-hide (but that's still the odd boxed arrow icon in the title bar, right click menu options, and double-click the active tab name).
(Interesting to me is that the Simplified Ribbon in Outlook actually feels more useful to me and less space wasting than its Classic version and I switched my preference in Outlook from collapsed to shown because of it.)
I think both. This is the hard part about GUI design -- it is pretty easy to make a list of 100 command-line options listed alphabetically on the man page, but for GUIs, people expect much more.
There should be some sort of logical grouping. One area of the screen would be options related to what is transferred, a second area is metadata, the third one is speed-only optimizations, fourth is logging and so on. Having "hardlinks" all the way on the left and "symlinks" all the way on the right does not make a good GUI.
There is a very wide variety of input elements, so checkboxes are are not the right solution all the time! For example, while having separate "--verbose" and "--quiet" options is fine for CLI, one would expect to see a drop-down or a slider in the GUI. This will decrease cognitive load because there are less things to read and there is no need to worry what happens if you check both.
Another great GUI feature is dynamicity -- take the metadata for example. A good design might have a dropdown: "everything", "nothing", "x-bit only", "custom". Most of the time, first three options would be fine, but "custom" will show entire new group of checkboxes.
... this was just my subjective design, based on how I use the program. If I were trying to do a popular product, I'd have to spend some time asking people / looking at the forums to determine which sets of features do people use. For all that I know, there is a super common case for "--group" without "--owner", and this is just me not knowing about it.