Whole document tree
8. Graphical User Interface
Everybody loves graphical interfaces. Many times they make our life easyer, and this way helps to popularize a Software, because the learning curve get smaller. But for the everyday use, a command with many options and a good manual becomes much more practicall, making scripts easy, remote access, etc. So the suggestion is, whenever is possible, to provide both interfaces: graphical for the beginers, and the powerfull command line for the expert.
8.1. KDE, GNOME, Java or Motif?
Better then a simple graphical interface is a consistent integrated desktop. And the desktops today in Linuxland are KDE and GNOME. Try to allways use one of them, or both.
KDE is the most destacado, offering a true consistent desktop, felxible, with an extremely elegant architecture, using components, intercomunication, performance etc. It is constantly evolving, and is developed in C++. Its applications have an familiar integrated look-and-feel, is light and mature.
GNOME also brings the integrated desktop proposal, but it is far from the maturity and ease-of-use of KDE. From the other side, is very well supported by the comunity, and good improvements are appearing.
Motif isn't an integrated desktop. It is a widgets library (button, scrollbar etc), plus a window-manager. It was born commercial, is mature and popular in commercial aplications. But is considered obsolet in front of KDE and GNOME, that integrates the desktop. Motif source code was opened by the OpenGroup and because that was renamed to OpenMotif.
Java is being used more and more for graphical interfaces, specially in server Software, where the graphics are only helpers to configuration and administration.
8.2. Web Interface: Access from Anywhere
Nowadays every desktop has a browser, and if your Product is a server application, the Web Interface is the right choice, because it lets a user aminister it from anywhere. But keep in mind the security and organization of your CGIs, because they use to be front doors for crackers. Web interface (CGI) is completely different programming paradigm. Try to understand it conceptually first, starting from "how a web-server works", "what is a URL", etc, to get on this without compromising your Product's security.
8.3. Wizards and Graphical Installers
Specially for a commercial Product, your Software must provide a graphical installer. Believe me, they are impressive in a demonstration, and CIOs love them.
More then just installation, a wizard helps in the initial configuration of your Product, collects info like activation key etc, and shows the developer license.
A wizard should not do more than this:
Ask which modules to install, experienced by the user as checkboxes.
Get the necessary info to build an initial configuration (the soul) for the Software.
Install the selected modules, that are in fact RPM files. Each checkbox must represent one or more RPMs, because each RPM is a indivisible (atomic) portion of a Software.
After RPMs instalation, change the configuration (soul) files (marked this way in the RPMs), or create some content, based on the data the user gave to the wizard.
So the wizard hides the RPM instalation and writes initial personalization. RPM is still responsable for putting all your software files in the correct places. This role should never be of your installer. Think that an experienced user (there are a lot of them in the Linux world) should be able to reproduce your Product installation without the graphical help, using only RPM commands. In fact, in big data centers, where people make mass installations, a graphical installer only atrapalha.
RPM provides tools that help your graphical installer insteract with them, like installation percentage viewer. Documentation for use are allways in the RPM manual (man rpm) and in the Maximum RPM book.