Further Comments on Muscle Memory

Tim Negris posted a comment to my post: Productivity And The “Muscle Memory” Interface It bears repetition. This is what it said…

To dig deeper, it seems that the muscle-memory user interface (MMUI) has a few common attributes appearing in most of its manifestations.

1. Task Path – the order in which things must be done to get the desired result.
   Gun: Ready, Aim, Fire.
   Game: Find Key, Open Door, Kill Dragon.
   Car: Check Mirrors, Signal, Change Lanes.
2. Step State – the extant processes and conditions in effect at any point within a task path.
   Gun: Aiming in Motion.
   Game: Dodging Fireballs.
   Car: Lane Merge.
3. Essential Modality – the necessary conditions that must be in effect at any given step state.
   Gun: Have Ammunition.
   Game: Know Secret Code.
   Car: Headlights On.

Thinking more specifically about muscle-memory user interfaces for computer applications, the venerable status quo is the “Desktop/Document” UI.  It was created by Xerox PARC researchers more than twenty years ago when storage, memory, and throughput were measured in KBs, not MBs, GBs, and even TBs as they are now.

Despite some valiant attempts to rethink the DDUI along the way, e.g. the IBM/Apple Pink and Taligent projects, it became and still is the norm for most Windows and Mac applications.

Menus, icons, and dialog boxes have their rightful place across computing, but that doesn’t explain why the general UI form and function in Microsoft Word and Adobe Photoshop are substantially the same.  The task path for writing a document has little similarity to the one for editing a photograph, and yet both programs have a “File” menu, from which you can “Exit” the program.

In the Desktop/Document model, the function of the application largely follows the form of the UI.  Those who find this OK will likely point out that it reduces the learning curve for any individual application when all applications follow the same design guidelines.

To me this sounds like the Golden Hammer

Be that as it may, it seems that there are many task paths that go un-automated or are poorly automated because they simply cannot be made to conform to the DDUI model.

They tend to be *practical* (as opposed to cerebral or computational) task paths, e.g. music education, auto repair, land survey, or (shameless plug) photo editing.

And then, finally, as the computer itself morphs into a smart phone, where the screen small and typing and pointing functionality are limited, UI interaction is in itself a practical matter and the DDUI model is further taxed, and in a more essential way.

I hope you and readers will continue to explore this topic in the future, as I feel that there is a growth industry to be had in rethinking the UI.

There’s too much here not to comment on, but I’ll focus specifically on the lack of organized task paths and the lack of task orientation in the DDUI. It is very badly broken. When we work at the computer there is always a task of some kind that we’re carrying out. Now you can build workflows. On the Mac for example, you could use Applescript (with Automator) to assemble task paths. But there is no attempt by most software to assist you in this and it isn’t easy to do. So task-based environments are rare and task flows are not built in to applications. The interface is simply not organized in a task oriented way.

There is also a gesture problem. Tim and I like the word “gesture” because it seems like an appropriate word to describe a “physical act”, whether it be a mouse movement or click or keyboard key or combination or a touch in a touch interface (such as the iPhone or Microsoft Surface). A physical act is a letter of the “muscle memory” alphabet. The computer interface (whether it be Windows or the Mac) would be more productive if there were a consistency of gesture. This is particularly noticeable with keyboard shortcuts. For example, on the Mac, some combinations (e.g. Command-Q for Quit) always do the same thing in every application, but others vary widely in their use. The problem is that the part of the brain that implements muscle memory doesn’t do choice.

Taking a choice slows the whole interface down. This is what poisoned drag and drop on Windows. It didn’t always work. There was no consistency. (This may be fixed now, by the way, but I gave up on Windows 3 years ago – before Vista.) With the Mac, “drag and drop” is consistent, it is nearly always an option and it works the way you expect it to.

Tim, by the way, has built a Windows App called PixQuik which implements a task based interface. It is in early beta at the moment, but if you’re really interested in this topic and you’ve got Windows, you may like to download it and play (if so click here). It provides a very simple workflow for doing a handful of photograph manipulations in a way that Photoshop could have and should have done a long time ago, but didn’t.