DesignAday

My name is Jack Moffett. I am an Interaction Designer with over ten years of experience. According to Herb Simon, that makes me an expert, so I must have something worth sharing. I have started this venture as an exercise to spur critical thinking about my chosen profession. I hope that others may find it thought provoking as well.

DesignAday will present a brief thought about Design every weekday.
Jan 19
Permalink

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.

Comments (View)
Permalink
Comments (View)
Jan 17
Permalink

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

Comments (View)
Jan 16
Permalink

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.

Comments (View)
Sep 28
Permalink

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.

Comments (View)
Apr 27
Permalink

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.

Comments (View)
Jan 14
Permalink

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.

Comments (View)
Apr 28
Permalink

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

Comments (View)
Feb 25
Permalink

In Comparison: Music Search Results

There are a number of differences between Amazon’s MP3 store and Apple’s iTunes Store, but the one that makes iTunes far and away the best experience is the way search results are presented.

I was looking for a particular song that has been performed by multiple artists. When I performed the search on Amazon, I was presented with the first 24 results ranked by…well, I’m not sure what they were ranked by. Amazon says they are ranked by relevance, but I don’t know what their criteria are for determining that. So, for all intents and purposes, I received a random assortment of tracks that contained the words I searched for in either the song title, artist name, or album title.

So, I sorted by song title. I was presented with the first 24 results beginning with “Thirteen Better Be Good To Me” and going on to titles beginning with the letter A. The track I was searching for starts with “Good”. I scrolled to the bottom and pressed the link that said “See all 1,490 MP3 song results”. Then I was looking at that same 24 plus another 26 that got me into the Ba’s. I was able to skip forward to page 3. That made it to the beginning of the C’s. From that point on, I could only go forward one page at a time, scrolling all the way to the bottom each time to reach the page navigation. I finally found tracks with the title I was looking for on page 9, but they continued across another two pages.

This experience was all kinds of bad.

Put the navigation at the top of the page. Let me jump ahead multiple pages, or better yet, jump to a particular letter of the alphabet. Let me filter the list so that I can get rid of the results that are obviously not what I was looking for.

In iTunes, the search returned all of the results in a single list. There were only 150 results. I was able to sort the list by song title and easily find all of the tracks that were relevant. Boom!

Comments (View)
Feb 23
Permalink

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.

Comments (View)