design: /di·'zin/

Sections: 4

IMail (legacy version)

Tue Nov 8, 2005 Link to this entry

 — Thomas M. Tuerke

My web hosting company provides online email via the IMail web front end by Ipswitch, Inc. This is convenient when I just want to check on some email, no matter where I am. I use it in preference to a heavier mail client like Outlook or Eudora: I don't need to install anything, and no matter where I am, the interface is the same.

Unfortunately, the latest version seems to make life a lot more difficult—all in the name of security. They've polished the interface, but put timeouts everywhere. If you haven't done anything for about five minutes, it promptly logs you off. Now, for most pages, this makes sense .. just not when you're composing messages. There, five minutes is just not enough time to finish anything but the simplest note. If you take too long before hitting Send, the server will have forgotten about you, and that nice letter you were crafting just disappears. And don't think about hitting the Back button to get back to the draft. They've expired the Compose page, too, so it's gone!

This Design Pebble means users have to do one of three things.

1. Not use the webmail interface—a pity, considering the effort that went into making it look so much nicer, or
2. Composing a message in Notepad or some other editor, then logging back in to send the reply, or
3. (and this is the real Rube Goldberg solution) Opening three windows: one is the main view of your messages, which refreshes automatically every five minutes, keeping the connection alive; the next is the letter you're replying to; and the third is your draft reply.

All because the developers decided to make the Compose page time out after five minutes—where it doesn't make sense—just to be consistent with the rest of the site—where usually it does.

---

Perforce Revision Control System

Wed Nov 23, 2005 Link to this entry

 — Thomas M. Tuerke

The context menu at right appears in the Perforce P4Win product when the user right clicks over a folder in the Perforce depot.

The Design Pebble is that the indicated action, Add to Source Control... is ambiguous at best, contradictory at worst. How so?

The context menu is supposed to be contextual, which is to say, it is supposed to apply to the thing selected. In linguistic terms, the thing is the direct object of a command phrase, and is implicit in the text that appears for each menu item, as in "Sync (this thing) > to Head Revision" or "Open (this thing) for Edit". The problem is, it doesn't hold true for "Add (this thing) to Source Control..." because this thing already is added to source control.

Really, the command is completely noncontextual, since nothing it does has anything to do with the folder selected. Any files you add to source control are added in folders determined by their location on disk. In this regard, the command shouldn't even be on the context menu: a toolbar button, or an item on the main menu seems better suited to a command of this nature.

Sections: 1

Perforce—followup

Sat Dec 17, 2005 Link to this entry

 — Thomas M. Tuerke

In fairness, it turns out that the context menu is contextual, in a round-about sort of way.

The contextuality comes into play when you consider that the file dialog that follows opens to the on-disk directory corresponding to the folder shown. So in effect, the menu should say Add to Depot here..., where here instead of this is the direct object of the command.

But that's not immediately obvious.

---

'Cool New Toolbar'

Tue Jul 25, 2006 Link to this entry

 — Thomas M. Tuerke

There's a product (the name of which I won't disclose for specific reasons ;-) that has a "cool new UI". On the whole, the cosmetic quality of the UI is quite good. It's attractive to look at, and seems easy to use; it's approachable and relatively predictable.

One of the quirky novelties, though, is that there's an entirely new windowing system for this product's dockable toolbars. This design decision is somewhat understandable: most of the toolbars make more sense being vertically oriented, docked as they likely are to the left or right side of the application's main window. The upshot of this is that the toolbar "caption"—that bar typically at the top—is now found along the side of the thing.

