What’s the first thing that anyone has to do with an application? Install it. In some way, shape or form, they have to get it from the installation media to their hard drives. Now, you can run some applications from the installation media or a disk image, but after a while, that gets tedious. So you have to install the application.
|
Related Articles |
|
|
Spam Filters for Your Mac: Six Choices Apple Adds Automation to Aperture Using Vista and Linux on a Mac, Part One
|
I have to say that I am, and have been for almost my entire career, amazed at how a company will put great care into the application, then make the installation almost an afterthought, or at worst, a nigh – torturous experience. I really don’t understand this, as it’s like creating a beautiful bit of hardware, then making you drink sour milk just to get it out of the packaging.
The installation is the first real experience a customer has with your application, so why would you want to make that experience anything but as painless as possible? Bad installers are even more surprising when you realize that it’s not hard to make, if not a great installer, then at least a not bad one.
1) Use the simplest installer method you can.
If you can, use drag and drop. Customer mounts media, customer drags application to destination, customer uses application. That’s the closest thing to a perfect installer you’ll see. It’s simple to use for one (or a thousand) users. It scales well, and it requires almost no technical ability. Firefox, and even Microsoft Office 2004 win here. So does Adobe Acrobat Professional.
2) Use the simplest packaging method you can.
Don’t be like some vendors, (Epson, I’m looking at you here) and use a compressed, binhex’d installer that then installs the installer that will actually install the product.
If that sounds lame to read, it’s far worse to use. On a Mac, all you need is a compressed disk image, and you’re set. If you want something cross-platform, zip, or zipped tar is best. Yes, I know, Stuffit still exists, and it still works well, but its advantages are small at this point.
Zipped files are best if the application is a command line component. For things like source code, where you may have a complex file structure, a zipped tar file is a good idea. But if at all possible, on a Mac, just use a disk image. They compress well, and you can encrypt them if you wish.
Adobe both wins, (Acrobat Professional) and loses, (Adobe Reader 8) here. Reader Pro not only requires separate Intel and PPC installers, but if you don’t know the magic URL, you download an installer that downloads the real installer. Even worse, if you decide to cancel the installer, too late, it’s already installed. Not good.
3) Everything is not exactly the same, or, use the appropriate installer for the platform.
If you’re building the installer for a Mac OS X application, use a disk image for drag and drop, or an Apple installer. For Windows, you should use MSI, or whatever the follow-on for that is.
|
Related Articles |
|
|
Spam Filters for Your Mac: Six Choices Apple Adds Automation to Aperture Using Vista and Linux on a Mac, Part One
|
This isn’t just platform snobbery, it’s a critical issue for sysadmins. When you use some third-party installer that essentially requires you to manually install everything, you make it really hard to install on a couple hundred machines. If you simply must use some bizarro installer, then please, please give us a way to install it onto multiple machines at once.
For example, starting with CS 2, Adobe added a way to do installs on Macs completely via the command line. This was a nice workaround for their insistence on not using the Apple installer.
Microsoft, while making the initial install for Office 2004 simple, then messes it up by making it really tedious to install updates. Adobe is starting to move towards the whole “installer downloads the installer” thing, and even worse, the downloaded files are opaque to most of the sysadmin tools on the Mac, which means you have to figure out what goes where to build your own installer. Gah.
4) Think of how someone will install your application on a couple hundred machines in different locations.
Just because it “only requires a few clicks,” that doesn’t make it a great install process for a couple hundred machines. If I have to manually install it, or build my own installer to install it, the installer stinks. Period.
Ideally, use either drag and drop or an Apple installer. Barring that, give me a way to customize the manual process. In other words, do the work so that I, the person installing your application, don’t hate your product.
Apple used to make me scream with the QuickTime updates that made you watch the “GET PRO NOW” message half way through the install. Luckily, the sound of millions of voices crying out made them stop.
Another part of this is don’t force me to install it in /Applications. Just because you think it’s the best place has no bearing on anything. Schools, labs, and corporations all have specific procedures for installing things, and it is your job to be flexible here. Don’t make us do silly workarounds like symlinks back to /Applications just because you don’t want to do the extra work of adding some flexibility into your installer. Software vendors disagree on this.
5) Think of security.
|
Related Articles |
|
|
Spam Filters for Your Mac: Six Choices Apple Adds Automation to Aperture Using Vista and Linux on a Mac, Part One
|
This one really bugs me. Whether it’s Adobe creating world-writable folders inside of Safari, Flip4Mac popping Finder windows on machines at the login prompt, or Quark just mangling permissions left and right, it’s just bad news. (Please note that these examples are not all current. Don’t go writing angry emails without testing in your situation first.)
It not only makes sysadmins hate you, it can, depending on the rules the customer operates under, make your application get banned from that customer’s site. Do you really want to – quite literally – force your customers to not use you? Didn’t think so.
So don’t be silly with security. Take a little time to check the state of a system after your install process is completed. Along these lines, don’t always make people enter a password. Yes, I know, it’s to prevent people from installing things they shouldn’t, but if their destination is writable by them, (i.e. their home directory – if you aren’t being inflexible in your installation destinations, this isn’t a problem), then the logic behind making them authenticate is pretty weak.
If you have to install things that will run at a higher privilege level than the user doing the install has access to, then yes, authentication is appropriate. But if I’m installing it to /Applications, and I have write permissions to install there, popping an authentication dialog is not “enhancing security,” it’s just “wasting time.” It’s also teaching people to blindly enter passwords. That’s never good.
I realize that you can’t get an ROI on an install, and that install writers get no respect, but a bad installer is like daring your customer to go to your competitor. Is that what you really want?
