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…

Brent Simmons has just blogged a bit about the design of one feature in NetNewsWire 2.0on his blog. If you’ve been enjoying my posts about this, you’ll probably enjoy Brent’s, too! Brent classifies himself as an Experimenter/Gatherer, which I usually am too, when actually doing the coding. When I’m doing the design, I try to experiment as much as possible on paper and roll in feedback, but get close to final and keep the tweakable elements to a minimum so as not to waste Bruce’s time. That doesn’t always work out, as my Scheduling posts show…

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.

It was pretty clear, after we’d released the first version of SuperDuper! that, scheduling was something users were clamoring for. We kind of knew that was coming — it’s a pretty common feature of this kind of program. So, after Bruce and I talked about whether or not it was something that we wanted to do (it was), I started to think about how to accomplish the high level goal. As (I think) I’ve said elsewhere, part of SuperDuper!’s philosophy is to keep things as simple as we can, and keep the options to a minimum even when that might mean disappointing a customer or two. The last thing we want is for SuperDuper! to grow into some giant, confusing beast of an application — and so, we’re pretty conservative about what we add, and take a long time to think about the simplest way to implement what could be complicated functionality. So after thinking about this for a while, right around WWDC 2004 I sketched out a relatively simple change to the main SuperDuper! window: a Copy Later button. And, from that, a window that showed these scheduled copy operations, and a basic UI to set the schedule that was flexible, but not too flexible.

I do most of my initial UI design on paper, with basic “storyboarding” of the way things work and how they look, along with little notes about other behavioral issues that are implied by the design. I’ll try to scan one of two of those in here at some point, if anyone’s interested…

I was fortunate enough to schedule a session with one of Apple’s UI designers at WWDC, and ran through the existing UI, as well as the changes planned for Options and some other parts of v2.0. The reaction to the changes (and, to my surprise, to the existing UI — a topic for another post) was very favorable, so I felt pretty strongly that we were on the right track. Bruce and I talked about the engineering necessary to achieve our goals, and soon thereafter we broke things down into what needed to be implemented along the path to v2.0 (much of which is in the current version of SuperDuper!). This included:

• “Settings documents”, which allowed a user to save all the information associated with a backup operation.
• AppleScript support
• Many internal changes to support “hands-free” operation
• An AppleScript framework that will actually run the backup itself (while being useful for other things, too)

What happened over the next few months is an interesting lesson in “losing the light”, and it all comes back to the Copy Later button. Stay tuned.

Our Bernese Mountain Dog, Ketzl, is a great girl, but she’s been through a lot in her 8 years. Even knowing that Bernese have a tendency toward health issues didn’t quite prepare us for:

• Entropion (eyelids turned slightly inward, which causes the eyelashes to irritate the cornea - surgically corrected)
• OCD (lesions in the joint capsule - shoulders, for Ketzl - corrected surgically with a then-experimental method involving a scope)
• Torn ACL ligaments, both sides, requiring corrective action (TPLO, in K’s case, which requires 12+ weeks of recovery for each operation, 6 of which necessitate putting no weight on the leg - quite the challenge)
• Mast cell tumors, caught early

