UI controls are the basic building blocks of any graphical user interface. Through controls, we express the interaction options to the user and we communicate the state of the system. Controls are combined into composites and patterns and are finally arranged on a screen.

Having a sufficiently complete and powerful selection of controls is a requirement for any UI technology. On the other hand, a too wide variety of controls can make it difficult for a user to understand and learn the interaction standards within a design system. An average user might actively know 20-30 controls. This comprises simple controls such as buttons, links, labels, and input fields as well as more complex controls such as tables, a date picker or a rich text editor. However, complex controls usually build on top of the existing simple controls using the standards that have been introduced there.

Question 1: When to build a new control?

Why do we need controls? In the first place, controls establish a vocabulary for the interaction between the system and the user. When used consistently, the user knows beforehand that a button will trigger an action and that a link will bring them to another page. This behavior was established more than four decades ago since the introduction of the graphical user interfaces in the seventies. As with any language, the control language is based on conventions that need to be followed to be understood.

Question 3: How to design a new control?

Another important aspect of controls is the fact that by encapsulating complex functionality in a reusable piece of code, the development of graphical UIs can be simplified and accelerated enormously. Complex functionality can be built once and used in many different places by just defining some properties of the control or by binding specific data sources to it. Changes and enhancements can be reflected into all places where a control is used if the interfaces remain stable.

Question 3: What is needed to implement an enterprise-ready control?

In the following article I want to look at these questions and provide some answers that should help you make the right decision when confronted with the challenge: There is no control for that?

When to Build a New Control?

UI5 Explored app showing examples for all available controls currently contains more than 200 controls.

Every designer has encountered the situation where the set of available controls at hand were just not sufficient. Typical reasons for identifying the need for new controls are:

1. “If I had a control that could do that, then the user could make changes much easier.” The user expects the data to be displayed and the action that is required to do so to be done in a natural way and this is not supported by standard controls.
2. “I don’t know how I should visualize that without the right control.” The data that needs to be communicated to the user is very specific and the information you need to convey requires a specific way to be visualized that is not supported by existing controls.
3. “If I do that with the standard controls, it will look bad.” The interaction can be covered or the data can be displayed by standard controls, but in an artistically unsatisfying way.
4. “Using the standard controls will make this very cumbersome.” The interaction can be covered by standard controls, but this will reduce effectiveness and efficiency and it might increase error rates.
5. “I have a great idea how that interaction could be done in a cool way.” Maybe there is a way the interaction could be covered by a standard control, but there is a need to showcase certain qualities such as innovation, difference, coolness, etc. with the application that can be expressed through a specific control.

We can distinguish between the reasons that are driven by the user’s needs and those driven by the designer or business. If the control improves usability or merely enables the appropriate visualization of information or a function, we think about a control that will support the user’s needs. If the control is meant to increase the coolness factor or the marketing value of an application, then this is driven by design or business interests. Design and business interests are valid and can be important drivers of innovation, but without addressing the user’s needs they remain simply eye candy and will most likely wear off in daily use and might even become an issue in the long term.

Example: A team has a list of elements—e.g. training material—from which the user should be able to select the relevant items for their curriculum. Using a list would be the standard option to help the user to easily scan and compare the contents and then sort and filter them in a known and easy way. But as this is perceived as being boring by the team they decide to invest significant capacity into building a separate visualization for the training materials. They work with users to validate that they like it, but the cross check reveals that the list performs just as good. The investment to create a new control is not motivated by a user need but by the decision of the team.

Introducing a new control should always be motivated through user needs. And it’s important to fully understand the underlying needs early on before focusing on a specific solution. Often, we tend to pick a design solution before we full understood the need. If you have a hammer, everything becomes a nail! As a result, we might identify the need for a new control that we design and implement with great effort to solve problem that wouldn’t exist if we had understood the actual user need.

If you come to the conclusion that a new control is needed, you should still validate your approach upfront before you base your design on the new control. Ideally, you would have alternative options including those using standard controls and run a comparative study (A-B-testing).

Why should you be very conservative introducing new controls?

