What Panther Should Fix: Part One, Broken Windows
Windowing in OS X is inconsistent. In some applications the windows expand beyond the dock (e.g. Flash, Photoshop), while in others they do not (e.g. Word). Some applications allow windows to be dragged up above the menu bar (e.g. Photoshop), some don�t (e.g. flash, word). In some applications, hitting command-h will hide the applications and in others it does not. And, finally, in some applications, hitting option while clicking on the desktop will hide the application; in others it doesn�t.
While this appears to be a somewhat minor complaint, it is one of those aspects of the user experience that takes an operating system from being merely usable to enjoyable to use. With Panther Apple has the opportunity to make the windowing experience in OS X as consistent as it was in the legacy classic OS�s. I would like to see windows in all applications behave the same way (and that includes the iApps as well, why should iMovie get rid of the dock while other applications do not?). Ideally, when I click on the maximize button, it should do what maximize does on the Windows platform�maximize the width and height of the available screen space abutting the dock. I realize that taking a cue from Windows may be somewhat sacrilegious but I have always felt this windowing experience is much cleaner. What do you think of the way windows work in OS X? What would you change? What would you keep the same?
del.icio.us
Digg
Facebook
Slashdot
StumbleUpon
Comments
One developer’s perspective:
Hadley:
All of the things you mention in your first paragraph are the responsibility of the application. Generally speaking, you’ll find issues with them most often in Carbon apps.
That said, there does appear to be a bug in the OS function that handles dragging windows in Carbon. Specifically, under certain circumstances it does not respect the “bounds rectangle” that is passed to it. As a result, you can drag windows under the menu bar.
Respecting the dock is a clearly documented application responsibility. Any app. the violates the dock probably wasn’t tested enough as the solution is quite simple.
Command H is handled by the OS unless an application has it mapped to something else. This is real dilemma for developers who may have a user base with years of history using CMD-H for something else.
Cheers,
-bc
I COMPLETELY agree. Like many things it sounds small, but is a fundamental usability problem in OS X.
“User Interface Design for Programmers” has a really wonderful anecdote about usability and how small things are important. Read the story about “dough”—it’s a little down the page when you first hit the site. http://www.joelonsoftware.com/printerFriendly/uibook/chapters/fog0000000057.html
Something else I would like to see in the control panel somwhere is a simple check box to turn “show contents while dragging” (resizing) windows OFF. I know this is something that is written into the apps, but there should be some global policies that override the options in the applications.
This would help users who are running 10 on slower G4’s eleminate the problem of jerky window redraws cause the cpu cant keep up.
The single most annoying element in OS X’s window management (IMHO) is the inability to grab a window by it’s edges in order to reposition. This ket function must return to the system. It’s absurd to be forced to change screen resolutions in order to re-arrange a recalcitrant window that has appeared partly off the screen but cannot be manipulated because the edges (sides) cannot be grabbed.
I would have to agree with what Dan, Jason and ‘mapple’ said. A lot of good ideas have been programmed here and there, implementation is the key. I would also like to offer a suggestion.
Make all additional features and those previously mentioned togglable both by preferences and by modifier keys.
If we apply this to the edges of windows we get the following possible happy users:
Bob likes windows to behave as they currently do in 10.2. Slim, unclickable edges, drag only with the title bar, resize conforms to the content width, no windowshade or transparency.
Suki likes her windows to behave more like other *nix with fat grabby sides that resize when dragged. She also doesn’t have the fastest of macs, so live window action is best defaulted to Off.
Achmel runs a public mac and needs to keep the interface stock, so that the random users aren’t confused. But he’s also a power user that prefers using things like windowshading, draggable edges, transparency and full screen resize. So he has memorized all of the modifier key options that let him manipulate the interface smoothly.
Sheniqua prefers window shading and transparency always available through the title bar. And though she does like slim window edges, she likes the grabby bars to appear when she hovers the cursor over the edge. About the only keyboard modifier she wants to remember is the one that toggles the grabby sides from Resize to Move.
Svorn really gets the most out of the depth-based auto transparency feature of the new windowing system and has had the lost window centering and forced refresh commands come in very useful at times. He also thinks that the next version of the 3d Window Plug-in (open source donateware) he was testing will be a solid enough arrangement metaphor to use all the time.
That’s what I’d like to see. All the features, all by choice, open architecture. If that could also be made small and fast, we would again have THE window manager that everyone would try to follow.
Hoby