This session was led by Johannes "Dscho" Schindelin. Supporting cast:
Jonathan "jrnieder" Nieder, brian m. carlson, Ævar Arnfjörð Bjarmason, CB
Bailey, Phillip Wood, and Emily Shaffer.
Notes:
1. A serious problem! ~½ of blog posts about Git start by ridiculing the
command-line interface of Git
2. Is very flexible, and that flexibility is reflected in the user interface
3. On the other hand, it could be a lot easier to use. Example: GitHub CLI in
Go, tries not to supplant Git but gives a really good user experience
interacting with GitHub-specific entities like PRs and Issues. Everything
you can do day-to-day in the web UI you can do in the command line, and
it’s scriptable
4. Excellent discoverability. Never needed to check the manual. Well designed
interface, good command line completion.
5. What would it take to revamp Git’s user interface?
6. “git restore” example
1. Dscho doesn’t like it, feels wrong
2. Designed by a software engineer, not a designer
3. jrnieder: The manpage is pretty clear about “this is experimental,
we’re willing to modify it based on feedback”. Is there information we
can gather and work with a designer to improve it?
4. brian: “I don’t know how to use it” is valuable feedback. Maybe the
documentation is failing? Etc
5. Can be a sign of excessive complexity or of it relying on too much
previous knowledge to use
7. Ævar: On switch/restore in particular, there was a recent discussion.
1. Ultimately came down to inconsistency with other commands in the same
area
2. I gave some suggestions
3. Some patches started, there was some trepidation about making changes,
though
8. Dscho: Is working one command at a time too incremental?
1. Inconsistencies between different commands
2. “git add -A” exists, “git commit -A” doesn’t
3. Are those the most pressing problems? I don’t even know that
9. Want guidance from user interface experts that work on the command line
10. gh command involved contractors that are no longer with GitHub
11. CB: The “pip” project is doing UX research. I don’t know who commissioned
it. Got UX experts to design study:
https://pip.pypa.io/en/latest/ux_research_design/
12. Phillip: The inconsistency between 'checkout -b' and 'switch -c' was
deliberate in the hope that '-c' for 'create' would be easier for users to
understand but ends up being confusing.
13. jrnieder: we should not expect an “angel” to swoop in and solve all our
problems for us. It’s more about how do we build this skill within the Git
project (by improving our own skills or attracting new contributors)
14. We should also consider that there are many people on the mailing list
with plenty of backgrounds, we might just need to band together to get it
done
15. Emily: maybe we can get some training (maybe the SFC could fund it, or
others in the Git ecosystem)
16. jrnieder: training is easier to fund than a permanent engagement
17. brian: if we had this expertise, we could probably make better decisions
in the future
18. Ævar: Conservancy could potentially find someone, but funding a different
matter
19. jrnieder: neutrality not all that important in this context, finding
funding at Google or GitHub should be easy
20. Ævar: often comes down to these consistencies. Getting anywhere with that
might just be a long slog.
21. Phillip Wood: checkout -b vs switch -c inconsistency was deliberate, in
that “-c” for create is meant to be easier for a new user
22. Dscho: Good first step is getting the UX design basics (training), I’ll
look for funding
23. Example: when I just run “git” with no other options, can that output be
more helpful? “gh” has a nice overview when I run it.
24. Ævar: That in particular was improved years ago
1. Dscho: Oh! Good. Might be possible to keep improving along those lines.
2. Dscho: Sounds like we have a good path forward. \o/
25. hallway conversation
1. the index as a UI concept, what if we didn’t have it?
2. learning curve design space
3. how much does telemetry help us?
4. popcon-style telemetry
5. statistical rigor in surveys
