>I kind of doubt that we have modal forms and prompts in programs today because of some legacy limitations. I think there is a very good case for them even today, regardless of how many windows a modern computer can handle open at once.
I agree, specially with the "even". Having a couple of Linux boxes around the house, I've noticed how many dialogs are not only not modal, but actually resizable (and nowadays, I can only curse whoever set the modify structure dialog, expression builder and a few others to fixed sizes... which may have been great on 800x640 and quite decent on 1024x768, but look like a practice in philately on today's displays - and the size has only doubled). So... the GUIdelines of the past may not necessarily be wise decisions, not all of them. We have the benefit of a couple of decades of development (OK, let's count the development of the GUI since the first Mac, that's more than 20 years in the past).
>Case in point -- if your wife has trouble noticing that a new modal form has popped up, wouldn't she have an even HARDER time realizing it if the modal form didn't insist on staying on top of all other screens until she DOES notice it.
But it doesn't stay. She brings up another app to find the fuqueing folder name, to navigate to where she left her files, then clicks back to the first app where she had the file selector open, but can't do a thing, because she had originally selected wrong kind of file, got the error message, read it - and didn't click OK to remove that message. So the whole app is blocked because there's a modal window somewhere. And this window was somewhere to the left, small lost among the icons. So she calls me and I notice the modal window, and feel like such a pro for that :).
> Say, if a modal form pops up, she doesn't realize it, clicks another window that HIDES the modal form, then she would be in even WORSE trouble, no?
Depends on the importance of the dialog. If it's a showstopper, it should be modal and always on top. However, not too many windows should have that privilege. If it's just to set a value which will change the behavior (i.e. be the user's choice of a setting), it can be closed at any time, and the dialog can sit there endlessly if user wants so. Why would a, say, color selector have to be modal? Because it holds a reference to the object which it should paint? So what, today's apps hold hundreds of such references, no sweat. What happens when such a window gets pushed back? Its parent object doesn't get painted. But nothing goes wrong if the user's attention drifts to something else while this dialog is open. It can be set to expire, or to close automatically (or with a prompt) when the parent is destroyed etc etc.
> For example, VFP has this annoying habit of occasionally hiding a report -related prompt behind the report review window. So, you are staring at the partially displayed review window which takes up the whole screen, and you have no idea why it stopped. The modal prompt is there, but it is hidden by the other window.
While I tolerated Vista on my laptop, it used to run help windows behind the app... luckily, not modal.
And I've seen what you describe in a couple of other situations (a nasty ActiveX was involved), and it basically renders a live app inoperable. Now if that dialog was not modal... :).
>So, I may be a heretic as far as some schools of thought are concerned, I still think that it is the users' habits and preferences that must guide user interface design, even if it runs contrary to the latest way of thinking and doing things. Take Office 2007, for example (please!) -- a LOT of my customers absolutely hate it because they don't know how to do things with it the way they are used to doing things. The UI is modern and probably well researched, but it doesn't serve these particular users at all -- quite on the contrary, it is a hindrance and a major headache for them.
As I said, habit is hard to acquire, twice as hard to lose. And you aren't the only one with users who like it the old way - many times I like it the old way. When FP came around, I kept using the RoadRunner (or whatever it was called) external editor... until I realized that the simplicity of the GUI of Fox's editor clearly wins, and that I actually achieve more by being very versatile with few simple tools (RISC approach :) than with the fifty keyboard shortcuts in RR (CISC). Or, in VFP6, the dropdown key (between right win and right ctrl), Y,Enter was used to run the Beautifier on the current code window. In the Seven of Nine (pun intended), it just didn't work anymore, wasn't there in the dropdown, so I had to relearn alt+t,y,enter to do the same from the main menu. Then it was fixed in VFP8 and could do drop, y, enter, but half the time I do it like in 7.
So I changed a habit; so will the Office users, once they get to lose the old and get the new habit. Doesn't mean that the old was better nor that the new one is.
The trouble with the teams who design GUI guidelines get their wisdom from watching the people use... the software they already have. Not the software in general. If it weren't so, the data entry would still be done singlehandedly - the Enter would mean the same as in Set Confirm On, and the data entry folks could keep their right hand over the numeric keypad and the other on the document from which they are typing (yep, I'm talking about that generation, where the computers weren't on the spot yet). There is no other explanation for the need to use two hands (or go keypad-mouse-keypad) just to enter two numbers in a dialog, just because some wiseass somewhere decided that the preferable paradigm for data entry is typing using the tabulator key... so we have the tab key as the preferable way of data t... entry all over the world. Press Enter before you're completely done and your document will try to fly!
There are other instances where I wonder what were they on, and whether I would have liked some too... or rather not.
