The user-friendly concept is missassociated with a good GUI (graphical user interface). In fact, it is much more than that. In systems like Linux (with more server-like characteristics), the user measures how easy a Software is, mainly in the installation and initial configuration. He can even forget how easy were to install and use a certain product, but it will never forget that a Software package has a complex configuration and installation process. A migration or new installation allways will be a nightmare, making the user avoid it.
Imagine you'll install that expansive product your company bought from ACME, and realized you'll have to do the following:
To have a manual that shows the installation process step-by-step. We know that a manual is the last thing the user reads
Read some README files
Uncompress huge files in your disk (after downloading them from net our CD), to create the installation environment
Read more README files that appeared in the installation environment
Comprehend that the installation requires you to execute in a special way some provided script (the inconvenient ./install.sh
)
Uncomfortably answer some questions that the script does, like target directory, user for the installation, etc. To make it worse, it frequently happens in a terminal that has a missconfigured backspace
After the installation, configure some environment variables in your profile, like $PATH
, $LIBPATH
, $ACMEPROGRAM_DATA_DIR
, $ACMEPROGRAM_BIN_DIR
, etc
Edit OS files to include the presence of the new product (e.g. /etc/inetd.conf
, /etc/inittab
)
And the worse: Change security permissions of OS directories and files to let the product run OK
Sounds familiar? Who never faced this sad situation, that inducts the user to make mistakes? If your products' installation process sound like Uncompress-Copy-Configure-ConfigureMore-Use, like this one, you have a problem, and the user won't like it.
Users like to feel that your Product integrates well with the OS. You should not demand that the OS adapt himself to your Product (changing environment variables, etc). It must let the user Install-and-Use.
The Install-And-Use glory is easily achieved using a 3 ingredients receipt:
Understanding the Four Universal Parts of Any Software
Understanding how they are related to Linux's directory hierarchy
Aggressively use a package system, for process automation and leverage first items. In our case is RPM.
We'll discuss here what are these ingredients and how to implement them.