-
Notifications
You must be signed in to change notification settings - Fork 18
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
CLI: Improve User Experience #12
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Overall I really liked this proposal. There are some areas where it was hard to tell what you're actually proposing, and what you're suggesting we do in the future. I would prefer that we keep proposals about what we are going to do in the short term, and not a blank check for future feature development.
Also, try and stay consistent with the structure. I really really really loved how you started out by driving everything with a user story, but for some reason that didn't get carried throughout the doc. Also some cells in the table are missing which is sort of weird.
tctl activity complete {options} | ||
``` | ||
|
||
### Integrate with Bash/zsh |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This isn't expected to work unless you're compiling the CLI yourself right? Even then, won't it require a script which injects completions in *_profile
?
Create a default config file that CLI will look into to read them and use in commands. | ||
If the user passes an option explicitly, ignore the defaults from the config file | ||
For start, support the following default options through the file: | ||
- `--namespace` |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's not clear what will actually be added and what you're suggesting is nice to have in the future. I assume the only actual change proposed is
For start, support the following default options through the file:
But that's hard to grok.
For start, support the following default options through the file: | ||
- `--namespace` | ||
|
||
### Standardize wording |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why are some of these missing meanings?
|
||
### Bring consistent schema for operations on multiple entities | ||
|
||
Allow operations to run on multiple entities by providing multiple identifiers or by filtering entities by a query |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What happened to the user stories?
|
||
# Adoption strategy | ||
|
||
Make annoucements about all of the CLI changes when we release them. Update the CLI documentation. Expect some users to learn from the CLI itself if they miss the annoucements/checking docs |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Migration guide maybe is a good idea
to be clear is this something we are only discussing or are we actually working on this right now? |
This looks really great to me. Shell completions would be huge, and consistency of passing more things as positional arguments rather than "required options" would also be a massive improvement. Also have the same question as Shawn. I know @wxing1292 showed some interest in potentially Rustifying tctl. I'm not necessarily advocating for that as just tuning up the existing implementation is almost certainly cheaper, but it's something to consider. The argument parsing libs for Rust are excellent. Also I know this seems hilariously trivial but in my experience writing CLIs people really, really love colored output. We should figure out where and how we'd like to work that in. It's super cheap to do and people go bananas for it. |
i made colors the most prominent part of my CLI workshop 😹 https://github.com/sw-yx/egghead-cli-workshop#cli-workshop |
@Sushisource since Rust has generics this makes customizing print outputs much easier than in Go 👍 |
Summary
Refactor and improve a number of items in CLI, such as semantics, commands discoverability, integration with bash/zsh, rethink global vs command options, improve UI, support config file for default option values
Motivation
The current CLI was designed seemingly for the internal use and the good UX wasn't among the top priorities in the initial implementation.
The UX lacks in the number of areas such as consistency, semantics, commands discoverability, no integration with bash/zsh, few options are global when they arguably shouldn't be, no default configs file support, UI that could do a better job helping users to "scan" though the
help
output