Conversational Mail

E-mail exchanges would be easier to follow if mail clients displayed messages more like chat conversations.

This would be particularly useful in exchanges in which there are more than two participants: users would no longer have to try to form a mental mapping between a color and a conversation participant. Color could be used as a secondary participant identifier.

The writer’s name could be displayed beneath their picture or just the name could be displayed to save space.

Dealing with Ejection

I’d like an easier, more obvious way to unmount disks and drives from the desktop. A post by Don Norman inspired me to look at the problem.

The Utilities folder icon is from Derek Gordon’s “Organize X” set. The hard drive icon is from Carlos Reyes’ “Carlito Drives” set. Beware InterfaceLIFT’s very annoying pop-up. I tried in vain to find the sites of the artists.

Implementation Notes

  1. The frame and button would appear 1 second or so after the cursor hovers over the icon. This would prevent visual distraction when rapidly moving the cursor across the desktop icons.
  2. The frame and button would very rapidly fade 1 second or so after the cursor moves outside the frame.
  3. The frame and button would disappear as soon as the user began dragging the icon.

Considerations

Pros

  1. More obvious than dragging the icon to the Dock’s Eject button. From observations of family members, that ejection method can be rather confusing.
  2. Requires less mouse dexterity. The drag-and-drop process isn’t easy for everyone.
  3. Doesn’t require the elimination of existing methods, no matter how ill-conceived.

Cons

  1. The close proximity of the Eject button to the icon would significantly increase the chances of accidental ejection.
  2. Would not work with multiple disks/drives.

Wisdom from Alan Cooper, circa 1998

A product that doesn’t have desirability designed into it might address a robust market need, but any success it enjoys will be the success of the dancing bear. The single greatest weakness of dancing bearware is that it never generates customer loyalty. Without the long-term brand loyalty of satisfied customers, your entire company is highly vulnerable to competition.

Alan Cooper‘s “The Inmates are Running the Asylum“, page 74.

This makes me think of Microsoft. Does anyone desire their products? How many customers will abandon them once a product that can meet their needs and fulfill their desires is available?

Two passages made me think of the portable audio player market:

After a vendor has claimed a market by being the first to offer needed functionality, there is little advantage to hurrying to market with something equivalent. You have already lost the time-to-market race, so no amount of raw speed can ever gain that position for you. However, it is quite possible to take leadership from the market pioneer with better design. Design makes your product desirable and that will make your customers actively seek out your product instead of the competitor’s, regardless of who got there first.

Cooper, “Inmates”, page 77.

Apple wasn’t the first to market a portable audio player, but the iPod was the first one worth a damn.

Being first to add extra features, however, is not the same thing [as good design]. Features do not benefit users the way that primary problem-solving abilities do and adding features won’t have the same beneficial effect that primary problem-solving abilities will. In a marketplace of equally poorly designed products, added features will not influence a broad segment of the market.

Cooper, “Inmates”, page 78.

But our player can record! Receive radio! Play 101 encoding formats! Trim your nasal hair! Most people don’t care. They want to listen to their music!

Try this sequence:

  1. While any given application is frontmost with at least one window open, activate the Application Windows Exposé mode (F10 by default).
  2. Click on the Dock icon of another open application.
  3. Notice that you exit Exposé but remain in the first application.

It would make more sense for the Dock to act similarly to how the Command-Tab switcher works in conjunction with Exposé, tiling the open windows of single applications as they are selected in the Dock until a window is chosen. Individual application windows could also be tiled if the user triggered All Windows mode and then clicked on an application in the Dock. Clicking on an application that wasn’t already open would launch it in the foreground and exit Exposé.

These features would be unavailable to users who hide their Dock unless Apple changed how hiding works while Exposé is active.

A Dim View of Menus

If all of a menu’s commands are unavailable (dimmed) at the same time, dim the menu title. Users should still be able to open a dimmed menu to see its contents.

Aqua Human Interface Guidelines: The Menu Bar and Its Menus

If all of a submenu’s commands are unavailable (dimmed) at the same time, dim the submenu title.

Aqua HIG: Hierarchical Menus (Submenus)

For most applications, if no windows are open or on screen, only the application menu, File (or equivalent), and Help should be available and displayed as standard fully saturated black text. Assuming none of their contained commands are usable in this context, the Edit, View, and Window (unless there are minimized windows) menu titles should be dimmed.

