Hacker News Reader

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.

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.

>I really liked being able to middle-click the maximize button for vertical, or right-click for horizontal.//

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.

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.

Double clicking the vertical resizer also maximizes vertically.

In what... Gnome3? Win7? OS/X?

Win7

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 can't explain your downvotes...

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)

I think I use tools like Divvy http://mizage.com/#macdivvy more than I use the zoom icon, it makes it so much easier to position windows..

Looks a little like ShiftIt (a similar utility) http://code.google.com/p/shiftit/

You want to use the github fork which is still being developed.

Thanks for the notice. I get the auto updates and hadn't noticed I was on 1.5 and the google code page stops at 1.2

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.

Spectacle is an awesome open source util for this too: http://spectacle.divisiblebyzero.com

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.

I do this on Gnome 3 every day! I have it bound to right-click on the titlebar

Still better than Windows, where it just takes up your whole screen.

I disagree, because taking up the whole screen is what many people expect said button to do.

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.

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).

> The green button in almost every case just resizes the window to the optimal size.

For varying values of optimal including "not optimal in any way for any user in any situation"

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.

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.

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).

I don't know how I lived without cinch.app

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.

Yes - I think you're talking about the Principle of least astonishment, which states that:

"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

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?

Hold shift while clicking the zoom button to maximize the window. Edit: in Chrome only.

I'm using Lion and that does nothing in Finder or in Safari.

Right you are. It works in Chrome for me. I guess most apps don't have it.

Works for chrome. Doesn't work for Safari or Finder.

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.

Open and Shift modifiers are listed in the help in Lion.

Or install a utility like RightZoom.

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.

F.lux is actually available for all platforms! I've been using it on Windows for a while, one of my favorite small utilities.

Well, not iOS yet.

Separate volume bars for speakers/headphones are already maintained, no?

They certainly are on my work Mac (Snow Leopard).

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.

Option/Alt + 'Plus button' does that in iTunes.