It’s All About Muscle Memory

This year I will properly launch PDQMac.com. I will be selling (and giving away to some degree) training intended to make people more productive on the Mac.

I patched some posting through from HaveMacWillBlog and I’ll be rewriting every one of them both to upgrade them and to deliver them in a style that allows me to quickly turn them into practical tutorials.

If there’s a key underlying point to what this is all about, it is this:

Interface productivity is all about muscle memory.

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.

  1. Guns and Fighter Planes. You may have noticed that an AK47 has no drop-down menus. Does that surprise you? The popularity of the AK47 (I’m no gun expert by the way) is generally that it’s dependable, easy to maintain and the interface is true point and shoot. Although fighter planes are far more complex than guns, the design of fighter planes follows the same principle. You really don’t want the pilot who is caught in a dogfight to be wandering whether the “Shoot Cannons” command is on the Format Menu or the Tools Menu.
  2. Cars. Once Ford got the driving interface buttoned down on the Model T, all cars that came after adopted very similar interfaces, to the point where now, when you change cars, your learning curve is minimal – usually a few minutes. A software writer I know, whom I’ve discussed this topic with at length, tells me that it took a few attempts to get the Model T right, with the first model T using controls that were based on farm machinery. Notice how much more of a learning curve can be involved when a major revision of Windows or MS Office occurs. Sometimes users even have to be retrained.
  3. Games Machines. Luckily we have games machines to prove indisputably that computer interfaces can be very productive. And notice how successful both the iPhone and the Wii have been, partly I suspect because they’ve added interface features that are very effective in terms of muscle memory.

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 fundamental problem is this:

Normally, we begin to discover a new application with the mouse. The simple fact is that most people find it easier to do it that way. I find it easier to do it that way, so the first thing we’re going to have to do is to learn that we need to learn an application in two steps:

  • Step 1: Learn what it can do (in any way you please).
  • Step 2: Learn how to do each activity it offers quickly.

Here’s the point. You’ve finished learning how to use an application when you’ve finished learning ho wto use it quickly.

Posted in Foundations | Leave a comment

QuickSilver Performance Issues On The Mac

If you use QuickSilver on the Mac, as an-application-launcher-and-more, you may discover that you are having performance problems. This seems to have been happening recently and occurs with the current release. Naturally, it all  depends on whether you ever look to see what resources are being used by your apps, but you will probably do that if you suffer from the QuickSilver issue I’m about to describe:

Primary Symptom: The Mac seems to be running slow. You may especially notice that some activities like downloads or moving between Spaces are slowed. Also some browser activities (FireFox or Safari) may cause the “spinning wheel” to appear.

Secondary Symptom: You run the Mac’s Activity Monitor and discover that QuickSilver is running at or above 90% of cpu. Note that no application should be that much of a hog, except in short bursts, but in this case QuickSilver is running at that level all the time.

Application Hoggery – A Note

In application terms, there are only a few resource hogs. Both Aperture and Photoshop can hog resources – but that’s normally because they’re busy doing useful stuff. Back-up utilities (like Time Machine) can hog the network (if they use the network) because they’re sending data to disk. Browsers do hog resources and can chalk up high cpu usage, and so, of course can Skype, especially when you use video. Virtual machines like Parallels chew up resources, but you should expect that. Apart from that the indexing routine that serves the Mac’s Spotlight Search capability is a nasty little resource hog – so much so that I disable it. (I never use SpotLight anyway.)

The QuickSilver Problem Described

When QuickSilver starts to tie up a cpu it is almost certainly because it indexing frantically and that’s causing it to “thrash”. Under normal running QuickSilver only uses a few percent of cpu. Here are four possible remedies, depending on the cause:

  1. Cause: QuickSilver’s indexing files have got their “panties in a bunch” in some way. Quicksilver has become confused.
    Action: Quit Quicksilver. Go to ~/Library/Caches/Quicksilver/Indexes and move all the files out of there. (QuickSilver will recreate them.) Restart QuickSilver. If this doesn’t solve the problem try 2. below.
  2. Cause: QuickSilver is frantically trying to manage its ClipBoard History. If you have set the number of clipboard items to remember above 25 items, this may be the cause – although it would need to be a high number to cause thrashing. Also check to see if you have the Shelf module as this can contribute to the problem.
    Action:
    Set ClipBoard History to 25 items. Switch Shelf module off. Quit Quicksilver and then relaunch. If this doesn’t solve the problem try 3. below.
  3. Cause: QuickSilver is obsessively indexing its Catalog. This is most likely caused by Custom sources that you yourself have added.
    Action:
    Open the Catalog page in QuickSilver, and click on Custom. Go through the Sources you have added, one by one. For eacj click on i at bottom right corner of window and a draw showing source options will slide out. Click Source Options (bottom of the drawer) and it will shwo the depth of search. If you’ve set the search depth to infinity that’s almost certainly the cause of the problem. Set the value to no greater than the depth of the folder you want scanned (probably 3 at the most). Quit Quicksilver and then relaunch. If this doesn’t solve the problem try 3. below.
  4. Cause: QuickSilver is indexing its Catalog insanely, but you never provoked it. This is most likely caused by a recent plug-in you added.
    Action:
    Open the Plugins page in QuickSilver. Start removing plug-ins you’ve added recently. (Best to take a snapshot of the ones you’ve got enabled first). You have to find the culprit, so the best way is probably to remove ones you know you added recently and while you’re at it, you may take the opportunity to remove ones you don’t use (if there are any). Quit Quicksilver and then relaunch. If this doesn’t cure the problem keep removing plugins.
    If you can’t make headway this way, then it may be a combination of a plugin and cause 1. above. In which case the only way out I can think of is to kill QuickSilver completely and reinstall. It performs fine on every installation I’ve done, so it should be clean on reinstall. After that add plug-ins one by one. Sorry but that’s the only way I know that can pin the problem down.

Incidentally QuickSilver is now Open Source and no longer controlled by its initial author. Problems caused by plugins are best directed to the plug-in authors, who will be best positioned to find out if the offending bug is in QuickSilver or the plugin.

Note: This posting also appears on the PDQ Mac web site, which is not officially launched yet. When it is launched, I’ll let you know.

Posted in Mac Productivity, Productivity Apps | Leave a comment