Why don’t most OS X developers implement menu title dimming? Apple’s own adherence to these guidelines is less than stellar (see iCal, iPhoto [both of which have the View menu in the wrong place], iChat, Mail, Preview, and Address Book for proof), so I’m not surprised that third-parties have not stuck to it. If there is some technical reason that it is difficult to do, it is understandable that developers would invest their resources in more obvious and/or important issues.

iTunes is one of the only applications I know of that implements top-level menu title dimming (it has no submenus to dim), which I think is unfortunate given the potential benefit to users — quickly focusing their attention on the commands that are available in the current application state.

Multi-modal input

I think the future of human-computer interaction lies more in the multi-modal realm than the keyboard-centric approach used in Jef Raskin’s Humane Interface project and advocated in his recent Desktop Linux Summit keynote.

The keyboard is very efficient for some tasks (text input and editing being the best examples), but it doesn’t allow people to take advantage of all of their senses and communicative capabilities, ignoring spoken and gestural input altogether.

We are not going to be using interfaces like those depicted in The Minority Report (your arms would fall off after a day at the office), or pedantically telling our computers:

Copy this to the clipboard.

Create a new e-mail message.

Paste the clipboard here.

Send this message.

More likely, we’ll use a combination of currently common input mechanisms (mouse and keyboard) along with gestures made using the fingers and some spoken commands that are contextually understood by our computers.

The computer could understand what you mean when you say:

Mail this to Joe.

The computer knows what content you are looking at, and knows who Joe is, so it can act on the command. You wouldn’t have to baby step through a command sequence.

Rather than Bernstein-on-crack arm flapping, a trackpad-like surface that could interpret finger movements as gestural input is one possibility. The fingers are capable of repeatedly making very precise motions without tiring – think of how complicated and precise writing can be. Your hand may tire after a while, but finger gestures would be only one input method.

I’ve also thought a bit about completely non-graphical interfaces. What information can be as easily or more easily communicated audibly? Do I really need to see movie time listings? Weather information? Dictionary definitions? Think of how many simple questions you “ask” your computer throughout the day – who won the game tonight? When does that movie open? How much is that new book? The problem is that to get the information they want, users must currently think “data retrieval” rather than conversationally or simple Q&A. You’ve already formed the question in your mind, so why should you have to reformat it to fit the interface?

I recognize that the input method is only one small part of Raskin’s vision for THE. I plan to write a bit about the other aspects in the future.

Drag and Drop to the Dock

My idea of triggering the single application Expose view by hovering a dragged item over the Dock works great (theoretically!) if an application already has a window or document (or two) open. What if you attempted to drag and drop an object onto an application that had no open windows? What about applications which are not open at all? The obvious solution is to create a new document containing the dragged object, assuming the application can indeed handle it, regardless of activation state.

  • For pictures dragged to an image viewer, a copy of the image would be opened in a new window. For iPhoto, this would add it to the library.
  • Text snippets would create new documents in text editors.
  • Any type would open a new mail message containing the dragged object in e-mail apps. For links to movies and images, the link itself would be placed in the body of the message, not the movie or image.
  • Spring objects could create a new canvas to be used as a holding spot.
  • Web links would open a new browser window or tab depending on existing user preference.
  • FTP links would open a new connection. AFP links dropped on the Finder would do likewise.
  • Files dropped on chat clients are tricky. Prompting for a buddy to send the file to seems like the only real choice if no conversations are in progress.

This would really work best in concert with my spring-loaded Dock combined with Expose idea. This portion handles situations in which no document or window is open, eliminating the need to choose one such item as a destination. The single app Expose would handle situations in which an application already presents one or more valid destinations for a dragged object.

For single-window applications whose sole window has been minimized, it would obviously be necessary for it to unminimize to provide an object destination.

Some problems to further ponder:

  • It is probably necessary for the cursor itself to actually hit the Dock icon to initiate the drop. It may even be necessary for the dragged object(s) to stop just outside of the Dock so that the cursor is clearly visible for selecting an application.
  • Would Dock icon-drop created documents come to the foreground or not?
  • Where would items dropped on the Finder’s icon go? The Desktop folder or the frontmost Finder window?

I’m sure there are many other potential problems that I cannot currently imagine.