Ask HN: Good examples of interactive command-line user experience?
What are good examples of interactive TUI/CLI user experience? I'm looking for nice layouts, use of ASCII color, interaction patterns, nicely written help text, etc.
82 comments
Yes, 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)
- 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)
I 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.
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.
Thanks for the feedback! I'll see if we can get that in the guide.
This is great. Exactly the kind of thing I'm looking for.
The symbolics accept/present system (part of Dynamic Windows). Unfortunately if you haven't used it, all I couldn't find was Gene Ciccarellis' PhD thesis: https://dspace.mit.edu/bitstream/handle/1721.1/6946/AITR-794...
Basically: Lisp supports idempotent type-based printing (print something in a form that can be read back to identify the same object -- basically unremarkable these days; consider python's __repr__ and __string__) as well as human-friendly printing.
The presentation system was remarkable in that when you printed an object it printed in the user-friendly form, but when the text was read back the IO system knew what the object was and so acted as if a machine-readable representation had been printed. It also used the type hierarchy to support mouse action in "ordinary" text, thus if you needed a SHAPE object, the mouse would highlight "Square at 4,4" and "Circle centred at 5,5, radius 7" as if it were #<CIRCLE 5,5, r=7>. In fact the "printed" representation need not be textual.
Also BSD4.1 sh is quite good one !:... and ^...^ etc were added.
As a side note, IIRC Emacs started out as Ciccarelli's TECO init file around '75/76 or so.
Basically: Lisp supports idempotent type-based printing (print something in a form that can be read back to identify the same object -- basically unremarkable these days; consider python's __repr__ and __string__) as well as human-friendly printing.
The presentation system was remarkable in that when you printed an object it printed in the user-friendly form, but when the text was read back the IO system knew what the object was and so acted as if a machine-readable representation had been printed. It also used the type hierarchy to support mouse action in "ordinary" text, thus if you needed a SHAPE object, the mouse would highlight "Square at 4,4" and "Circle centred at 5,5, radius 7" as if it were #<CIRCLE 5,5, r=7>. In fact the "printed" representation need not be textual.
Also BSD4.1 sh is quite good one !:... and ^...^ etc were added.
As a side note, IIRC Emacs started out as Ciccarelli's TECO init file around '75/76 or so.
For the modern version of this, see CLIM or McCLIM
It'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]
https://github.com/nvbn/thefuck
[TL;DR -- typo a command, type 'fuck', will run the command you should have run]
There was a talk at Pycon 2017 about this [0] that's pretty good. He(amjith) goes through several examples with his favorite being bpython [1] and even covers writing such a thing in python live on stage.
[0] https://www.youtube.com/watch?v=hJhZhLg3obk [1] https://bpython-interpreter.org/
[0] https://www.youtube.com/watch?v=hJhZhLg3obk [1] https://bpython-interpreter.org/
click is another package that implements a lot of these things.
http://click.pocoo.org/6/
http://click.pocoo.org/6/
Python prompt toolkit is worth a look https://github.com/jonathanslenders/python-prompt-toolkit/bl...
Yes good on you for mentioning that, as well as the other projects in the umbrella:
- pymux (tmux clone): https://github.com/jonathanslenders/pymux/
- pyvim (vim clone): https://github.com/jonathanslenders/pyvim/
Lots of community-driven CLI tools with superb autocompletion:
- ptpython: http://github.com/jonathanslenders/ptpython/
- pgcli: http://pgcli.com/ + mycli: http://mycli.net/
- complete shells: xonsh (http://xon.sh/) + ergonomica (https://ergonomica.github.io/)
- pymux (tmux clone): https://github.com/jonathanslenders/pymux/
- pyvim (vim clone): https://github.com/jonathanslenders/pyvim/
Lots of community-driven CLI tools with superb autocompletion:
- ptpython: http://github.com/jonathanslenders/ptpython/
- pgcli: http://pgcli.com/ + mycli: http://mycli.net/
- complete shells: xonsh (http://xon.sh/) + ergonomica (https://ergonomica.github.io/)
The talk covers Prompt Toolkit. The presenter wrote pgcli and mycli, and covers most of your list as well.
But it's probably good to list it all out here, for the lazy, or the ones unable/unwilling to play youtube.
I'm constantly impressed by fzf (https://github.com/junegunn/fzf). I use it both from the shell (for files and command history) as well as a fuzzy finder in vim. I greatly enjoy the speed and intuitiveness.
There's mapscii[0], which was on HN a little while ago. Easily the coolest console experience I've ever had.
You can check it out by running "telnet mapscii.me"
[0] https://github.com/rastapasta/mapscii
You can check it out by running "telnet mapscii.me"
[0] https://github.com/rastapasta/mapscii
Shameless plug: Elvish (https://github.com/elves/elvish) is a shell with a rich UI.
The idea of enriching shell's UI is not new though, zsh and fish are both prior arts.
The idea of enriching shell's UI is not new though, zsh and fish are both prior arts.
Telemate BBS client was a great example of a windowed TUI in the style of DESQView. You could have a chat window, a DOS terminal and an ANSI terminal all open at the same time. Overlayed dialog boxes were framed, resizable and movable within the window. Scripting was supported in chat and terminal windows to navigate through menus or to type "^H^H^H^Hsexy beast" any time your name comes through the chat.
Another favorite of mine, Vern Buerg's List.com, was far better than Norton Commander or the MC clone, in my opinion. As a multi-column file viewer/manager, it maximized the number of files displayed onscreen and allowed simple file operations from a keystroke. By using a hex editor you could change the viewer and external editors. It was also written in 8086 assembly and was very fast.
I think that gnus & magit are pretty good.
Gnus is a full-featured news, email & RSS reader (and others too maybe?). I've used it for most of my life.
Magit is a full-featured git UI, good enough that I don't bother using git from the command line anymore.
Gnus is a full-featured news, email & RSS reader (and others too maybe?). I've used it for most of my life.
Magit is a full-featured git UI, good enough that I don't bother using git from the command line anymore.
for the TUI - aptitude, midnight commander, back in the days the Turbo Vision was awesome, which I think has some ports for Linux.
I'm constant midnight commander (linux/osx), FAR commander (windows) user. I'm so glad that it works flawlessly almost anywhere there is terminal support...
I'm constant midnight commander (linux/osx), FAR commander (windows) user. I'm so glad that it works flawlessly almost anywhere there is terminal support...
I like npm-check https://github.com/dylang/npm-check it has a really useful and easy to use UI, on of the nicest terminal UI driven applications I have used.
Edited: to use TUI instead of CLI
Edited: to use TUI instead of CLI
TUI is not CLI.
htop and these curses interfaces was TUI
Thank you for the clarification, I updated my post.
Thanks for pointing that out. I'm interested in both.
Midnight Commander and its spiritual predecessors going all the way back to Norton Commander and Volkov Commander are marvellous examples of TUI.
They're intuitive, interactive, come with embedded help, and use text mode to present a sophisticated, productive interface.
They're intuitive, interactive, come with embedded help, and use text mode to present a sophisticated, productive interface.
The Norton Editor (NE) was very good too. Really fast. Probably written in assembly, maybe by Peter Norton himself. I had bought and read a book of his on programming in assembly language (x86) for the IBM PC. Also very good. He developed a TUI hex editor in the book as a running case study, IIRC.
Also the Norton Guides were fantastic. TSRs [1], but with a TUI. You could get guides for C, dBASE, Clipper, Assembly, etc. I loved the TSR popup experience on DOS.
[1] Terminate and Stay Resident programs. They hooked into a keyboard interrupt to allow them to pop on a press of a hotkey.
Also the Norton Guides were fantastic. TSRs [1], but with a TUI. You could get guides for C, dBASE, Clipper, Assembly, etc. I loved the TSR popup experience on DOS.
[1] Terminate and Stay Resident programs. They hooked into a keyboard interrupt to allow them to pop on a press of a hotkey.
Tangentially-related: check out Vermont Views [1], a complete TUI development solution. I wish they open sourced it before they exited the market, or re-entered the market for IOT/embedded developers. I've never found a comparable open source effort, though here's to hoping the Blessed project for node.js takes inspiration from Vermont Views for future directions.
[1] http://web.archive.org/web/20091011010412/http://www.vtsoft....
[1] http://web.archive.org/web/20091011010412/http://www.vtsoft....
Serverless (https://serverless.com) has a nice experience. I believe it is built using inquirer.js (https://github.com/SBoudrias/Inquirer.js)
I've recently built an internal tool with inquirer and it was a really nice development and user experience. I haven't figured out the best way to test the interactions though.
termUI in go is also nice if you need graphing and viz for a dashboard like command line.
I've recently built an internal tool with inquirer and it was a really nice development and user experience. I haven't figured out the best way to test the interactions though.
termUI in go is also nice if you need graphing and viz for a dashboard like command line.
I think many/most Node TUI's use Inquirer. I have mixed feelings about it. Python has several library's that provide lower-level constructs for building CLI and TUI's. Then they provide examples for using the library to implement a common pattern or prompt. Inquirer gives you some ready-made prompts but doesn't provide any help/convenience for creating your own prompt. It seems like the wrong level of abstraction.
Which python libraries do you prefer?
Inquirer is def the HTML inputs of the terminal but I got pretty far with it. My use case was Fairly Simple™ though. What other UI components do you think it's lacking?
Inquirer is def the HTML inputs of the terminal but I got pretty far with it. My use case was Fairly Simple™ though. What other UI components do you think it's lacking?
I like python_prompt_toolkit, though I think the learning curve can be a bit steep. It gives you a ton of flexibility, which I really appreciate, but I have a hard time remembering how all the pieces interact. I hope I don't sound overly critical of people's open source work, because I've used and really appreciate both Inquirer and PPT. Just seems like there's yet to be a canonical library for this problem set.
It'd be really nice to see one in go or something else I could ship around easily w/o needing NPM and node, etc.
I'll give PPT a swing. I haven't used it before. Thanks!
I'll give PPT a swing. I haven't used it before. Thanks!
I can second Serverless. Apart from being quite a powerful tool, it also has a nice experience overall.
- Emacs' Magit
- moc (Music on Console)
- moc (Music on Console)
I highly recommend ranger[0]. It's a very useful console based file manager with great vi key bindings.
The configuration is also very flexible and includes a python API to write your own commands[1].
[0] http://ranger.nongnu.org
[1] https://github.com/ranger/ranger/wiki/Commands
The configuration is also very flexible and includes a python API to write your own commands[1].
[0] http://ranger.nongnu.org
[1] https://github.com/ranger/ranger/wiki/Commands
I'd look at old DOS applications - the last mass market (i.e. not just technical users) for non-GUI apps. Although towards they end, they were often just aping Windows GUIs as well as they could (see https://en.wikipedia.org/wiki/IBM_Common_User_Access )
`parted` is pretty good, in an old-school way.
The only thing I'd personally ask for is if you offer an interactive interface, make sure you can execute the exact same commands on the plain CLI. Also (yeah, two things) support --help and --version (as well as -h and -v) out of the box.
Color, layouts (other than those required for readability), and other things just don't really matter as much, IMO.
The only thing I'd personally ask for is if you offer an interactive interface, make sure you can execute the exact same commands on the plain CLI. Also (yeah, two things) support --help and --version (as well as -h and -v) out of the box.
Color, layouts (other than those required for readability), and other things just don't really matter as much, IMO.
https://www.youtube.com/watch?v=hJhZhLg3obk "Amjith Ramanujam Awesome Command Line Tools PyCon 2017" goes through some nice examples: mycli, pgcli, fish shell and few others
The `micro` test editor is fantastic. GUI-standard keyboard shortcuts. Mouse support. Ability to execute commands while editing test.
https://micro-editor.github.io/
https://micro-editor.github.io/
The dbcli suite (pgcli, mycli) provide a great user experience on the command line that even some gui database tools don't match up to.
https://github.com/dbcli
https://github.com/dbcli
While it mostly piggy backs on ag, I think tag (https://github.com/aykamko/tag) has one of the best UX workflows I've seen.
Oh and don't forget figlet when you need that dope ASCII logo banner.
The FreePascal TUI is good, IMO. So was Turbo Pascal, back in the day. Both are very fast, get out of your way (IMO) and also look(ed) good. Okay, TP not so much :), but not bad either.
Jest is pretty neat: https://facebook.github.io/jest/
yeoman is pretty good. It gives the option of interactive or command line. Reasonable use of colour, with some layout formatting. Dynamic options.
The first tool that came to mind for me was htop [0] with ncurses. It's a friendly alternative to top.
I've previously used ncmpcpp [1] without any major complaints, although it's been a few years since then. It's an mpd [2] client written with ncurses.
On my personal servers I use goaccess [3] to analyze access logs. I remember being able to pick it up pretty quickly on my first try.
Only tangentially related, but you may find it useful to read the "Utility Conventions" [4] entry of The Open Group Base Specifications. I'd also suggest reading through the relevant entries under the "Program Behavior for All Programs" [5] section of GNU Coding Standards [6]. By following existing conventions (or even being aware they exist) you can sometimes make it easier for others to learn how to use your tool.
If you know JavaScript, you may consider writing your program with node. The blessed [7] library is a JavaScript reimplementation of ncurses, and there's even a react renderer [8]. This makes building the UI much easier than many of the alternatives I know. When you're ready to release, you can generate an executable [9] for easy deployment or publication. The biggest benefits of taking this approach are that it makes it very easy to achieve cross-platform support, and the barrier of entry is lower than many alternatives. The biggest caveats are that it'll be slower and much larger than if it had been written with C.
[0] http://hisham.hm/htop/
[1] http://rybczak.net/ncmpcpp/screenshots/
[2] https://www.musicpd.org
[3] https://goaccess.io
[4] http://pubs.opengroup.org/onlinepubs/9699919799/xrat/V4_xbd_...
[5] https://www.gnu.org/prep/standards/html_node/Program-Behavio...
[6] https://www.gnu.org/prep/standards/html_node/index.html
[7] https://github.com/chjj/blessed
[8] https://github.com/Yomguithereal/react-blessed
[9] https://github.com/zeit/pkg
I've previously used ncmpcpp [1] without any major complaints, although it's been a few years since then. It's an mpd [2] client written with ncurses.
On my personal servers I use goaccess [3] to analyze access logs. I remember being able to pick it up pretty quickly on my first try.
Only tangentially related, but you may find it useful to read the "Utility Conventions" [4] entry of The Open Group Base Specifications. I'd also suggest reading through the relevant entries under the "Program Behavior for All Programs" [5] section of GNU Coding Standards [6]. By following existing conventions (or even being aware they exist) you can sometimes make it easier for others to learn how to use your tool.
If you know JavaScript, you may consider writing your program with node. The blessed [7] library is a JavaScript reimplementation of ncurses, and there's even a react renderer [8]. This makes building the UI much easier than many of the alternatives I know. When you're ready to release, you can generate an executable [9] for easy deployment or publication. The biggest benefits of taking this approach are that it makes it very easy to achieve cross-platform support, and the barrier of entry is lower than many alternatives. The biggest caveats are that it'll be slower and much larger than if it had been written with C.
[0] http://hisham.hm/htop/
[1] http://rybczak.net/ncmpcpp/screenshots/
[2] https://www.musicpd.org
[3] https://goaccess.io
[4] http://pubs.opengroup.org/onlinepubs/9699919799/xrat/V4_xbd_...
[5] https://www.gnu.org/prep/standards/html_node/Program-Behavio...
[6] https://www.gnu.org/prep/standards/html_node/index.html
[7] https://github.com/chjj/blessed
[8] https://github.com/Yomguithereal/react-blessed
[9] https://github.com/zeit/pkg
Great list! Thanks a bunch.
slap[0] (the terminal-based text editor) was designed to emulate Sublime's UX within the terminal. It has a shallower learning curve than other command line editors.
[0] https://github.com/slap-editor/slap
[0] https://github.com/slap-editor/slap
Far Manager is my favorite TUI and is the primary reason I haven't switched over to Linux yet.
tig is pretty solid
I'll second that. I use tig daily.
Another tui I like is for networkmanager. For whatever reason, nmtui always seems to work better than the gui frontends.
I think PyPy deserves a special mention -- it's been a few years since I built it, but the last time I did it drew the Mandelbrot set as a progress indicator.
Another tui I like is for networkmanager. For whatever reason, nmtui always seems to work better than the gui frontends.
I think PyPy deserves a special mention -- it's been a few years since I built it, but the last time I did it drew the Mandelbrot set as a progress indicator.
I use tig every day and it is easily my favourite git client. I especially love the staging view and ability to stage individual lines.
Turbo Pascal 7.0
terminal_velocity
darcs
dockly
git
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...
https://git-man-page-generator.lokaltog.net/
https://git-man-page-generator.lokaltog.net/
Made my day. Thankyou! :-)
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.
- 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.
> 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?
Yes to all. Then I showed it to people new to git. And saw them fail week after week. They got into states they didn't expect, didn't understand, and didn't see expected feedback. Clever people who needed to blow away the repo to get to a known state in the easiest way. The most common problem was making a new commit in the middle of a rebase, and accidental committing or blowing away conflicts on pull. Next was switching the branch during an interactive operation and basically ending up with unknown state.
You listed many things which make git powerful, but a good ux is something different. It requires good, consistent context, clear boundaries between expected and unexpected operations (why can you checkout during rebase, for example?), and discoverability. If you interact with enough developers, you'll get asked "what do I do? I don't know what just happened" - and that's the mark of bad ux.
Yes to all. Then I showed it to people new to git. And saw them fail week after week. They got into states they didn't expect, didn't understand, and didn't see expected feedback. Clever people who needed to blow away the repo to get to a known state in the easiest way. The most common problem was making a new commit in the middle of a rebase, and accidental committing or blowing away conflicts on pull. Next was switching the branch during an interactive operation and basically ending up with unknown state.
You listed many things which make git powerful, but a good ux is something different. It requires good, consistent context, clear boundaries between expected and unexpected operations (why can you checkout during rebase, for example?), and discoverability. If you interact with enough developers, you'll get asked "what do I do? I don't know what just happened" - and that's the mark of bad ux.
Good UX doesn't mean holding your hand. I think Vim has pretty great UX -- it's been my daily $EDITOR for years. Is there a steep learning curve? Sure.
Often with tools like Vim, Git, etc. there is a dependency on the end user taking the time to learn, absorb and understand the documentation for the tool.
> It requires good, consistent context, clear boundaries between expected and unexpected operations (why can you checkout during rebase, for example?), and discoverability.
I think git really excels here. Why wouldn't you want to be able to checkout during a rebase?
To me, UX is ultimately about the long tail -- if I am using this tool for a hundred hours a week, am I helped or hindered by it? For too many tools society embraces, it's the latter.
UX and HCI is about so much more than just sitting an untrained person in front of a keyboard.
Often with tools like Vim, Git, etc. there is a dependency on the end user taking the time to learn, absorb and understand the documentation for the tool.
> It requires good, consistent context, clear boundaries between expected and unexpected operations (why can you checkout during rebase, for example?), and discoverability.
I think git really excels here. Why wouldn't you want to be able to checkout during a rebase?
To me, UX is ultimately about the long tail -- if I am using this tool for a hundred hours a week, am I helped or hindered by it? For too many tools society embraces, it's the latter.
UX and HCI is about so much more than just sitting an untrained person in front of a keyboard.
Why is it bad? Genuine question, and please don't give me the "it's so unintuitive" answer, that's why programs come with documentation.
That's not why programs come with documentation. Documentation helps, but being intuitive in usage is something completely different. Intuitive means you can either do the simplest operations without reading the docs, or that you can figure it out as you go from the context clues. Git does neither. You need to learn about the model, the operations, the repo / staging / checkout / remote areas to complete the most trivial "modify-commit-push" workflow.
Git as a command will not help you.
Git as a command will not help you.
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.
All of what you say is correct. git is great in many ways and not too difficult to use once you grok the internals.
But git's user interface is inconsistent, has got weird error messages and confusing terminology with too many ways to do some things.
Good thing that it has quite decent manpages which explain these things thoroughly. The UI gets the job done but it sure isn't a great example of a well designed command line.
But git's user interface is inconsistent, has got weird error messages and confusing terminology with too many ways to do some things.
Good thing that it has quite decent manpages which explain these things thoroughly. The UI gets the job done but it sure isn't a great example of a well designed command line.
It's rough in some ways, and elegant in others. A bad error message does not a bad UX make. Good error messages are great, but remember UX is also about hitting the important points well.
It didn't matter how powerful it is. It's still inconsistent and a bad example of ux. Some trivial examples: "tag -d", but "remote remove"; exiting editor after "commit" aborts, but after "rebase -i" continues operation; etc.
There are other projects that interact with git and are really good: tig, for example. But git itself? Someone wrote a good paper about it already. "What's wrong with git?" was the title, I believe.
There are other projects that interact with git and are really good: tig, for example. But git itself? Someone wrote a good paper about it already. "What's wrong with git?" was the title, I believe.
git has a terrible UI, IMO. git reset, for instance, does like 17 different things. And what does checkout have to do with creating branches as in "git checkout -b"? Not that git branch is that much better, it's conflating creating, listing and deleting under one command (named after a verb or singular noun). Compare to hg's branch/branches or fossil's even clearer convention of noun + action, like in "fossil branch new ...".
That said, you are right that understanding the git model helps a lot and for that, I recommend the "Getting Git" talk. https://vimeo.com/14629850
That said, you are right that understanding the git model helps a lot and for that, I recommend the "Getting Git" talk. https://vimeo.com/14629850
There is even a science paper showing that "for most people Git is a magic black box they whisper obscure spells into":
http://www.ppig.org/sites/default/files/2014-PPIG-25th-Churc...
I question this study's sample size and diversity.
Git was made by and made for kernel hackers to support the Linux kernel. It has an expectation that the user understands how their computer works and wants a tool catered to that knowledge. The average web developer writing Ruby or Node in Atom on their Macbook Pro isn't in the target audienece. For someone in git's target audienece, it's a great tool with far better UX than any other VCS - because it gets out of your way and gives you powerful tools for mucking with the VCS to suit your needs precisely. THIS is what makes for a good UX. A tool that's easy to learn is great, but if it can't be mastered and bent to the user's will then I'd rather take one that's hard to learn but accomodating of the master.
Git was made by and made for kernel hackers to support the Linux kernel. It has an expectation that the user understands how their computer works and wants a tool catered to that knowledge. The average web developer writing Ruby or Node in Atom on their Macbook Pro isn't in the target audienece. For someone in git's target audienece, it's a great tool with far better UX than any other VCS - because it gets out of your way and gives you powerful tools for mucking with the VCS to suit your needs precisely. THIS is what makes for a good UX. A tool that's easy to learn is great, but if it can't be mastered and bent to the user's will then I'd rather take one that's hard to learn but accomodating of the master.
> The average web developer writing Ruby or Node in Atom on their Macbook Pro
It does not matter who it was designed for, git is the de-facto VCS that almost everyone uses today. And people are having trouble using it because there is no better alternative: it is fast and powerful and used by many companies.
But it's UX is terrible: I use git for 10 years and I have to Google every time I need to make a branch tracking a remote one. git reset does different things based on what type of object you pass.
This has nothing to do with knowing how internals work, it is a question of consistency and providing a small non-overlapping set of tools to do my job.
It does not matter who it was designed for, git is the de-facto VCS that almost everyone uses today. And people are having trouble using it because there is no better alternative: it is fast and powerful and used by many companies.
But it's UX is terrible: I use git for 10 years and I have to Google every time I need to make a branch tracking a remote one. git reset does different things based on what type of object you pass.
This has nothing to do with knowing how internals work, it is a question of consistency and providing a small non-overlapping set of tools to do my job.
>It does not matter who it was designed for, git is the de-facto VCS that almost everyone uses today. And people are having trouble using it because there is no better alternative: it is fast and powerful and used by many companies.
It _does_ matter who it's designed for. If someone outside the target audience uses it, then it's not the tools fault for not accomodating them. My point is that the UX is great for those it's meant to be great for.
>I use git for 10 years and I have to Google every time I need to make a branch tracking a remote one.
git branch --set-upstream-to=upstream/master master
Didn't have to look this up. Seems pretty straightforward. Or just git push -u upstream master.
>git reset does different things based on what type of object you pass.
So? I don't see how this is a bad UX. Would you prefer 10 different commands? I wouldn't.
It _does_ matter who it's designed for. If someone outside the target audience uses it, then it's not the tools fault for not accomodating them. My point is that the UX is great for those it's meant to be great for.
>I use git for 10 years and I have to Google every time I need to make a branch tracking a remote one.
git branch --set-upstream-to=upstream/master master
Didn't have to look this up. Seems pretty straightforward. Or just git push -u upstream master.
>git reset does different things based on what type of object you pass.
So? I don't see how this is a bad UX. Would you prefer 10 different commands? I wouldn't.
I personally think mercurial (hg) is much more intuitive than git. Even for use with git, via hg-git[1].
Can't quite put my finger on it, but some subtle differences seem to nudge the user towards more usable workflows than bare git.
[1] https://hg-git.github.io/
Can't quite put my finger on it, but some subtle differences seem to nudge the user towards more usable workflows than bare git.
[1] https://hg-git.github.io/
Thanks, didn't knew about hg-git
it was awful, it is getting better and I think it's a good example in several occasions
(I mean when it's not an unpredictable sequence of commands that need to be passed to accomplish something outside of a regular workflow)
(I mean when it's not an unpredictable sequence of commands that need to be passed to accomplish something outside of a regular workflow)
I enjoy how much git-flow-avh dumbs down git for me. I've been using regular old git commands for years but inevitably end up in some weird merge conflict with myself and possibly a slightly inebriated version of me that was coding the night before.
I'm using git cli.
Already tried sourceTree, gitkraken, intellij plugins, atom plugins.... all these attempts ended up in "I do not know which branch I am in" or "How do I get a diff to remote"?
Agreed, part of why I love the integrated terminal in VS Code... mostly doing git, node and npm commands while working on my projects. About the most GUI I use, is the active diff tool in VS Code. But that's not CLI based. I've also tried a few gui tools for git, and none seem to be quite as easy as just using the CLI for it.
Probably the cli that I find the most useful beyond git that I use regularly is docker... It's pretty useful if you aren't in a linux environment but need to build something in one... In my node lambda builds, I'll do something like:
Probably the cli that I find the most useful beyond git that I use regularly is docker... It's pretty useful if you aren't in a linux environment but need to build something in one... In my node lambda builds, I'll do something like:
docker -i -v "${PWD}/dist":/app -w /app node:6.10 npm i