Although I like Notepad2, it has some pathological alert dialog behavior, particularly when it comes to searching. Here's an alert dialog I almost always get when searching a document:
The firefox search bar is great. For thoses who have not upgraded condescending grin besides the default ms-windows search keys, wonder if ms-office will even fully use them, you can hit the / key. This brings up a bar just above the status bar which allows you to enter the search criteria it also provides the status of the each, such as not found, looping around,etc.
It also does real time highlighting of the search phrase. Great for smaller document which most of your web pages are.
For large documents the ms-word 2003 is actually rather good. it is non-modal and if you modify something it start researching from where you edited. However even it will display modal boxes when for various things such as looping around.
OK, so we all hate dialog boxes.
But they’re the only tool we have in most standard toolkits. Or, if there are others, they are hard to use.
What we need is a few more options for displaying messages to the user.
Some of these options might demand a shift in how we program. For example, if a dialog is to be non-modal, you can’t just call Show() or whatever and have it block until the user makes a choice, you need to set up callbacks or use predicate programming or some other more complicated thing.
Others will require some hard thinking and work on the part of both application and gui toolkit authors, and will need some context awareness to be truly effective. Do you show your unobtrusive firefox-search-style message on the top or bottom? Or maybe attached to the side of a certain window or panel, but out of the way of the user. It would be awesome if we could do that but someone needs to sit down and implement it.
As a secondary gripe then, it would really be beneficial to user interfaces if the GUI toolkits were more hackable. It took me a long time to get a control working in wxWidgets, and I turned around and ran the first few times I thought about adding a new widget to GTK.
Reed
Yes, those dialogs suck, but when searching i find it to be even worse that every application seems to have it’s own “find next” shortcut. Visual studio is master in search suckyness though, but then that’s where I spend most of my time so I’d notice it more.
Anyway, crap like that needs to be outlawed yesteryear.
Is it really possible that people have this much time to discuss modal dialog boxes?
Couldnt agree more - the Find dialog is one of the very few issues I have with Notepad2 stopping it from being a flawless text editor for my uses (it also shouldnt be modal in the first place let alone have these popups).
Back to your point of dialogs - I found what the morons in the VS team at Microsoft did with VS2005 to be inexcusable - there are now more irritating dialogs than ever. For chrissakes they have a status bar for the IDE - use it instead! There are numerous examples but Edit Continue in particular is a joke - you try to make a change in the code window yet only if the planets are aligned in a particular way can you do so without getting more modal dialogs in the way. I ended up turning the whole feature off - let me type when I damn well like and respect that I don’t need to be told over and over modally what the impact of that is…
It isn’t the dialog boxes that are the problem, it’s the modal dialog boxes.
We’ve had dialog boxes in the form of forms (ahem) on web pages for ever, but they don’t force us to complete them before they’ll let us get on with anything else.
Firefox’s extension installer is one of the few good dialogs I have seen - it won’t let you OK it until it has been displayed for several seconds, meaning you have to see what it is trying to install.
You can always cancel though.
At least the Mac’s dialogs actually put the action text on each button rather than “Yes/No/Ok/Cancel” which requires you fully understand the question.
[)amien
[ICR], I agree that there’s a lot of space for innovation in the desktop UI. But look at some of the nice non-modal notifications we’ve seen in the last few years. There’s the yellow info bar in Internet Explorer and Firefox (it’ll tell you you need a plugin, or that you’re about to install a Greasemonkey script). And there’s the potentially overused “toast” popups made popular by MSN. The problem is that a lazy coder doesn’t have access to these. You can’t just include an InfoBar in your Form and say InfoBar.Show().
Well we’ve had Balloon Tooltips for a number of years now, and they’re still very underused. I think it’s partly also habbit.
I think it is nice to know that notepad actually got all the way to the end of the document. 
Josh wrote: “Windows (and OSX) would likely benefit from testing a graphical enhancement to throwing things away by animating the icon representing the file being deleted moving to the recycle bin”.
Please, please, please don’t provide any more cutesy little animations. Those are even more annoying than the dialog boxes, in my humble opinion. Any animation screen that some UI specialist deems must be there should have a check box saying “Never show me this annoying stupid thing ever again”.
I think Adam and Reed have hit the proverbial nails with: “The Windows dialog boxes are often nothing more than liability transfers more than information. Infected? Hey, you chose to run the code.” and “Some of these options might demand a shift in how we program. For example, if a dialog is to be non-modal, you can’t just call Show() or whatever and have it block until the user makes a choice, you need to set up callbacks or use predicate programming or some other more complicated thing.” respectively. However, these are, IMHO, merely symptoms.
Having been a developer and a requirements writer I believe the problem with message boxes popping up is many fold (or is that manifold?). Requirements writers are often too lazy or lack the technical expertise to think through all the possible use case paths - we write about the main success scenario [see Alistair Cockburn in “Writing Effective Use Cases”] and maybe one or two alternate outcomes. We then naively hope that the developers, with their skill for detail, will spot the missing outcomes. Unfortunately, the developers either don’t spot them or do spot them but don’t raise the issue having been conditioned by us to not do that through years of us whining to their managers about nit-picky developers who have pointed out “nit-picky” little errors in the spec. Then, when the code is being built and the path that nobody thought of arises, all too often we, the developers, (note: I’m changing roles here) are too lazy to get up out of our chairs and go discuss with the requirements writer what to do in this situation. We may have already invested a lot of time hacking out the code that we never really designed and we don’t want to have to rewrite that so we solve the problem by inserting a message box and then explain it to QA and the product managers as necessary or by design or too expensive to fix.
The problem is not the use of message boxes; it is the fact that in altogether too many projects, error handling and scenarios other than the main success scenario are ignored until the code is being written. The result is that unusual paths through the code are handled in an ad hoc manner that is annoying to the end user or brings the product crashing down or logs some informative message like “Unable to open Window handle. Consult your administrator” which may accurately describe the problem but doesn’t actually describe the problem.
The firefox search bar is great. For thoses who have not upgraded condescending grin besides the default ms-windows search keys, wonder if ms-office will even fully use them, you can hit the / key. This brings up a bar just above the status bar which allows you to enter the search criteria it also provides the status of the each, such as not found, looping around,etc.
The firefox search model is close to perfect. I talk about that here:
http://www.codinghorror.com/blog/archives/000432.html
The one exception is that it doesn’t return focus to the place you started when you close the search bar.
I think the reason why people don’t read alert dialogs and instinctively go for “OK”/“Yes”, is that they’ve been inundated with them since the dawn of time and become desensitized.
From what I’ve seen of Vista, the problem has only gotten worse.
Even with all the overuse, there are still times I want modal alerts for system-level “oh sh!t”-type stuff. Things like “your laptop battery is at 20%”, or “your video card is about to melt”.
I don’t know if I agree. Yeah, OK, the case presented with NotePad2 (and “standard” NotePad does something really similar) is quite extreme, but there are certain cases where a dialog box is needed. Where a modal dialog box is needed.
Let’s assume not every user is like us; not every user knows the inner workings of applications. I want to know the consequences of my actions when removing or updating a record, for example. If that configuration file needed to run the application is missing, I’d prefer the application to create a new one from scratch with “base” options instead of stop working, but I’d like a notice of it, thank you very much. And as a programmer I want to give notice of things like that on a modal box, to make sure that the user sees, reads and understands what he’s going to do and the consequences of it.
Users don’t notice/read modals? Their fault. And, OK, maybe our fault too for not using modals only when they’re really helpful.
Ironically we use dialog boxes in our latest app specifically to break the users flow - we want them to pause - and they are “are you sure you want to do this” confirmation boxes.
We do this because on the two buttons they could click on that present the dialog boxes, they are buttons that should rarely be used and have significant consequences for the stock records that get altered and they could present a shortcut to lazy operators. So significant, that at the same time we send an email alert to the administrators.
So we actually benefit our users, not fail them. But we still stick to the flow theory. We do not alter their flow unless they really are about to do something that shouldn’t be done casually.
I don’t expect them to read the dialog box however but it does break their flow.
There are times when it is appropriate to use for certain users. I’ve always been an advocate of knowing your audience/users and giving options for both. In the case of Excel, it is helpful to know that something maybe harmful, but it needs better wording for the novice user. It could also use a setup macro the first time to set options like warn for macros and also give a brief description of what it is.
Don’t condemn the tool for the programmer’s sins.
Here here! Gawd, do I ever hate those silly modal dialog boxes. Makes me appreciate the approach taken by Growl on OS X all the more.
I think the reason you see so many modal dialog boxes is that it is easiest thing to code in the MS world. In both VB and VC++, all it takes is a one-line call anywhere in your code. You don’t have to bother taking the time to design a form, or have to handle multiple threads (since that wonderful one-line call is executing in the same thread that called it - which halts everything). It is just too easy.
I also think the reason that so many people click through without reading them is that there have many, many genius developers that over use the dialog box with just an “OK” button. There is nothing else that you could possibly do besides click the button - so there is no reason to waste your time reading it.