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.

“Near-Final Screenshots” or Wireframes?

Paul Thurrott has posted what he claims to be “near-final screenshots” of the Windows Phone 7 user interface. Seriously? These screens look more like wireframes than a user interface. They are mostly white text of varying sizes over top of a black background. It’s too simplistic. There isn’t enough variation between what is tappable and what isn’t. It works better when over a photographic or illustrative background, but I doubt that every screen is intended to do this. The whole set of screenshots seems very disjointed to me. Some of them have a high level of finish, while others appear to have been thrown together without any attention to detail. Many of the widgets appear to be placeholders, as I would expect to be used on wireframes or low-fidelity mockups. There are inconsistencies between screens that I would not expect to appear within a finished UI. And what’s the deal with all of the labels running off the edge of the screen? If this is “near-final,” they have problems.

In Comparison: On-screen Keyboards

I’ve been testing an application I designed for use on a ruggedized Windows Mobile device running version 6—one version behind the most recent. I’ve never liked Windows Mobile, and now that I’ve been using an iPhone for almost three years, Windows Mobile seems positively antique. It has changed very little in the past five or six years since I last had to work with it (WinCE, at that time). One aspect that illustrates this perfectly is the on-screen keyboard.

Granted, the WIndows keyboard is intended for stylus input, rather than a finger, but they didn’t even attempt to optimize the keyboard for mobile use. It is an almost exact duplication of a full-size keyboard. The keys are tiny and packed so tightly together that I can’t type very quickly at all. I must be very precise in targeting the keys. On the iPhone, the invisible area in which a particular key registers varies based on the likelihood it would be tapped given the context of the previously entered characters. Even when I do miss, the software is smart enough to realize what I meant to hit and automatically correct it. WiMo will suggest words as you type, but it doesn’t correct misspellings.

I’ve also gotten used to double-tapping the space bar on the iPhone to enter a period. This little shortcut allowed them to save a lot of space, relegating all punctuation to a keyboard accessed from a modifier key. WiMo stuffs in the hyphen, equals sign, left and right brackets, semi-colon, apostrophe, comma, forward and back slashes, and an acute. How often am I going to use any of those? The comma is the one punctuation mark I would like to have available on the iPhone keyboard without having to press the punctuation key. I’ve found that for most contractions, the iPhone will insert the apostrophe without me having to type it.

Perhaps the difference that bugs me the most, however, is capitalization. The iPhone automatically capitalizes the first word of a sentence. As such, I very rarely have to use the shift key. Not so on WiMo; every initial character must be proceeded by the shift key.

Mobile use requires many special considerations. The keyboard is a very visible tip to the Windows Mobile iceberg.

In Comparison: Special Characters

While headquartered here in Pittsburgh, my company has a number of satellite offices, some in other countries. We have customers in Europe, and I’ve done had to do quite a bit of design work for a German audience. I’ve created presentations for Daimler that I’ve been required to produce in both English and German. The point of explaining this is that I have often had the need of inserting special characters in text. This is one detail in which the Mac OS UI is far superior to Windows.

I’ve asked people before how to insert special characters in Windows, and nobody has ever been able to tell me. That is a noteworthy indicator in and of itself. I looked it up online and found two methods.

The GUI Method (from eHow.com)

1. Open the Character Map from the Start menu. (Choose Start, then Programs, then Accessories, then Windows System Tools and finally Character Map.)
2. Click on Fonts to select the font you want to use.
3. Locate the special character that you want to use, and click on it.
4. Click on the Select button. An image of the character will appear in the text box above the Select button.
5. Click on the Copy button. Your character is now copied to the Clipboard.
6. Click Close.
7. Go to the document that is to receive the special character. Put your cursor at the spot where you want the character to appear.
8. Paste the character into your document (Control + v from the keyboard or Paste from the Edit menu). Your character appears on the document.

The “Shortcut”

1. Find the appropriate numeric code for the character you want to insert. For example, the code for lowercase a acute (á) is 0225.
2. Hold down the ALT key and type in the code using the numeric keypad. Then, release the ALT key. Note that this method only works if you have a numeric keypad on your keyboard.

So, I can go through a process that is, at best, 11 clicks, or I can keep a reference of character codes in easy reach.

