Description

A workspace is a typical work area based on a role a user might have or may want to focus on. This is an organization pattern that allows the main workflow of an app to be divided into multiple portions with their own dedicated space. Each workspace may contain its own floorplans, page tabs, split screens, views, and other space-defining components, such as menu bars, toolbars, contextual side panels, and dialogs.

All workspaces inside a module app contribute to the same object file. They come short of being their own module app because they don't make sense as stand-alone applications and don’t produce their own object files.

Usage

Use workspaces for support content and sub-workflows when the main content area has grown in complexity and acting in-line and in-place is no longer feasible. Or, when smaller support layout options have been exhausted or outgrown.

• Your workflow is too complex for the main content area, too different to fit under a tab system, or too big to fit inside dialogs.
• Your main workflow can be divided into self-contained sub-workflows that can be housed in their own functional areas or spaces.
• Your intended workspace will produce new or independent object files that will be named and saved in the application's file repository. Use module apps instead.
• Your intended workspace could be a standalone tool that can benefit other object files. Use module apps instead.
• You intend to show two screens/floorplans/workspaces at the same time for whatever reason. Use a flexible column layout or a split screen instead.
• You will use the same global menu toolbar across all workspaces. Use tabs instead.
• Your workspace is just a different representation of the same content. Use views instead.
• You have a strictly linear workflow. Use wizards instead.

Anatomy

1. Header / Toolbar

Workspace headers can take different forms to support its content and workflow. Object file creation pages generally use a menu bar, non-creation pages use a title toolbar, and object pages use a header toolbar. Do not combine two different styles of headers, or create a hybrid using elements from different types. Workspace headers should be consistently used and applied, and their structure should be recognizable to users.

2. Workspace Switchers

Workspace switchers can take one of two forms, depending on the number of spaces available in an app. When two workspaces are available, use a segmented button. When three or more spaces are available, use a select dropdown component.

Switchers are placed on the left-most side of the global menu bar under a ‘Workspaces’ section, and their toolbar placement should be the same across all workspaces. Users should be able to recognize a space by its name and anticipate what they’ll find in it before clicking on it.

3. Container Pages

The container page of a workspace occupies the full content area of a screen. This allows them to have their own floorplans, page tabs, split screens, views, and other space-defining components, such as menu bars, toolbars, contextual side panels, and dialogs. However, container pages, and workspaces by extension, do not occupy or make up another level in the module app’s breadcrumb.

Only one workspace may be open and visible in the screen at a time, and creating situations where they can be compared or consumed next to each other should be completely avoided.

Different colors for the background can be achieved using the sap.m.PageBackgroundDesign enumeration, or by hard coding their values if not using UI5. The default background for a workspace is , resulting in a light grey background; or resulting in a white background. Follow the link to see API references or see Specifications for exact color values.

The underlying grid of becomes its main structural system. As with all other Fiori-based UI design, workspaces employ a 1rem (16px) grid system. This base unit allows consistent and predictable content layouts, sizing, and zooming. The grid system may be exposed or hidden from users.

Best Practices

Dividing a modular app into multiple workspaces has many benefits but may also lead to a range of usability problems that confuse and disorient the user. Consider the following best practices when introducing workspaces to a module app.

Define and Optimize Workspaces

Define workspaces around common tools, goals, themes, or functions expected by the users who will use that module app. A workspace can appeal to one or more user roles/groups.

Decide which space makes the most sense to act as the main content's space:

• The main space houses the main content.
• The main space acts as the standard or default way of initiating the workflow of that module app.
• The main space is listed first on the switcher and in the module app's empty state.
• The main space is supported by all additional workspaces.

Optimize the experience by leveraging the module app's empty state/introductory screen. This screen provides alternative ways to begin the workflow that may begin from a different workspace as the starting point (that is, start a story by connecting to data first, instead of story building. Or, start by creating dimensions instead of the model). However, in all those scenarios, the main workspace still retains the priority.

Adopt a Flexible Workflow

Module apps with workspaces follow a matrix organization, as opposed to a sequential or hierarchical one. As such, the notion of a strictly linear workflow for those kinds of apps are naturally challenged and should be avoided.

Workspaces afford the user a large degree of autonomy and flexibility to decide which part of the workflow to address first and how to proceed from that moment onward. This principle is similar to the third heuristic of UI design, which grants the to explore without being hindered or limited.

Choose Simple Navigation Patterns

Workspace switchers, as described above, provide a simple mechanism for navigating between workspaces. When mapping out user journeys and flows, consider making workspaces as self-contained and self-reliant as possible to reduce the interaction costs of having to go back-and-forth between spaces to complete a single task.

Occasionally, and only when appropriate, consider contextual transition points to different workspaces. Transition points are buttons or actions that automatically navigate the user to another space; or, any messaging component or help text that prompts the user into making that switch themselves.

Use the Same Saving Pattern for all Spaces

A module app should use the same saving pattern between all its workspaces. Because all workspaces remain in a perpetual ‘open’ state, avoid creating scenarios where some require a finalizing action, while others do not.

Likewise, avoid scenarios where a workspace cannot be accessed again after a task has been completed in it. Ideally, clicking on ‘Save’ in one space should also save the current state of all other spaces.

Avoid Workspace Comparison

Workspaces are not conducive to comparing items between spaces, as the back-and-forth places undue burden on short-term memory, increasing cognitive load and interaction costs.

If your intention is to compare items between workspaces, then consider other layout options that are more suitable for this, such as flexible column or split screen layouts.

Specifications

For apps with two workspaces, create switchers by adding transparent (ghost) style segmented buttons in text-only style on the left-most side of the menu toolbar. For apps with three workspaces or more, use a select dropdown. Place switcher under a header labelled Links to specs found below.

Page Background

Segmented Button Switcher

Select Dropdown Switcher

Dropdown List

Links and Resources

Button

Segmented Button

Segmented Button

sap.m.Segmented Button

Select

Select

Select

sap.m.Select

Support

If you have any questions or feedback about this page, please contact our team. For further information and questions in regards to the Design System, please visit the DNA Design SharePoint.