• TCD – Creating a new control is an investment that is continuous. You have to invest in a new control initially when you design and implement it. Depending on the complexity of this control the investment might be significant compared to the entire investment into the frontend development for an app. There are numerous aspects that need to be taken into account both from a design and a development standpoint that will be detailed out in the following sections. More unpredictable is the long-term investment that comes with maintaining the control. Every release you will have to invest into testing and updating the control to adjust API’s, theming parameters, new interaction features that have been introduced into the standard that you haven’t considered, browser changes, and other incompatibilities. When using standard controls, both, the upfront as well as the follow-up investment, isn’t necessary as SAP development takes care of maintaining these controls for you.
• Skills – Creating controls requires specific skills both on the design as well as on development side. In environments where new controls are developed regularly, these skills are easier to find than in environments that focus on application development and web development in general. Experienced designers will be able to consolidate a complex requirements profile including user requirements as well as product standards such as accessibility, security, and performance into one coherent picture that is also consistent with the surrounding standard controls. But this requires a certain level of practice and experience. Some of these aspects will be described below.
• Usability – In the introduction I talked about the vocabulary of controls that regular users know and have mastered. A regular user actively knows about 20-30 controls. Of course, when a user interacts with a specific tool on a regular basis they will also acquaint themselves with the specific controls they find there, but our business users have their focus on the business side and not on the details of a digital tool. They need a tool that helps them to complete their tasks and many of them have to switch between different tools on a regular basis. In the real world these tools are coming from different vendors. Users need to be able to make use of their experience across applications and vendors as much as possible in order to work efficiently. Therefore, we rely as much as possible on standard controls that are commonly used and established in functionality and semantics and play well together with other tools. Only where we see a significant improvement in usability do we introduce new controls that best support specific business scenarios. I believe that this is in the interest of our users, customers and partners, and this is also what we would recommend in customer or partner projects.

Why should you take the risk of building a new control?

• Usability, of course, is undeniably a good reason. If there’s no way to achieve a usable solution with standard controls, you need to extend the control library on your own by either extending existing controls or by building new controls from scratch. The same is true if you can find opportunities to significantly improve usability. But beware, this can be a trade off if you do, for introducing new controls increases the cognitive load for the user! The user has to actively understand and learn the new control and if it’s not consistent with existing controls this might result in a negative effect.
• Innovation is another strong reason that justifies building a new control. There’s always inherent risk with innovation since it’s an unproven approach that you choose to follow. But you mitigate that risk by doing sufficient user research to make sure you solve the right problem and that the control you create really improves usability. Such improvements have a good chance of establishing themselves and eventually, they can become standard controls as well. However, avoid building new controls just for the sake of being different or cool as such “innovations” can become annoying in daily work.

Building a new control is an investment decision that has to take into account the benefits, costs and risks. Design plays an important role in this equation and should be assessed before starting development. As yourself:  What are the design options? What is the usability impact locally vs. globally? What is the impact on the experience and attractiveness locally vs. globally?

How to Design a New Control?

The form control in the UI5 Explored app displayed in the touch-optimized cozy density factor.

As mentioned above, designing a control for enterprise software is a complex task that requires a certain amount of upfront investment as well as experience on the design side. Above, we already discussed the reasons why creating a new control is an investment that has to be evaluated wisely.

If this evaluation has happened and it’s clear that implementing a new control is the only viable solution, you should take into account the following aspects.

Solve the Right Problem

In the use case that you want to solve, you identified interaction requirements that weren’t met by any of the existing controls provided by SAPUI5 (an overview of all controls per release can be found in the UI5 Explored app). Make sure you understood the problem the user has in their task and explore alternative solutions.

Don’t stick to the first control that seems obvious, but force yourself to continue questioning the solutions and track down the actual issue.

Use the Right Metaphor

In many domains there are specific established terms and metaphors. Try to understand the language of the users and their mental model to provide solutions they understand. Especially, if you think about rich visual controls, it’s important to use the right language and metaphors to avoid misunderstandings.

Cover as Many Use Cases as Possible

Once implemented, you also might want to use the control in other contexts. Therefore, it’s important to stay generic or foresee possibilities to abstract the control from the domain, e.g. provide the possibility to exchange icons, colors and any type of symbolic elements.