On the Mac, there is an equivalent method to the Windows character map. I have an icon for it in my menu bar, so it is only two clicks away. It is also much more robust than the Windows version and can insert a character directly into your document, rather than relying on the extra steps of copy and paste.

I rarely use the character viewer, however, because the shortcuts on the Mac are fantastic.

If I want an acute accent on any letter, all I have to do is hold down the option key and hit “e“. This inserts the acute at the cursor position without a character highlighted in yellow.   The next character I type gets the acute (é). There are corresponding shortcuts for all of the standard accents, typically assigned to the letter that most often receives them. The tilde, for instance, is option+n (ñ). The umlaut is option+u (ü). This makes them extremely easy to remember—much easier than seemingly random, four-digit codes—and it is the same combination regardless of case. To get a capital, you just hold down the shift key when you type the letter, just as you normally would.

Entering special characters is a perfect portrait of the two operating systems. Mac OS X’s method is fast and elegant. In Windows, it is clumsy and tedious.

Leave Me Alone

If you read DesignAday regularly, it’s obvious I’m a Mac user. Of course, as an Interaction Designer working for a software development firm, I do have to use Windows on a regular basis. I typically remote into PCs on our network to test my code in IE, for example. When I do, I’m deluged by little alert bubbles. They inform me that new software is ready to install, that Java updates are available, that my computer may be at risk, or that there are unused icons on the desktop.

I’ll close one and start to do something, and about two seconds later, another will pop up. It interrupts what I’m doing and really annoys me. Now, I’m willing to concede that this isn’t my machine, so I don’t particularly care about it as I would otherwise. Furthermore, nobody is managing the machine on a daily basis as I do my own, so there may be more alerts than would be typical. But in my opinion, they demand too much attention. From the little “pop” sound they make to the fact that they overlay other things on the screen, I am forced to acknowledge them. They completely interrupt my flow.

I don’t want a computer to nag at me.

In Comparison: Show Original

Here’s a simple one. Is there any way to find the original file from a shortcut in Windows? On the Mac, I can right-click on an “alias”, Apple’s name for an icon that acts as a shortcut to a file, and the contextual menu provides a “Show Original” option. When selected, a window opens, revealing the file that the alias links to. I have not been able to find the equivalent functionality on Windows (as of XP—I haven’t used Vista).

No Nissan for You!

The other day, I mentioned that I’m starting to look for a new car. One that I’m very interested in learning more about is the Nissan Cube, which is supposed to be available this Spring. They don’t have much in the way of detailed information on their website, so I registered to have them send me a brochure. I got it in the mail. It is a four-panel fold-out with pretty pictures and less information than is on the site, but it contains a CD.

“Great,” I think, “There’s bound to be some information on that!” Then I read the minimum requirements.

• Pentium 4, 2 GHz or better
• 1 GB of RAM
• Windows XP or Vista
• DirectX 9 compliant graphics card

Seriously?! In this day and age, they couldn’t go to what tiny little effort it would take to make it run on a Mac too?

Crossover was able to install the application, but it was designed to be controlled using a webcam. You are supposed to hold the brochure in front of your webcam to reveal information within the app. While Crossover would run the application, it couldn’t utilize my iSight.

So, they sent out a CD-ROM that requires a webcam, but didn’t make it compatible with Macs, that all come with webcams! I’m willing to bet that a high percentage of webcam owners are also Mac owners.

Stupid marketing! I’d be really interested to know what percentage of the people that get the CD are actually able to view it.

In Comparison: Scroll Wheel

I just received instructions in email explaining how to go about reporting mid-term grades. This bit caught my attention:

==> NOTE:  You should be aware that using the wheel on the mouse (if it has one) to scroll down the page could change your assigned grade for a student. We recommend using the scroll bar on the side. <==

The reason for this warning is simple. In Windows, the scroll wheel will move the selection within a menu form widget. It will do this regardless of whether or not the menu is actually open. If the menu has focus, the scroll wheel will control it. So, you are filling out a form, and you have just made a selection in a menu. The menu closes. Out of habit, you finger the scroll wheel to scroll the page down to the next form entry. The page doesn’t scroll, and your selection in the menu changes to something farther down in the list. Hopefully, you notice that this has occurred and correct it. To return to scrolling the page, you must click somewhere to deselect the menu.

The Mac OS, on the other hand, does not move the selection in a menu with the scroll wheel at all, thus avoiding any chance of accidentally changing values.