A few years ago, user experience was mostly a unknown topic. Preached by Don Norman and Jackob Nielsen, user experience gained some traction and helped a few companies become extremely successful. Now everyone talks about it, because everyone knows how critical it is for the success and survival of a product to be user friendly, especially if it's a new thing.
One of the most critical aspects of user experience of a product (and one of the less valued) is its installation process. Nowadays most of the new and sexy software being produced runs in the cloud (formerly in the web) and requires no installation, which is one of the most publicized features of web-based products. But there are some areas of software where running exclusively in a browser is impractical, such as the software that runs behind the scenes powering web-based applications. This is the category where the OutSystems Agile Platform fits, and that's why it's OK for it to be an installable product.
Why is installation such a critical aspect of user experience? Simply because if the user can't use your installer, he won't use your product, pure and simple. And why is installing a product something we like to avoid? Because all the time and energy spent installing and configuring software seem like pure waste. That's why the best installation experience is no experience at all. Or very close to that.
In Debian based Linux distributions, installing software has traditionally been at the distance of a click or a single command. In the Mac OS, one way of installing software is by performing a simple drag & drop. In the new mobile ecosystems, installing apps is also a click away. In all these systems, the psychological resistance to installing software is virtually null.
Not all software needs only to be copied to be usable. Some software products require that certain conditions are met in its running environment. The task of verifying those conditions (and fixing them) is usually the installer's responsibility. If, for example, you're distributing a Java application, then it's expected that your installer verifies if a Java runtime environment is present in the system and act accordingly.
Meeting this (reasonable) expectation of finding and ideally fixing problems leads to the rule of thumb that the more complex the product or the more dependencies it has, the more complex its installation process is.
In the past, these increments in complexity would usually mean a worse installation user experience, bloated with more choices and buttons to press. But lately a new wave of installers has been appearing where most complexity is absorbed by the installers' intelligence, resulting in one-click installers even for products that traditionally required a lot of brainpower to overcome their laborious install (such as Oracle Database or Microsoft's Visual Studio 2012).
But building a simpler to use installer that takes care of everything can be a really tough challenge. For each prerequisite check the installer has to perform, its chances of failing increase. For each of your product dependencies the installer has to take care of, the chances of that dependency failing add up to the chances of your installer failing. In order to limit this complexity and chance of failure, developers in general used to leave the burden of preparing the system to the user. It was simply the case that we said this program requires X and it was the user who had to get X. Nowadays users are more demanding so the burden is again on the developers (and on their installers).
Due to the heterogeneity of systems and configurations, it's virtually impossible to anticipate everything that can go wrong, let alone test it! Let's say you're installing Microsoft SQL Server Express with your product... will you remember to check if the destination disk is compressed or encrypted? Because if it is, SQL Server will not install... and neither will your product.
Regarding installers, since everything can go wrong, the path to success is designing for failure. Building a better installer isn't ultimately about predicting everything that can fail during the installation process. It is about expecting things to fail and go wrong and, as much as possible, guide the user towards the resolution of the issue.
If errors and unexpected conditions are likely to happen, then you should treat them as first-class citizens when designing the user experience. This means that instead of failing miserably, for example with a message box saying "Error code -1" you can fail with flair, or at least fail in as stylish way as possible. Make the effort to look up what the error codes for outside programs mean and write sensible messages: not only will your users thank you for it, but it will save you a lot of support work in the long run.
Note however that in some parts of your product, designing for failure will not mean helpful error messages but rather redundancy and self-healing mechanisms. When building installers, it's just not practical to build such mechanisms for the infinity of possible problems.
If you get to the point where you can't even tell what went wrong, at least show the user that you care and that you're eager to help him get through: Systems fail and your users already know it. They've all seen the fail whale or the little TumblBeasts, and as long as you show that you care and are willing to help them, they will forgive you.
In a sense, an installation is a joint venture between two people that will likely never meet: the developer and the user. And the installer the written contract, the set of rules, that will govern this venture. As the developer, you should write the rules as comprehensively as possible to cover most ambiguities, while at the same time writing them in as friendly way as possible to buy in good will from the other partner when problems arise.
Now, what does Bacon have to do with any of this? Read on in my next article...