March 2007

Readers of UsabilityBlog have probably gotten the impression that I’m a whiny b*tch. I do tend to slag on designs that aren’t immediately learnable.

OK, I’ll own that. I am a bit of a whiner. But it really does cheese me off when products make implicit claims of learnability and usability, but in fact possess neither attribute.

So it’s with all this in mind that I’d like to talk about the incredibly high usability and utility of the GUI’s ancestor, the command line interface (CLI).

CLI: Not “Walk-Up-And-Use”
Let’s be clear about one thing: in most circumstances, a CLI is NOT a “walk up to and use” interface like the touch-screen kiosks at the airport check-in counter. Using a CLI requires that the user possess *some* understanding of both the syntax and command set, AND the general concept of interacting with a computer via a command line interpreter or shell.

But once a person takes the time to learn a particular CLI, they possess the ability to perform tasks and accomplish their goals in an incredibly efficient manner. It’s the old tradeoff, learnability vs. efficiency. It’s not exactly a zero-sum game, but these two attributes are often in opposition.

Let me give you a real-world, personal example of how learning just a little bit about a command line interface provided me with an incredibly powerful, comprehensive, customized, and trustworthy method of regularly backing up my and my wife’s data.

The CLI and I
First, a little bit about my situation and goals: ever since grad school I have been obsessive about backing up my data. I make (somewhat) up-to-date redundant backups of my and Susan’s data files to two large external drives. And yes, I even maintain an offsite backup, although the drudge of carrying that drive from work to home and back again means that the offsite backup is hardly ever as up-to-date as the onsite backups.

Lately, with the pace of work picking up for both Susan and I, I’ve been feeling the need to keep the backup stores as up-to-date as possible. And I had grown tired of running the backups manually.

Finally, since Susan and I have both become avid podcast consumers, I have noticed that the backup drives are filling up with unwanted podcasts. So my goals are:

• Back up my and Susan’s critical data safely and redundantly.
• Automate the execution of backups.
• Conserve space on the backup drives by deleting files that we don’t need anymore (i.e., old podcasts).

Now I’m sure that I could buy a software product that would make periodic, maybe even continuous incremental backups. And I bet that a premium product might even let me specify which data can be discarded. In fact, many external drive manufacturers provide “lite” or even full versions of backup software with their drives. But I build my own external drives from empty enclosures and drives I purchase from eBay or Newegg. So that’s not an option for me.

I first started using computers back in the dark days of DOS 6x, so I know a little bit about Microsoft’s CLIs. Not much, mind you, but just enough to accomplish some rudimentary tasks.

So about four years ago, I started opening up a command line window in Windows 2000 (and later, XP) and entering DOS commands to copy all the data in the directories holding my data (as well as all subdirectories underneath) to another directory. (I always split my laptops’ drives into an OS partition and a data partition, so in essence my D: drive is the first line of defense. It keeps a backup of the contents of my user folder.)

The command I used was xcopy.

Using various options provided by xcopy, I could specify that I only wanted to copy files that had changed, and suppress confirmation prompts (“Are you sure you want to overwrite foo.bar”) as well. Pretty powerful.

I soon grew tired of entering the backup commands manually (yes, I kept the syntax on a post-it on my monitor…), so I put the xcopy commands into a batch file, and then executed the batch file whenever I remembered.

Obviously, I’m much less reliable than a computer, so about two years ago I decided to schedule the execution of the batch file using the scheduler feature of Windows XP. If you want to find it, go to Start / All Programs / Accessories / System Tools / Scheduled Tasks.

So about two years ago, my batch file looked like this:

Filename: Backup.bat

REM Copies Susan’s Favorites to the D:\ drive.
xcopy C:\DOCUME~1\Susan\Favorites\*.* D:\Susan\My_Docs\Favorites /s /d /e /i /r /y

REM Copies Susan’s desktop files to the D:\ drive.
xcopy C:\DOCUME~1\Susan\Desktop\*.* D:\Susan\Desktop /s /d /e /i /r /y