That’s a lot for any dog to go through (and I’m probably forgetting something): Ketzl has been great throughout — terrific attitude, enthusiastic… a great companion. A few years after her last TPLO we noticed something unusual: an occasional tendency for Ketzl to scrape her right foot on the ground when moving it forward. Given her previous orthopedic issues, we booked a follow-up appointment with our surgeon to see if perhaps something had gone wrong with her recovery (although this was some time after the surgery, it seemed to be the best initial approach). Dr. McCarthy at Tufts did an exam, and was positive after his examination that this didn’t look like an orthopedic issue, and referred us to the Neurology department. After a number of exams, it seemed pretty clear that the problem was something neurological, and an MRI didn’t show any significant spinal cord ‘pinching’… It’s important to recognize at this point that some diseases are diagnosed as a series of “rule-outs”: as all the other possibilities were eliminated, one-by-one, only the worst remained… Degenerative Myleopathy. DM is similar to Multiple Sclerosis in humans. The immune system attacks the myelin sheath surrounding the nerves, causing them to lose their ability to transmit signals. It starts in the back legs and moves forward, the end result being a completely paralyzed dog. There’s no real treatment (and no confirmation of the diagnosis until an autopsy is done; basically, they remove the spinal cord and examine the nerve fibers — pretty horrible), though certain types of supplements are anecdotally helpful (and we’ve got Ketzl on them). It progresses relatively quickly, and within 6 months or so the dog loses control of their back legs. Ketzl did quite well at first, and was able to actively walk and lead a relatively normal life, except she would lose her balance, fall, or cross her rear legs. (In general, the nerves that tell the dog where their legs are go first.) But, as time went on, the right leg became more and more paralyzed, and Ketzl was no longer able to use it effectively. The left side got weaker as well, and after a year and a half or so it was clear that she could no longer walk without hurting herself. But, this took longer than we expected: a good sign. There are two big decision points with DM dogs. The first is when the dog loses mobility, which is where we are now. Fortunately, I work in a home office, and am able to be around her all the time: I can use a (really great) harness to help her get around the yard, and tend to her when she wants to go places she can’t stumble/drag herself to. We also take her to a place about an hour away, once a week, that does animal physical therapy. This includes massage, electric muscle stimulation, a water-treadmill that allows her to walk “normally” by supporting her weight in water, and controlled swimming. All of this is designed to help keep Ketzl’s muscles as strong as possible for as long as possible — but even with all this, her muscles inevitably lose tone in her legs and back, and it moves forward. Today, she weighs about 13 pounds less than she did a year ago, and all that’s due to muscle wasting. If that was all, it wouldn’t be the best life for a dog… and without the time to do all that (and, believe me, it takes a lot of time), many would choose to put the dog down. Fortunately, we also found Eddie’s Wheels — a place here in Massachusetts that makes “carts”: wheelchairs for dogs. We had Ketzl measured for a cart, and right around Valentine’s Day we drove out to the shop, had it fitted, and took Ketzl for her first “unassisted” walk in months. After some initial “what the heck is this?” hesitation, she took to it enthusiastically, and walked up the hill, tail wagging — also, for the first time in months. It was clear she was beyond happy, finally able to move again! (I’ve got a movie of this: maybe I’ll post it once I edit a little, as it’s a very happy moment.) The Dog Wheelchair has really made a big difference for her, and for us. We can go for walks together again, and she can get exercise. If you’ve got a dog with similar problems, I enthusiastically recommend Eddie’s Wheels — they’re great people, and a cart will make a huge difference in your dog’s quality of life. Unfortunately, the disease continues to progress. Zabeth is a veterinary student (Tufts ‘07), and with that and the web, we know far too much about the disease and its inevitable march. Soon, it’s likely that Ketzl will become incontinent (something I’m not looking forward to, as many dogs get depressed when it happens) — and that’s another decision point for most owners. I’m looking at it like this: as long as Ketzl is still happy, I’m willing to do what I can to help her continue. As our veterinarian has said, DM is a trail of tears. And it’s true: it’s a bastard of a disease. Yet there are little victories every day, and the sight of a dog, in a wheelchair, zipping along and greeting other dogs and people — ears flapping in the wind, tail wagging… Trail of tears, sure. But sometimes, those tears are tears of joy.

Super Duper by Shirt Pocket Software, www.shirt-pocket.com, is free if all you want to do is clone one hard disk to another. But if you register your copy, for $19.95, great new features appear, including filters, scripts and the amazing Safety Clone, which lets you install new software and still roll back your drive to the way it was if things go wonky. And Shirt Pocket’s customer service is superb. When I was unable to register my copy, I sent an e-mail on a Friday night, and the solution was in my mailbox Saturday morning.

(via Dr. Mac’s column in the Houston Chronicle, Thanks, Dr. Mac!)

We try to keep “upcoming release” information quiet here at Shirt Pocket, or at least relatively so, until we’re close to releasing new a version. The last thing we want to do is frustrate our users by announcing something and then not shipping. But, let’s pull back the curtain a bit on the next release of SuperDuper! As you might (or might not) expect, Bruce and I have been working on v2.0 for months. We’re working hard to achieve two main things:

• Improve the user experience even more
• Add scheduling

There have been a ton of changes to the way SuperDuper! works internally, each of which ties into these two goals. I’d like to show you one example of what we’ve done, both to whet your appetite for what’s coming, and to show you how we approach changes. (If you enjoy this post, let me know and I’ll do the same for other new features, too.) So, let’s start with…

The Status View

