I’ve been a Mac user since 1984, which is to say, since the very first Mac (which was then “Macintosh.”) Over the years I’ve used many different Mac models and every new version of the OS that came out.
Until recently, I continued to use OS X 10.5.8 (Leopard), there being nothing compelling for me about Snow Leopard (10.6.x), no reason to upgrade. With the release of Lion (10.7.x) and Leo’s new no-longer-supported status, I made the leap to 10.6.8. That is, I installed 10.6.0 over my 10.5.8 then applied the 10.6.8 combined updater. Overnight I went from the latest Leopard version to the latest Snow Leopard version.
I was mystified, at first, by the vastly increased amount of mouse clicking required to get my work done. I process video files and their associated metadata (text) files. For much of this work, I have droplet AppleScripts to process and clean up the text files. I need only drag the files, mostly single, but sometimes in bulk, to the droplet AppleScripts and let them do their work. Depending on the type of video file, it may take between three and five droplets to process. There is necessarily a lot of clicking and dragging.
After processing, I inspect both the text and video recording files visually — the text in BBEdit and the video files in a video player. Those that pass inspection get copied, by dragging, from the scratch disk to the archive volume. Those that do not are discarded by moving to the trash.
Snow Leo requires a great deal more clicking than Leo did to do the same work. This is mostly because Snow Leo does not pass through a “first click” to a window. That is, if a window is not active, and you click on it, on a particular file, for example, the file is not selected. In Leo it is, but in Snow Leo, it only makes the window active. It requires a subsequent click to select the file.
What’s more, it used to be that a file would become selected on the “mouseDown” event — when clicked. Now it is not selected until the “mouseUp” event — when the mouse is released. It used to be that one had immediate visual feedback when you clicked, now there may be no visual feedback at all unless multiple clicks are employed.
Here’s what happens when clicking in a non-active window and dragging a file elsewhere:
Leo activates the window making it front-most, highlights the clicked-upon file and it is dragged elsewhere.
Sow Leo: The window is activated. Period. It requires a second click to select the file and a third to click and drag it elsewhere. Now, it’s true that once the window is active, I could just click and drag the desired file elsewhere (to one of my Droplets), but if I do that, the dragged file never becomes highlighted to indicate that it has been selected. In fact, if a previous file was selected, it remains selected even though I might drag the clicked-upon file elsewhere to be processed. This is soooo wrong. I should think that clicking a file and dragging it successfully to my Droplet would be sufficient to make it the selection, but it is not. Very un-intuitive.
Some of my droplets act upon a single file, some on multiple files. When dropping onto the former, what used to take one click-drag not takes three clicks and a drag (two clicks and one click drag). The first click activates the window, the second selects the file and then, after a pause so as not to click so quickly as to be a double-click, I can click and drag the now-selected file to my droplet. Using only one click to activate the window, then a click-drag to the droplet prevents the file from being highlighted and it’s up to me to remember which file I dragged or else I can lose my place in the window’s file listing.
If I lose my place, there’s the possibility of inadvertently skipping a file (when dragging a single file) or of processing the same file twice. Worse yet, at the point where I drag each file, singly, to the video player, if the visual inspection should find that the file is incomplete, my next step would be to hit the “Move To The Trash” icon in the recordings’ window’s ToolBar. But, if the wrong file is highlighted (instead of the one I just dragged to the player) then I’m liable to discard the wrong file (which I have done multiple times thus far). Three clicks and a drag where formerly a single click-drag sufficed.
In Leo, I used to be able to drag across a range of files in an inactive window to select them, in Snow Leo, the drag is wasted and only activates the window, so I have to drag again — double the work.
Even choosing a label for one or more files is now more clicks. I used to right-click, drag to the desired label in the hierarchical menu, then release the mouse over the desired label and be done. Now, when I release the mouse button over the desired label, it is not selected, does not get applied. It requires a second click on the desired label — a doubling of the clicks required.
It will doubtless take a long time to un-learn the work habits and muscle memory years of using Leopard. The result of these changes was almost enough for me to revert to Leo and be done with all the unnecessary clicking.
Almost. Why, I asked, did Apple change a perfectly good point and click interface to make it require so many more mouse clicks. For this particular work-flow of mine, the clicks required has more than doubled. Why would Apple require so many more mouse clicks? Then I had an insight.
It is in preparation for a gesture-based touch interface — the end of the mouse input device. Apple is currently making OS X more like IOS. Lion incorporates oodles of gestures lifted from IOS and even scroll bars do not appear, by default, in Lion unless scrolling is in progress — just like IOS.
We know that IOS started as a sub-set of OS X but required changes to utilize a touch interface. Now the touch interface of IOS has merged into OS X. It was a natural evolution as most of the Macs Apple sells are laptops, which come with a built-in trackpad. The non-laptops come standard with a mouse that has a touch pad built in.
Touch is in; clicking is on the way out. A touch input device must necessarily be treated differently than a mouse.
It wouldn’t do, for example, to activate a window and select the tapped file if in fact the user was merely swiping to scroll the screen or the window contents. Certainly a “swiper” would not want the swipe of a finger to select a file and move it elsewhere the way a click-drag would do. .
In IOS, it is the tap that selects a file. It is not selected when the screen is first touched, but when released (mouseDown and mouseUp in the same place, as it were).
So, while I seriously considered reverting back to Leo, in the end I decided I had two choices: like it or lump it. As I am anticipating a new Mac Pro when the Thunderbolt version comes out, and as it will doubtless rum Lion, I’d better decide to start liking it.
Still, it does seem like Apple could have taken into consideration the type of input device when determining whether a click in Snow Leo just activates a window or activates and passes the click through to the clicked upon file to cause it to be selected. I have no problem moving between IOS and OS X. But this OS X masquerading as IOS is driving me nuts. Let the mouse be a mouse and stop treating it like a touch-screen or trackpad.
To tell the truth, the first hint I had of this problem was in an application while I was still running Leo. The app was compiled with the latest XCode tools and exhibited the same “do not select the item” behavior when the clicked upon item was dragged, in this case, from one pane of the app’s window to another pane. Even though the item was in fact acted upon by the app, it was nonetheless not selected in the source pane when the operation was done.
This was a change from earlier versions of the app and I reported it as a bug.
The developer concluded that, if it was a bug, it was Apple’s bug, and then pointed out that “that’s how Finder works.” Of course, they were using a version of OS X later than Leo.
As the developer told me, “But, I’ve confirmed with some friends at Apple that this is the preferred, intentional behavior moving forward.” And: “It also seems odd that option-dragging behaves differently than regular dragging. And that they keep changing this in every iteration of OS X. (10.4 behaved the way 10.7 does now!)”
I get it. The mouse is out, touch is in. It’s clear that Apple believes we cannot distinguish between mouse use and gestures in a touch interface. (In this, they are wrong.) Witness the whole reverse scrolling issue. Seriously, There are people at Apple who think it’s confusing to have a “downward” (contracting finger on a scroll wheel/ball) that scrolls a page upward on the Mac and a downward swipe scrolling downwards on IOS.
At Apple, apparently, they see this as inconsistent. I’ve always thought of the scroll wheel or ball as being a virtual “roller” between my finger and the page; a downward roll of the top of the ball/wheel would therefore result in an upward movement of the virtual paper on the screen. That’s how a real roller would work.
Now, I think that most people have no problem moving between a mouse interface on the Mac and IOS. I see no inconsistency at all. The touch interface is like putting my finger directly upon the virtual paper. Naturally, it will move in the direction of finger movement. The mouse, by contrast, has that virtual ball or wheel between my finger and the “paper” and so the scrolling that results is totally consistent with having that virtual roller there.
I think people are more likely to be confused by “reverse scrolling” (after decades of it working one way and all that muscle memory) than by any difference between a touch interface and a mouse-driven interface. The mouse is not a touch interface device and Apple should not treat it like one.