Article
Stuffit … exactly
Over the weekend, something in my Stuffit Expander installation on my Mac at home went wonky. Usually, when I download a zipped file and open it directly with SE, there is a brief moment of bouncing icon spectacle before a new folder conveniently lands on my Desktop, uncompressed and ready to go. This weekend, though, the brief moment of icon bouncing bliss expanded to like three or four minutes followed by a similar period of non-response followed finally by the new folder landing on my desktop. I killed my preferences and reinstalled SE a few times with no luck. This gave me a severe case of swearing annoyance, an ailment from which I have suffered little since I stopped using Windows fulltime, and I couldn’t get over the fact that I was doomed from here out to unzip everything from the command line.
At some point, though, I realized that the problem seemed to be occurring at startup. The immediate solution, though not graceful, was to just leave the damn thing open all the time. That bugged me too, but at least it would work. After accidentally closing the application about three times, I finally decided something had to be done. Just as I was getting prepped for my search for a replacement, something occurred to me. In the past, SE had been kind enough to notify me when a new version is available. That meant that it was doing some sort of network version checking and while it seemed unlikely that they would be stupid enough not to setup a separate thread to look for the update, it was worth a try. I jumped over into the preferences, clicked off the check as seen below and restarted the application. Zing! I was treated with the same brief moment of bounce to which I had become so accustom.
And now for the rant: Why is version checking being done in the primary thread in this application? This, of course, means that the time it takes to unzip a file is now partially determined by my network performance. It also means that if the site to which the application is attempting to connect is down, you have to endure the full timeout before even starting the unzip process. And a timeout of like three minutes? Come on. Try this instead, check for a new version after you are done doing what you are supposed to do. Unzip my file, and then when you are in the process of shutting down, take as much time as you need to check with your broken update site.
This type of bug is an important one to think about in the larger context. Since this is certainly relavent to the efforts of the Simplicity Consortium at the Media Lab, I’ll talk more about this in more general terms in the next posting.
Personally, I absolutely hate the compressed folder tool in Windows XP. It commits the same design foul that Stuffit did but on a system level. The compressed folder bit is an Explorer extension, which means that when it has trouble it can actually bring down your entire desktop environment. This, of course, is an order of magnitude worse than having to wait six or seven minutes to decompress a file. On top of it, it's implemented poorly too. Try dropping a huge zip file into a directory and browsing into that directory. Explorer will take significant time to show you the files in that directory, because it uses the main thread to examine the zip file.
I think the trick is designing systems that are isolated, yet still have a good sense of their context. That's a balancing act, because in a lot of ways isolation means removing as much context as possible.