Introduction

Purpose

This document provides basic design guidelines related to the graphical user interface (GUI) in runtime of Comflow developed applications.

A uniform and harmonized appearance when it comes to Comflow applications is essential in order to give a professional impression and make the applications easy and intuitive to use. These guidelines should therefore be followed as far as possible when developing applications in Business Process Platform.

Who should read this document?

This document is intended for developers who work for a partner or a customer to Corzia, and who use Comflow for development of applications.

The document assumes that you have a good knowledge in Java and is well acquainted with Business Process Platform.

Presentation of content

The table below contains a brief summary of the content in each of the chapters in this document.

Guidelines related to the graphical user interface (GUI)

Used standards

In order to give the user an instant sense of familiarity, regardless of which system he or she is used to work in, guidelines related to

·     naming conventions, button sequence, and right-click details follow the MS Window standard whenever applicable

·     hotkey functionality follows the OS400 standard.

This means that non-frequent users, users who do not use AS400 but are well familiar with MS Windows, as well as users already familiar with AS400 all feel at ease when the guidelines are followed.

Naming conventions for actions

Button actions

The table below lists which names to use for the most common runtime graphical user interface (GUI) button actions. The list also explains when to use the respective button name, and how the button should work.

Right-click actions

The table below lists which names to use for the most common runtime graphical user interface (GUI) right-click actions. The list also explains when to use the respective right-click name, and how the right-click should work.

Guidelines for actions

Action properties

The table below lists what properties should be specified for the respective action.

* Comment about Confirm Delete: In some cases, for example when the impact of the operation is severe, it might be better not to have the function key Enter on Confirm Delete.

 Button actions

The table below lists additional information to keep in mind when working with button actions. 

About main operations (function key Enter)

“Main operation” in this context refers to the action that is the most likely next step in a user controlled sequence. Example: The user selects Edit for a record in a list to enter the record details. The most likely next step is Save, why it will be considered as the main operation.

The main operation should always be

·     displayed as a button

·     located to the left

·     Associated with function key Enter. (In other words, when pressing Enter, the button to the lower left in the graphical user interface (GUI) should be activated.

Normally, there should not be more than one main operation action in a portlet, except when the Add button is combined with OK, Save or Search. In rare situations, you might need to add two actions that normally use function key Enter to the same portlet. If so, specify function key Enter for the action that most often is used as the next step. If possible, locate the other button inside the segment where it is used, instead of at the bottom. If not, the button will sometimes be to the left, sometimes to the right.

About OK, Save and Cancel buttons

The OK, Save and Cancel buttons can co-exist in three combinations:

·     Save and Cancel: Use this combination in portlets where a user works for a very long time with repeated updates.

·     OK and Cancel: Use this combination in portlets where a single update of a record is usually done quickly by the user (who wants to return to the previous view once the update is made).

·     Save, OK, and cancel: Use this combination in situations where the characteristics of the both previous examples can co-exist (see figure below).

Example

The example below displays how Save, OK and Cancel can be combined. Note that the Cancel button is located as the second button to the left, after the main operation OK.

About views single Close or OK

Some read-only views have the need to only have the ability to be closed and nothing else. In these cases a Close or a single OK (without Cancel) should be used.

When the view is the first view in the function and there is no Find button, then you can use a Close button. 

If the view is not the first view, a Close cannot be used (because you want to jump back to previous view). In this case an OK button should be used (analogous to application ‘About’ dialogs in MS Windows).

Tab to buttons

Note that you can tab focus between open fields and buttons. If you have the focus on a button, you can execute that button by pressing the space bar. The Enter key will work on the button that is mapped with Enter.

Right-click actions

The table below lists additional information to keep in mind when working with right-click actions. Note that the operations are listed in the same vertical order that they should be presented in the portlet.

If there is a need to use other right-click options than the one listed above, these should be located between the Copy and Delete/Delete… right-clicks.

 Row data actions

A row data action should always correspond to the first right-click action, that is, the right-click action that is displayed in the top of the vertical right-click action list.

Examples

The figure below displays the right-click actions for a browse segment. The row data action in this case should be Open.

The figure below displays the right-click actions for a browse segment. The row data action in this case should always be Copy...

Hotkey actions

The table below lists which hotkeys to use for the Cancel, Close and Refresh actions.

In addition to the list above, F4 should always be used for prompt.

For the hotkey Enter, see more in chapter “Button actions”.

Guidelines for toolbar icons

The following guidelines apply for toolbar icons:

·     Minimize the number or toolbar icons

·     For a portlet with at least one browse segment, always use the following toolbar icons:

·     For a portlet with at least one detail segment, always use the following toolbar icons:

·     The often used Save State icon  is configured in the site definition file.

Related information

The table below lists documents or resources with useful and related information.

Swedish naming conventions for Actions

The table below lists the Swedish naming conventions for actions.

 Workflow design

Design workflows as interaction flows

In order to create a workflow that can be easily understood by others, design it in a grid based on interaction steps and possibly sub functions and NOT in just screens. This sets you on the right path to show the user the right data and let the user do the right action in the flow and perform the actions step by step. Since one portlet can be used in multiple points in a workflow, where possibly layout control is used to hide not wanted information, you can design few portlets and let them have their right context in multiple locations in the the flow.

Below you have an example of an application that has 6 different steps, where data is handled in three different functional scenarios. After some initial selection steps, you can perform 3 variants of functional step. After one functional step sequence, you can also perform a sequential functional step sequence. The design makes it quite clear what is happening in the flow, so it is easy to understand how the function is working.