mirrors/git-annex
2
0
Fork 0
Code Issues Pull requests Projects Releases Packages 1 Wiki Activity Actions

Added a comment: comment 1 response

Browse source
This commit is contained in:
daven.quinn@d0ed4e0e5e4462d9a74a5d5a8fbd1b17f85db13e 2023-01-16 21:45:35 +00:00 • committed by admin
parent e42ac8844e
commit be6aec3100
1 changed files with 29 additions and 0 deletions
Download patch file Download diff file Expand all files Collapse all files

29
doc/todo/Usability_improvements_for_new_users/comment_2_ea77f0894802a17854aeedeceababf8a._comment Normal file
View file

@ -0,0 +1,29 @@
[[!comment format=mdwn
username="daven.quinn@d0ed4e0e5e4462d9a74a5d5a8fbd1b17f85db13e"
nickname="daven.quinn"
avatar="http://cdn.libravatar.org/avatar/4811a26fff610f0c9668d183481a7158"
subject="comment 1 response"
date="2023-01-16T21:45:35Z"
content="""
Fair enough, I suppose. However, I think that feedback from early-stage users should be weighted highly, as we interact with \"onboarding\"/\"discoverability\" problems that eventually fade from being users' primary impediments to use.
> git-annex can't be limited to commands that happen to have equivalant git commands.
I'm not suggesting that all commands should have `git` equivalents. Instead, when a commonly used equivalent (or close relative) is available, the name should be mirrored to increase discoverability of common idioms.
> This would encourage drawing a false equivilance with git remote rename.
I'm not quite sure why the equivalence would be false — yes, the commands do somewhat different things. But they both fundamentally rename a remote.
> searching for strained equivilances to git remote commands.
Again, I am not sure the equivalences are so strained. Users should not (and I think broadly won't) expect a git-annex subcommand to do exactly the same thing as a git equivalent. But semantic-level parallelism with git top-level commands, and adopting git's pattern of grouping like functionality into subcommands, could greatly improve discoverability. As it stands, the goals of *preventing confusion between similarly named functionality* and *allowing functionality to be easily found* are in tension.
Another way to frame my suggestion is to consider the layout of the `git-annex` command line help output. Right now, when seeking assistance, the user is presented with a long list of commands and has to hunt for related functionality (`renameremote`, `enableremote`, etc.) within it. In contrast, when I type `git remote --help`, I see all of the commands for managing remotes in a single, shorter output. It is another nesting level, true, but I think a help page entry of `remote - manages git-annex special remotes` would be easier to parse than the current output.
Anyway, I appreciate your work on this system and consideration of user feedback.
Regards,
Daven
"""]]