I'm not sure if this discussion will be very successful in the middle of a so nice summer (at least here, in Canada :-) But lets try it...
If you used Folders Popup enough, you probably got at some point a special menu when you clicked the middle mouse button over a dialog box saying:
Dialog box not supported menu
This means that the dialog box where you clicked is not known by FP. When this happens, you click “Add This Dialog Box to the supported list”. The name of this dialog box is then added to the “Supported dialog box” in Settings. But why should we care about supported dialog boxes in the first place? This is a question of interface philosophy.
One point of view: protect the user against himself
Folders Popup was designed with this approach in mind even before I begun adapting DirMenu (see software credits). The idea, here, is to make sure the FP popup menu is made available only in file dialog boxes where is can achieve its goal: changing the current folder in this dialog box. If the popup menu was called over an unsupported dialog box (for example, a "Preferences" dialog box), choosing a popup menu could produce unexpected effects. In reality, there is not that much at risk here. But an option or a value in the unsupported dialog box could be changed by the FP menu selected command.
The other point of view: trust the user
Another approach would be to make the FP popup menu available in any dialog box and trust that the user will invoke it only in dialog boxes where it can be used to change a folder. Users should not call this menu in an "Options" or "Preferences" dialog box. Except by error.
My point of view based on my experience developing Folders Popup
The idea in software design is generally to prevent users error by making risky command unavailable. But, in our case, the risk is relatively low. And, on the other hand, the mechanics to prevent errors is relatively important: checking the current dialog box against a list of supported windows, offering ways to add dialog boxes to the supported list, etc. And, from my experience, this whole process is not very easy to understand for first time users (one would say this could be improved by a more user-friendly interface - but this is another story ;-).
So, at this time, I would prefer the second option: removing the "supported dialog boxes" stuff and let the user invoke the popup menu only in appropriate dialog boxes.
What's your opinion on this? I can understand both positions. What's yours? Thanks for taking the time to jump in the discussion.
Blog RSS feed
Why not set " protect the user against himself" as default and
have an option in setup for "trust the user"
Sven Åke
Could do. But this is not a simple option that impact a few lines of code.This is a whole set of commands, dialog boxes, list in the ini file, etc. And still, there would be the first time user issue. It would make the app lighter and easier to learn without all this.
>> So, at this time, I would prefer the second option: removing the “supported dialog boxes” stuff
>> and let the user invoke >> the popup menu only in appropriate dialog boxes.
How do you define/detect "appropriate dialog boxes"?
I think I don't agree.
Removing the "supported dialog boxes" is a reduction of functionality and flexibility.
Then, what if a user encounters a dialog that is not supported? He'll blame FP for not supporting it and maybe he'll abandon FP completely for an alternative application that is more flexible.
I think it's ok as it is now.
1. Since you provide good defaults, for the first time user that isn't aware of “supported dialog boxes” it just works. Which is good. In other words, the fact that the whole process is not very easy to understand for first time users, is imo no big issue, because of the good defaults.
2. The more advanced user, who wants to play with it, is able to do so. Which is also good.
Btw, I work with IntelliJ's IDEA and FP doesn't work in the "Open File or Project" dialog. I think that is because of the fact that it is a Java dialog and not an OS dialog. It also doesn't work in the Open dialogs of my own developed Java app.
Thanks for joining the discussion, Geert.
> How do you define/detect “appropriate dialog boxes”?
A dialog box having a component to choose a folder (select file, open, save, etc.).
> Removing the “supported dialog boxes” is a reduction of functionality and flexibility.
> Then, what if a user encounters a dialog that is not supported? He’ll blame FP for not
> supporting it and maybe he’ll abandon FP completely for an alternative application that
> is more flexible.
You got me wrong. Removing the notion of "supported dialog boxes" will increase flexibility. All dialog boxes will be supported, regardless if their name is known or not by FP. By default, FP only knows a set of standard (an English) dialog box names: Open, Save, Export, Insert, Upload, etc. If you use Windows in another language or when you use software that has its own dialog boxes with different names, the default won't work and you'll have to tell FP to support them. My preference would be to support all dialog boxes and let the user use the FP menu only on the dialog box having for task to change folder.
> Btw, I work with IntelliJ’s IDEA and FP doesn’t work in the “Open File or Project” dialog. I think that is because of the fact that it is a Java dialog and not an OS dialog. It also doesn’t work in the Open dialogs of my own developed Java app.
You are right. FP works only in dialog boxes developed using the standard Windows OS dialog boxes. It won't work in Corel Paint, for example, that designed its own set of dialog boxes. Sorry for your app :-(
I see. I got you wrong, indeed.
So, FP will detect if a dialog box has a component to choose a folder and if it has, it will be supported, no matter its (title bar) name?
In other words, it will work everywhere it is supposed to without any configuration needed?
In that case, I'm in favour. Definitely. :-)
> FP will detect if a dialog box has a component to choose a folder and if it has
Not exactly. FP cannot detect if a dialog box has a component to choose a folder from. (This being said, just to be sure, I'll do some more research on this).
The FP popup menu could be displayed in *any* dialog box.
>> The FP popup menu could be displayed in *any* dialog box.
Oh... I see.
Hence the "protect the user against himself" paragraph.
It would of course be very nice (not to say perfect) if FP could detect if a dialog box has a component to choose a folder... Definitely worth some extra research!
> FP cannot detect if a dialog box has a component to choose a folder from.
I checked on AHK forum and got no answer on this (http://ahkscript.org/boards/viewtopic.php?f=5&t=3907). I think we can conclude AHK cannot detect for sure that a dialog box is a file dialog box.
Let's take a closer look at what FP is doing when you select a popup menu over a dialog box. We'll examine two scenarios:
Scenario A - Choosing a popup menu in a "file dialog box"
* First, FP checks if the dialog box include a control named "Edit1" or "Edit2" (standard internal names for text zones in Windows dialog boxes). If not, it stops there.
* If yes, it saves the content of this field (Edit1 or Edit2) in a temp variable and replace its content with the destination folder (the folder you selected in the popup menu).
* Then, it sends {Enter} to the dialog box. Since the destination is a folder, this changes the current folder in the dialog box and keep the dialog box opened.
* Finally, it restores the content of the field with the saved content. The dialog box is still opened. End of command.
Scenario B - Choosing a popup menu in another dialog box (for example "Page Setup" or "Options)
* First, FP checks if the dialog box includes a control named "Edit1" or "Edit2". If not, it stops there.
* Then it saves the content of this field (Edit1 or Edit2) in a temp variable, change the content of the field to the destination folder.
* Then, it sends {Enter} to the dialog box. Since this is not a "file dialog box", it usually sends this {Enter} to the OK button. This will close the dialog box and save the content of Edit1.
* Finally, FP tries to restore the content of the field Edit1 or Edit2 but, since the dialog box is closed, it would do nothing.
In scenario B, we can see that there is a risk of having a text field modified and saved after the OK button is pressed. This is why users should not select a popup menu over a dialog box that is not a "file dialog box". Actually, FP protects the user against this scenario at the cost of user interface complexity and extra code. The question still is: should we trust that the user will only select the popup menu over a "file dialog box"?
First of all, I think the user should know what (s)he's doing.
Triggering FoldersPopup in a page set up window is not that smart.
But I know, such things happen. :)
Second, I think it's the responsability of the application the window belongs to, to protect the user against filling in wrong things. When in the 'Page setup' window of Word eg. I enter "c:\temp" as top margin, I get the warning "This is not a valid measurement" when I press the OK button) So, sending an {Enter} won't necessarily always close a dialog.
Of course if a path like "C:\temp" is found to be a valid entry, yes it will be accepted and changed, but in that case, I think it's the user's mistake (misuse of FP) and FP is not to blame.
I think that searching for Edit1 and Edit2 fields is already a good condition to avoid many problems.
Btw, How sure are you that fields of interest for FP are *always* "named" like that?
This has been found by experience by AHK developers before me (see posts from Learning One http://ahkscript.org/boards/viewtopic.php?f=5&t=526&start=20#p4673). It seems to be a standard practice in developing file dialog boxes in Windows. There are exception handled by FP for Office apps under WinXP that have field name "RichEdit20W2".
Based on this discussion, I'm going to remove the dialog box verification in v3. Thanks for your input. I'll let this discussion opened if someone want to jump in.
>> I’m going to remove the dialog box verification in v3
You mean the verification based on it's name/title (as in v2) in favor of scenario A & B you explained above?
Yes. That's correct.