In order to be prepared, cross-check with other teams or experts whether they have encountered similar requirements as you want to solve and learn their specifics.

Consistency with Other Controls and with User Expectation

Make sure that the control you are designing fits to the other controls in the library you are combining it with. This means that all aspects of the design should be in harmony:  geometry, interaction, micro-interaction, etc. Therefore, study the controls in the control library and understand how they are designed and try to embrace the approach they’re taking. Try to make use of existing controls and combine them into your new control where ever possible.

Design for the Extreme

We all love to design for the ideal data, with short words and beautiful images, all fields filled, none of them too long or too short. Of course, it should be obvious that designing with “lorem ipsum” is not an option when it comes to business software – it’s essential to design with realistic data.

• Realistic data is data of varying length. Ask yourself: What happens with very long or very short content?
• Is there missing data? What happens if nothing is shown? Is the absence meaningful?
• What about data that encodes information? Ask yourself: What is the meaning of the data shown? Some customers use IDs to encode hierarchies and relationships.

Make sure your control can handle more data than usual by wrapping or overflowing and less data than usual by managing the white space.

Design for Content

We want to make sure the content reaches the user undistorted and clear. Explore all options to format and emphasize the content and clearly communicate the meaning. The SAP Fiori design offers many means to treat the contents appropriately (bold-facing, semantic colors, etc.).

Responsiveness or Adaptiveness

SAP UI5 is one of the most comprehensive control libraries on the market that support different devices ranging from large screen displays to mobile phones. The responsiveness, meaning the capabilityto automatically adjust to the different device types, but also to different window sizes in an intelligent way is a key aspect of this control library and we are continuously investing into improving the responsiveness of the various control.

Example for the responsive behavior of the form in SAP UI5.

Any control should provide the optimal usability on the given platform taking into account specific space and interaction requirements. In extreme cases this might even change the interaction completely when running the same control on a phone vs. a desktop computer. With this capability, we are laying the foundation for a design that can be done once and then run on any device. However, there are reasons why an application still needs to be adapted for a specific device type because the use case differs between devices. In these cases, a programmatic adaptation is possible and should be applied.

It’s crucial, that your control respects this important aspect of SAP UI5 and is designed in a way that it is optimized for all three major device types: desktop, tablet and phone. This means that you should enable the content density, touch interaction, and dynamic layouts. Furthermore, you should look at how the control can be used on the different devices and whether this contradicts to platform standards or standards within SAP UI5.

Even if you think your app will only be used on a desktop, being a browser-based application you can’t avoid that the user will run it on a different platform and they might benefit from it, too.

Cozy and Compact / Touch and Keyboard

One aspect of a multi-platform responsive control library such as SAP UI5 is the optimization of the content density. On desktop computers, users expect controls that are dense, offering a lot of information in a smaller space. A mouse pointer is way more precise than a finger.

While a finger needs at least 2-3 rem as touch target, a mouse can easily operate on the level of few pixels. Also, as mobile devices are often used in difficult lighting conditions and on small screens, the need to include larger controls and more white space is necessary to make the contents of the UI readable.

For that reason, we have introduced the content density:

• Cozy
• Compact

For a few controls (currently only the analytical table) we even offer a condensed version that is extremely space efficient removing almost any white space.

In order to optimize your control for different interaction devices you need to offer specific style classes that adjust the dimensions in your control to the compact mode. The default style will always be the cozy mode.

Theming

SAP Fiori provides a visual design that is implemented as a theme. The first theme was called Blue Crystal and featured a light blue color set and later the background was toned darker to create more contrast and tension on the UI. For SAP Fiori 2.0 we created two theme versions: Belize and Belize Plus, one with a lighter color set and one with dark contrasts.

However, we know that many customers want to communicate their brand also in the software that is used by their employees applying their colors and CI. Therefore, these themes are based on theme parameters. This parameter structure is used throughout the entire user interface to apply colors to all aspects of the controls.

While the structure is fixed, the color values within the structure can easily be modified by just touching the base colors. The new theme then can be calculated using LESS parameters. This means that any customer can easily modify the colors of the theme in their system without changing the structure or coding of the UI, thus making sure that it won’t be affected by upgrades. Tools such as the theme designer can help the customer to change the theme in a visual mode.

