I have been working with a bunch of software (Kyle Kristopher’s excellent TAASSC and TAALES) that have Graphical User Interfaces (GUIs).
GUIs are great for ease of use, but when it comes to reproducibility, they often fall short. On the other hand, Command Line Interfaces (CLIs) tend to be much better suited for workflows that need to be rerun consistently or when you would like to automate the running of several experiments consecutively. However, both types of tools could do better in ensuring that past work is easily repeatable.

The GUI Problem: Convenience vs. Control

GUI-based tools are often designed with interactivity and accessibility in mind. They allow users to adjust settings, click buttons, and visually inspect results. However, this interactivity often comes at the cost of transparency:

1. Hidden State: Many GUI tools store configuration settings in memory or in obscure locations that are not easily accessible. Kyle’s tool preserves setting from run to run, which is very helpful. For other systems a user might tweak sliders and dropdown menus without having a clear record of what was actually used to generate a result.
2. Reproducibility Issues: Since the process relies on manual input, it becomes difficult to repeat an exact run later unless the user painstakingly documents every step.
3. Lack of Scriptability: Unlike CLI tools, which can be run as part of automated pipelines, GUI tools often require manual interaction, making them harder to integrate into systematic workflows.

One Fix: Exportable Run Configurations

One way GUI tools can improve their reproducibility is by allowing users to export a small, human-readable file (e.g., YAML, TOML) containing all relevant settings from a given run. This file could then be used to:
• Reload the exact same configuration later.
• Share a complete record of a run with colleagues.
• Allow the tool to be run in a batch mode using the exported file.

This would give users the convenience of a GUI while retaining the ability to revisit and modify previous work in a structured way.

Why CLI Wins in Reproducibility

CLI tools generally have a leg up when it comes to reproducibility. They allow users to specify explicit arguments, making it easier to track what parameters were used. Moreover it is easy to record the command that was issued. However, even CLI tools can fail in ensuring complete reproducibility unless they explicitly capture metadata.

Best Practices

The best tools should either:

1. Embed Metadata in Output Files: Any file produced should contain a metadata section with all the parameters used in its creation. For instance, a text-based output could start with a block listing the command-line arguments, the software version, and any relevant hashes.or
2. Generate a Standalone Config File: As an alternative, tools should produce a separate run configuration file (strict YAML, TOML, or JSON) that contains all relevant information about the run, including input files, parameters, and any dependency versions. The tool should accept this file back into the tool to rerun the process.

Typically these tools pull in external data files.

3. Include Hashes: If possible, the tool should generate cryptographic hashes of input files and outputs to ensure integrity and detect modifications.

By embedding metadata in outputs or producing explicit config files, CLI tools can ensure that results are fully reproducible even when running across different environments.

Conclusion: Every Tool Should Capture Its Own Provenance

Whether a tool is GUI- or CLI-based, it should take responsibility for making its runs reproducible. This means allowing users to save structured records of their work in a way that can be reliably reloaded in the future. GUI tools should provide explicit export files, and CLI tools should ensure metadata is always captured—either in output files or via standalone configuration files.

By prioritizing reproducibility, we make research, data analysis, and engineering workflows more robust, shareable, and transparent.