REM Copies Susan’s My Documents, Outlook data file, and desktop files from the D/: drive to the USB drive backup folder.
xcopy D:\Susan\Desktop\*.* U:\Susan\Desktop /s /d /e /i /r /y
xcopy D:\Susan\My_Docs\*.* U:\Susan\My_Docs /s /d /e /i /r /y
xcopy D:\Outlook\*.* U:\Susan\Outlook /s /d /e /i /r /y

You probably noticed that I used the 8.3 name for the “Documents and Settings” folder. A bit of trial and error taught me that xcopy will indeed preserve long folder and file names at the destination, but doesn’t always recognize long names in the xcopy command itself. So I used the 8.3 name for “Documents and Settings,” which is (usually) “DOCUME~1″.

Podcasts Improve – And Complicate – Our Lives
This little batch file served me well until last summer, when we both started downloading podcasts. This lifestyle change was definitely for the better; as we no longer had to listen to any of the incredibly annoying local radio stations. But it had one unintended effect: every time the backup batch script ran, it would back up all the podcast files that happened to be sitting in “My_Docs\My Music\iTunes\iTunes Music\Podcasts.”

Even though Susan and I erase listened-to podcasts on the source drive, they started piling up on the backup drives. I needed a way to regularly clear out the contents of the podcast folder on the backup drives so the backup devices didn’t become overrun with stale copies of “This American Life” and the Battlestar Galactica podcasts.

So I went prospecting in the Microsoft KB, and found that the RMDIR (“remove directory” or RD) command has some very useful options. For example, “RD D:\Foo\Bar /q /” will delete the folder “Bar” and all its contents, without asking me for confirmation.

I added some RD goodness to my batch file, and this is what I ended up with:

Filename: Backup.bat

REM Copies Susan’s Favorites to the D:\ drive.
xcopy C:\DOCUME~1\Susan\Favorites\*.* D:\Susan\My_Docs\Favorites /s /d /e /i /r /y

REM Copies Susan’s desktop files to the D:\ drive.
xcopy C:\DOCUME~1\Susan\Desktop\*.* D:\Susan\Desktop /s /d /e /i /r /y

REM Deletes the old podcasts from the backup drives before kicking off the current backup.
RD U:\Susan\My_Docs\MYMUSI~1\iTunes\ITUNES~1\Podcasts /q /s
RD S:\Susan\My_Docs\MYMUSI~1\iTunes\ITUNES~1\Podcasts /q /s
RD O:\Susan\My_Docs\MYMUSI~1\iTunes\ITUNES~1\Podcasts /q /s

REM Copies Susan’s My Documents, Outlook data file, and desktop files from the D/: drive to the USB backup drive.
xcopy D:\Susan\Desktop\*.* U:\Susan\Desktop /s /d /e /i /r /y
xcopy D:\Susan\My_Docs\*.* U:\Susan\My_Docs /s /d /e /i /r /y
xcopy D:\Outlook\*.* U:\Susan\Outlook /s /d /e /i /r /y

REM Copies the same data as above to the secondary backup drive.
xcopy D:\Desktop\*.* S:\Susan\Desktop /s /d /e /i /r /y
xcopy D:\Susan\My_Docs\*.* S:\Susan\My_Docs /s /d /e /i /r /y
xcopy D:\Outlook\*.* S:\Susan\Outlook /s /d /e /i /r /y

REM Copies the same data as above to the offsite backup drive (when I remember to bring it home that is).
xcopy D:\Desktop\*.* O:\Susan\Desktop /s /d /e /i /r /y
xcopy D:\Susan\My_Docs\*.* O:\Susan\My_Docs /s /d /e /i /r /y
xcopy D:\Outlook\*.* O:\Susan\Outlook /s /d /e /i /r /y

So there you have it. It’s not rocket science, but it works pretty well for me. It’s usable – provided you have some working knowledge of CLI’s. And I didn’t have to buy a separate application.

What did we learn today kids? First, the command line is your friend. Second, it can save you money.

{ 0 comments }