In order for your control to play well with the standard controls you must make sure that you are following the rules that enable your control to be themable:

• Don’t use hard-coded color values but theme parameters
• Don’t use font names
• Don’t use pixel values but rem as a measure based on font size
• Don’t use semantic colors (red, orange, green) as CSS codes but by their semantic names
• Chart color palettes should be used for controls with multiple color values

In this excellent article you find a detailed instruction on how to develop themable controls for SAP UI5.

Accessibility

In order to be successful, we believe that everyone should have access to our tools. Whatever can be done to support users with special needs should be done. SAP is continuously investing into making SAP UI5 one of the few control libraries for enterprise software that is accessible and compliant to the Web Content Accessibility Guidelines (WCAG) 2.0 (please refer to the accessibility status documents through your account executive). Any extension to the existing control set should comply to the same accessibility standards in the same way as the common controls.

Accessible controls should support:

• keyboard interaction,
• screen reader support (according to the ARIA standard), and a
• high contrast black (HCB) theme.

In addition, making use of font-size-based measures such as rem will allow users to use the browser zoom to dynamically enhance the size of the application contents. Here you find a good collection of accessibility-related resources as well as a good overview article on experience.sap.com.

Keyboard Enablement

Just in case you didn’t pay too much attention to the accessibility chapter I want to stress the importance of keyboard enablement once again.

In many cases, business applications are used on a regular basis. The more important the productivity and efficiency the more important the possibility to interact using the keyboard instead of the mouse to navigate within the application.

SAP UI5 controls support the definition of keychains and all controls have an inbuilt logic to reach any function using the keyboard (see this Open UI5 documentation).

• Make sure selection and action triggers work properly (Space, Enter)
• Make sure your control supports arrow key navigation and tab navigation
• List-like controls should support list item navigation (Up, Down, Home, End, Paging)
• Consider fast navigation (Shift + F6) for very complex controls or compounds

Globalization and Localization

It sounds very obvious, but the implications are huge. The users of your applications most likely will speak different languages and you need to make sure your control is prepared for all of them.

One of the aspects of globalization is the enablement of right-to-left mode which is natively enabled in SAP UI5.

Technically, SAP UI5 offers multi-language using either resource files or backend texts.

From a design perspective there are several aspects you need to take care. They are :

