DesignAday

In Comparison: Multiple Selection, part 2

Yesterday, I began to describe the detailed behavior of multiple selection in Windows and Mac OS. We took a detailed look at shift-clicking. Let’s add in control-clicking now. On the Mac, that would be a command-click, but there are some differences in behavior, so we’ll start off with Windows.

Control-clicking selects non-contiguous items. Control-click an unselected item to add it to the selection; control-click a selected item to deselect it. That’s simple, but what happens when we combine control and shift clicking. Try the following sequence:

1. Click item 1.
2. Shift-click item 5.
3. Control-click item3.

At this point, items 1, 2, 4, and 5 are selected. What do you think would happen if you now shift-clicked item 6? Windows considers a control-click to be an anchoring click, regardless of whether it is adding to or removing from the selection. Deselecting item 3 with a control-click replaces the original anchor on item 1. So, shift-clicking item 6 results in the deselection of items 1 and 2, and the selection of items 3 through 6.

Apple’s selection logic is a bit more sophisticated. The exact same sequence of clicks (replacing control with the command key) results in a more logical selection: 1, 2, 4, 5, and 6. 3 remains deselected. As it turns out, instead of treating a deselecting command-click as an anchor, Mac OS makes the next selected item in the list the anchor. This is a smart distinction, and I’ll show you why.

Going back to Windows, do the following:

1. Click item 1.
2. Shift-click item 3.
3. Control-click item 5.
4. Shift-click item 7.

Upon the last step, items 1 through 3 are deselected, leaving you with items 5 through 7 selected. The same steps in Mac OS result in two selected ranges. In a long list of items, you can repeat this pattern as many times as you like. With every command-click, Mac OS creates a new anchor point without affecting the already selected items. The only thing that screws it up is when you double-back, shift-selecting a range back over already selected items, and then reversing again with another shift-click. Since shift-clicks aren’t anchors, they don’t hold, and any contiguous items above the anchor point will become deselected.

The net result is that Mac OS X will allow you to easily move through a list, selecting multiple groups of contiguous items. Windows, on the other hand, will only allow selection of one group of contiguous items—all additional items must be selected individually.

Continue to Part 3

In Comparison: Multiple Selection, part 1

How often do you think about the details of the basic interactions that make up the OS you use on a daily basis? Last week, I had to specify the behavior for multiple selection of list items in a browser-based application. The customer’s requirement asked for shift-clicking and control-clicking, just as you would find on the desktop. With the intent of making the behavior exactly like desktop OS behavior, I analyzed both Windows XP (which will be installed on the machines our application will be used on) and Mac OS X Lion. Unsurprisingly, there are significant differences between them. I’ll start by describing shift-clicking now, and continuing with control-clicking tomorrow.

As you likely know, shift-clicking selects contiguous items in a list. So, if you click item 1 to select it, and then shift-click item 5, items 2, 3, and 4, will be selected as well. That’s clear enough, but let’s dig a little deeper. Feel free to follow along.

What happens if you have a series of contiguous, selected items, and then shift-click to add to the selection? For example, you have selected items 1 through 3 by clicking 1 and then shift-clicking 3. Now, let’s shift-click item 5. Sure enough, item 4 is selected too, and we end up with items 1 through 5 selected. Now try this: click item 3, then shift-click item 5. Items 3, 4, and 5 are selected. Now shift-click item 1. What happened? Items 4 and 5 deselected, and items 1 and 2 selected. Item 3 remained selected, so we now have items 1 through 3.

As it turns out, the OS is setting anchors on clicks, but not on shift-clicks. In other words, it remembers that you clicked on item 3, but forgets about the shift-click on 5. I consider this behavior to be counterintuitive; I would expect items 1 and 2 to be added to the selection without losing 4 and 5. This behavior is identical in Mac OS X and Windows XP.

Tomorrow’s post will be part 2.

The Quickening

In the Highlander series of films and TV shows, a Quickening occurs when one immortal beheads another, receiving all of the knowledge and power of their defeated opponent. A similar phenomena occurs in the software industry when a company ignores their customers. Those customers end up drifting away to competitors. It’s a slow burn, rather than an explosion, but the metaphor works.

I just received email as a “Mac Customer” from Aaron Forth, Quicken’s new General Manager of the Personal Finance Group.

I recognize, however, that we have not always delivered on this promise to Quicken Mac customers.

