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.
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.
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.
I can't explain your downvotes...
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.
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.
Works on my KDE4 (over Ubuntu) .. only been using KDE since about 98/99 and never knew about this.
This goes up there with double- and triple-click +drag for selection.
(I like Unity too, but it needs work on things like multiple monitor support)
The different behaviours are confusing and difficult to remember, and not only goes against user expectations but isn't user-configurable.
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).
For varying values of optimal including "not optimal in any way for any user in any situation"
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.
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.
"when two elements of an interface conflict, or are ambiguous, the behaviour should be that which will least surprise the user"
http://en.wikipedia.org/wiki/Principle_of_least_astonishment
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?
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.
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...