Objective

Due to the increased functionality of inspectIT that also has to be integrated into inspectIT user interface, there is a clear need to re-factor the current user interface. In the current form state, the UI can not support all the necessary operations that user has to perform, with the extended functionality. It is important that the improved UI organization provides easy integration of all new features that will come in the future, but with smallest possible changes on the already existing code.

Analysis

Coming soon?

Before going into GUI design re-factoring it is important to list all soon coming features, so that new design can easily support them:

• Disk data storage - https://confluence.novatec-gmbh.de/display/INSPECTIT/Disk+data+storage
• Configuration interface - https://confluence.novatec-gmbh.de/display/INSPECTIT/Configuration+Interface
• Load test comparison - https://confluence.novatec-gmbh.de/display/STU/2010-APM-ISE
• loadIT integration - https://confluence.novatec-gmbh.de/display/LOADIT/LoadIT+on+RCP

Eclipse out-of-the-box

The inspectIT UI is base don the Eclipse Rich Client Platform. The current UI does not use all provided out-of-the-box functionality that Eclipse offers. For example there is only one perspective, with one fixed view and many editors. This is not the classical Eclipse approach, because every RCP application usually has more perspectives and more views. Thus, it is clear that the re-factored UI can go into direction of specifying (if needed) more views and perspectives that can interact together.

It is necessary to list all the basic things Eclipse RCP is offering, so that design can focus on using them.

Each RCP application has a Workbench window. This window has a menu bar that contains the general application commands. Window can have several perspectives, but only one perspective can be opened at time. The perspective defines the tool bar, that has the perspective based commands. Each perspective can have number of views and editors. Views are typically used to navigate a hierarchy of information, open an editor, or display properties for the active editor. Views can also define an own tool bar, which can be used to control the look of the view, define view related actions, etc. An editor allows a user to edit an object, and is always associated with an input object. However, in inspectIT, editors are used to present the data.

RCP also has two ways of interaction with the user – dialogs and wizards. Traditionally Dialogs are used to enter a simple input, to select a choice from a list, to select multiple nodes from a tree, to inform about a success/failure from an operation, to input confirmations from the user, and so on. Wizards can serve the best when a more complicated interaction has to be performed, usually when it is consisted out of numerous steps that follow each other based on some condition.

A good input for re-factored design can be the look of the several open-source RCP applications, that can be found here - http://www.eclipse.org/community/rcpos.php.

Steps to perform

Before the actual design proposal, several steps need to be performed, so that general picture about the UI can be reached. The steps are:

• Define perspectives. Perspectives should separate, in the logical way the content or activates that user performs.
• Define shared things for each perspective, if there are ones. The shared things are needed by each perspective in oder to provide their functionality.
• Define non-shared things for each perspective. These are the only used in specific perspective.
• Define the views/editors for each perspective. The view can use both shared and non-shared perspective actions or properties, and should provide the way for view opening. Note that the view can be shared between perspectives, but in this case they can only relate to the shared perspective aspects.
• Re-factor the editors if necessary, so that they can fit new design.
• Define dialogs and wizards for each perspective.