GUI vs advanced config

[goebbe]

I certainly hoped for the config.yaml to stay in "advanced"-mode.

For advanced configs, in a certain respect .yaml-files provide a better UI than most GUIs:

With a GUI for "everything":

• you have your own dialog (and quirks) for each config aspect,
• you cannot put comments,
• it is harder to test variants,
• it is often harder to get an overview about all configs, (many views/ panes/ subdialogue)
• users are easily confused since the GUI expose (possible) complexity - even for users with simple use cases.

I don't even want to think about a GUI for hooks, exclude patterns, global vs. per repository settings. This
could easily become overwhelming/ confusing / messy. 😢

Where most GUIs shine:

• provide easy access to monitoring
• easy access to existing snapshots
• easy access to most common actions
• provide a familiar interface for common tasks (e.g. select elements like several folders as sources)

I would prefer a relatively simple GUI, that is limited to the most essential tasks:

• Add/delete backup repositories (with labels)
• set/ change a passphrase
• Select sources/ paths
• A simple schedule dialogue (with on_startup)
• A simple retention dialogue

With good defaults, this should be good enough to get everybody up and started.

The complicated advanced configs could then be done/changed directly in the config.yaml, e.g.

• hooks (requires text editing anyway)
• exclude_patterns (requires text editing)
• advanced settings for scheduler (e.g. cron-like) (requires editing?)
• limits (for advanced users only)
• compression settings (advanced only)
• passcommand:

Vykar could put/ keep (commented) examples for advanced configs, which would make advanced configs accessible.

[goebbe]

Just to complete my thoughts about the use of a config.yaml for advanced configs:

As an example I take Vortas GUI:
I like most of Vortas config possibilities, however there are some shortcomings that vykar-gui should avoid:

• the settings are scattered over a total of 4 tabs plus a separate setting/about button
  • a single tab can have different sub-panes, e.g. "Schedule" has 4 different views, for Schedule, Networks, Log and Shell Commands
  • these sub-panes are ordered from the top to the bottom - which make them hard to navigate
  • The "Sources" pane has the "Manage Exclude Items..." button at the bottom - which opens a new dialogue with another five(!) tabs.
  • As a result of the many tabs/ views/ panes/ dialogues it is really hard to get a quick overview of the settings, even for relatively simple setups. Essential settings are hard to navigate/ to spot.
• the most advanced configs have a GUI that is hard to use:
  • Schedule > Shell Commands: (the equivalent of vykar hooks?)
  • There are only a one-line text fields for Pre-backp, Post-backup, Extra arguments
  • Sources > Manage Excluded Items
  • The 5 tabs try hard to make excludes easy but are more confusing than anything else, despite the fact that re-includes are not even possibles.
• Vorta provides many config possibilities, but there are still advanced configs that are not integrated in the GUI. Try to change the advanced options for a repository-setup (e.g. remote_path). It is not in the GUI.
  • It is really hard to integrate all possible advanced configs in a GUI

In short:

• There is a price to pay, if you try to integrate every possible config into a GUI: GUIs tend to become complicated and confusing. Configs are hard to navigate. Settings are hard to spot or hidden in submenus/ dialogues.
• It is worth to think about what degree of possible complexity you want to expose in the GUI.
  • Would it make sense to expose the cron-like specs for schedule in a GUI? Or is this an advanced feature that would confuse most users?
• In my experience, advanced configs are often better off with an advanced / flexible interfaces.
  • yaml provides a good balance between nice readable structure and the possibility to express advanced settings. e.g. multi-line hooks.

For advanced setting, I would, hands down, prefer a commented yaml (with syntax highlighting) where I could just comment/ uncomment/ adapt in a multi-line "Text-editor like" UI.
My yaml.config provides a very good overview about my actual settings, since it reflects what actually matters in my scenario. Whereas a complex GUI would also expose a large set of options / possibilities that are not relevant, for me.

Perhaps it is also worth to think about user scenarios? Target user groups and their requirements?

Sorry for the long text. Hope this is helpful anyway.

[m3nu]

It's a good perspective and I generally agree.