Pierre Igot recently wrote about Adobe’s atrocious CS4 installer. While I didn’t have the opportunity to enjoy that particular installer myself, it’s a good opportunity to discuss the issue.
The bottom line about installers is extremely simple: they suck.
People are hardly ever interested in using software (they’re interesting in getting things done). Guess how much they’ll be interested in installing software? As a consequence software makers should think, think again, and then think again again again before they publish software which cannot work without an installer.
Of course there are many different kinds of software with a wide range of requirements and there isn’t a simple rule to fit all of them. Yet, it seems that only very few pieces of software actually require an installer in any strict-ish sense of the word.
If there is a piece of software which looks like it might require an installer, it could be the operating system itself. I am not really convinced that is the case, though. A look at ‘Classic’ Mac operating systems suggests that an installer for the operating system is just a control freak nuisance: You could simply copy the System Folder over to a different hard drive and then restart from that drive back then. It Just Worked™. If it worked back then, it seems unclear why it shouldn’t work today with machines being more powerful and technology having advanced.
Admittedly, the ‘Classic’ Mac OS’ came with an installer as well even though a simple copy operation would have worked but at least you could continue using the machine while the installer was doing an install on a different volume rather than having to stare at an ugly star field for half an hour…
Software Suites like Microsoft Office or Adobe’s Creative Suite may be the next best candidates for needing an installer. The fact that they consist of many applications and c components which may be shared between them gives a sort of excuse for having an installer which makes sure everything ends up in the right place.
However: even Microsoft managed to make a version of Office that didn’t require an installer in the early Mac OS X days - dragging and dropping a folder sufficed - and it’s unclear why that doesn’t work today. If the software is sufficiently well programmed why can’t it simply find its resources on the drive and do additional copying or downloading if things went missing?
As far as I can tell - from seeing current Adobe Reader Installers anyway - Adobe FAILs massively on all of these points. Their installers and updaters even want to force you to place their software in a very specific place on your drive (e.g. Adobe Reader at the top of my /Applications folder while I prefer having it in /Applications/unloved/)
This may cover Microsoft and Adobe as well I guess, but I was thinking more along the lines of Unixy packages. Those may require many files in obscure places on your hard drive and as a consequence there’s no way you’ll manage to run them without an installer doing all the right things for you. As such software tends to be rather inflexible when dealing with tiny changes of the setup, you don’t even want to try doing this yourself. There’s a reason why even sturdiest nerds love
Uh, and that’s why one wouldn’t consider such packages proper Mac software, I guess. Occasionally people take all the ugly Unixy bits, wrap them in a pretty Mac application package and ship them like that. That’s a lot of effort but it can work and leaves a much better impression with the non-command-line people.
Plug-Ins frequently come with installers because users are assumed to be too stupid to ‘install’ them in the right folder.
When seeing that I usually think that it may just be a sign of the application developers being too lazy to make the host application automatically install the plugin when it has been double clicked. Even Apple do that for preference panes, so most other people should - and increasingly many do! - do the same.
For system extensions the case is similar to that for the system itself. Back when computers were smart you could simply drop control panels, system extensions or fonts on your system folder and the system would figure out what has to go where and simply use it after the next restart. Mac OS X is too dumb for that (for actual software, the current version is quite good at finding any font files you may have on your drives automatically).
Thus, system extensions may have a good excuse for an installer as someone has to make sure that things end up in the right place and nuisances like Unix permissions are set in the correct way. As this may affect the machine’s security, it seems advisable to let someone mildly competent figure out how to do it.
A cynic may feel compelled to say that software like Adobe’s apparently does install software at the system level to handle some DRM crap. As these things go, it appears that this is just a waste of their customers’ money to litter people’s computers with code that makes the software harder to use. How many people complain on the internet that Adobe’s apps are too hard to crack? All that while their registration management system seems to be so legendarily broken that their paying customers have started to expect their apps to refuse working right before a deadline?
Apart from the inconvenience, installers also mean mystery. They put you off if you want to try out an application or tool as the installer may just litter and manipulate files all over your hard drive. Windows users are super weary about such stuff, but even Mac users dislike it. If an application ships as a single file (or bundle), it at least appears like a problem that is much more contained and can easily be removed.
Contrary to popular opinion Apple’s installer packages also leave it completely unclear what the installer will do. While the Installer does display a list of files when asked, it can also run scripts which may add or manipulate additional files - or erase your hard drive for good measure.
It’s not terribly hard to create applications which are fully self-contained on the Mac. Software developers should make an effort to achieve that even if it may be more convenient to use an installer.
Just compare the experience of ‘installing’ EyeTV with that of ‘installing’ Parallels. Both applications need a kernel extension in the right place. Parallels comes with an installer (a custom one even which them seems to launch Apple’s‽) that installs - or in the case of an update re-installs - the application and the separate tools it needs, littering your applications folder in the process.
EyeTV comes along as a simple application. You move it wherever you want and when you launch it and it doesn’t find its kernel extension in the right place you are asked to authenticate yourself so it can be installed.
Now guess which of these experiences is the more pleasant one?
While Adobe’s installers may be abominable, their Lightroom application suggests that they have sane people working at the company as well. It wasn’t clear to me why Lightroom needs an installer, but that one is harmless compared to the others.
Amusingly Pierre’s post was also seen and discussed on an Adobe blog. Probably the fact that it’s labelled a
rant already indicates how seriously they take this. But it’s amusing to read that they’re
going to work with the installer folks to create a response.
In my opinion the situation Pierre described is nothing that requires
a response. Just reading his description is a (tragi-) comical story in itself. One of continued (it’s not exactly a first for Adobe to ship such installers) FAIL to understand or respect what would be convenient for the user. The Adobe install situation smells unfixable and needs a complete re-think or brainwash to end up in a good position.
A first step towards that might be to change the objective for their installer from ‘reflecting the CS application hierarchy and sneaking all sorts of stuff on people’s hard drives in as many applications as we can launch’ to ‘from a single drag and drop to your first sketch in 15 minutes’. As I consider that bit of advice obvious, I’ll leave it to the internet free of charge…