On Mar 13, 2012, at 4:50 AM, Bob Freeman wrote: I think Alex is right about the new "Automatic Termination" feature in some apps with Lion. Siracusa talks about it in his Lion review, but why Lion would decide to shut TextEdit down with 8GB of free memory does seem a bit draconian.
It appears to me that this is very hard to predict if the system will actually do it, as I frequently have TextEdit running for hours or days with no windows and my 10.7.3 system doesn't cause it to terminate. Don't recall if it ever has, but have no idea why it stays open, but the next time I get low on free memory I will try and see if it does try to kill it off.
I know they were working on it in 10.7.3, when I left some unnamed beta but the basic case is that the app is left running, yet you are prevented from using the GUI. Sometimes it quit the app if I clicked in the Finder, sometimes it didn't when I command tabbed to another app. And with 8 GB of RAM free. This does not generate a sense of comfort with the operating system for the user. This generates the exact opposite.
Since this is such a switch for the longterm Mac users, the PAINFULLY OBVIOUS THING to do is to offer a switch, a system preference for "the new way", or "the way you're used to".
This could have been done in Lion for the new scroll bars, and for this "I can guess what you want to do better than you can" behaviour of semi-auto quitting but not really auto quitting of the app.
Really, the app's not auto quitting - only the GUI is. Why, when the app is using the least RAM would you quit the GUI so that the user would be prevented from using this wonderful GUI experience that Apple has made available to us for decades?
Considering that this experience is foreign from the user experience and expectations that Apple has set up, if they want to make the iOS users happy and the install base happy, OFFER A SYSTEM PREFERENCE to allow the user to set it up to how they prefer it.
Same with "Save a version" and Scroll bars.
See, someone or some group at Apple fell and hit their head. Really. No HUI designer in their right mind would take user interface metaphors from a touch device with limited RAM and limited screen real estate and try to force them on to a system with THE EXACT OPPOSITE SPECIFICATIONS - mouse driven, large screen real estate, large amounts of RAM devices.
Yet this is what happened. And it's a BAD experience on the desktop.
Take the touch interface. The intersection of your finger with the screen is a blob where the OS can detect which actionable elements are under your finger and act on them. If a really skinny, yet visible item is an actionable item (an iOS scroll bar) it doesn't matter if it is skinny, since the intersection point of the interaction item (your finger) and the element is the overlap of your fingertip's blob on the GUI item.
But if you are using a mouse, you are faced with using a 1 intersection point to click the UI item. with scroll bars that are as thin as a quarter, this is a BAD IDEA. Whomever designs things this way makes it harder for the user. This is the wrong HUI interaction metaphor for the system. This is PAINFULLY OBVIOUS.
Take for example the UIAlertView. These pop open on small screens and are fine in that small field of view. But Apple sells 27 inch screens and when every display or removal of a window must pop open, swoosh across the screen, or otherwise animate, the very size of the item being animated can easily make the effect startling, distracting and unpleasant.
When you can't turn this off, this makes users MAD.
Again, the wrong UI metaphor for the specifics of the device. Large screens.
There are so many examples of HUI strangeness that are so foreign to good design and the design that Apple had established the standard on for a decade, that leaping to Lion's way of doing things is too much of a change for established users - without allowing a set of switches to turn off the new ways of doing things.
Apple needs to un hit its head and it needs to do that badly.
Think it would go something like (not positive about this - it might be "-boolean FALSE" instead):
defaults write com.apple.TextEdit NSSupportsAutomaticTermination -string NO
If it does work please let us know. I've not done it because my system doesn't ever shut it down. If the stock version in Mac OS X Lion /Applications/TextEdit.app doesn't pay attention to this setting, you could always build and modify and use the opensource version of TextEdit from within Xcode - it's in the folder /Developer/Examples/TextEdit
-Bob
- Alex Zavatone
|