In Comparison: Align Objects

Why are there so many differences between the UI’s for object alignment in Adobe’s products? It’s a simple enough microinteraction—one would think that they could settle on a unified approach.

Illustrator’s palette covers the basics, providing buttons aligning objects left, center, right, top, middle, and bottom, as well as distributing objects by each edge and their centers. There’s a little more to it, but let’s leave that detail to my previous post.

InDesign’s palette starts with the same options as Illustrator, but then adds on the ability to specify spacing when distributing objects. You can also select from a list of things you may want to align objects to, such as the page or margins. Below that are options that I find much more useful than the distribution options above. Making sure objects of different sizes have equal spacing between their edges is more often the way I want objects distributed.

Photoshop doesn’t even have an alignment palette. It will, however, display the same alignment controls as Illustrator in the toolbar when the move tool is selected. I rarely select the move tool, preferring instead to hold down the command key to temporarily switch to the move tool, so those buttons aren’t particularly convenient for me. Photoshop also adds an auto-alignment feature. I had to try it to figure out what it does. It’s used for stitching photos together, and this is not where I would expect to find that functionality.

Of the three, I prefer InDesign’s palette, as it is the only one that provides the Distribute Spacing commands. Honestly though, I still miss Freehand’s Align palette. It was really quick to use for simple alignment, but still provided more advanced options, like distributing spacing. I used the Align to page checkbox heavily.

In Comparison: Command Key

Something that still trips me up is InDesign’s use of the command key. Back when I was using Freehand, I never switched to the arrow tool. I always had the text tool or pen tool selected. I’d just hold down the command key anytime I needed to use the arrow to select or drag something. As long as I held down the command key, I’d have the arrow cursor. Release the command key and it would go back to whichever tool I had selected.

InDesign has this same feature, which I appreciate, but for some reason they’ve doubled up on the function of the command key. Not only does holding the command key change your cursor to the arrow, it also allows you to select an object that is underneath the currently selected object. Every time I use InDesign, I make the mistake of holding down the command key to change to the arrow tool, holding down shift to select multiple objects, then clicking and dragging one of the selected objects. Instead of moving all of the selected objects as I intended, I end up moving an object underneath the one that I clicked and losing the selection of the objects I wanted to move.

In Comparison: Multiple Selection, part 3

Parts 1 and 2 of this series of posts were the result of my exploration to determine the behavior I would specify for a new, browser-based UI. Now that I’ve explained how it works in Windows XP and Mac OS X Lion, it’s only proper that I wrap up by relating my own design rational.

I sat down with the developer who is to implement the feature and went over my findings. She agreed that including an item that was just deselected in a new ranged selection seemed like a bug. While I like the flexibility of Apple’s implementation, I agreed with her that for our purposes, it was needlessly complex. Together, we settled on a single anchor. We decided to set the anchor on clicks and shift-clicks and to not move the anchor for control-clicks. We also decided that, to keep things simple, we would never deselect items on a shift-click. This goes against the standard desktop behavior, but my thinking is that the average user doesn’t likely realize the intricacies of such interactions. As long as we do something that is sensible and internally consistent, I doubt it will be noticed.

I documented the behavior in a series of Interesting Moments Grids, like the one below, that the developer will reference during implementation, as well as during testing.

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.

In Comparison: Duplicate vs. Step and Repeat

I hope I’m never one of the proverbial old dogs. I like new things, and I don’t tend to be overly averse to change. But there are so many things about the Adobe software I’m using now that just aren’t as good as the way Freehand worked a decade ago.

In Freehand, I could use the Duplicate command (command+d or option+drag) to make a copy of one or more selected objects. After dragging the new object to where I wanted it, if I left it selected, subsequent duplicates would automatically move exactly the same distance in the same direction. This was extremely useful, and I used it a lot.

InDesign also has a Duplicate command (command+option+shift+d), but it doesn’t automatically follow the behavior described above. Instead, it has a feature called Step and Repeat (command+option+u), which opens a dialog box.

As you can see, it allows you to specify horizontal and vertical offsets and the number of times you want the object repeated. The preview is very helpful, as I’m typically eyeing the distance, rather than knowing a specific measurement. The additional UI, while useful for fine tuning, makes it take significantly longer to accomplish the same effect. Furthermore, Freehand was able to duplicate any transformation I put on an object, such as rotation. Step and Repeat only seems to handle the offset.

Freehand had a more robust capability, yet handled it in a much simpler way.

Note: I have CS 4. CS 5 may differ. Also of interest, I can’t find a Duplicate command, let alone Step and Repeat, in Illustrator.

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

  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.

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).