Description

Views offer alternative perspectives of the same content. They also help users make new associations between an object and its key attributes and characteristics. Users can switch views in order to see their content represented in different ways, such as lists, cards, grids, tables, etc.

Views vs. Modes

Although often referred to as a “view modes”, changing a view is not the same as changing a mode. While individual views may trigger their own modes, views are not modes in themselves.

Modes

Modes are different interpretations of user input by the system. Depending on the active state of the system, the yields . A classic example of a mode is the caps lock key. Different text cases can be achieved with the same keyboard input depending on the mode of the keyboard.

Views

Views are alternative representations of the same content or data; regardless of which view the user is in, the should result in the . For example, clicking on a list item in a list view, and clicking on a card in its alternative card view results in selecting the same item.

View changes are effective because they provide users with new insights on their content or data; and encourage different ways of interacting with it. When done properly, view changes promote a high level of flexibility and ease of use of a tool or space. Ultimately, views are effective ways of accommodating different kinds of thinking and working and empowering users to decide the best way for them.

Usage

Use views strategically and with purpose, and avoid sub-levels of view switching inside larger views. This leads to a “view-inception” effect that makes it harder for users to orient themselves and remember where they may have seen something in the past.

• You want to represent main content in different ways.
• You want to interact with main content in different ways.
• You intend to create entirely different areas of content. Use page tabs instead.
• You want to create entirely different functional spaces. Use workspaces instead.

Anatomy

View Switchers

View switchers are made with segmented buttons. Use either text-only or icon-only styled buttons as recommended by Fiori. View switchers should be grouped together and placed in the section of the application toolbar if one is being used. If not, place view switchers at the highest-level toolbar available in that screen.

2

do

false

Use segmented buttons in icon-only or text-only styles, as prescribed by Fiori for view switching.

dont

false

Don't separate views into single individual lite (transparent) buttons in the toolbar, or use icon + text combinations.

View Content

Because of their high customization, responsive adaptability, and the ability to meet accessibility standards, prioritize Fiori components to build up view content. Otherwise, consider how custom designed components can meet these same standards.

Best Practices

Although there are many benefits to offering multiple views of the same content, they can also be disorienting and cause a range of usability problems related to discoverability and findability. Consider these best practices to make view switching a smooth and successful transition.

Offer Clear Visibility of Current State

All possible views should be clearly labelled, identifiable, and positioned next to each other. The current, or active view, should be well indicated and apparent to the user.

Design for Recognition

Users should be able to recognize their data or content immediately upon switching between views. The content between them should be self-explanatory and instantly recognizable; expect users to recall something from one view in order to successfully operate within another.

The faster users can recognize their content, the faster they will proceed with their workflow. Help users make connections between views by providing enough cues:

• Visual Cues
  Applying labels, icons, and colors consistently, preserving text and numeric formats, etc.
• Interaction Cues
  Persisting selections made and buttons pressed; maintaining effects from triggered actions, etc.
• Conceptual Cues
  Representing the same objects at the same level, making the same groupings and associations between objects, following the same sequence of steps to a task, etc.

Design for Completeness

Because views are alternative ways of carrying out the same workflow, users choose which view they will work on based on preference. Tasks, functions and actions may look different, but a view would be insufficient or incomplete if it didn’t offer feature parity between both views.

If this isn’t possible, identify the core functionality of a workflow, and ensure that can be delivered as a minimum viable scope until the feature parity can be met. is created when views are not equally supported, and users cannot carry out their entire workflow in their chosen view.

Design for Value

Working in one view cannot be more difficult than working on another, and users should not feel disadvantaged when doing so. Users should be able to accomplish the same workflow, across all views, with the same level of ease and the same degree of success.

Views need to offer more than a simple cosmetic change — it should provide new insights, better understanding of an object and its data, or new ways of interacting with content. If a view cannot be inherently valuable beyond a new look, then it adds unnecessary complexity to a design.

Specifications

For views that will affect the entire main content area, place segmented buttons in the global menu bar. Create view switchers by adding transparent (ghost) style segmented buttons in either text-only, or icon-only styles. Links to Fiori's specifications are found below.

Links and Resources

Fiori Guidelines: Button

Core Visual Design Specifications wiki: Segmented Button (Fiori 3)

DemoKit: Segmented Button

API Reference: sap.m.SegmentedButton

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.