Jump to content
  • Advertisement
Sign in to follow this  
  • entries
  • comments
  • views

Installer Client GUI #1 - The state of play

Sign in to follow this  


As I promised before, I'm going to throw up one or two posts about what I want to do with the Installer. First up is the client GUI system.

This topic is a bit of a stretch, so I decided to break it over two entries.

Tonight I'm going to throw out some ideas, thoughts and observations on the current state of GUIs in installers. I'm confident that everyone who reads this will have at some stage had to install an application on a computer, so hopefully everyone will be able to relate to what I am saying, and hopefully have an opinion.

In a day or two, I will post what I have in mind for the system I am putting together myself. Hopefully, I'll have enough feedback that I will have to either delay or rewrite that entry [grin]

Where better to start than:

Windows - Wonderful Woeful Wizards
By and large, if you're installing something on Windows, you're going to encounter a wizard.

We all know the generic template - splash screen (optional), "this app is going to install that app" screen, script compilation progress screen, license agreement, serial number entry(optional), change directory path, choose the components to be installed (optional), advert (thank you, iTunes), progress bar, "you're done/would you like to open the read-me file" screen. Tedious, at best. What typically happens here is that the user just keeps bashing the "Continue" button until the thing is done.

Wizards were designed to be about data entry - a way of grouping common, relevant boxes and options so as to help set up a feature properly. Where is the data entry on the majority of screens in a modern, Windows installer? Don't get me wrong, wizards still have their place in this process, but really only where they allow the user to perform pre-startup configuration on the applications settings.

There have been attempts to move away from this, toward an x-copy model of installation. However, for the most part these attempts have been based around one particular technology, e.g. Sun's Java Webstart, and Microsoft's ClickOnce. Unless your application is written in Java or .NET 2.0 these are pretty much not an option. Even where these technologies are available, take up can be slow, or it may just not be suitable for your application.

Also, many installers allow any user to put their application on any computer. There is little to no regard for system security. This is a double edged sword - on the one hand, users won't need to have administrator privilages to set up their IM client on their box (although the benefits of this are equally debatable [grin]), but that also leave it open for any application to be installed through a silent installer.

*NIX - Theres a GUI!?!
Commonly, Unix application installers don't come with a graphical method of installing an application. Usually, an authorised user will take the privilages necessary for the system in question, open a console (if using a window manager) and use one of the many systems available to automatically, and with very little fuss, download and install the application in question from one of a chain of registered repositories. The systems have their own ways of ensuring that everything necessary is there, and at the right version needed to work. There are graphical versions of these systems, but they don't deviate from the original idea massively.

For the most part, these systems follow the same pattern, be it RPM, DEB, etc. By and large, the installer consists of an archive, commonly gzip in structure, with an enclosed script that determines how the process works. Its a nice simple system, and for the most part it works great. The only issue that can be taken is the need to track down faster or backup repositories, but Linux users generally enjoy challenges like this. [/sweeping statement]

In some versions, distros such as Fedora Core have included an application that automagically generates a wizard for RPM files should you double-click on one. Generally, these suffer the same problems as the wizard structure on a Windows based machine. Thankfully though, we are spared a lot of the chaff that has been finding its way into those installers, since the RPM graphical wizard is an after-thought rather than a design decision. Unfortunately, its still another needless wizard that doesn't really serve much purpose in its role.

This is where you come in...
Right, I have an idea of what I want to do to try to muddle through some of these issues, and if possible help make the entire process smoother. But I know every user is different, so what are your thoughts? What do you like or not like about the various systems? Is there anything you would do differently? is there anything you violently disagree with me about?
Sign in to follow this  

1 Comment

Recommended Comments

If you're looking for suggestions, the only thing I'd like is that you don't limit the console install to *NIX. It's a pain to go through all the Windows GUIs changing the defaults when I'm trying to install nine different programs on each of 15 computers. Having a batch file that can specify even just the destination directory and selected components makes it so much easier.

Share this comment

Link to comment

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Advertisement

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!