Just noticed this:

Painless disk cloning - Just a quick plug for SuperDuper which may end up joining DiskWarrior as my must-have Mac utility. It does exactly two things very well: a) it creates bootable DMG clones of Mac disks and b) it lets you very easily update the disk images using boilerplate or customized scripts. Part 1 has historically been the domain of Carbon Copy Cloner — a great little app. One thing SuperDuper adds is a simple interface for scripting the items/folders you do and don’t want to clone as well as how you want them to behave (new vs. changed, etc.). This basically means you now have a perfect copy of your drive that can be restored very easily in case of calamity. Ditto for doing a “safety clone” before you install a bunch of dicey system upgrades. Highly recommended utility.

via 43 Folders: Thanks, Merlin! (and don’t miss Merlin’s classic 5ives, either!)

Hey, so it’s been a while since I’ve written specifically about SuperDuper! v2.0. And it’s not because I’ve got nothing to say.

So, let’s do a bit of a status update, and another sneak peek.

Where We Are Now

As you might expect, we get asked when SuperDuper! v2.0 is going to ship all the time.

I know you want the new version: I want to give it to you! But, it’s not ready. We’re close, but we’re not done: there’s one significant thing left to do, and it’s a bit more difficult than we anticipated. We want to get it right—as we always do—so, it’s taking a little time.

But, once that’s complete, we’ve got a bit of polishing left, and we’re done. I don’t know how long it’s going to take. We’re going as fast as we can.

So, How’s it Look?

Actually, it’s looking great. Every part of SuperDuper! v2.0 has been improved, from the main window to Options, from the log to status… the copying is better… really, it’s all good.

You Mean, You’ll Never Have to Update it Ever Again?

Yeah. Right.

Well, C’mon—How About Some Screen Shots?

Coming right up!

In the new version we’ve broken out the v1.x options into two sets: General and Advanced. This emphasizes the common options—such as the During copy method—while putting more advanced ones—like custom shell scripts, package install and post-copy imaging—into its own tab.

You can also see that we’ve taken our What’s going to happen? approach a bit further, and explain the During copy option you’ve selected right under it (as well as in the main text).

You might also notice the pop-up in On successful completion. In there, we’ve got many more options for what happens after the copy completes, including the ability to shut down the computer, put it to sleep, simply set the destination as the startup volume, etc.

And then, in the Advanced tab, much geekier things that most users don’t need.

We’ve added an additional Before copy option to run a script—this allows people to do cool things like dump MySQL databases before backing up and do other “before you touch things” operations, and renamed things a bit to make their purpose clearer.

So, we ended up with:

So—there you go… and yes, everything we’ve posted about so far works, and works well.

Back to the grind!

The Pavlov’s Beep post got me thinking a bit about how user expectations can set a product up for failure out of the gate… and that made me think of the late, lamented (by some), lambasted (by many) Newton.

Ignoring the obvious hype surrounding the rollout—something the product could never live up to—one of the things that was coolest about the Newton was also the thing that caused the most frustration: handwriting recognition.

Handwriting and speech recognition are two areas that have seen a lot of advancement in the past years—for example, the recognizer that comes with Windows XP Tablet PC Edition 2005 Elite Pro Extreme (or whatever that product is called) is exceptional, and from all reports is improving in its next iteration. And, according to those who use these things routinely, like David Pogue, the latest Naturally Speaking (ex-Dragon, now ScanSoft) is similarly surprisingly accurate.

All that said, though, they’re doomed to teeny market segments, because no matter how accurate, when they make mistakes they frustrate their users.

Why? Because we’ve asked the computer to play by our rules, rather than asking us to play by its.

When a device imposes an unnatural input method on its user, any mistakes you make are your own. Consider Graffiti, as used on Palm OS: it specifically requires you to make certain “letter shapes” if you want them to be recognized. It doesn’t try to recognize your handwriting. If a letter comes out wrong, you might be frustrated, but you know it’s “your fault”—you didn’t make the shape right.

But, with the Newton, it was supposed to recognize your handwriting. Not an alphabet of its own design. And, when it doesn’t, the first thing that runs through your head is: this thing sucks! Even if it got 90% right, which is pretty remarkable considering many people can’t read their own handwriting!

Speech is hard, too—especially if used in an “unrestricted vocabulary” scenario. Not only do you have to “speak” all punctuation (try it sometime), but correction is an incredible pain. And speech is such a natural part of most people’s daily interaction that it’s near impossible to rise to an acceptable level of performance.