• Different languages differ in the average length of their expressions. While your control might easily be able to display the label in English it might just show a fraction of the same expression in French or Italian (read more on the variance in text lengths in translations). This effect of truncated labels can often be observed in translated user interfaces and can be a real issue if the culture in the customer’s country is very sensitive to such effects as this can be the case with some languages.
• Different languages have different grammar. Especially those UI texts that include dynamic contents such as numbers or variables into a sentence or sub-sentence can lead to unwanted effects when translated (e.g. “## days ago” becomes “il y a ## jours”). Especially when such expressions are concatenated, translators need to know the right context of the entire sentence. We tend to dismiss such expressions in favor of label-value combinations to avoid such issues.
• Some languages not only have longer average text lengths but also longer single words. In German for instance new words are created by concatenating other words (“company code responsible” for instance is “Buchungskreisbeauftragter”). In many cases, you won’t be able to programmatically determine the correct word wrapping for such words, which will thus lead to broken layouts or truncation.
• You might want to solve length issues with abbreviations, but also this is something you should handle with care. Abbreviations might have different meanings in different languages and even within a language the meaning might vary between domains, which might lead to issues in translation. In general, abbreviations are not a good solution as they usually require additional cognitive processing when decoded.

It’s strongly recommended to validate your controls in different languages and take the variance in text and word length into consideration. Avoid creating sentences by concatenating strings and variables and avoid abbreviations.

Cultural awareness

It might seem a bit far-fetched to raise the requirement of cultural awareness when it comes to the development of a new control. However, especially when it comes to such interactions that include symbols and metaphors it’s important to make sure none of these metaphors contradict norms and values in the cultures you want to address.

In the user interface, symbols are usually represented by icons. SAP UI5 uses icon fonts to provide scalable vector-based icons. These standard icons already were checked against cultural implications and we have eliminated those that held any potential for conflict.

In our research in literature and in interviews with designers from different cultures we identified the following basic guidelines for icons:

• Avoid icons that show gender-specific aspects
• Avoid icons with religious symbols
• Avoid icons with currencies

Other such considerations can hardly be generalized so you always have to think through the scenario and different aspects of it in order to assess appropriateness and cultural implications.

Example: When creating the icon for leave requests we thought of the most popular reason for leave, taking a vacation, and we created an icon with a palm tree and a hammock. What we completely missed out on was the fact that there are many other reasons for leave, such as sick leave or bereavement leave. From that perspective, the palm tree was of course completely inappropriate.

Literature lists many other cultural aspects that might have an impact on the optimal design, such as the cultural dimensions by Hofstede.

• Power distance
• Collectivism vs. individualism
• Femininity vs. masculinity
• Uncertainty avoidance
• Long vs. short-term orientation

In her interesting and entertaining article Nehal Shah explains and illustrates how these dimensions can be applied to the design of commercial web sites. If you are designing for global customers in domains that might strongly react to such aspects this will be a good read.

Documentation

We provide extensive guidelines describing the use of standard controls, patterns and floorplans. As we also make this available for our partners and customers, you too can benefit from this documentation when designing your own SAP Fiori applications. In case your control will also be used by other people it’s also recommended to provide sufficient documentation including guidelines for use and include some samples.

• SAP Fiori Design Guidelines: https://experience.sap.com/fiori-design-web/
• SAP UI5 Explored: https://sapui5.hana.ondemand.com/sdk/explored.html

Implementing SAP UI5 Controls

SAP UI5 is based on HTML5 standards, which allows you to extend the control library either with entirely new custom controls or with extensions of existing controls. A good part of SAP UI5 is available as open source so that all developers can make use of the capabilities of this enterprise-grade control library for their products and contribute to it. Therefore, Open UI5 and its community is a good starting point if you want to build your own controls.

As I’m not a developer myself I have pulled together some resources that could help you with your own projects to build or extend UI5 controls. Many of these resources have been provided by members of the core SAP UI5 team so that you get first hand insights from the real experts.

• The starting point for everyone working with UI5 is the SAP UI5 Explored app. In this app you can browse all available controls as well as sample pages on various topics and inspect the code behind. It’s also a nice feature that you can filter for specific releases and switch different parameters like the content density.
• The SAP Fiori Design guidelines of course is also an excellent source of information if you want to understand how we use which control for what purpose and what parameters we offer to influence the behavior.
• The development tool for SAP UI5 can be a notepad of course. But to have a well-integrated experience we offer a development environment that can run in a browser and that supports your work as a developer – SAP Web IDE. There is the possibility to explore SAP Web IDE and read through the extensive documentation in the SAP HANA Cloud Platform if you sign up for a trial.
• There are multiple resources around extending existing UI5 controls or creating new controls from scratch in the SCN UI5 Developer Center that are very helpful to get started.
• In addition to that, there are many interesting contributions on the same topic on OpenUI5 such as control development guidelines or instructions on how to develop controls for Open UI5 and for extending existing controls.

Take Aways

In this article, I wanted to give you a more comprehensive perspective of what it means for us (and eventually you as well) to develop a new control in a business environment.

• The first and most important question before developing a new control must be:  Do I really need a new control? Is the investment justified? Can I solve the problem with standard means?
• In order to answer this question, you should make sure that you really have understood the problem the user needs to solve. Sometimes the problem can be avoided by adjusting the flow just a bit.
• If you start designing a new control you should consider combining existing controls into one complex control or extending an existing control to ensure consistency on the interaction level.
• If you start a completely new control make sure that you address the core qualities of Fiori such as responsiveness, accessibility, theming, and so forth. In any case there are well established aspects of design that you should embrace even for a single control. Iterate, compare and improve until it’s perfect.

Controls are the building block of a user interface. With the weakest of its parts it can break and lose its elegance and usability. Make sure that your control fits into the picture.