It’s not commented on a lot by our users, but the SuperDuper! status view — what’s displayed while the backup is going on — is a model of not-very-good design. Sorry to everyone who’s had to deal with it up to now, but there’s a happy ending, so read on! While the existing status view gives basic information about what’s going on, it’s not nearly as helpful as the “What’s going to happen?” section of the UI that appears elsewhere in the UI. And it’s pretty ugly. And what’s up with those two progress bars? And, hey — I know it was successful and all — but what happened while I was away from the computer? I could go on, but I think you get the point. For background, SuperDuper’s UI is specifically designed to be as unambiguous as possible. I’m really careful to not use generic placeholders like “source” or “target”. I try to avoid some of the “conventional” backup terminology like “incremental” or “differential” because they tend to confuse and obscure what’s really going on. We try to cut our features to the bone to make sure the product isn’t overwhelming. The idea is that I’m really trying to eliminate the worry that surrounds the backup process — that “Am I doing this right?” feeling that makes you not want to back up, or not be confident in the result. SuperDuper’s simple UI, stripped down functionality, and “What’s going to happen?” section does this, as does its rapid and accurate operation. So, the question was: how do I carry that same feel through? The first thing I thought of was: well, the “What’s going to happen?” part of the UI was pretty successful, so why not just do that? You could kind of “bold” each part of the description and turn it different colors as it went through… but, no. Yes, the WGTH? section is reassuring and very popular with users. It’s a narrative of your choices. That’s very helpful when you need the “expert” pointing out what exactly you’re going to accomplish when you hit the button. But, once you’ve told SuperDuper to go and do the backup, you’re basically entering “Computer World”, where things are far more linear, structured and concise. Trying to shoehorn that into a paragraph just would not work. Instead, I felt it needed to tell you things in a different voice — still helpful, of course, but more “mechanical”. After thinking about it for quite a while, I settled on an approach based on a classic speechwriter’s maxim: first, you tell the audience what you’re going to tell them. Then, you tell it to them. Finally, you tell them what you told them. And so, after a lot of prototypes: that’s what I did: This is a real shot of a recent build of SuperDuper! v2.0, running an actual backup. I’ve broken the backup into different major “Phases”, each of which has a bar. A phase is grey when pending, blue when currently in progress, green and checked if successful, and red with an X if it failed (not shown). Each phase has a number of steps, and each step changes to show whether it’s pending, current, successful or failed as well. The wording of the step changes, too, following the maxim: going to do it, doing it, done! Everything follows our ‘no placeholder’ policy, and tells you exactly what drive it’s operating on, and what it’s doing. We’re also giving significantly more information about the process of copying (and will likely provide even more in the final version). So, in the end, it seems pretty simple, and I think it feels pretty great in use. (The static picture here doesn’t show you the nice compositing Bruce does as the steps complete, nor the way that a step automatically expands when there’s more info to show, but you’ll see all that soon enough.) What do you think?

My conversation with Dave goes above and beyond what I’d call “support”. Not only that, I hadn’t even registered SuperDuper! yet — I planned to if it worked for me, but I was in the middle of proving that out, and I didn’t mention that to Dave at all. This kind of support is why I’m happy to “pay for software”. I put that in quotes because in my mind, I’m not really paying for the software, I’m making sure that Dave has time to continue to be amazingly responsive to questions like mine…

(via Ted Leung on the air, Thanks, Ted!)