Darn right, you haven’t. The message goes on to explain that they are working on a solution that will make Quicken 2007 “Lion-compatible” (his quotes, not mine) by early Spring. Yes, that’s right: they are working on making a 5-year-old version of their software run (limp?) in the latest OS. Well, guess what. I don’t want Quicken 2007. Lion finally forced me to kick that fossil to the curb and find something better. I’ve been happily using iBank since July (I wrote about switching at the time). It’s not perfect, and I really do miss the ability to pay my bills directly through the application, rather than having to do it separately on my bank’s website, but there is no way I’m going to go back to Quicken 2007.

Rather than spending time to jury rig obsolete software, why not figure out why so many Mac users were still using it (as if that isn’t fairly obvious), and work on a new version that we actually want to use?

In the Details: Double Tap

I just discovered that in the latest version of Safari, Apple has carried over another feature from iOS. Double-tapping an object, like an image or paragraph, zooms in on it, fitting it to the width of the window. Notice that I said “double-tap” rather than “double-click.” Given the touch-enabled input devices that Apple now sells, it is possible to tap the surface of a touch pad or mouse as an action distinguishable from a click. While this feature isn’t particularly useful to me, I could see it being quite handy to someone with vision deficiency. I never would have thought to try tapping the surface of my mouse, even though I slide my fingers across it to scroll all the time. I discovered it accidentally, and it took me a minute to figure out what I had done. Double-clicking, of course, still selects text, as it always has.

Scroll Barred

When Apple designed iOS for the iPhone, they designed it for direct manipulation. They intended for the user to interact with the UI as they would with something tangible. To that end, they did not include scroll bars; at least, not in the traditional sense. Scroll bars don’t make sense when you can push the content itself. But scroll bars have evolved on the desktop to be both an interface for scrolling, and an indicator of what portion of the entire scrollable area is in view. Scroll bars allow us to navigate content, while at the same time showing us that there is more content to see. Thus, in iOS, Apple included scroll indicators to convey the same information, but they also decided that it would be inefficient to give up the screen real estate they require. Instead, the scroll indicators only appear while scrolling is occurring. It is an elegant solution, one well fitted to mobile devices.

Enter Lion. Apple decides that the best way to scroll is with their gesture-based input devices. It is more convenient, faster, and frankly, makes more sense. Scroll bars are too abstracted from the physical action, and it’s a point of inconsistency between their platforms. So, they reverse the scroll direction and do away with scroll bars, relying on the same scroll indicators present in iOS, the one difference between that, if you catch one before it fades away, you can actually drag it like a scroll bar.

At the outset, it sounds reasonable. Aesthetically speaking, I appreciate the reduction in clutter. Most of the time, I don’t miss them. However, since upgrading to Lion, I have experienced several occasions where I didn’t realize that I wasn’t seeing all of the content. There have been times that I’ve had a long list of files to scroll through, and catching the hide-and-seek scrollbars isn’t exactly convenient.

I haven’t yet turned scroll bars back on, but I’m not yet convinced that the current implementation is a good idea on the desktop.

Of Mice and Men

Depending on who you ask, Apple’s reversal of scrolling direction in Lion was either the dumbest decision ever or no big deal. Natural scrolling, as Apple refers to it, works the way it does on the iPhone, iPod Touch, and iPad. Move your finger in the direction you want the content to go, as opposed to traditional scrolling, in which the content moves in the opposite direction.

While it is easy enough to change it back in the system settings, I decided to give it a try, and I delayed posting about it until I had given myself plenty of time to adjust and ponder the change. After several weeks, I can honestly say that I was able to adapt with very little annoyance. I still have one old machine that I use on our NOFORN network, and that’s where I’m now starting in the wrong direction.

Frankly, the change makes a lot of sense, and it’s not just to be more like their mobile devices. Apple no longer sells input devices without gesture support. Their Magic Mouse allows for gestures, as do their Magic Trackpad and the trackpads on their laptops. They have decided that the best way to scroll is by stroking your input device with a finger or two. In fact, they believe this so strongly, they have decided that scroll bars are no longer necessary. Why clutter the UI with scroll bars that aren’t being used? Well, up until now, when you used a mouse wheel, you weren’t controlling the page directly—you were interacting with the scroll bar. The wheel moved the bar. Push the wheel up, and the scroll bar would go up while the content went down. If the scroll bar is no longer controlling the content, that means we are interacting more directly with the content, so the content should just move in the direction we are pushing. The removal of scroll bars has other repercussions, but that’s another post.

I think the scroll reversal is a reasonable thing to do, and Apple is the only company with the chutzpah to make such a fundamental change. The question is, will Microsoft ever follow suit, or will this create one more rift between the two platforms?

