Design Pebbles ™

Replies: 3

Tue Nov 8, 2005 Link to this message

Design Pebbles ™—IMail

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

---

Wed Nov 23, 2005 Link to this message

Design Pebbles ™—Perforce

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

Replies: 1

Sat Dec 17, 2005 Link to this message

RE: Design Pebbles ™—Perforce

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

---

Tue Jul 25, 2006 Link to this message

Design Pebbles ™—'Cool New Toolbar'

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