It’d been a few months since I’d left Compuware and set out, once again, on my own. Shirt Pocket was initially formed to create products for PDAs, a market segment that I’ve always found interesting… hence the name. I was still working on a PC — an IBM ThinkPad T23 — and while I had some good ideas, I was having a lot of trouble getting going. The design part was relatively easy — I knew what I wanted to achieve — but transitioning to coding was going poorly. Our dog Ketzl needed TPLO (Tibial Plateau Leveling Osteotomy, pretty radical stuff) surgery to recover from a torn anterior cruciate ligament (Skier’s Knee for Dogs — who knew?), and that required an extended rest-and-recovery period: a time where she required near constant nursing. Since I work at home, I got to be the “dog nurse” as well. Ketzl needed attention fairly often — a constant interruption. I’m usually pretty good with that kind of thing, but I was finding it difficult to keep focused on the task at hand: coding the new product. Just. Wasn’t. Happening. I put the whole thing to the side for a while and focused on Ketzl. And read. And listened to music. And got frustrated with my CDs. It was just too hard to find the music I wanted to listen to. While I’d spent a little time ripping some CDs to my computer, it was clear that the PC-based music players just didn’t have what it took to be usable. I tried all of them, even wacky and obscure ones like B&O’s BeoPlayer (stylish, but absolutely horrific usability): they just weren’t working for me. It was too difficult to find music, even with a modest amount encoded, and I’m not of the type to shuffle everything… I know what I want to hear, and that means I need to find it. Years ago, we’d used the Macintosh at UnderWare to do our in-house email and various other things that Macs were good at, but after Zabeth had a horrific experience with a 6300CD (from the Dark Days), we stopped buying Macs here (and tossed that one off the roof, which was strangely satisfying). And when the Newton was discontinued, I stopped following what Apple was doing very closely. While there was a lot to admire in Mac OS, it seemed to be maturing poorly, and OS9 just didn’t do it for me. The introduction of OSX, though, piqued my interest. I’d had a NeXT cube back in the day, and did a lot of Track Record’s design — and nearly all its internal documentation — on it. Although its screen eventually became too dim to use and the whole thing was sent to the Computer Museum (aka the basement), it served me well for years: it was even UnderWare’s mail server back when we were “uw.com”. And now, it was back — sort of — on the Mac. And, when I went to take a look at it, I saw one other thing, too: the Mac had iTunes. One quick look at iTunes made it clear that it was an excellent application. It organized things well, presented a simple and logical UI, and excelled at searching. Clearly great stuff. OSX looked good too: it felt less polished than iTunes — less well thought out — but had potential. So, I made my very first computer decision as a user, as opposed to as a business owner. I bought an iBook. And, while taking care of Ketzl, I started ripping my CDs. I outgrew the iBook really quickly: it was almost disturbingly obsolete, for my use, in days. Sold it and bought a PowerMac G4, then a Powerbook… an obsession had well and truly started. And OSX was better than I’d hoped. It was terrific. I was enjoying using my computer again. It’s good to be a user! As the time taking care of Ketzl went on, I’d managed to rip about 2000 CDs (don’t ask — I’ve been collecting music for a long time), and had begun to realize one big problem with digital music: sure, I could use it on the computer, and on an iPod (or whatever), but it didn’t connect very well to my “real” stereo. And here I have a whole-house system that was crying out for that connection. That wasn’t so easy! The main receiver was in a totally different part of the house. Running an audio cable was out of the question… but I could network up there, and attach another Macintosh, and share the disk that has the music library… So, that done, another problem reared its ugly head: the computer playing the music was far away from where I was listening, and heading over there every time I wanted to find music was no fun at all. I tried using Apple Remote Desktop and VNC, but they were awkward (at best) — I didn’t want to take over the whole computer, I just wanted iTunes. And that’s when I came up with netTunes. I just wanted iTunes, remotely. Exactly iTunes. So, that day, I became a full time Macintosh developer: learned Cocoa, designed and wrote netTunes, released it… and haven’t stopped — or developed for the PC — since. (More about the design process in a future post.) Not where I expected to be when I set out again in this business. But I’m awfully happy I’m here!

I didn’t know it at the time, I made two huge mistakes when I settled on the various sweated-over terms used in SuperDuper! While the vast majority of the wording is clear to the vast majority of users, it’s pretty obvious at this point that Safety Clone and Copy Script have “prior experience” associations that interfere with what I was trying to get across. Let’s take Safety Clone first. Sadly, I no longer remember exactly what I was thinking when I came up with it (probably involved dancing through the Land of Chocolate, or maybe a funny monkey), but what I didn’t consider was that it might be confused with “Cloning” in the “full disk copy” sense. (Yeah, I know — seems obvious now, after all, it does kind of include the word “clone”.) Some users come to SuperDuper! with prior experience, and rather than reading the (hopefully helpful) What’s going to happen? section of the UI, choose one of the Safety Clone scripts to back up all their files. As I said in my previous Safety Clone post, this does not back things up. But, to some, it sounds like it does. Bad mistake. I’m pretty sure this is going to be easy to fix in v2.0 with a wording change. Rather than calling this a “Safety Clone”, I’m thinking of calling it a Sandbox — so the two scripts would be “Sandbox - shared users and applications” and “Sandbox - shared users”. The “Sandbox” term clearly resonates with users, and I don’t think it’ll be confused with a full backup/clone. That’ll make the two real backup scripts — “Backup - all files” and “Backup - user files” — stand out much more. Copy Script is a bit more problematic. A copy script is really just a way of specifying files you’re going to copy, ignore or share. It has a text field for a description that’s shown in the What’s going to happen? section, and a way to “build” on scripts that are already created. That’s about it. What it’s not, then, is a script. It’s kind of a file picker. With some other useful stuff. Anyway, it implies a complexity that isn’t really there, which scares users away. (And, it has a poorly designed UI, which we’ll be addressing eventually, but that’s the subject for another post.) Unfortunately, I haven’t yet come up with a better term, so Copy Script it is… for now. I just don’t like File Picker or File Selector or Selector or Chooser or… Roget’s, take me away!