(By the way, my first impression was one of disorientation, seeing the application load for the first time, and seeing "hollow" toolbars load looked like they're rotated 90%)

Despite its new location, it serves its purpose reasonably well on the side. The toolbar title appears there (rotated so it reads sideways) as do assorted buttons to control certain toolbar behaviors. If you drag it, it moves the entire toolbar. All pretty much as you would expect.

That said, it seems like this same windowing system is employed by various dialogs too—larger and more complex than a simple toolbar—and I sometimes find myself wanting to move the dialog aside to see what it's obscuring.

Now for me, moving a window is an act nigh on unconsciously done. Just drag that bar at the top of the window—where it's been since the dawn of GUI—and ... oh, that's right: it's not at the top, it's down the side, remember? Mental Speedbump: move the pointer to the side and continue what you were doing.

Yes, I know. There's no law that says the caption must be at the top. It could be down the side, or along the bottom, or any old place. No argument. And yes, I can (and probably will) just get used to it being where it is. But I wonder why I have to? What problem is it solving for me by being on the side? Yes, it's nice that there's enough real estate to see the whole title—which, by the way, is presented in a particularly large and heavy (bold) font—but that's about it. Other than its cosmetic "coolness" (an affectation I'm not really warming up to,) there doesn't seem to be much else.

Here's another oddity. You'll notice that I've said that the caption is along the side of the toolbar, but I've avoided saying which side. That's because it can be on either side. It seems to favor the left, but is sometimes on the right. Imagine: you drag your toolbar using the left-sided caption to the right edge of the window. Just as it gets close enough to dock with the right edge, the caption flips to the right, leaving your pointer precariously hovering over "live" toolbar. You haven't taken your finger off the mouse button—you're still dragging—but the visual feedback leaves you uncertain. Have you docked? No. Continuing to move the mouse continues to move the toolbar, (albeit by its tail and not by the scruff of the neck... ;) But be careful: if you lift your finger (even accidentally, so get rid of that hair-trigger mouse) the drag is complete and you have to move the pointer to the other side of the dialog to move the toolbar again.

More dangerously, the swap having resulted with a tool button possibly being positioned under your pointer, if the pressure on the mouse button wavers enough, you could end up finishing the drag and immediately clicking that button without meaning to. Ooops! Alt+Backspace to the rescue!

My point in this is that it's good—indeed it's vitally important—to innovate and do new things... as long as it's for the better. It has to improve the state of the art in some material way. If it's just a troublesome bit of gimmickery, I personally would be just as happy sticking with the banal caption at the top of the toolbar.

---

Camcorder Record Buttons

Sun Mar 1, 2009 Link to this entry

 — Thomas M. Tuerke

You've probably done it dozens of times if you've done it at all. You know, accidentally started recording video when you didn't mean to. If you're lucky, you only ended up with a five-minute sequence of the inside of your camera bag, or upside-down landscape bobbing and bouncing as you saunter along unaware that the camera is merrily recording every moment.

If the video gremlins have been up to their usual mischief, it probably used up the rest of your tape and/or batteries. But if they've been particularly unkind, you find that unfortunate sequence instead of what you really wanted. You remember that feeling as you play it back for the first time: your heart crawls up your throat as you see the camera being brought unsteadily to bear on your subject, and them bam! ... it ends at exactly the moment you wanted to record.

Now, granted, most video cameras ding or play some audio sequence to let you know you're about to start recording. Except that in a noisy crowd—say, at an amusement park, or in a noisy gathering—you just can't hear it.

And there may be an icon that appears in one corner or another to let you know you're recording. Except that your attention may be on keeping the subject in-frame, and you may not notice the absence of such an icon way off in the periphery.

So the problem persists.

Well, the problem exists because the same gesture is used to start recording as to stop it, namely, pressing that small red button. And by accidentally pressing it, the camera changes state on you, so the next time you press the button with intent, the outcome is not what you intended.

You thought you were starting to record, when in fact you were stopping.

Now in a critical environment where the stakes are higher, such an interaction—namely having the same gesture do an action and its opposite —would simply not be allowed to exist. Could you imagine, for example, pressing the same button in the same way to put your car into drive and reverse gears?

Ooops! I thought I was backing out of the garage, but...

Or, by the same token, the same pedal applying both gas and the brake? Imagine how many more accidents there would be. Fortunately, the auto industry has learned that a single control that toggles opposites in such a high-risk environment is plain old bad design, so it isn't done.

But video cameras continue to do so to this day. I'm guessing this is out of habit: the first camcorder of yore—or maybe the first popularly successful one—had a single button, and all the rest have followed suit in a me-too sort of way. The camera manufacturers aren't sweating bullets over this: you go through more tapes (good for them) and you're more likely to buy that backup battery (also good for them.)

And even now, I can imagine designers of such devices playing blame-the-user: "Look, we make it ding, and we show the icon. You just need to pay attention to these clues to avoid this condition." That's true, we could do all these things.

But we don't exist to serve the camera. We're busy doing other things, and the camera exists to serve us, so it should be accomodating our needs ... and our shortcomings, (namely of attention, and time at that crucial moment we're hoping to capture.)

So, what's the alternative? I'm thinking a simple rocker switch—such as the zoom control uses—would do the trick. Flicking it up starts recording, and flicking it down stops recording. No more missed video turning the recorder off when you wanted to turn it on.

Two distinct gestures for two opposite actions.