Newton, near the end of its life, tried to get around this problem by taking a bit of a Graffiti approach: it encouraged people to print, and there’s a lot less letter variation in printed characters. Suddenly, with the new Rosetta printed character recognizer (still in use in Mac OSX today), people started saying the Newton did a good job recognizing handwriting when—in actuality—it just shifted the burden onto the user some more by restricting input.

Similarly, speech is becoming more common in situation where the vocabulary is highly restricted and expectations are low: package tracking #s; pick 1-2-3 menus; interacting with “speed trade” stock systems. Correction is pretty easy and, given the relatively robotic nature of the interaction, expectations are low. (You’ll note that as the systems got better, they started using more animated, natural voices at the other end—raising expectations they knew, from testing, they could meet.)

So—if you’re designing a UI, remember that the way you “frame” the interaction often sets user expectations.

Leaving aside speech and handwriting, free form input can be really, really cool—see Simson Garfinkle’s SBook and Microsoft Outlook’s date/address fields for examples.

But if you put up a free-form field , you better make damn sure that it accepts all sorts of wacky variations. If date-based, expect things like “tomorrow”, “next wednesday”, etc—every one you miss, given the free-form nature of the field presented, is the fault of the program, from the user’s perspective. Similarly, what about international addresses? And how do you tell the user you’ve made the inevitable mistake?

A lot of words to say something obvious, I know. But it’s a mistake I make all the time… e.g. “Safety Clone”…

Once again, I’m really happy to announce that a Shirt Pocket product has gone all gemilicious!

netTunes was just reviewed by Dan Frakes of Macworld Magazine, in the Mac Gems section.

netTunes 2.2 was awarded 4 mice—and also mentioned, in another recent MacGems column, as “the best solution, by far”!

Not too bad for my first Macintosh product… not too bad! 

Thanks, Dan!

We’re asked, every so often, why we don’t offer a time-limited full version of SuperDuper!.

It’s pretty simple, really.

If you’re going to time-limit a program, you have three choices:

