Apple decided to incorporate certain iOS-isms into Mac OS X. I guess somebody in the user experience group decided this was the direction OS X had to take, and as I know from painful experience that I have almost zero expertise in user interface design, I'll defer to those who allegedly know.
That said, somebody needs to drag the iTunes and AppKit teams into a conference room and bang heads together until they get the actual user experience right. (It wouldn't hurt to have the Safari team in there, too.)
The problem is that by doing away with AppKit's former scrolling behavior, Apple has made it much more difficult to navigate within windows that have embedded, scrolling subviews. Imagine gesturing on a MacBook's trackpad to scroll down an iTunes artist page in which there are scrolling views for songs, videos and movies. You want to get to the "movies" section, which isn't visible on the screen. However, the cursor enters the "music" section and you're suddenly scrolling within that instead of the surrounding view.
You sigh, then look for the scrollbar that shows up at the far side of the surrounding view as you scroll through it. Then you realize that the scrollbar goes away when the scrolling movement stops. You move the cursor over where the scrollbar shows up, but just hovering the cursor over that area doesn't make the bar show up: only scrolling will do that.
The arrow keys work, but only for the outermost view. They might work on the inner views too, but I haven't tried that, and before that could work you'd need to get focus into whichever inner view you want to manipulate. I don't know how to do that without selecting something in the inner view, which is not what I want to do.
I use hardly any iOS apps so I don't know how many include embedded scrolling subviews, but I haven't experienced the problem I just described in Lion. Part of the problem, I just realized, is that iTunes in OS X allows its window to consist of nothing but embedded subviews: there's no requirement that the outermost view be accessible at all times via, for example, an outermost strip just inside the enclosing window. That means there's no place to put the cursor within the iTunes window boundary to indicate "my gestures apply to the outermost view". (Or if there is such a place, it's not obvious.)
The pre-Lion AppKit, and before it AppKit in NeXTStep, had a solidly-designed set of user interface elements and behaviors. Other versions of OS X tweaked the visual appearance of the elements and sometimes the default layouts (e.g., the location of the scrolling arrows), but these changes didn't disturb the logic of the fundamental behaviors. With Lion, AppKit has stepped into quicksand because the user experience metaphors and hardware/software environment of iOS don't completely match those of OS X.
I hope the user experience and AppKit teams are already thinking long and hard about those user experience metaphors in OS X. It's long past time for an overhauled human interface guidelines document (which Apple issued early in the life of OS X and proceeded to violate whenever the guidelines were inconvenient, but never mind that). The upgraded document would be valuable in itself, but the thinking behind it — the thinking needed to arrive at a consistent model of user interaction and a coherent set of user experience metaphors — is what is really crucial.
No comments:
Post a Comment