Seasoned A Better Finder Rename users will probably remember the good old days when A Better Finder Rename was “only” a context menu that was neatly hidden away in the Finder contextual menu.
With version 7.0, however, A Better Finder Rename became a full blown “stand-alone” application that may also be launchied via the context menu. This meant that some user interface rework had to be done. Throughout this, I tried to disrupt the working habits of existing users as little as possible.
New users, who have never known the “context menu only” A Better Finder Rename find some of its behaviour a little odd however.
Chief amongst these annoyances is the behaviour of the default “Rename” button. This, most new users feel, should simply peform the rename and stay open. I tend to agree. It’s only logical..
The problem is that when A Better Finder Rename was only a context menu item, it made more sense that it would be behave like the “Get Info” dialog: You make your changes and then the dialog closes, the Finder window shows you the new file names. Neat.
This is the reason why even the latest version 7.3 (for new users “inexplicably”) quits just after peforming the rename.
With the new version I have added an “Apply” button, which performs the rename, empties the preview list and stays open.
Now it is represented to me that this should be the default behaviour, ie. I should get rid of the “Rename” button behaviour and make the “Apply” button’s behaviour the default. Hitting the return key will apply the changes, but not quit the application.
This is of course the request of a user who has not spent the last decade hitting the return key to perform a one key stroke “rename and quit”. My highly scientific “one user poll” shows that 100 percent of existing users don’t want that.
How is a software developer to know which option to choose? Why, he could just ask his users..
So please cast your vote below:
I will probably only change the behaviour if there is a strong (two thirds?) vote in favour of the change..
How about fleshing out the preferences dialog with more options, to allow users to change these things for themselves, rather that have a poll and lock everyone into one choice.
why not simply make this choice a preference setting?
Ok. So you want more preferences?
I’m kind of trying to keep things as simple as possible so that ABFR doesn’t end up with a huge learning curve and dies of featuritis.
Moreover, I know from my support questions that there are already lots of users who have trouble with advanced features, such as the “Rename from File List”, regular expressions, multi-step renames, etc.
On the other hand, I guess preferences are pretty much hidden away and my other products (MacBreakZ is a good example) are full of customizable options..
So what other things would you like to customize?
Anybody else in favor of more preferences? Anybody against?
I think that Rename and Apply would be confusing as both would do almost the same task, except for quitting. Then it would be better to rename “Rename” to “Apply & Quit”. Or, just leave “Apply” or “Rename” button and add checkbox “Quit application after renaming”.
This is what the Apple’s Human Interface Guidelines/ Bible has to say about apply buttons:
“Providing an Apply Button in a Dialog
You may choose to provide an Apply button in a dialog that displays multiple settings that affect the user’s view of data. An Apply button should allow a user to preview the effect of the selected settings without committing to the changes. Be cautious about using an Apply button for operations that take a long time to implement or undo; it might not be obvious to users that they can interrupt or reverse the process. Save dialogs or dialogs that allow users to make changes that can’t be previewed easily should not include an Apply button.
Clicking the Apply button does not dismiss the dialog because the user must decide whether to accept the previewed changes (by clicking OK) or to reject them (by clicking Cancel). Do not use the Apply button as another OK button—when the user dismisses the dialog without clicking OK, all previewed changes should be discarded”
That pretty much says that only with the “OK” button should the preview results be applied in earnest and the dialog should then be dismissed. Hhmm..
I don’t think anybody expects an “Apply” button to do what a “Preview” button should do? “Apply” to me (and this seems to be the case in all applications that I’ve seen) means “Do It” but without a connotation of dismissing the dialog.
In any case, a dialog should be dismissed only by an “OK” button (for applying the changes) or a “Cancel” button (for not applying the changes).
Despite Apple’s HIG, lots of you want a way of renaming files without dismissing the dialog.
The best (and most mindful of the HIG) solution I can think of is to provide two buttons:
“OK” renames and quits, just as it should
“Cancel” quits without renaming, just as it should
“Apply” in violation with of the HIG, but IMHO intuitively, just renames and stays open
The “Rename” button will thus become “OK”, which according to HIG needs to be mapped to the return key.
For convenience’s sake the “Apply” button should have a keyboard shortcut. HIG does not define a shortcut for “Apply” and Command-A, -P, -L and -Y are already taken.. Any suggestions?
ABFR is now an application, not a dialog box. You don’t expect an application to quit when you tell it to do something.
ABFR already clears the preview pane after a rename, which is equivalent to dismissing the dialog box. I don’t want to keep re-loading ABFR after each rename. “Apply” helps, but I still find myself hitting the “OK” in version 3 instead of “Apply” when I see the change I want in the preview pane. That’s annoying.
You can get by with two buttons: “Rename and quit” and “Rename”. I’d make the rightmost button “Rename” the default and leave “Rename and quit” (or a check box with that option) for “one-button” users.
I’m not sure why it would ever automatically quit. I don’t know of any other application that does that. I’d rather have to tell it quit, as I would with any other application. But I like the idea of an “apply” button where you have the option of reviewing each change as well as an “OK” button that just makes the changes.