tig is pretty solid
Ask HN: Good examples of interactive command-line user experience?
21–30 of 83 posts
Re: Ask HN: Good examples of interactive command-line user experience?
#22git
For the love of your chosen deity, please do not take git as a good example to base your CLI UX on..
Maybe you just need to read the manual? Hmm...
Re: Ask HN: Good examples of interactive command-line user experience?
#23Oh and don't forget figlet when you need that dope ASCII logo banner.
Re: Ask HN: Good examples of interactive command-line user experience?
#24git
Sad to see this in the grey. Git is unintuitive to those who don't understand it. If you read about its internals and learn how it works, the command line gets much better. It's well documented and it gives you a whole lot of power and insight into the inner workings of the VCS. Things like launching your editor to do more complex commands, plugging a script into git bisect, these are all great design choices.
Re: Ask HN: Good examples of interactive command-line user experience?
#25It's a terrible idea, but an excellent example of experience: https://github.com/nvbn/thefuck [TL;DR -- typo a command, type 'fuck', will run the command you should have run]
Oh my, this is hilariously awesome.
Re: Ask HN: Good examples of interactive command-line user experience?
#26I would recommend that you check out the Heroku CLI Style Guide: https://devcenter.heroku.com/articles/cli-style-guide There are many different teams within Heroku that need to provide interactions for developers via CLI whether its for dynos or data services. The guide was a way to codify building a consistent interaction that all product managers and engineers could follow. Disclaimer: I work for heroku.
One thing not mentioned there is exit statuses. I think they're just as important a thing to think about, up there with what arguments to accept.
Re: Ask HN: Good examples of interactive command-line user experience?
#27Yes, tmux.
- tmux counts as a TUI UX. it is backed by ncurses (https://en.wikipedia.org/wiki/Ncurses)
- colors: it supports 256 colors, 24bit colors landed in 2.2 (but haven't used it)
- layouts: 1) supports splitting multiple command lines into "panes" which are resizable 2) supports custom layouts and arrangements for panes 3) you can "zoom" in on panes via `C-b z` 4) you can actually run other TUI applications within it
- interaction: 1) tmux also forks itself into a server in the background so you can de/re-attach your workspace 2) you can create and move between collections of panes, what tmux calls "windows" 3) command-based, so configuration via ~/.tmux.conf uses the same language as scripting 4) tmux can be scripted / remote controlled, you can even send-keys and copy the contents of panes
- help: the tmux manual is superb (https://www.freebsd.org/cgi/man.cgi?query=tmux)
Downsides are, I still get glitchy issues when using vim / unicode / colors in tmux panes which are difficult to diagnose. `reset` normally fixes it. It's been this way for years, and I don't want to even begin figuring out what the hell is happening because I'm using too many plugins. Considering starting from scratch. So if you get into tmux/vim/other CLI stuff, the simpler you keep your config, the better off you'll be.
(P.S. I am the author of The Tao of tmux, a book you can read free online)
Re: Ask HN: Good examples of interactive command-line user experience?
#28The `micro` test editor is fantastic. GUI-standard keyboard shortcuts. Mouse support. Ability to execute commands while editing test.
Re: Ask HN: Good examples of interactive command-line user experience?
#29git
For the love of your chosen deity, please do not take git as a good example to base your CLI UX on..
I think there are a number of great things to learn from the git UX.
- sub commands (and sub sub commands) provide a high level abstraction over the many different tools and features. The "toolkit" approach allows for easy expansion and refactoring of individual features, and is entirely pluggable by end users. It even provides tools to interface seamlessly (git rev-parse --parseopt; rev-parse is amazing and allows you to wrangle git types trivially). Git also doesn't care what language you use. It ships git subcommands in C, shell and perl, but you can use node, python, bash, go, whatever you like. Really great.
- git divides it's interface and features into porcelain (user facing) and plumbing (internal; used by porcelain implementations). This allows them to avoid breaking changes while providing new and exciting features. This is a great design choice and it's been copied extensively by many projects, but I've never seen it pulled off as well as git.
- git consistently reuses terms and objects (there have been some missteps over the years but the maintainers are very humble). Commit objects, refs, dates and times all work the same almost everywhere.
- git is extremely well documented, both in its man pages, online and within the tool itself. Help flags and interactive messages and descriptions and suggestions of what to do next. Have you ever performed an interactive rebase? Or resolved a merge commit? Or corrected a tracking branch? Just great stuff.
I know we love to hate on git here but let's just for a moment acknowledge this wonderful, powerful tool for something it does a great job at. Git cuts no corners, it's consistent and trustworthy, and a hallmark of modern day software engineering and UX.