Desktop applications

Layout of the main window in a PC application  

Layout of the main window in a PC application


The framework describes the basic structure of a screen and the behavior of a PC application. PC applications normally have the following areas:

  • Header with menu bar and tool bar: Provides general actions.
    • Example: Opening/closing files.
    • Example: General processing actions: clipboard actions; undo/restore.
    • Example: Help actions
  • Workspace: This area is freely available and can be structured such that it provides optimum support for the user's activities. Other areas are optional.
  • Status bar: The status bar is used primarily to display information. Furthermore, the information displayed can be manipulated directly.
    • Example: Information on the files open, such as the number of pages in Microsoft Word.
    • Example: Display of the input modes, e.g. the language set.
    • Example: Display of the progress of background processes, such as a the progress of a document being printed.

Areas in detail

  • The header area runs across the entire width of the main window.
  • It contains the menu bar and the toolbar.
  • All actions in the toolbar can also be found in the menu bar.
  • Common actions are displayed in the toolbar.


  • The workspace takes up all of the free areas.
  • It always has a dark background.
  • The workspace can be divided with the aid of DockableWindows:
    • The height and width of all DockableWindows are variable and can be adjusted by the user.
    • Containers that have an arrow at the upper right-hand edge can be displayed in their own windows.

Status bar

  • The status bar runs across the entire width of the main window.
  • Information is displayed in the status bar.
    • The arrangement of information should remain stable within the application.
    • The arrangement of information should be consistent across applications. For example, the zoom level of a view both in Microsoft Office applications and in Project+.


Normally, users receive feedback on their entries immediately. Simple messages are displayed via desktop alerts. The user can not interact with the desktop alert. If users are to have a selection option, dialog windows are used (see superjacent windows).

Error panel

Application messages can be listed in the error panel. The error panel is suitable in the following cases:

  1. If messages display states that cannot be immediately identified upon making an entry.
  2. If messages remain displayed for a longer period, until the user has changed the underlying state.
  3. If several messages (can) occur simultaneously.

The error panel can be used in addition to the standard solution for messages if the criteria (above) apply for a clearly definable sub-area of the application (e.g. PC Worx Engineer: only compiler messages are displayed in the error panel). If the criteria listed above apply to the majority of messages (approx. 90% or more), the error panel can also be used for all messages.

  • Messages are deleted as soon as they are no longer applicable. Ideally, the application will do this immediately upon the user changing the state that triggered the message. This can also be the result of an explicit user action, e.g. a compile procedure started by the user in PC Worx Engineer.
  • Users can filter messages according to message type.
  • It should be possible for users (if logical) to navigate to the "location of the cause" directly via the message. In this context, the location of the cause is a display in which the user can verify the cause of the message and, ideally, process it here directly.
  • The status bar indicates whether there are messages available in the error panel, in order that the user is informed even with the error panel closed.

Interaction pattern for navigation

The DockableWindow on the right-hand side shows details of the selected station (Project+ wireframe)  

The DockableWindow on the right-hand side shows details of the selected station (Project+ wireframe)

PC applications have a scalable main window. The workspace of the main window can be divided into the actual content area used for processing. In addition, DockableWindows can be used for providing context-independent information and data.

Multiple document interface in the content area

Contents can be divided in tabs. Examples:

In a web browser, tabs are available for various websites.
In Project+, the tabs contain various configuration contents: station overview, stations, results view.

Working with DockableWindows

Typical uses for DockableWindows are:

  • Structure-enhancing DockableWindows for project/document structures:
    • If a task requires a number of different elements which can be processed individually, a DockableWindow makes these elements available in an overview.
    • In the DockableWindow, users can select which of these elements are displayed in the content area.
    • The default position of structure-enhancing DockableWindows is on the left.
  • Master detail DockableWindows:
    • The content area is the master, while a detail DockableWindow displays information on an element that is displayed in the content area.
    • The default position of a detail DockableWindow is on the right-hand side of the application.
  • Selection DockableWindows:
    • A number of elements are made available for selection. These can be added to the workspace, within the DockableWindow, but not changed.
    • The default position of selection DockableWindows is on the left in the application.


Dialogs are subordinate windows. In these, users can specify and execute actions or answer a query. Through dialogs, an application can also provide information to users or display the progress of a process. These also include the standard dialogs, such as "Open / Save as …", "Search and replace" and "Print".

GmbH & Co. KG

Flachsmarktstraße 8
32825 Blomberg, Germany
+49 5235 3-00