Description

Task panels are similar to dialogs; they are both used for self-contained tasks; they have Footer bars; and they sit at the forefront of the UI. Their main difference is their . Task panels are a non-modal alternative to dialogs that don’t block the entire UI.

Usage

Use a task panels similarly to how a dialog is used: for simple tasks that need a and button. Examples of tasks include small processes, procedures, forms, selections, settings, configurations, downloads and uploads; as well as, creating, maintaining, and editing simple items.

• You have a self-contained task that cannot be completed in the main content.
• Your task requires the user to see or reference their main content on the screen.
• You content would fill less than 1/3 of the panel. Use a Popover with a Footer bar instead.
• The task can be completed without looking at the main content area. Use a Dialog box instead.
• Your content is not a task or cannot be formatted like a task. Use a different panel type, or a different layout option for supporting content.

Anatomy

• Panel header, required – includes an icon, label, and a grey border line
• Content area, required
• Footer bar, required – a defining characteristic of a task

Header Style

Most task panel headers contain an icon (1A) and label (1B). The label describes and communicates what the task is. Because not every task will have an associated icon, use of a header icon is optional (C).

Avoid using generic icons or overly technical labels for task panel headers and footer buttons, otherwise risk the task and its intent not being clearly communicated to the user.

Footer Toolbar

Task panels are the only Contextual side panel with a Footer toolbar (3) because that is a key piece of formatting a task. This also establishes a strong connection with Dialog boxes and Popovers that contain footers of their own and may be used as alternatives to Task panels.

Footer toolbars in Task panels generally contain at least two right-aligned buttons: the finalizing action in an emphasized style button (3A), and a negative path action in a transparent style button (3B). Additional actions may be placed in the Footer if needed, but these are generally considered secondary or standard and thus use a ghost style button (3C).

Footer button labels should correspond to the name of the task and obviously complete it.

Themes & Styles

Task panels are identified by their grey headers, and like regular Panels, contain a content area with a white background. The Footer bar, the same used in Dialogs, appear in the same theme as the panel as of Fiori 3, and no longer displays as a dark one.

Behaviors & Interactions

Panel Access

Task panels can be accessed from a variety of points, be it via in the Application toolbar or Tool Menu, buttons in other panels, or from any component that may trigger an action. Always ensure any icon and all labels used to trigger the panel matches the task's name in the panel's header. If triggering a Task panel from a menu, always use an ellipsis in the menu item.

Interact with the Footer toolbar to close the panel. If users refresh or navigate away from the page, the panel should be closed without completing the task. close a Task panel by clicking outside of it. Never complete the task by some other means than the finalizing button at the footer.

Placement

Like all Contextual side panels, Task panels slide in from the right side of the UI. If a Panel is already on display, the Task panel will overlay on top of that Panel and stay in position until the task is completed or terminated.

While the Task panel is active, the Panel beneath it should not be closed. Ideally, when the task is completed and the Task panel is dismissed, the Panel that was momentarily covered should be visible and prominent again.

Panel Expansion

Task panels expand into larger Dialog boxes. This expansion rule is different than Panels and Sub-panels because Task panels are normally selected as alternatives to Dialogs when the rest of the screen needs to be seen. But if the panel were to be extended, then the screen would not be seen, so use a Dialog.

To facilitate this transition, place a secondary action for expansion in the Footer toolbar in a standard or ghost style button. When the Dialog opens, the user can transition back to Panel, or complete the task in the Dialog and close both simultaneously.

Alternatively, Task panels may expand into a whole other screen, like an Objec t Page. Task panels should

Best Practices

Format tasks like a pro

The Task panel is optimized for tasks that needs to be performed in place. A task is a series of actions or steps taken to achieve a particular end. Good tasks need to be simultaneously recognizable to the expert user and guide a novice one through an unknown process intuitively. Any function can be considered a task whenever it is like one. How to format a task? See below.

The goal of the task should be reflected in both the task panel’s header and the finalizing action on the Footer toolbar. The name of the panel should be clear, simple, and use as few words as possible. Typically, this should be a verb (the main action to be performed) followed by a noun (the subject being acted on). Example: Create [ObjectName], Select Column, Filter Selection, Set Default Values, etc.

The finalizing action’s name should coincide with the task name on the panel’s header. For example, if the task name is , then the finalizing action could be .

Avoid making the task name too long, too generic, or too specific that it alienates users unfamiliar with the chosen name. Ensure the finalizing button in the footer is wide enough to at least match the Cancel button’s width — this is especially important if the finalizing action has a short string (like ') and it creates a small button.

Establish order and direction in a task by arranging contents so it has a clear beginning and a coherent sequence of steps to reach the end. The sequence should follow real-world conventions so users can leverage their business experience instead of relying on in-app training or tutorials. Consider what users need to know first so that they can make key decisions after.

Never open a Task panel with any field in an error state – any validation should be executed after the user’s input. If a field is required, consider marking its label with a red asterisk instead of showing it in an error state before the error has been committed.

No one wants to spend their time fiddling on side tasks, so consider how to help users get through them as fast as possible. Speed up the pace and effort of completing the task by employing any of the strategies below:

• Use auto-complete and auto-suggest for Search fields, Select dropdowns, and Combo boxes.
• Have a recommended setting already selected in a list of Radio buttons or Checkboxes.
• Provide smart defaults in dropdowns based on the most likely or the most popular selection. For example, if there is only one item in a dropdown list, have that one be pre-selected. The default value should be what most users will want.
• Use devices like placeholder text, reference text, min/max value length limits, and mask input to restrict formatting and prevent users from making invalid entries. Read about the properties of an input field here.
• Auto-generate technical strings like unique IDs, codes, tags, and links and pre-fill them for the user. Ensure such strings can be easily copied (by placing a button to Copy) and pasted.
• Don’t ask for information the user has already provided somewhere else. Reuse this information to pre-fill input fields or make selections. It is a better experience to validate pre-filled information than having to type it all in again from scratch.
• Give users all the information they need to complete the task in-context instead of requiring them to navigate away to verify it. This helps a task become self-contained to the Task panel.
• Consider the most appropriate form of validation for the contents of the task. Check out Fiori’s Form Field Validation concept for more information.

Avoid using defaults for high-stake decisions that require the user’s attention. Any high-stake decisions that could lead to a loss of data, an irreversible consequence, or result in an overwhelming flow of information (like signing up for email updates or notifications), should not have a default option.

Task panels are the only Contextual side panel with a Footer toolbar because that is a key piece of formatting a task. The Footer toolbar gives the user an option to finalize the task or to terminate it.

The finalizing action should be an emphasized button and coincide with the name of the task on the panel’s header. To terminate the task at any moment, click on the negative path action, typically the Cancel button. The task will also be terminated if the user refreshes or navigates out of the page without completing the task. Don't implement any additional forms of finalizing or cancelling a task than the ones described here.

Always ensure the buttons in the Footer toolbar are enabled. If the user cannot progress because something is amiss, it is far better to run validation and mark problems with an error state immediately after clicking the finalizing button, than to disable the button and prevent the user from clicking them.

When a task is completed, and only the finalizing action button is clicked, the task’s outcome should immediately take effect. If the outcome does not produce any visible change in the UI, use a toast notification at minimum to communicate whether the task has been completed successfully or not.

Strive to make the outcome of a task reversible, editable, or removable – users should always be able to reverse selections, delete objects, and change settings by opening the Task panel again or in some other way. Should the outcome of a task not be manageable in such a way, then consider whether it should be formatted like a task or if it should be incorporated into the main content area and its workflow instead.

Specifications