!Windows
Popup windows, Utility windows, Modal dialogs, Warning windows, Schmindow window! Arrrgh! Why do we have them in the first place?
Lately, like the past few months, I’ve been ever increasingly annoyed with application windows of all kinds. Why is it that almost all applications pops up tonnes of small windows for all kinds of odd purposes? Talking about elegance I am pretty sure that we could provide a more elegant solution without a new window popping up in 95% of the cases.
For instance I really like the new GtkInfoBar as seen in GEdit below, one less dialog right there:
I also think that Apple has been ingenious with their Sheet Windows:
For those unfamiliar with sheet windows they roll out from the top of your window and acts as document- or application modal dialogs, but contrary to dialogs they are not full fledged windows, but appear as “attached” to the application.
I am not saying that we should blindly copy the competition, but I really think that we could give our users a really smooth ride if we don’t pop up new windows unless we absolutely have to.
Window Manager?
I actually think that most modern window managers do a respectable job, but when apps start throwing random windows all over the screen there’s really not much they can do to make it look pretty. But why do the apps create all these windows that I am talking about then? Well, I don’t think they have ever had much of a choice. With the inclusion of GtkInfoBar in Gtk+ this has become a bit better, but we can take it so much further.
Example
Let me stress that I am not picking on Synaptic in particular, it is just a convenient example. In general I like Synaptic a lot. Try counting the number of windows spawned when installing a new package. Counting the root password dialog and a single “find” action into the entire process I counted 7 windows. I can think of no reason (other than toolkit constraints) that there would ever be more than 1 window needed.
The One Window App
I think it would be cool to try and constrain applications to only one window (with the obvious exceptions like file managers etc.). Preference- , warning-, and Utility dialogs could all be integrated into the main window in some manner.
As a first stab one could convert all (modal) dialogs to borderless overlay windows and dim out the background. These overlay windows should be immovable and stick to the parent window when it is moved, much like the sheet windows mentioned above. This might even be testable by hacking up GtkDialog.
More advanced window-internalling techniques such as rollouts and morphing window layouts would likely require bigger changes in the applications.
I am on Crack
Yeah, I know that this is all a pipe dream, and that there are lots of pitfalls and stuff I haven’t considered. All these pesky windows are just getting to my nerves!
I hope that there are at least someone out there who agrees with me on this whole deal… Somebody..?
… anybody?
Tags: Gnome, gtk, sheet window, window
August 25th, 2009 at 15:04
Go try Gnome Do.
August 25th, 2009 at 15:05
Go try Gnome Shell.
August 25th, 2009 at 15:12
As a regular user of Gnome I absolutely love your ideas!!
In fact, just today I got annoyed by all those little windows popping up in synaptic too.
I hope some skilled hacker is wanting to work on this.
August 25th, 2009 at 15:14
I agree. It would be interesting to see how a heuristic type approach that places a GtkDialog over its parent when certain conditions are met works.
At least in theory, the csw work should allow efficient snapshots of the main application window, to which dimming / desaturation effects could be applied under the dialog.
August 25th, 2009 at 15:17
@Mouse: Already did both. A desktop is unusable without Do or deskbar-applet!
August 25th, 2009 at 15:23
The “sheet” idea is very good. I hate it, when some dialog blocks the main UI, but is hidden behind the original window due to window switching.
Then you have to find the dialog first to continue working. if it would always stay ontop (inside) the parent window: problem solved.
August 25th, 2009 at 15:32
Absolutely! In particular the “sending / receiving” dialog in evolution makes me want to smack somebody — hard.
August 25th, 2009 at 15:33
I totally agree with you on this
They’re very annoying when I’m working in f.ex a text-document. We must find a solution on this.
August 25th, 2009 at 15:39
I totally agree, single window applications are awesome, for what I see as the canonical example of this, blender 3d.
http://www.blender.org/
And the 2.5 branch makes it look pretty too.
August 25th, 2009 at 15:46
“I hope that there are at least someone out there who agrees with me on this whole deal… Somebody..?”
Uh, pretty much every modern web app developer?
August 25th, 2009 at 16:52
I absolutely agree; I’ve been annoyed with the staggering quantity of windows, too. The info bar, and possibly overlay, are great improvements, usability-wise, and should be embraced.
August 25th, 2009 at 17:01
Go try Sugar, we have hardly any windows, and each app is fullscreen by default with a bare bones “window manager”.
August 25th, 2009 at 17:14
One window per app and integrating everything within the constraints of that window is basically what we’ve done with Moblin. It works pretty well.
August 25th, 2009 at 18:10
Totally agree
August 25th, 2009 at 18:14
Yes, you’re on crack. What are you thinking?
Thanks for sharing
Really thanks, so much in usability these days seems to be focused on making things visible by adding additional steps (popup-windows for example) requiring more clicks to accomplish the task at hand and cluttering the desktop.
I fully agree, lets use the windows god gave us before spawning new ones.
Right arm!
August 25th, 2009 at 18:29
I agree in general, although I’ll point out one problem with sheets is that they obscure window content. On more than one occasion, I’ve wanted to look at information that was hidden by the sheet to answer the question on the sheet. Maybe my short-term memory is just…what was I talking about?
August 25th, 2009 at 19:33
Two things that really get on my nerves: interfaces that need to be read in an order which is not left-to-right top-to-bottom, and windows that appear in random parts of the screen. For example, where details we want the user to see (such as tabs) appear on the bottom. Unless you are desperate to look “unique,” titles should go on the top.
The randomly appearing windows are evident all over the place, and they are a reason why the tunnel vision users (a phenomenon I have been meaning to write about…) have so much trouble. For example, go to Edit -> Preferences and a modal window appears (blocking the window below from functioning). Great, that will draw the user’s focus! Except for one problem: the modal window has appeared at the bottom right corner of a 50″ screen, far away from wherever the user’s eye was. Thus, five minutes of confusion. Similarly, try to predict where the preferences for a panel applet will open…
A beautiful thing with the info bar concept is that it can be applied to all of the things you mentioned, and with a sane designer it can do them really well. For example, with gedit there it’s a non-modal popup in the context of the document specifically. This is IMPOSSIBLE with popup windows (because the window manager is not for that, hence the lack of support for MDI).
A small move and this info bar can be a non-modal popup for the whole application. With the right effects, it can easily give the right visual hints towards being modal, too.
The only thing this needs is to be as easy as popup windows, which is completely attainable. We need to be able to really quickly say “give me an info bar” and, in that function, say what window the info bar should appear within. (That being a notebook page, a toplevel or maybe a text box). No preparatory garble involved. This would totally drive some movement towards cleaning up our interface. Further, with a single API controlling “dialog boxes,” the toolkit can be a lot smarter about how to present them. It is no longer at the mercy of a window manager in deciding the best course of action for a part of UI design that is entirely out of the WM’s knowledge.
After 20 or so years of hopelessly overwhelmed end users, I think it’s safe to say that the idea of having a window manager control half of an application’s interface and the UI toolkit control the other half has failed. Basically, we need apps to take more responsibility for their own windows
August 25th, 2009 at 19:58
Let me give you some issues to consider with your idea, specifically for small screens (or large screens with large type):
* If they’re not windows, they can’t be put behind the main application. So toolboxes and the like will eat up precious screen real estate you want to keep for the document (image, drawing, text, whatever) you’re actually working on.
* You describe modal interactions. Which means you can’t see the dialogue or whatever and actually change your document (according to the infor the dialogue gave you) at the same time.
* You want them immovable and always on top. So they risk covering up precisely that area of your document that the dialog is all about. Imagine a search and replace dialogue that ask you if you want to replace this occurrence – but that part of the text (or some nearby text important for context) is covered by the dialog.
Basically, anything that involuntarily reduces the area given to viewing the actual document – the thing the user is actually interested in – is a bad idea at its core, and any deviation from that needs to be very well thought out and motivated.
Inkscape, for instance, is already just borderline usable, hobbled by its insistence to keep its dialog windows on top at all times. If they were enforcing their “all in one window” defautl as well I would no longer be able to use it – the drawing area would be a useless postage-stamped sized bit somewhere in the middle. Your example image above already uses most of the screen estate on the UI, and only a small part on the actual contents. That is bad.
August 25th, 2009 at 21:55
This is one thing I have noticed many programs doing and failing with their intent.
Most computer users will click on a command and not see the dialogue box pop up in the middle of the screen or if they do see it, they will drag it to the side (trying to ignore it) and attempt to click on the main window.
This is consistent behaviour in both experienced and novice users.
The Info bar is a great solution if it is used consistently across many of the desktop applications but I have to wonder if there is a better way of completely drawing the users attention to something.
Dimming the main window and having a fold out sheet that is attached to the main window seems to hold a lot of promise.
My idea was to completely replace the contents of the main window with the dialogue box contents (in a darker shade so as to draw the users attention) but this may lead the user to think their data is lot or the program has crashed and try re-launch it again.
This seems to be a difficult problem to solve without universal composition or animation.
August 25th, 2009 at 22:12
In general I agree with having one application window.
But couldn’t things like modal dialog appearing as a slideout be something that could be handled by the window manager?
August 26th, 2009 at 01:11
Thanks for all the awesome comments everyone! There’s a lot of insight here I see
@jsled: The fact that almost every web app behaves like this is also a good pro-argument. General consistency with web apps is of course not attainable, but there are definitely some broad trends that we can adapt to. More consistency with web would be sweet!
@Faraone, Nick: I actually think that a lot of my window frustrations come from my experience with Sugar, Moblin, and Ubuntu Netbook Remix. They all take an approaches where the window=application to some extend, and I’ve just grown very used to this concept since it is so much easier to work with for most tasks.
@Shaun, Janne: First of all the sheets are for modal interactions so I need never *edit* anything underneath it. I might however want to *see* what is underneath it. This could be achieved in many ways, but some form of triggered translucency effect would probably be best… Unless one needs to copy-paste some text from the parent window (can I even do that from a normal modal dialog?). But the important thing is that I think this class of problems is solvable.
@Irwin: Yeah, I also think that the WM could magically convert modal dialogs to sheets. This might be better than hacking GtkDialog, but I suspect there are a lot of tricky interactions between tookit< ->WM…
August 26th, 2009 at 01:44
@Janne: Object Preferences panes in Inkscape (for ex.) could automatically slide in and out to free space for the whole image.
August 26th, 2009 at 03:12
@Mie, you need to see the object you’re manipulating, so being able to move the panes around is critical. I would really liek to see the function that can slide them in and out automagically without making it even more frustrating.
As it is, opening and closing the panes is a real hassle. There’s no shortcut key for closing as far as I know, so you have to use the mouse to hit the close button, and then you have to bring the panes up again, each with its own shortcut key. A lot of work when all you want is to have them go behind the workspace for a moment. It’s gotten to the point where I consider getting the source and patching it to get rid of this “always at the top” setting. Really – why is it there? Is anybody actually helped by having that set?
And the reality is that window switching, with Alt-Tab, already does what we need. It’s fast, it’s convenient, and it’s the same key for all applications. The one real improvement that apps like Gimp (or Inkscape, if they only let you do this) would be to have all the panes and semi-permanent dialogs in the same group, so that the opened dialogs all come to the front at once or go behind the work space at once.
August 26th, 2009 at 05:28
Great ideas. I really like gedit for this reason. Overwriting, reloading, saving over a network, it’s all done in the infobar. Except for the search dialog, it should be more like how firefox does it.
August 26th, 2009 at 06:37
@Janne, Re: hiding/showing panes in Inkscape: F12 hides/restores dialogs. I use it a lot at work in combination with F11 (fullscreen). It can on occasion be slightly buggy with several documents open and a combination of docked/undocked panes but mostly it works quite well.
August 26th, 2009 at 16:31
@Will, thanks, that helps a bit. Didn’t know about that one. Still wish they could sinply not lock those dialogs to be on top. This way each application would end up with their own key combination for things like this.
August 26th, 2009 at 20:43
I agree the gedit should be a model (when they made the change to the infobar I instantly loved it). OSX should not be the model. Though their little animation looks slick and the basic idea is the same, the fact that they cover up your document is *really* frustrating. I use macs quite rarely, and I’ve run into the situation where this style interface put me in an impossible bind more than once. The problem is that the kinds of questions applications have to ask you very often have to do with the content that you are looking at, so if that content is obscured, you can get really annoyed (and on OSX there’s no way to hide the window, minimize it, etc., without answering the dialog)
August 26th, 2009 at 23:26
I used the one window principal for the tic tac toe game I wrote this weekend (launchpad.net/tictactoe, http://bit.ly/ETrHh). I had to use one dialog, because there are no python bindings to GTKInfoBar. I Tried to implement it myself but no dice.
The game came out really well done, and very elegant.
August 27th, 2009 at 04:05
I agree with Tom:
Hiding information that enables you to make an informed decision on the dialog is why I for one move that dialog to the side.
“Do I want to save unnamed-1? Which one was that? Oh, its behind the dialog…”
This is why I really appreciate the gedit way, and the firefox way (the options for saving a password for the site roll down from the top of the content area), and the Pidgin connection error information that appears on the bottom of the buddy list, keeping the whole content still scrollable, not obscuring it. More solutions like these!