Comments
Comment by Nicholas Riley:
¶
So, uh, that’s a bug in Safari. Report it. Accessory windows like the Downloads window should not be considered in deciding whether to open a new document window.
Personally I -like- the new-window-upon-click-in-dock feature. Pester uses it too, at least in 1.1 (but treats the Alarms and Preferences windows as accessories, so the New Alarm window will appear regardless).
Comment by ssp:
¶
I assumed that’s just the default behaviour of NSDocument based applications they went with. It’s the same bug we have in TextEdit, for example (well, TextEdit IS a bug, but that’s a different story).
Whether or not I like the clicking-the-dock-opens-window-thing depends on the kind of application. It’s nice in case there is only one thing you would possibly want to do with the application.
That’s the case for a web browser (particularly Safari, that doesn’t have a separate bookmarks window), Address Book, System Preferences or WordLookup. But in most other applications it’s a nuisance, e.g. TextEdit where you may want to use the open command (for UTF-8 files, say) or Terminal, where I usually open predefined sessions from the Library submenu (having to close the newly opened window) or ProjectBuilder (which wisely doesn’t open a window on clicking it’s dock icon.
Another issue with this behaviour is that it’s utterly inconsistent. You easily have situations where behaviour when clicking a dock icon becomes hard to predict. And it seems that clicking the dock icon isn’t equivalent to activating the application, which IMO it should be: If you command tab to TextEdit it won’t open a new window.
I guess my argument against automatically opened windows would go as follows: While it is possible to make applications behave consistently and predictably in opening windows on clicking their icon, doing so will require a lot of care and thinking through all the possible odd situations that can occur. Experience shows that it’s highly unlikely to expect the programmers to get it right. Hence, it shouldn’t be done.
Comment by Nicholas Riley:
¶
Thanks for the copy. That’d be a cool thing to do - just have a button ‘email me with any responses in this thread’ - Manila supports something like this, perhaps MT will soon. RSS would be better but significantly more difficult.
That’s the case for a web browser (particularly Safari, that doesn’t have a separate bookmarks window), Address Book, System Preferences or WordLookup. But in most other applications it’s a nuisance, e.g. TextEdit where you may want to use the open command (for UTF-8 files, say) or Terminal, where I usually open predefined sessions from the Library submenu (having to close the newly opened window) or ProjectBuilder (which wisely doesn’t open a window on clicking it’s dock icon.
Well, I can see it for PB as there is no such thing as an untitled file there (much to my annoyance; I used to use untitled files for note-taking and code snippets all the time in CodeWarrior).
For Terminal sessions, I used to use HostLauncher before it bitrotted, now I just drop the Terminal Library folder into the Dock so I don’t have to use the awkward hierarchical menu to get to it. I still miss keyboard-only access to Terminal sessions; perhaps some day I will resurrect this feature of HostLauncher.
In the other cases, one can make an argument that any other features you’d use other than opening an untitled document. should appear in the dock menu. Camino puts your bookmarks there; Project Builder lets you open a file, etc.
Another issue with this behaviour is that it’s utterly inconsistent. You easily have situations where behaviour when clicking a dock icon becomes hard to predict. And it seems that clicking the dock icon isn’t equivalent to activating the application, which IMO it should be: If you command tab to TextEdit it won’t open a new window.
That’s by design, though I notice LiteSwitch (which I use instead of Apple’s anemic dock switching) causes TextEdit to open an untitled window.
This behavior originates in pre-Mac OS X, where double-clicking an already-opened application in the Finder was changed in Mac OS 8 to generate a ‘rapp’ (reopen application) event. This was especially useful for new users who were confused that double-clicking an application the ‘first’ time would generate an untitled document, but double-clicking subsequent times would do nothing (the menu bar changes, in too subtle a change). Since the Dock is used for application launching in OS X, the same reasoning applies.
I guess my argument against automatically opened windows would go as follows: While it is possible to make applications behave consistently and predictably in opening windows on clicking their icon, doing so will require a lot of care and thinking through all the possible odd situations that can occur. Experience shows that it’s highly unlikely to expect the programmers to get it right. Hence, it shouldn’t be done.
I think this is endemic of a lot of Mac OS X problems - less thought is being put into interface decisions than happened earlier, mainly I’d guess through lack of time, insufficient review and non-UI-aware programmers. Good UI is hard, and while an OS can make consistency easier, it can’t make these kinds of logical decisions automatic in the face of arbitrary program behavior.
Comment by ssp:
¶
That’d be a cool thing to do - just have a button ‘email me with any responses in this thread’ - Manila supports something like this, perhaps MT will soon. RSS would be better but significantly more difficult.
Interesting idea. What would be done about people entering other people’s addresses in blogs. Could be pretty nasty.
Bill Bumgarner has comments RSS up and running on his site. Perhaps a way to do it in MT would be to copy mt-comments.cgi, and simply make it output another template. I don’t want to get into this, though, as I lack knowledge of all those languages. Any takers?
Good UI is hard, and while an OS can make consistency easier, it can’t make these kinds of logical decisions automatic in the face of arbitrary program behavior.
I still expect Apple to get the UI in their own programs on their own OS right. They should know. Although it frequently seems that they don’t recently.
P.S. That’s neat: Fill the textarea on this page, making the scroll bar appear. Place mouse on top. Use scroll wheel (or uControl scroll wheel emulation). This will first scroll the textarea to its limits and then go on scrolling the page. Scroll backwards and you’ll scroll the page until the textarea is below the mouse cursor. The you’ll scroll your own text. I like it.
