Adobe CS5’s Non-Standard Cursor
Using a non-standard alternative animation instead of the SBBOD is not going to do anything to improve the performance, perceived or real, of the applications. It just looks like a really poor way to try and mask the applications’ responsiveness issues instead of actually dealing with them.
Using the standard Mac OS X indeterminate progress spinner as a cursor is just bizarre.
Update: Jesper’s take.
Update 2: Igot’s follow-up post.
8 Comments RSS · Twitter
Actually, they are trying *harder* than most apps.
There is no notion of "using the SBBOD".
The spinning beachball is displayed automatically by the Window Server when it thinks your app has stopped handling events. If it ever shows, you have a badly coded app (iTunes included) - ie, its gone into a cpu-intensive loop that should have been done on a background thread, or in an async NSOperation, leaving the main runloop working.
At least Adobe have *tried* to make the app indicate that its busy without frying everything else.
@Pedant That’s what Igot is getting at. They’re trying harder to give the appearance of being responsive, without actually being responsive. I think this is almost like lying to the user. At least with the beach ball I know what the score is.
I fail to see why implementing their own was worth spending programmer time on. Instead of the system telling you the app is being unresponsive, the app is telling you it itself is being unresponsive.
Perhaps it's an attempt to show that the app is still alive, given that the beachball frequently means a zombie application that will never wake up again?
Incidentally, the worst beachball offender from Apple is Aperture, at leas version 2.x. Much worse than iTunes for me. On the other hand, it's actually doing a bunch of work.
Guess what: Photoshop is NOT unresponsive when you see this cursor (e.g. when you see it you are in the midst of an operation that can be canceled using the standard Esc or Cmd-. keys). If it were not responding to events you would see the SBBOD
"Guess what: Photoshop is NOT unresponsive when you see this cursor (e.g. when you see it you are in the midst of an operation that can be canceled using the standard Esc or Cmd-. keys)."
Oh, well that makes it all better then. No, it's still hostile because there is no indication that it's that type of operation, and there's no precedent to expect that it would indicate as such.
Pop up a freaking dialog or drop a sheet with a barber pole and a cancel button if it's an operation that can be cancelled, it's not rocket surgery.
Windows has, since Windows 95, had two 'hourglass' cursors that applications can use: one where the entire cursor turns into an hourglass, and another where the arrow remains, but a small hourglass appears at its tail. The latter is used by an application to indicate that background processing is happening, but the application is still accepting input.
Indeed, the Java implementation on OS X has a 'wait' cursor for similar purposes, which is an arrow accompanied by a blue spinning ball.
It's quite an informative cursor state, and I've always been a bit surprised that OS X doesn't provide a native one for app developers to use, particularly now as we are being encouraged to take advantage of multiple cores and push processing off into the background more often.
I suppose the counter-argument is that such processing is always either be something the user doesn't need to know about (so you shouldn't be indicating it to them anyway), or an operation that the user is interested in tracking and potentially cancelling (in which case you should give them a dialog).
I have beefs with Adobe not adhering to the Mac UI, but I notice that Safari is using the start-up progress indicator wheel when it is busy working to open a window. Hmmm.
