Save Changes Integrated 2
2007-05-18 7 Comments
After some discussion with Peter Sikking, I decided to modify the design from my previous post.
Before, I placed the dialog part at the bottom, to keep the buttons in the usual place (if you think of the whole window as dialog). This time I aim at a stronger visual separation, more like the dialog appearing right on top of the image window, but precisely aligned and glued to it. The canvas part could either slide down, or the message / button part could appear above it for not having to resize the window.
Note the disappearance of the close button. Close buttons were the user has to wonder if they equal cancel and close or do-whatever and close are a well known problem. For GNOME/GTK, it has been argued that the presence of a Close button on dialogs is an accessibility feature for the blind. Well, I don’t quite get that.
(Click to enlarge)
Thorwil's 
Close buttons can be read by screen readers and are way more obvious to
users than the window decoration only.
There is also the matter of certian themes (or even window managers) not
providing a suitable X in the window decoration. Most do but that
historical possibility makes us very reluctant to leave out the close
button.
Ironically, the Gimp is perhaps the best example of a program where this design wouldn’t work well. In the Gimp, unlike other apps, a window can quite often be much narrower (e.g. when editing an icon) than the confirmation alert needs to be.
A program like OpenOffice Writer would have the opposite problem: the window would be much wider than the confirmation alert needed to be, so the alert would be distended and difficult to scan.
Well done for continuing to think of new ideas, though. 🙂
Alan: screenreaders can’t read the buttons? And as what is a WM close button on a dialog read? If it is just close, it’s the same problem of uncertainty about whether an action is carried out or not.
mpt: When working on icons, I have my image window large enough to contain the menu bar and for zooming in.
But for small windows, the dialog part could be larger than the document part below.
For very wide windows, I would limit the width of the content of the dialog part and left-align the whole block.
Looks a lot like the messages embedded to the image window, that I proposed years ago. However I don’t think that this concept it well suited for things such as the Save Changed dialog (and fail to see the problem with the current approach). But it would probably be a good idea to use it for informational messages. I once spent a weekend trying to implement this but found that it’s rather difficult to get right. Especially since GIMP windows are often too small for the message to be displayed. And enlarging the window is not an option.
Sven: The problem with the Save changes dialog is actually much the same for all modal dialogs refering to document windows.
The current dialog already shares focus and minimizing with the document window. That’s good as hiding only one of the 2 would lead to an ugly situation. The dialog being a separately movable window is only useful to move it off the canvas for free sight. If you want that, we can do better by automatically arranging things (within the limits of screen and window size). If you don’t want that, having a separate window with its own title bar is useless.
Like said earlier, for too small windows, the dialog part could be larger, resulting in the shape of 2 overlaid rectangles.
I guess this would be easier to do on a WM level.
If the title bar is your concern, use a window manager that doesn’t draw a title bar for transient dialogs.
BTW, your argument with Alan about the Close button is most probably a misunderstanding. He talks about Close buttons in the action area of dialogs and I think you are talking about the Close icon in the window decorations.
GTK+ 2.10 has API to convince the window manager not do draw the Close button in the window frame (and some window managers might even respect this). This might even be useful in some cases but it is not possible to change this after the window is already visible. So it wouldn’t work as you suggested it here.