Usability observations below...
On Thu, May 2, 2013 at 11:49 PM, Jiang Xin <worldhello.net@xxxxxxxxx> wrote:
> The interactive git clean combines `git clean -n` and `git clean -f`
> together to do safe cleaning, and has more features.
>
> First it displays what would be removed in columns (so that you can
> see them all in one screen). The user must confirm before actually
> cleaning.
>
> WARNING: The following items will be removed permanently. Press "y"
> WARNING: to start cleaning, and press "n" to abort the cleaning.
> WARNING: You can also enter the "edit" mode, and select items
> WARNING: to be excluded from the cleaning.
The user intended for files to be removed when invoking git-clean,
therefore WARNING that git-clean will do what was requested explicitly
seems overkill. Along the same lines, the user asked explicitly for an
interactive session (via --interactive), hence the above paragraph is
effectively redundant since it does little more than tell the user (in
a lengthy fashion) what he already knows (that the session is
interactive). The short prompt printed after the listed files says the
same thing (more succinctly), thus this warning paragraph is
essentially superfluous.
> What would be removed... What would be removed...
> What would be removed... What would be removed...
>
> Remove (yes/no/Edit) ?
For convenience, implementations traditionally allow single letter
responses (y/n/e), but this one does not. Should it?
> In this confirmation dialog, the user has three choices:
>
> * Yes: Start to do cleaning.
> * No: Nothing will be deleted.
> * Edit (default for the first time): Enter the edit mode.
What about the user who desires more traditional "rm -i" behavior in
which he is prompted for each file? Should that be supported with a
"Prompt [each]" option in the above menu?
> When the user chooses the edit mode, it would look like this:
>
> NOTE: Will remove the following items. You can input space-seperated
> NOTE: patterns (just like .gitignore) to exclude items from deletion,
> NOTE: or press ENTER to continue.
As earlier, this (lengthy) paragraph says little more than what could
be said in a more succinct prompt printed after the file list, thus is
probably superfluous.
> What would be removed... What would be removed...
> What would be removed... What would be removed...
>
> Input ignore patterns>
The list of files to be removed was already shown directly above.
Dumping the entire list to the user's screen a second time upon
entering edit mode seems unnecessary. If you drop the WARNING and NOTE
paragraphs as suggested, then the session becomes much less verbose,
thus there is little reason to re-display the file list upon entering
edit mode. For instance:
% git clean -i
file1 file2 file3
file4 file5 file6
Remove (yes/no/edit)? e
Exclude (space-separated gitignore patterns): file[4-6]
file1 file2 file3
Exclude (space-separated gitignore patterns): [enter]
Remove (yes/no/edit)?
> The user can input space-separated patterns (the same syntax as gitignore),
> and each clean candidate that matches with one of the patterns will be
> excluded from cleaning.
>
> When the user feels it's OK, presses ENTER and back to the confirmation dialog.
>
> WARNING: The following items will be removed permanently. Press "y"
> WARNING: to start cleaning, and press "n" to abort the cleaning.
> WARNING: You can also enter the "edit" mode, and select items
> WARNING: to be excluded from the cleaning.
>
> What would be removed...
>
> Remove (Yes/no/edit) ?
>
> This time the default choice of the confirmation dialog is "YES".
> So when user press ENTER, start cleaning.
Is there precedent for this sort of self-mutating default action in
other utilities? Wouldn't this lead to high "surprise factor" for
users and potential for lost files? For instance:
% git clean -i
file1 file2 file3
file4 file5 file6
Remove (yes/no/Edit)? [enter]
{user presses ENTER for edit mode}
Exclude (space-separated gitignore patterns): file[3-6]
{user mistakenly types "3" rather than "4"}
file1 file2
Exclude (space-separated gitignore patterns): [enter]
Remove (Yes/no/edit)? [enter]
{user notices mistake and presses ENTER expecting edit mode}
Removing file3
Removing file4
Removing file5
Removing file6
Oh no! The user didn't notice the subtle change of default from
"yes/no/Edit" to "Yes/no/edit", thus he pressed ENTER thinking it
would take him to edit mode as it did initially, but instead git-clean
proceeded with the removals and file3 is lost.
Other considerations:
Is it necessary to force the user to escape from edit mode by pressing
ENTER (i.e. empty input)? Wouldn't you achieve the same level of
functionality by exiting back to the (yes/no/edit) prompt
automatically after the user enters his gitignore pattern(s)? For
instance:
% git clean -i
file1 file2 file3
file4 file5 file6
Remove (yes/no/edit)? e
Exclude (space-separated gitignore patterns): file[4-6]
file1 file2 file3
Remove (yes/no/edit)?
More generally, is this sort of modal edit mode desirable and
convenient? Can the edit operation be combined with the top-level
prompt? For example:
% git clean -i
file1 file2 file3
file4 file5 file6
Remove ([y]es, [n]o, [p]rompt, exclusion-list)? file[4-6]
file1 file2 file3
Remove ([y]es, [n]o, [p]rompt, exclusion-list)? p
file1 (y/n/q/!)? y
file2 (y/n/q/!)? n
file3 (y/n/q/!)? y
-- ES
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html