Re: "maximize" button that is being complained about in this thread. It's not a maximize button, it's a zoom button, and while I don't like its behavior, it's always been this way in OS X. From the current HIG:
Your application determines the initial size and position of a window, which is called the standard state. If the user changes a window’s size or location by at least 7 points, the new size and location is the called the user state. The user can toggle between the standard state and the user state by clicking the zoom button in the title bar. Follow the guidelines in this section so that users can have the zoom experience they expect.
Choose a standard state that is best suited for the tasks your app enables. A document window, for example, should show as much as possible of the document’s content. Don’t assume that the standard state should be as large as the current display permits; instead, determine a size that makes it convenient for users to use your app. If appropriate, you can allow users to take some app windows full screen if they want more space.
Adjust the standard state when appropriate. The user can’t change the standard state that defines a window’s initial position and size, but your app can do so, based on other settings. For example, a word processor might define a standard that accommodates the display of a document whose width is specified in the Page Setup dialog.
Respond appropriately when the user zooms. When the user zooms a window that is in the user state, your app should make sure that size defined by the standard state is appropriate in the current context. Specifically, move the window as little as possible to make it the standard size, while at the same time keeping the entire window on the screen. The zoom button should not cause the window to fill the entire screen unless that was the last state the user set.
If the user zooms a window in a multidisplay system, the standard state should be on the display that contains the largest portion of the window, not necessarily on the display that contains the menu bar. This means that if the user moves a window between displays, the window’s position in the standard state could be on different displays at different times. The standard state for any window must always be fully contained on a single display.
Don’t allow a zoomed window to overlap the Dock. You always want to make sure that users have full use of both your windows and the Dock. For more information about the Dock, see “The Dock.”
Who cares about the justification. The major problem with it is that the behaviour is unpredictable. You have no idea what is going to happen when you push that button for a given app. In some apps, they'll go full screen. A browser might resize to fit the current web page. iTunes actually shrinks down to a mini control window.
So now in order to use this button if a useful manner the user has to remember exactly what it does for any given application.
i tend not to use it for this very reason. i've wished, on more than one occasion, that a user could customize this action to be a "maximize vertically", as one could in gnome2. maybe i'm one of the few who actually used this, as it seems to have been phased out in gnome3. but i found it very useful.
Yeah, over the years Mac OS has increasingly offered functionality that was once a separate utility to install, MacDivvy is one of the few utilities left I install separately.
One of Divvy's coolest features is you can build preset window positions and attach them to keyboard chords. So for me, cmd-shift-space brings up divvy then hitting 1 makes the app fill the window, 2 is upper left 2/3 of the screen, 3 is upper right 2/3 of the screen, etc -- I have 7 or 8 presets. Full keyboard control of window position is awesome. It's the best $13 I've ever spent.
retailmenot also claims a $20% code, so that will knock some money off. But I happily paid retail and I use it 100 times a day. It's also particularly helpful if you use an external monitor at your desk and regularly resize windows as you attach or detach the monitor.
You're not the only one to use vertical maximization. I really liked being able to middle-click the maximize button for vertical, or right-click for horizontal. It seems that's no longer the case in Gnome-3-hacked-to-look-like-Gnome-2-in-Ubuntu-11.10. I suppose it's replaced by Windows 7-style border dragging, but that's less flexible as you can only do maximize, left half, or right half.
Windows 7 actually supports explicit vertical maximization; dragging the top of a window to the top of the screen will maximize the app vertically but leave its width unchanged.
I've got that action keybound to alt-space on my desktop.
Which would be WindowMaker.
Key benefits: virtually no development, Steve Jobs designed it, but for engineers on UNIX (well, NeXT), not idiots, and it's ~20 years old, so it's balazzzzzingly fucking fast on modern HW.
Stays the fuck out of my face, lets me get shit done.
When I first saw a fully customized WindowMaker in 2002, I thought, "Wow, HollywoodOS does exist!" Back when Linux used to come with several functional desktops, AfterStep and WindowMaker (both clones of NeXTStep) were my favorite, followed by Enlightenment (the only place I've ever seen window buttons on the side of the window).
I've played with a lot of desktops. twm, fvwm, fvwm2, WindowMaker, Enlightenment, icewm, various *boxes, GNOME and KDE through the ages, and XFCE4.
The latter is probably the closest to a replacement to WindowMaker that I've found, but it has two serious deficits:
1: No "raise on circulate" (with window contents visible) when you're alt-tab circulating through windows. Makes it really hard to find what you're looking for.
2: No pinnable window list. In WindowMaker, any arbitrary menu (or sub-menu) may be pinned to the root window. F11 (or middle mouse on root) brings up a menu of all open windows (the windowlist), which can be navigated (arrow keys or mouse), and if pinned, stays persistent while you hunt down the particular window you're looking for. Very useful when needed.
I’m using Gnome 3.2 on Debian Sid and vertical/horizontal maximization is still there.
To define shorcuts: Go to Settings, Keyboard, Shortcuts, Windows, and set your shortcuts.
To change the behaviour of middle-clicking or right-clicking on the title bar, install gnome-tweak-took, run gnome-tweak-tool, and go to the Windows section.
Gnome shell on Ubuntu is really misleading. On Fedora the support for it is first class so it works wonderfully, out of the box, including features like this.
(I like Unity too, but it needs work on things like multiple monitor support)
because they've come from Windows where that is the behaviour. Much like using ctrl or cmd as a modifier - when you become accustomed to one, the other takes some getting used to.
I know a lot of people who are more familiar with Mac than Windows and still don't know what that button does and simply ignores it. Along with the other small oval button that's there in pre-Lion.
You would have a point there, except that the zoom button, as I believe it's called, behaves differently in different applications.
An example, in some browsers clicking zoom will zoom to the page width, however in iTunes clicking zoom shrinks you to the miniplayer.
The different behaviours are confusing and difficult to remember, and not only goes against user expectations but isn't user-configurable.
How is this an argument? If users expect a button to do a certain thing then that is what the button should do. Where the behavior was learned is irrelevant.
How is THAT an argument? Different users will obviously expect different things.
The green button in almost every case just resizes the window to the optimal size. Whereas the maximise button simply wastes most of your screen estate (which, bizarrely, many Windows users think is actually taking advantage of their large displays, whereas its really doing the opposite).
6 paragraphs, complete with 7 points, multiple states, and not messing with the almighty Dock. No wonder Apple can't figure out window management, and is resorting to the "Maximize everything!" approach.
I would say a more accurate name would be the "fit window to content" button, as that is what it does.
If you're looking at a document in Pages, clicking that button will fit the window to the document, not wasting any screen space with blank unused area, but also not obscuring any of the document (screen space permitting).
The problem is that some third party applications ignore this and just implement Windows-style "maximise" behaviour. In addition, for some applications the 'content' area is likely to be larger than the screen (see Logic and Final Cut), so maximising actually makes sense.
What I imagine Apple's designers were considering is whether "maximise" behaviour actually makes sense. What are you gaining when you maximise a window? For applications such as Word, you're just filling the screen up with empty grey space on either side of the document. For most web pages, the content will appear within ~1000 pixels of horizontal space, with any additional space being wasted (or worse, the page has liquid resizing text, resulting in hard-to-read loooooooooooong lines when the window is maximised).
One argument may be that maximising a window blocks out distractions, but surely something like a full screen specific mode would be more appropriate for such a situation.
Ultimately I think that the problem is that users already have an expectation of what that button does; it is another casualty of the thoughtless interaction design that Windows has normalised to the general computer-using public.
For those of you who dislike the green button's behavior, I'd highly recommend the tiny app Right Zoom: http://m.lifehacker.com/5240827/rightzoom-makes-the-os-x-max.... It makes the green button maximize windows to the full screen size. More importantly for me, it gives a keyboard shortcut (CMD-ALT-E) for maximising a window. It's one of the few modifications I'd hate to be without.
I like to refer to the zoom button as the optimize button. I find that it helps people understand its function more than zoom (which makes me think enlarge, full screen).
It's interesting to juxtapose your excerpt from the HIG with megamark16's comment below ("When I click the Maximize button on OSX, it doesn't actually maximize the window 99% of the time, it just picks a seemingly random size.")
What this should tell us is that a UI strategy can be "optimal" -- in the sense that the HIG passage you quoted likely emerged from a lot of intense debate between some very bright, motivated people at Apple -- yet still unintuitive and confusing to users who weren't sitting on the committee that came up with it.
If we accept Einstein's dictum that things should be as simple as possible but no simpler, then it's very hard to defend the byzantine "Zoom" button in OS X. A sufficiently-complex model may indeed appear to be a random process to someone who sees only the model's behavior.
Adherence to convention is important, but so is quality documentation. I'd argue each of those virtues are on the downswing right now. Lots of new devs, faster platform feature additions, Apple failing to lead by example...pick three and add three of your own.
TL;DR: Put thorough doc under the Help menu. Every time.
Someone mentioned Photobooth hotkey weirdness below. There's definitely a (low, low) threshold at which the presence of mystery-hotkey functionality moves from "easter eggs yay!" to "your doc sucks." Dogcow moof was all the easter egg I needed, really.
The "apps should be obvious from first launch" maxim has had awful consequences here. Are people thinking "if it needs doc I did it wrong"? Because hey kids, it needs doc whether you think it's obvious or not.
Curious whether you'd consider this to be evidence of platform doc erosion:
I develop a pretty simple Mac application and market it through the MAS. It ships with thorough instructions that are available through the standard Help menu.
Aside from the odd feature request, the only question I ever hear from users (maybe 1% of them?) is: "I launched your app and it doesn't seem to be working at all. I went to your website and there's no PDF user manual to be found. Is it broken?"
My responses to that have morphed over time into a very polite text wrapper around a screenshot of the Help menu.
Are these isolated cases of people just not thinking to look for help under the Help menu, or has the overall quality of content under the Help menu declined to the point where a subset of users just never expect useful information to be there?
That's one of the things I hate in OS X: many features are there, but hidden until you press some modifier key. Hold shift to maximize. Hold option while pasting to move a file instead of copying. Hold Cmd+Shift+. to see hidden files, and so on. That's the opposite of user-friendly.
The worst example of this tendency? Photobooth. You can press shift and alt to disable the flash and the delay (resp.), but there's no hint of this feature anywhere. I think it's not even in the help or in any documentation.
This type of thing is my biggest complaint with OSX.
I've been using OSX as my main desktop OS for about a year now, and it's unbelievable how many simple customizations require third party products. To make it worse, a lot of them cost money.
Coming from Debian and Fluxbox I'm used to almost any possible configuration or customization being possible via /etc, the files in ~/.fluxbox/, or utilities installed using synaptic.
Thanks for the tip! I didn't know about RightZoom.
Here are some little known Mac utilities I like:
* MutableCode's Breakaway let's you configure separate audio volumes (including silence) for with and without headphones.
* Stereopsis' Flux adjusts your display's color temperature to match the type of lighting in your room (e.g. daylight, halogen, fluorescent) to avoid the blindly blue glare in a dark room.
Your application determines the initial size and position of a window, which is called the standard state. If the user changes a window’s size or location by at least 7 points, the new size and location is the called the user state. The user can toggle between the standard state and the user state by clicking the zoom button in the title bar. Follow the guidelines in this section so that users can have the zoom experience they expect.
Choose a standard state that is best suited for the tasks your app enables. A document window, for example, should show as much as possible of the document’s content. Don’t assume that the standard state should be as large as the current display permits; instead, determine a size that makes it convenient for users to use your app. If appropriate, you can allow users to take some app windows full screen if they want more space.
Adjust the standard state when appropriate. The user can’t change the standard state that defines a window’s initial position and size, but your app can do so, based on other settings. For example, a word processor might define a standard that accommodates the display of a document whose width is specified in the Page Setup dialog.
Respond appropriately when the user zooms. When the user zooms a window that is in the user state, your app should make sure that size defined by the standard state is appropriate in the current context. Specifically, move the window as little as possible to make it the standard size, while at the same time keeping the entire window on the screen. The zoom button should not cause the window to fill the entire screen unless that was the last state the user set.
If the user zooms a window in a multidisplay system, the standard state should be on the display that contains the largest portion of the window, not necessarily on the display that contains the menu bar. This means that if the user moves a window between displays, the window’s position in the standard state could be on different displays at different times. The standard state for any window must always be fully contained on a single display.
Don’t allow a zoomed window to overlap the Dock. You always want to make sure that users have full use of both your windows and the Dock. For more information about the Dock, see “The Dock.”
http://developer.apple.com/library/mac/#documentation/UserEx...