[objective] Command Line Usability

[viega]

For configuration

Ideally, we wouldn't want to directly expose our configuration language to anyone except power users (the config language is not-so-secret sauce for making the uncommon things easy).

And we've done a lot of work toward hiding it. For instance, the chalk load command can take a URL. But, off-the-shelf configs need to be tweaked... people need parameters. And they shouldn't have to drop into a text editor to provide them.

People should be able to configure based on the problem they're going to solve. If they want to tackle something like SBOM implementation, they shouldn't have to navigate a lot of configuration that's irrelevant to the problem. It should be easy to find the configuration UI they need, whatever it is.

Any UI we provide here needs to be not only incredibly easy to use, it needs to be easy to keep in sync w/ any changes to chalk over time.

Eventually, 'wizard'-like interfaces or other similar things might be great, but just being able to reliably configure stuff easily from the command line would need to come first!

For help

We've worked hard to make sure we can provide consistent help in-command and on the web. But the UX for the in-app help did NOT get finished.

The framework is all there to make help easy to search, and easy to browse individual help items. The help's all available. However, we have not finished the presentation layer (everything looks ugly with lots of formatting problems, and while full text search works, it can produce an unmanageable mess of results at the moment).

Beyond that, we should also be considering how much value people would get if we had better "navigation" primitives, both for the help system, and possibly for operating the command in general (e.g., some basic TUI options, probably via wrapping notcurses).

Other commands

We definitely want to improve the user experience for any common command-line operations. For instance, when using the chalk extract command to view data about artifacts in real time. Based on early feedback, we learned most of the time it's better to only show small summary reports for command line operation; but when people do want them, grepping a log and piping it to jq isn't a great, easy to use experience for me personally.

We could imagine a chalk log command that focuses on just removing the cognitive burden, a full TUI interface, both, or none of the above, based on feedback.