• “Cookie" the user’s system in some hidden way so you know when the program was first run, and can therefore calculate when you’re supposed to expire.
• Automatically identify the system and phone home, asking some server when the copy should expire, and not allowing execution without internet access
• Force the user to provide personal information, including an email address, so that you can give them a key that expires (and the key, which need not be hidden, can contain the “cookie")

The first, in my opinion, is right out. I hate it when programs hide things on my system, and while I understand why they do it (see above), it’s just the wrong thing to do, especially for a backup program. A backup program that writes hidden stuff to the source volume? I don’t think so.

The second is nasty for obvious reasons.

The third, while doable, forces users to announce themselves to me when they just want to evaluate the software. We’re very conscious of privacy here, and a lot of people are understandably touchy about this kind of thing. The last thing we wanted to do was to alienate them right out of the gate, and force them to register just to take a look.

So, given those not-so-good choices, we decided to:

• Provide useful, free functionality in the unregistered version of SuperDuper!, including technical support and full documentation
• Never “expire” or take away the free functionality we’ve provided, even in future versions
• Offer an evaluation key, on request, for users who want to examine its full capability (all we ask is that you drop us a note and tell us what you thought)

So, now you know!  I think this has proven to be a good compromise, and while it doesn’t satisfy everyone… what does?

Here at Shirt Pocket World Headquarters, we’re often asked about our upgrade policy, and—specifically—exactly how much v2.0 is going to cost if you already own v1.x.

Here’s the deal: SuperDuper! v2.0 will be a free upgrade for registered users of v1.x.

That said, not every major upgrade of SuperDuper! will be free. But, we promise one thing: we’ll always be fair. We truly respect and appreciate you—our users—and work like crazy to do right by you. But, we can’t do that without—well, to put it bluntly—money.

So, why is v2.0 a free upgrade?

It’s free because I wanted to reward registered users, both for their patience waiting for the new release, and for supporting us over the past year or so. You took a chance on a new product, and we’re incredibly gratified by and grateful for the response to SuperDuper!

To each and every person who registered, posted comments about SuperDuper!, and recommended us to their friends, family and colleagues: thank you! I’m sure you’re going to love the new version when it’s released. Stay tuned.

I’m really happy to announce that SuperDuper! was just reviewed by Dan Frakes of Macworld Magazine, in the Mac Gems section.

SuperDuper! 1.5.5 was awarded 4.5 mice—with the only failing being a lack of scheduling. (Those of you here likely know that scheduling will be featured in v2.0: I’m discussing various bits of v2.0 here in my blog, and there are some screen shots in here, too.)

Thanks, Dan!

I think the best way to sum up my feelings at the end of the usability test would have been “despairing”. A lot of work went into what we did, and yet—somehow—it all went totally wrong. But why?

We’d thought that users knew/understood that “Saved Settings” were present, were documents, and as such—since the way scheduling worked was based on that model, and many had used them previously to manually schedule SuperDuper!—were an everyday part of SuperDuper! usage.

But once I had stepped back and thought a little more—and regained my user perspective—that clearly wasn’t the case. The only reason users even got near documents, for the most part, was to do a one-time scheduling setup. And most users didn’t even bother with that.

Users basically run SuperDuper! in immediate “mode”. That is, they start it—SD! conveniently restores their settings—and they click “Start Copying”. That’s it. Smart Update is fast enough that the backup takes but a few minutes. Then, quit. No need to save settings: SD!’s doing it for them, in the background.

Given that, it was clear that “mixing” the immediate usage model and the scheduled usage model was flawed: they’re two entirely different ways of dealing with the program. Combining them—no matter how well it might follow the internal model of what was going on—didn’t follow the external/users’s mental model. So, they couldn’t get their head around it without work, even when they could find the buried functionality: absolutely terrible usability.

So, I reviewed how I’d arrived at this point, and suddenly the answer was right in front of me! All I needed to do was roll back to the original design! Before we started working through the implementation, I’d solved the whole problem:

• The scheduling functionality was right up front, in the main UI
• The scheduled/immediate parts of the program were distinct from one another
• The whole concept of “Saved Settings” was hidden from the user during the scheduling process, and they didn’t need to worry about it at all

So, I wrote the whole sad saga up, and sheepishly presented it to Bruce. He wasn’t happy about it, as we’d have to throw away a lot of work but—fortunately—I pointed out that the vast majority it could be re-used: after all, while the effect on usability should be significant, there were no “new” elements, just existing items that moved around.

Some judicious rewording of the buttons—from “Start Copying” to “Copy Now”—and “Copy Later” fit in the main window. Thus (some tweaks left to go, but this is the current build):

(In what you’re looking at, the red entry has failed to run: clicking Show Log will give the reason why.)

Of course, there are many parts here you can’t see: the way the “Scheduled Copies” window comes up and moves forward when it’s time to schedule, emphasizing the second type of use; the sheet that actually gives you the way to select the repeating timeframe; the new log window that makes it easier to contact support; schedule editing. But you get the general idea: it’s quite simple.

The second test commenced with the same four users, and it went great. Every one completed their task with no confusion, save for one point: most didn’t unlock the application, so the schedules never ran. Once we took care of that: bingo.

We’ve got scheduling!

At the end of the last part of our tale, Bruce and I were feeling pretty good about the state of Scheduling in SuperDuper! We’d solved the technical challenges involved, the UI for setting up the times looked good, worked well, and seemed logical.

In short, we were ready to try things out on “real users”.

In a large organization, Usability tests are done in a very formal way (you can see this in the comments for my last scheduling-related post). The user is given a series of tasks and a (typically instrumented) build, and put in a room where they can be extensively observed. Everything they do is logged, video cameras look at different aspects of the process, sometimes even physiological measurements are taken. And the team, either on the other side of a one-way mirror or in a control room away (sometimes far away) from the test, gets to watch.

What you see is always a surprise. No matter how much you plan and design and argue and rework, something always comes up when you usability test. And it’s never pretty.

Well, here at Shirt Pocket, we can’t afford that kind of usability test.

Instead, we select users who are good at approaching things naïvely. Each one is given the build, and a task, and then I watch and listen very carefully—often using an iSight—while they perform the task. And takes notes. And stay very, very quiet. After all, we’re hunting usability rabbits…

Well, the first tester was—of all people—my brother Paul. Paul’s a good choice, because he’s a very typical Macintosh user, and he indicates in lots of ways, which makes his reactions easy to read.

The task in this case was pretty easy—something like “Schedule a backup of all files on your drive at a time and frequency of your choosing”.

Right off the bat, lots of confusion and the very worst question of all: “How the hell do I do that?”

And, once he found the settings in Options, and checked the box, and it didn’t seem to do anything, he thought he was done and then found out he had to manually save settings, and didn’t know why, and… well, it kept going downhill.

Not good. Not good at all.

(In a real usability test, the designers and developers at this point are usually screaming at the user—who can’t hear them—in the remote location, begging them to find the stuff they’d worked so hard on. It’s really very frustrating to have a lot of work that seemed so good fail so completely.)

So, I thanked Paul, hoping his reaction was an anomaly, and moved onto my next tester. Who reacted almost identically. And a third. Same thing.

The fourth, a user who had previously used saved settings extensively, had virtually no problem at all.

75% failure. Many, many points of confusion. Most of the nice touches in the UI—and there were many—were ignored because the major portion of it was fundamentally flawed: it assumed you knew about saved settings and were comfortable with them, and the vast majority of users know nothing about saved settings and don’t want to know anything about them.

An unmitigated disaster. I’d really screwed the pooch. Gah. And now I had to tell Bruce how poorly it went, and fix it…

During the development of v2.0, almost everything went according to plan. Almost.

What didn’t go right, at least not entirely, was scheduling. In fact, the usability testing for scheduling went absolutely horribly. Embarrassingly so. And it wasn’t just isolated to a single tester: in fact, only one user in the test group managed to figure it out at all.

The question is, of course, what happened? We should know this stuff cold, shouldn’t we?

Looking back, it’s pretty easy to tell where things flew off the tracks, and it started with a simple thing: there wasn’t enough room in the main window to fit the Copy Now button.

SuperDuper!’s main window isn’t “narrow”, and we didn’t want to widen it. A small issue, easily understandable, that snowballed into something fundamentally wrong. Here’s how.

It’s very difficult, when you’re going through a months-long development process, to stay focused on usability. You become so familiar with the concepts you’ve designed that it’s difficult to remember that users—the users you’re trying to serve—don’t necessarily approach the feature set the same way you do.

So, we’d added a “Saved Settings” feature to SuperDuper! as one of the very first changes on the roadmap that would eventually bring us to full scheduling. This was a way to save a whole SuperDuper! setup—from the drives and script to the options—and had been part of SuperDuper! for a very long time. We rarely got any questions about it—usually a good thing.

The initial design of scheduling basically used these documents “behind the scenes”: the user clicked Copy Later, the settings were saved for them, a scheduled copy “job” was created and appeared in a Scheduled Copies window, all automatically. That copy then ran at an interval selected by the user. All pretty straightforward.

But, as I said, Copy Later didn’t fit: a definite problem.

Well, since we knew that we were basing our scheduling around these “settings”—in essence, a SuperDuper! document—we decided that we’d just make the scheduling part of the document itself! After all, that’s sort of what was going on anyway, and obviously people were familiar with these saved settings documents, they’d been in the product for a year! (Plus, this resolved the whole issue of managing “hidden” documents behind the scenes, something that didn’t feel entirely right.)

The design I came up with was this: rather than a Copy Later button, I did what I thought was the next best thing. I moved scheduling to a tab in Options called, of all things, Scheduling. You’d just switch to that, check a box that said “Automatically copy (source) to (destination)”, set the schedule, save the document, and bingo—scheduled document! And all without any changes to the main window.

Problem solved. Looked nice, too! And there was much rejoicing: perfect!

Design settled, Bruce expended much effort implementing it exactly that way.

But during that process, there were some warning signs that should have told me something was wrong. Bruce would come back with questions like “When exactly does the document get scheduled? When it’s saved? Do we force a save when the check the box?” There were intermediate builds with little quirks and small issues that needed to be worked on. These were all problems with solutions, but the fact that they were coming up at all—questions about basic operation that didn’t fall immediately out of the design—should have raised a lot of flags. A whole United Nations of them.

But they didn’t. Or, if they did, I aggressively ignored them. Big mistake.

This was totally my fault: although I wasn’t doing the implementation, the developer in me was thinking about implementation details from a developer’s perspective—never a good thing. Because I knew what was going on behind the scenes, I let it influence the way I framed the UI, and totally lost the light—my “user” perspective—thinking something like:

• We have documents.
• User, of course, knows we have documents.
• Scheduling uses documents.
• Therefore user will know that documents are the way that scheduling works.

It’s so obvious!

Nothing quite like a usability test to toss cold water on that kind of crap thinking. And we’ll pick up that sad saga in the next entry.