Archives
- April 2010
- March 2010
- February 2010
- January 2010
- December 2009
- November 2009
- October 2009
- September 2009
- August 2009
- July 2009
- June 2009
- May 2009
- April 2009
- March 2009
- February 2009
- January 2009
- December 2008
- November 2008
- October 2008
- September 2008
- August 2008
- July 2008
- June 2008
- May 2008
- April 2008
- March 2008
- February 2008
- January 2008
- December 2007
- November 2007
- October 2007
- September 2007
- August 2007
- July 2007
- June 2007
- May 2007
- April 2007
- March 2007
- February 2007
- January 2007
- December 2006
- November 2006
- October 2006
- September 2006
- August 2006
- July 2006
- June 2006
- May 2006
- April 2006
- March 2006
- January 2006
- December 2005
- November 2005
- September 2005
- August 2005
- July 2005
- June 2005
- May 2005
- April 2005
- March 2005
- January 2005
- December 2004
- October 2004
- September 2004
- January 2004
- December 2003
- October 2003
- June 2003
- January 2003
- December 2002
- June 2002
- January 2002
- January 2001
- May 2000
- April 2000
Categories
Meta
-
This reminds me of how much I would love to love Blacktree’s Quicksilver. More importantly, this explains why I have yet to fully integrate it into my workflow.
-
Thanks for shedding light on this important topic.
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 (http://en.wikipedia.org/wiki/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.
Trackbacks and Pingbacks
-
[...] January 2, 2009 by theanthrogeek Robin Bloor’s latest posting on “Productivity & Muscle Memory” reminds me of how much I would love to love Quicksilver. More importantly, it explains why I have yet to fully integrate it into my workflow. Productivity And The “Muscle Memory” Interface | HaveMacWillBlog (aka Robin Bloor’s Blog). [...]
-
[...] Productivity And The “Muscle Memory” Interface | HaveMacWillBlog … Share and Enjoy: [...]
-
[...] you have a well developed muscle memory, you will be able to perform under wide varieties of conditions that might otherwise hold you back, [...]
Productivity And The "Muscle Memory" Interface
This year I will finally be able to put some effort into PDQMac.com, the site I’ve set up with the aim of improving people’s interface productivity. If there’s a key underlying point to what I’ll be doing with that site, it is this:
Productivity is all about muscle memory.
So I’d better explain what that means before I go any further. Let’s start with the fact that nearly all of us have learned how to drive a car and have a memory of that learning process. There are quite a few physical things that have to be learned in order to drive a car that you simply did not know before you started to drive; including managing the accelerator, brake, steering, winkers, and stick-shift (if you learned on a stick-shift car.) You were, no doubt, told how all of these controls worked, but you couldn’t drive properly just because you knew how to with your thinking brain. You had to keep practicing until your body learned how to use these controls. And nowadays, years after, you never think about most of the controls or how you use them because they are perfectly stored in your “muscle memory.”
Muscle memory is the automation of behavior and most of what we do, including for example, how we pronounce words, involves muscle memory. As regards computer interfaces, the simple truth is that the PC interface has not been designed with muscle memory in mind. In fact, at times it seems to be designed almost to defeat muscle memory. So let’s forget that abysmal interface for the moment and talk about interfaces that are built with muscle memory in mind.
This gets me to the point where I think I can define what a “muscle memory interface” is:
It is one that is built so that controlling the device or environment can be done with minimal need to engage the thinking part of the brain.
The very fact of the keyboard and mouse, and the need to switch between them makes it very difficult to establish muscle memory in some usage contexts and in other contexts, the tendency is for the user to remember really slow ways to do things. Yes, actions get committed to muscle-memory, but the outcome is not productive.
The software writer I mentioned above (Tim Negris) has written an application for manipulating photos. It runs on Windows and every effort has been made to design it with muscle memory in mind. Over the next few days I will be using it and I’ll give it a full review when Ive used it enough to comment on its interface.