DropDMG 3.0
Yesterday, I shipped version 3.0 of DropDMG. This is the biggest update ever for my first Mac OS X application, and it adds lots of new features and refinements that customers have been requesting and I’ve been wanting for myself. Pretty much everything has been rewritten or revised and modernized. It’s come a long way from the first version, more than eight years ago, which ran a single thread, had no preferences, and used an icon designed by the programmer. The basic concept—easy disk image creation via drag-and-drop or AppleScript—remains the same, however.
Although I’m the sole developer, I have many others to thank for helping with this release. Kenichi Yoshida did a great job on the new icon. The volunteer localizers had five translations ready by the time I was done with the code. The beta testers made lots of good suggestions and found all the significant bugs (so far, fingers crossed). And thanks, of course, to the users who paid for DropDMG, told me what was good and what needed improvement, and politely nagged about when the new version would be ready.
DropDMG 1.0 running on Mac OS X 10.1.2. I was pleased to find that it still works on Snow Leopard, a testament to good application code, Rosetta, and Apple honoring its API contracts.
12 Comments RSS · Twitter
I don't know if you should take this as a (polite) insult or a compliment, but you've grown as an interface designer by leaps and bounds since the last release.
I can't wait for EagleFiler 2.0.
"Total Tangent but YIKES to those pinstripes."
In retrospect, sure.
But back in the day, 'twas the fashion.
I'm going to say the same "(polite) insult or compliment" thing I did in the first comment, but in more words:
Michael,
I've always thought of you as a kickass programmer. Your stuff has worked incredibly reliably, which is incredibly important.
I've also always thought of you as a mediocre interface designer. But that completely ends with this release. This really raises your game. Kudos.
Best,
-Chucky
Interface design is a generally neglected category when folks discuss software. It often gets confused with visual design is discussions. But it's something separate, and it really makes a difference in how folks feel about using a piece of software.
For example, on a scale from 1 to 10, Delicious Library is a 10 in visual design, but maybe only a 7 in interface design. There are some glitches, some unintuitive things, and some unnecessary departures from the standard expected behavior that combined make it more difficult to use than it should be.
And nobody loves iCal, even though I'd rate it at an 8 or 9 in visual design. But the interface design is only a 4 or 5, and so folks struggle with it.
On the other hand, everyone loves the software from James Thompson and Objective Development, in large part because their interface design is so kickass.
But folks don't have a vocabulary for discussing interface design, other than the Alan Kay line that "Simple things should be simple, complex things should be possible". And that line is mostly unknown or not thought about. But discussed or not, interface design is crucial for user satisfaction.
(On the other hand, interface design isn't everything. I adore Mike Bombich's software even though you have to struggle with it. But I love it because I trust the hell out of the programming, and he certainly does make complex things possible, if you're willing to struggle a bit.)
It’s confused by the fact that Apple (both Ive and Jobs) talk about design in relation to how products work, and yet the Apple Design Awards tend to focus more on visual design.
Delicious Library looks great, and the design is decent, but it just never made me happy. The iSight scanner didn’t work. The manual importer was glitchy. It required that my iTunes library be in a certain location. Various stuff was non-standard, limited, failed without reporting an error, etc.
I love great interface design, but in choosing an application reliability is more important to me. I’ll be interested to see how Xcode 4 is. It’s only in the last year or so that it’s gotten mostly glitch-free for me.
"I love great interface design, but in choosing an application reliability is more important to me."
For me, it depends on the task.
For example, I consider both Picassa and Adobe Bridge to be more "reliable" than iPhoto and Aperture since they store my precious files in a standard hierarchy I can control. The "reliability" in question being that I have better confidence in getting at my data in a recognizable and usable form 5 years down the line, should software and platforms change. But I don't like the interface design of either Picassa or Adobe Bridge, since they don't speak the native interface language. So I use iPhoto and Aperture instead, make backups, and trust I'll have enough of a grace period to export my files out when the time comes. (While it's nice to know I could theoretically do a rescue by hand from their packages, that'd be so much work that it makes the knowledge cold comfort.)
For a task I'm going to be spending lots of my time occupied in, interface design becomes incredibly important to me, especially if I can find some workaround for any reliability defects.
Similarly, I consider Excel to be more "reliable" than Numbers, despite the atrociousness of Microsoft's OS X programming, entirely because I expect Microsoft to be selling versions of Office 10,000 years from now that will read all legacy files. But I find Numbers more productive to work in because of the interface design, so I ignore the reliability part and go with Numbers. (And Numbers has plenty of interface design problems of its own...)
But, OTOH, I need my reminder system to be 100% rock solid, so I stick with iCal, despite being occasionally tempted by the notion that BusyCal's interface design will make me happier. Similarly, in the tasks I was using DropDMG v2.x for, reliability was key, so I was perfectly willing to put up with interface design things that didn't make me happy.
So I tend to weigh interface design pretty heavily in my calculations, unless I've got a real need for reliability.
Hell, I run a kernel extension to let me remap my fn key to a control key, which is pretty much the definition of someone who values interface over reliability. Which reminds me, WindowShadeX for Snow Leopard has been out for a couple of months now, and I haven't seen any reports of machines running it catching on fire, so I'd better go and upgrade....
For some of those examples, it seems like you’re talking about future-proofness rather than reliability. That matters, too, but it isn’t what I meant. If I were still doing heavy spreadsheet work, I wouldn’t use Numbers. First, I don’t think it’s yet up to the task; and second, I don’t trust that I’d be able to convert everything to Excel format if needed. Word has never been reliable for large documents, but who knows whether Pages documents will be readable in the future. iWork can’t even read my four-year-old AppleWorks documents.
Interesting comments about iCal and BusyCal, since I’ve been considering switching to the latter. What makes you say that BusyCal would be less solid? For me, iCal’s reminders have always been unreliable. They sometimes go off an hour late or not at all.
"Interesting comments about iCal and BusyCal, since I’ve been considering switching to the latter. What makes you say that BusyCal would be less solid? For me, iCal’s reminders have always been unreliable. They sometimes go off an hour late not at all."
Do you have time zone support enabled? If so, turn it off.
iCal hasn't missed a single reminder for me since 2003 or 2004. I think it's solid because that's my experience with it. (And I haven't seen any reports of issues other folks are having with it in the past couple of years, other than time zone support issues.)
For all I know, BusyCal could be just as reliable. But I need reminders to work, and I'd be spending a evaluation month moving from something I can count on to an unknown quantity on a mission critical task.
I might give BusyCal a real test at some point. I tried it for a day, and it seemed as if it could be a more pleasant interface experience than iCal. But I've been loathe to do a real evaluation so far for the above reasons.
"For some of those examples, it seems like you’re talking about future-proofness rather than reliability."
Reliability is a multi-faceted thing to me. It includes robustness and predictability, of course, but it also includes data-protection, of which future-proofness is an important part. I've got an unbroken hierarchy of files that dates back to 1993, the large bulk of which are still easily readable with my current apps, and I hope to have my hierarchy available to me in 2027, still in easily readable form.
"iWork can’t even read my four-year-old AppleWorks documents."
Yup. That's why I theoretically try to avoid Apple-only file formats. Cupertino has a deeply anti-legacy attitude. It's why I try to avoid webarchive files, for example, even though they are more convenient than pdf files in certain ways.
In theory, at least, I'm deeply conservative in my file format choices. It's why I try to avoid putting media into mov containers. It's why I'm still encoding music in mp3 format, (though I'm starting to finally think aac might be here to stay.) But I don't always follow the theory when a nice interface design catches my attention, as is evidenced by my use of Numbers despite knowing it might well cause me grief down the road...
I’ve used iCal with and without time zone support (and tried recreating the events after switching that preference), and the reminders don’t work reliably either way.
Sometime before I get rid of my last Mac that can run Classic, I need to go through and convert all my old files to future-proof formats. I’m not sure what can be done about iDVD and iMovie, though. Those would require keeping an old Mac and old versions of the apps, which probably isn’t worth it.
"I’ve used iCal with and without time zone support (and tried recreating the events after switching that preference), and the reminders don’t work reliably either way."
FWIW, I think that is atypical. If reliable desktop reminders are something you'd find more than slightly useful, it might be worth your while to troubleshoot, as the feature generally works.
First do a fresh user backup, obviously. Then do an iCal Export to Archive within the app. Delete all iCal and Calendar stuff from your ~/Library. Reimport the Archive from within the app.
If that doesn't fix the issue, and you sync your calendar with anything, try doing research on how to best reset your Sync Settings.
But again, my sense is that your problem is atypical. There were issues with alarms not firing for everyone when iCal was first released, but the big bugs got squashed six or seven years ago.