In the Details: Resize

I forget where I heard someone make the comment that, with Lion, Apple is attempting to remove abstractions from the user interface. I’m not sure that is universally true. Take window resizing, for instance. In the past, Apple always provided a visible handle in the bottom-right corner of a window that was used to resize it. Windows, on the other hand, relied on a cursor change at any edge of the window. Lion has adopted the Windows convention, removing the persistent visual cue, and in the process, abstracting the UI.

The change is particularly apparent in the column view. Prior to Lion, each column had a space on the right of the scrollbar, and below that, a drag handle for resizing the column. Since they did away with persistent scrollbars, the space for the drag handles was also lost. Instead, you drag the 1-pixel borders. The tricky thing is that there is no visual distinction between the edge of the right-most column and the right edge of the window. There are two different cursors: one representing the column, which will enlarge the window and the column at the same time, and one representing the window, which will resize the window without resizing the column. You just have to get the cursor in the right place. I consider this to be a poorer design than the previous version.

Of course, this also refutes the argument that Apple is turning Mac OS X into a touch UI. Touch UI’s can’t rely on hover effects and cursor changes, and a finger needs a larger target than a 1-pixel border.

In the Details: Icon Morph

One of the little changes in Lion that I noticed right away is the morphing of a dragged icon between views. Let’s say you have a document sitting on your desktop, and you are moving it into a folder within a column-view window. On the desktop, the document is represented by a large icon with the white label centered below it, wrapping to multiple lines. When it is displayed in column view, the icon is much smaller, and the label stretches out to the right in a single line. In previous versions of OS X, the icon would remain the same as the dragged source until dropped. In Lion, there is an animated transition during the drag in which the icon smoothly shrinks and the text moves. It’s a subtle change, but transitions such as this make for seamless interactions, removing any chance of confusion.

Desktop Underpinnings

Last week, I posted my thoughts on Apple’s new Mission Control feature within Mac OS X Lion. Chris Parker pointed out an inaccuracy, so I’d like to address it. I had complained that Apple removed the ability to pin an application to a particular space (or to all spaces). This is not the case, and I should have realized it, because my applications were actually following my prior settings; I just hadn’t realized it with the change to a single row of spaces. The functionality is still there, but it is hidden, and not particularly discoverable. Whereas in Leopard, space assignment was managed in the Spaces preference pane, Lion does away with the centralized list, putting the settings on each individual application. You must now navigate to the desktop to which you wish to pin an application, right-click the application icon in the dock, select Options, and then choose either All Desktops, This Desktop, or None in the sub-menu.

Once you know this, it is more convenient than having to open the preference pane. It’s less abstract. But, it’s hidden, buried two-levels into a right-click menu. My rule is that right-click menus are for shortcuts, not the only way to access a function. I would expect the same options to be included in the Window menu of the application.

Mission Control

Spaces was the multi-desktop feature in Mac OS X Leopard that has now been rolled into Lion’s Mission Control, which also incorporates Dashboard and Expose. I have heard that Spaces wasn’t used by a lot of people. I used it extensively and loved the flexibility of it. I had Spaces set up as a grid of six: three on top and three on bottom. I had certain applications pinned to specific spaces. For example, space number four (bottom-left) always had Mail on the left display and iCal on the right display. Space two (top-middle) contained iTunes on the left and TweetDeck on the right. Some applications, like Safari, were left to open in whatever space I was looking at when they were launched. Then there were other applications, such as Skype, that I set to display in every space. Using the control and arrow keys, I was able to quickly move between spaces, each space being no more than two keystrokes away.

Mission Control isn’t as robust. I assume Apple decided to simplify Spaces in an effort to make it easier for more people to understand. All spaces are now in a single row, rather than a grid, so it takes longer to navigate between them. There are keyboard shortcuts to jump directly to them, as there were in Spaces; I just need to learn them. They didn’t retain the preferences for assigning applications to spaces, and there is no way to make an application present on every space. Mission Control allows me to move windows from one space to another, but unlike Spaces, I don’t have the freedom of dragging a window from any space; only those windows in the current space can be dragged. Furthermore, I can’t drag a window from one monitor to the other monitor in a different space. I must first drag the window to the other monitor in the current space, and then drag it from the current space to another space, requiring two actions instead of one. This all makes the rearrangement of applications and windows a bit tedious, and I find that I’m doing it more often, now that I can’t specify where I want applications to open.

Hopefully, Apple will return some of Space’s functionality in future updates.

Correction: See post for 8/8/11, Desktop Underpinnings