User Experience Stack Exchange is a question and answer site for user experience researchers and experts. It only takes a minute to sign up.
Sign up to join this community
Take a simple dialog window:
The user will expect that the titlebar can be used to drag the window through the screen. But why is it limited to just this bar?
Why is it uncommon that windows can be moved by clicking anywhere in the window that isn't an input element and just drag from there?
I would say that this often leads to an unwanted drag and drop action. What if this window for example has a small scrollbar, you want to scroll to the bottom of the page and you accidentally miss the scrollbar? You would drag the window down and you might need to reverse this action.
Why is it uncommon that windows can be moved by clicking anyway in the window that isn't an input element and just drag from there?
Often there are images and other elements that you want to drag and drop to another window. Then you must be able to copy the label when you click near it but you also want to drag the window when you click far enough. So you need to define a place where every user can expect the window drag to work. And this currently is the title bar.
The title bar isn't always the only spot to that can be used to drag the window, (these days some windows can be dragged by parts of their background, but it's rare) but it's the oldest and most established and common convention. It originated in the early WIMP UIs, the Smalltalk systems from the 70s and 80s.
If you study the way the above windows were designed you'll see there really isn't any other affordance on a window for dragging it other than the title bar - there's no unused window background that could be grabbed (remember screen real estate was much more expensive back then). Soon the title bar became extended across the whole width of the window, making the window rectangular shaped, providing more space to grab and made screen updates computationally more efficient. And making the title bar full width allowed it to hold buttons that act as window manipulation shortcuts.
This turned out to be a very learnable, usable system and was copied by many different UIs (Mac, Windows, etc.). There wasn't any good reason to go away from this convention. It wasn't broke so there was no need to fix it, and it still survives today.
This is actually not always true. In some cases the default behavior of most apps would be to allow to drag windows by empty space. An example is KDE. See the screenshot:
KDE's default Oxygen widget style has window decoration visually merged with window contents. Thus, to make feel match look, the theme also by default allows to drag windows from all empty areas. Both parts of design are somewhat configurable: drag window option is highlighted in the screenshot — it can be disabled or minified, and there's also an option to outline active window title to prevent merging of decorations with content.
But this feature is a source of controversy between some users and developers, not only because of mistakenly dragging the window instead of moving a widget handle, as mentioned in Marvin's answer, but also because it is next to impossible to implement perfectly with current widget toolkits like Qt and GTK+. For GTK+ (in oxygen-gtk) there're quite some hacks including blacklisting some common applications and individual widgets from triggering drag operation. Similar hacks, though to a lesser extent, are present in oxygen-qt.
The Windows OS provides the (optional) title bar and control box, as well as a mechanism for OS users to organize their application windows (re-positioning, minimizing, maximizing, closing).
From the perspective of the Windows OS, the title bar is the user's API for these operations. Everything else in the window is "content" that is under the control of whoever developed that specific application.
The developer of the specific application may provide additional ways for a user to do re-positioning, minimizing, maximizing, and closing, by creating controls that trigger the API programmatically (i.e. you could implement an application where the windows could be re-positioned by dragging the background of the content). The developer may also switch off the title bar API entirely. It is their application. The OS can't impose re-positioning by dragging inside the content area, simply because it is (by design) outside their control.
Dragging is limited to the title bar for consistency and perhaps usability. If you could both drag a window by clicking in the content area, as well as interact with buttons, text, etc. in the content area, there would be a much higher margin for error (and presumed difficulty in programming).
Clicks within the window are reserved for interacting with content. In your sample dialog window, there is ample whitespace to click and drag if that option existed. However, lets say you wanted to copy an error message from a window similar to what is below. Copying the message will allow you to paste it into a Google search and get more information in an attempt to solve the issue. It may be very difficult to copy the error if you could also drag by clicking in the main content area.
download bmml source – Wireframes created with Balsamiq Mockups
There's quite probably also a historical reason: defining whether the cursor is in the title bar is computationally a much simpler problem than defining whether it is in NOT(text OR button OR input box OR scrollbar OR ...). I think I remember draggable windows in GEM on a machine bought in 1987 with 512kB of RAM, and certainly in some DOS applications (text mode) from a few years later. In both of these cases code had to be kept simple. Without a compelling reason to change this convention it stuck. You could even suggest that some of the other reasons in the other answers follow on from this long-standing behaviour, as windows became more complex. That might be going a little too far though.
The question is mostly moot because, even where dragging on empty space is an option, nobody sits there choosing a spot to drag from. That would take longer than moving the mouse straight to the one place you know will work.
In terms of quickly acquiring a draggable area, I think it has more than zero value. But if it's not consistent it's not useful, and it seems like the only way it could be consistent is if windows had thick borders all round; and in that case, the borders would anyway be more useful as resize handles than drag handles.
Anyway, I'm not convinced there is a performance penalty to draggable empty space. When you click with the mouse, the system (OS + applications) has to search through every control on the screen to make sure it has found the correct target for the click. By the time it has figured out that your click was not inside any controls, it doesn't cost anything extra to say "OK then, start dragging the window".
Mac OS X allows dragging by window content. All windows that were "brushed metal" worked this way. So the whole window body was a draggable area, and only areas occupied by actual controls weren't draggable. The problem with this approach (at least for me and some friends) was that it was not quite clear to users where one could drag and where one couldn't.
This is exacerbated if you have views that do not have an obvious border. As the drag area was generally specified per view, the non-draggable area was always a rectangle around a view, even if its graphics were circular, or if some parts of the view were thinner than others.
It seems Apple has noticed this, as the general look of "brushed metal" has been removed (though windows created as such still allow dragging, they just don't look that different). However, windows like Safari browser windows or Messages buddy windows still let you drag them e.g. by their status bars at the bottom. So there seems to be a development towards making only clearly delineated areas without borderless UI elements draggable these days.
