Component Basics

Imagine that the SAP design system is one living, breathing organism and like us consists of its atoms and molecules. With that picture in mind, we can say that the components are its heartbeat, pumping life and functionality into all the digital products that will be built with it. But what exactly is a component? And why are components so vital?

Let’s embark on a journey to uncover these mysteries.

Before diving into the microscopic world of components, let’s recap what we already know about the SAP design system. The design system is a collection of design standards, guidelines, and a toolset of UI (user interface) elements that follow a specific design language. This toolset includes the components, patterns, floorplans, and templates.

Having all the above in mind, we can put on our lab coats and glasses and dive in. Like the atoms that create an organism, the components are the building blocks of the design system. Combining them, we can create a myriad of structures to shape the unique user experience our users deserve.
Below you can see some of the important characteristics that a component has:

• Modularity: Components are designed to be modular, meaning they can be used independently without dependencies on other components. This makes it easier to support and update them.
• Reusability and consistency: One of the primary advantages of components is that they can be reused across various parts of an application or even across multiple applications. This reduces redundancy and ensures consistency.
• Encapsulation: Components hide their internal complexities and expose only what is necessary, ensuring that the internal workings don’t interfere with other parts of the system. This encapsulation also makes it easier to swap or upgrade components without affecting the rest of the system.
• Specific function: Each component is designed for a specific purpose or function. For example, in a user interface, you might have components like buttons, sliders, or navigation bars. Each of these has a distinct role in the user experience.
• Interactivity: In digital design and development, components often have defined states and behaviors. For example, a button component might have different states like “hover,” “down,” or “disabled.”

Let’s look at the following example to illustrate the points made above: Imagine that you are working on an application that uses a button on one of its screens. If the application has multiple pages with multiple buttons, instead of designing or coding a button from scratch for each page, you will be using the same button design and behavior, ensuring consistency across all pages. The same goes for the different applications created within the same suite or the different organisations within one company.

Anatomy

The anatomy of a component describes the distinctive areas and elements a component has.

For example, a dialog component consists of 3 areas: a header, a content and a footer. There are few elements that are displayed inside of these areas – you will always find the title inside the header and the action buttons inside the footer. Depending on the usage of the dialog, the content may consist of different components such as text, text and image, form, and more.

The anatomy of a dialog

Variants

The component can have one or more variants depending on the purpose, structure, and functionality.

Let’s look at the dialog again. In the SAP design system, it currently has only two variants – basic dialog and draggable/resizable dialog. Both have the same anatomy, but some of their properties are different.

The variants of a dialog

States

States are visual representation of the status that each component or interactive element has after a certain interaction has been made. Using the correct state or combination of states helps users to recognise viable options and see where they need to act. Most states come out of the box from the components.

• Component state – corresponds to the interactivity and the visibility of the component.
• Interaction state – communicates the status of the element, corresponding to the phases of one user interaction with this element. The interaction state is only relevant for components that are interactive.
• Value state – Value states show the semantic meaning of the component. The value depends on its contextual meaning for the current use case.
• Focus state – The focus determines which component receives the user input when the user input itself does not supply positioning information (for example, keyboard input). This state is most important to keyboard users.
• Selection state – it is available only for the selectable components such as checkbox and radio button. It shows whether the component is selected or not.

Each state slightly alters the component but not drastically changes its appearance. The difference should be enough to distinguish its different statuses. Bear in mind that not all components offer all the states and there is a limited number of combinations between them.

The different states of a button

Responsiveness

Responsiveness in design ensures that a component looks and functions well on any device, from smartphones to tablets to desktops. It means that automatically adjusts to fit different screen sizes, providing a consistent and user-friendly experience.

Interaction Options

Interaction options include the numerous ways users engage with the components, including actions like clicking a mouse, tapping on a touchscreen, swiping, dragging, using keyboard shortcuts, and interacting via screen readers. All of them are some of the component’s building blocks, and they ensure that all users, regardless of their preferred or required mode of interaction, can navigate and communicate with the system effectively and intuitively.

Text and Globalization

In terms of globalization and text, all components should work in different languages and cultural contexts. If a component includes a text, it should be aligned with the experts whether the space is enough to accommodate it in its longest version and the text is culturally appropriate. If there is symbolic content, such as icons for example, it should also be culturally acceptable.

Accessibility

Lastly, a component must be accessible. This means that the components are usable and understandable by everyone, including people with disabilities. This means that all components should have features like screen reader compatibility and keyboard-friendly navigation, ensuring that all users, regardless of their physical or cognitive abilities, can interact with them and the application they are part of.