The Problem with Custom Installers
While I can appreciate Jesper’s intention to keep the UI simple (an assumption based on his brief post) I can’t endorse the use of custom installers.
First I’ll say this: if you can provide the app as a drag and drop application bundle and copy what ever weird support files you need on first launch, do that. If you truly need to do some sort of install process, please use the built-in install system. It actually has a lot of useful features for users:
- The ability to show and search the file list which explains where stuff will go.
- Works well with Apple Remote Desktop allowing system admins to deploy you app to whole labs of Macs with ease.
- Trust and comfort.
Trust and comfort come from experience. I’ve used this Apple installer many times. I know what’s going to be asked of me, I can examine the end result of the install (ie: the file list) and while the process does involve many clicks they are (after all this experience) brain-dead clicks.
The overall problem with custom installers is that they make you think. You have to be just a little more attentive to what’s going on. Is this such a huge issue to stop the majority of users from evaluating your software? No, but why introduce hesitance?
I am not alone in my uneasiness with custom installers. Many high profile and “power users” look down on them as well. Some of the big boys like Microsoft and Adobe may get away their shenanigans but for the rest of us, the more we follow the expected behavior the more they will like our products.
PS: For building installers friends recommend Iceberg.
Posted on: April 20, 2007 – 4:03 pm
10 Comments
I don’t know where the comfort should come from. An installer package can easily write files not in the file list or delete you hard drive or whatever if it wants to. The Installer’s listing is handy if you already trust the people who made the installer. But if you don’t, it doesn’t provide much comfort.
And even if you need to install stuff, you don’t necessarily need an installer. Just look at eyeTV. Apparently it needs to install a kernel extension (I assume you can’t just run USB devices without that?) and when you first launch it, you are asked to authenticate yourself, the extension is installed and things work right away. Neat.
The only people benefitting from installers might be network admins. But why should a developer sacrifice user’s comforts for them?
@ssp: I’m not trying to encourage developers to use installers instead of drag and drop installs (see second sentance of the post). I’m saying if you have to, use the Apple installer (which has user benifits) and don’t write a custom one.
Sure, I read what you said. I just wanted to point out that in most situations where people think they need an installer they don’t actually do.
What are examples for Mac-like user software that needs an installer?
(Gee, new arithmetic exercise each time!)
@ssp: Examples of Mac-like user software includes much of the Final Cut tools, and Garage Band. They install several extras that do not get placed into the application bundle.
First of all, the app I’m showcasing in the screenshot is Hex Color Picker, a (gasp) Color Picker, which needs to be thrown in ~/Library/ColorPickers. I define this in the readme file. I also get support mail about it, because people do not read readme files.
Two of my four products are not orthodox apps (the other is Gmail+Growl, a Growl-enabling plugin for Google Notifier), and there has to be an easy way to install those, too. These things are plugins and can’t be double-clicked to be installed, and if I’m to provide an app to do that, why not call it an installer?
I admire the Installer for everything it is - including, obviously, tremendously compatible with Apple’s own automation piping. I initially tried to wrap the
installercommand line tool. But look atman installer. (Crazy fun-time aside: with an open backtick, the live preview gets a Rails application error.) It says outright that you will need to be an admin to run this. I don’t want people to be admins to install a color picker or a plugin in their own accounts.Now that you know there are technical reasons behind it, I can reveal that there are more emotional reasons behind as well: I’d rather not use the full-out installer because it is suspiciously large. Packages have psychological ‘heft’. “What, will this take me to that wizard again?” I have at times postponed trying out software because it came in installer packages. There’s also the case of the installer being all things to all people - Apple needs to optimize towards the high end when they design the installer. Simultaneous installations and permissions in the package source material. I just want to copy a damn file to a folder that doesn’t exist by default. (If it did, I’d provide an alias and “drag and drop” disk image wallpaper, like everyone else.)
Let me also make sure that while I intend to make it as small as possible, I also intend to make it as good of an installer as possible. It will have Show Files. It will write some kind of receipt. It will warn you on disk space worries, file locking, permissions, and it will certainly handle upgrades and downgrades. I am piping this through a number of folks, like Gruber, who I know care about this.
I believe I have done my research so far. I really do need something that’s beyond drag and drop, and I really do need something that’s smaller than Apple’s Installer. I really do believe that I’ll be able to provide a satisfying fewest-clicks-possible experience and not toss out every worry that might arise along the way without bringing up an alert.
You will have to take my word that this is not your typical case of the second-week Cocoa programmer writing an installer for its rad brushed-metal Temperature Converter mod just to learn NSFileManager. And it feels really good that people called me out on this, because there are a lot of people who write brushed-metal Temperature Converters.
@Darren: I don’t know FinalCut, but I guess when your application brings resources (such as instruments) with it that can also be used by other applications and which are so huge that just copying them elsewhere automatically is impractical, then an Installer may make sense.
(It seems a shame that the system doesn’t just automatically notice all plugins that may be in an application bundle and then offers them to interested parties. With the power of LaunchServices and Spotlight doing that smoothly should be within reach)
Jesper’s problem is one, I guess. And here it’s a shame that Apple don’t offer automatic moving of all such plugins just as they do for System Preferences and fonts. Luckily most people wanting them either know how to handle things or figure they should look at the readme.
We are distributing a Quartz Composer plugin. Which not only isn’t officially supported by OS X but also saw a change of the folder it had be placed in after some update. Luckily its user base is so tiny that this didn’t become a nightmare.
Good blog Mike.
I am like you and seriously frown on custom installers. One of the biggest reasons is I have found them to be buggy, poorly done and just down right bad. A perfect case in point is the Installer Canon uses for DPP. Works. Doesn’t work. Crashes. Doesn’t crash. Fast. Slow. It is just bad.
It has gotten to the point that I refuse to test any software if the install does NOT use drag/drop or the standard installer. Custom installers, IMO, are simply bad news.
Bit once too many by custom installers.
BTW: I almost answer 10 base 7 but thought the answer would be rejected:-)
Steven: 95% of the bad installer experience I have are from printer drivers. I agree that installers from Canon and HP are usually downright rude (to the point of shutting down your apps without warning). I also frown on this particular brand of installers, the ones that aim to needlessly replace the Apple Installer which would do fine work with their installer scenarios.
In my case, for both my plugins, I need something I can tell “create a folder if it doesn’t exist and then copy a file into that folder”. I have not eschewed Apple Installer because of a need to do my own stuff, but because it’d make installation longer, and also because needing to use a package is a stop signal in some people’s eyes - “why does he need to use a package? Is he out to screw with my computer?” (Nevermind that my code would soon be running on their computer anyway - this is psychological.)
My question to you is this: what can I do to ensure that you won’t get that impression from me? Unlike folks at Canon and HP, I am interested in creating an installer myself in order to make sure it behaves the way you’d like it to.
It helps if you know that simply not using an installer is looking less and less likely as a proposal. I’ve had full instructions in the readme for quite some time, and I still get email about it almost daily. Using an Apple Installer package would bring up more steps for the user to deal with, not less.
To be honest, I have yet to install a printer driver on OS X. I have been lucky thus far.
But I think you far over-estimate the “intimidation” people feel using packages. I will admit to using the package system for about 10 years or so (I started in the Next days) so this might be part of my comfort level with them. But in my many years of using them, I have found them to be a very effective method for distributing applications. Much more so than any custom installers.
So to answer your question: “My question to you is this: what can I do to ensure that you won’t get that impression from me?”
It is simple.
1) Use a drag/drop type install and then create/copy the required directories the first time you run your app.
2) Use the standard provided Apple installer.
A custom installer is, to quote the immortal words of the great Monte Python, right out.
Steven:
For the second time, the products that I have that would use a custom installers aren’t double-click-and-go applications - they are plugins for other applications, you can’t double-click them to make them run. I can’t follow alternative 1 in your example because it requires something to run before my products. And if something has to run before my products, why can’t it just carry an Install button?
I can use an Apple installer, but it’d be more tiresome for my users than copying a file manually to a folder that might not exist. The Apple installer is designed to be easy to scale up, not to strip down.
Post a Comment | Comment RSS feed