Could someone explain to me why installers are often the least thought-through part of the application development process? And more importantly, why, especially at Microsoft, the people who write the software and thus know the limitations it has on file layout (including files comprising the application and its support libraries, but also plugins, caches, temporary user data, persistent user data, configuration files or *puke* registry keys) are usually not the people producing the software installation packages? And even when they are, they think first Test Matrix and second Customer Utility.
Installation is the very first user experience (after opening the box, in the case of full package product, which rarely happens anymore with web downloads), and is a regular experience as upgrades come out, or more likely, security patches. Getting your installer right enables people to install your application where they want it to. Whether that means an alternate volume (other than the boot volume) or in a user-specific directory (in the case where they’re not an admin and don't have access to the root of the volume), or on some network share for multiple people to use, they should be able to get it there, and installer writers are notorious for arbitrarily limiting this.
Furthermore, custom installer scripts do the most insane things, requiring you to quit apps that have nothing to do with the thing you're installing, or to reboot because they couldn’t figure out how to gracefully install in a way that lets running apps continue to work correctly. Gaah!
I downloaded the
RDC update (well, from v2.0 Beta to v2.0 RTW) and tried to install it. It wouldn’t allow me to install to my data volume. Why? No reason that I can fathom. (It doesn't have the same installation requirements promise that Mac Office 2008 made; it's an RTW product and free–they could change it to be whatever they wanted, even 10.4.10. Heck, that would even
reduce the all-important testing matrix.) Even if I use the same hack to fix that, the package was not marked as relocatable, so it would have installed the thing to /Volumes/OtherVolume/Applications, rather than let me nicely select where to put it (i.e., to replace the Beta version that was on the data volume and running fine from there). So, I decided to install it “normally” and just move it after the fact. While running, it asks me to quit Entourage. Why does it need to quit Entourage? There’s no shared libraries between Entourage and RDC. Ah, but it needs to install Microsoft AutoUpdate, and Entourage uses that. There are two obvious problems here: (1) There was nothing in the package that said it was installing two different items, RDC and AutoUpdate. If AutoUpdate is not in the package of RDC, then it should be its own separate line item to be installed. Even if the developers wanted to enforce an (unnecessary) dependency between RDC and AutoUpdate, having it called out would be actually useful. (2) Why does Entourage have to quit in order to update Microsoft AutoUpdate? Even presuming that there was an actual update that was occurring (which seems strange considering I just updated to Office 12.1.1, and would have expected that any updates to AutoUpdate would have been in that package as well). The best part is that your only choice when Entourage is running is to quit Entourage, because the only button available to you in the installer is “Continue”, and if you click that while Entourage is still up, it just causes the dialog to reappear. I suppose there’s always Force Quit.
So, in summary, the installer fails on several fronts:
- relocatable installation
- different path
- different volume (unless the volume happens to be a system volume of 10.4.9 or later
- non-admin installation to ~/Applications
and is a little annoying about hiding multiple packages with weird installation requirements.
Guess I’m back to fighting the uphill battle.
