- SAP Managed Tags:
The first part of this series had the goal to raise awareness of the importance of consistency for design. In the second part, I gave a bit more background on the effects of consistency on design and on the underlying psychological processes. Part 3 was about the difference between visual and functional consistency.
In the following section I want to give an overview of different design aspects and how they can help establishing design consistency. With this, I want to share some of the insights and learnings I made. I would be happy to learn from your experience if you want to share that in the comments below.
As mentioned in part 3 of this series, the visual appearance of an application is the most obvious aspect to achieve perceived consistency. Colors, shapes, fonts can be adjusted to match across the entire suite of applications and with that, visual integration can be achieved.
Figure 1: This example shows the work that has been done on the visual harmonization of SAP WebGUI (the web version of the SAP GUI) to match the SAP Fiori visual design theme called “Belize”.
However, what you see there, a pure visual alignment usually will not be sufficient if screen structures and the construction of controls don’t match. In most cases you will find that changes in the controls and floorplans are unavoidable. In this documentation the process of creating visual harmonization is described.
The most important aspects in the alignment of look are:
An important technical aspect of the look is the theming capability. There is nothing as short-lived as a visual design. Usually, the market requests face-lifts after one year and redesigns after 2-3 years. If you have a variety of UI technologies that you want to keep visually consistent you can’t afford implementing a new visual design every two years for each of them. Therefore, it is important to establish a theming concept that abstracts the visual design and allows you to centrally change the visual design once and apply it then to all of your technologies. This comes with the nice side-effect, that you can allow you (internal or external) customers to have their own brand implemented at little cost. SAP offers for that purpose the Theme Designer, which offers different branding strategies for a multitude of our UI technologies.
When it comes to theming, you should not forget about accessibility themes like high-contrast white and black, which can also be implemented more easily if a proper theming concept is available.
The feel addresses the more interactive parts of the user interface as well as motion design. From my perspective, the most important aspects regarding consistency are the following:
With controls, I refer to all components that are used to compose a user interface. This includes layout controls, basic controls like a button and compound controls like a table or filter bar.
Figure 2: Overview of the controls described in the SAP Fiori design guidelines.
Controls encapsulate a lot of functionality in a reusable way. Controls represent something like the designer’s vocabulary out of which the interactions are constructed like the sentences of a language.
In today’s graphical interfaces we already have established conventions for controls, so that many controls exist in a similar way in different designs and technologies. They share a core set of features that behave in a similar way and we use them for similar purposes. These conventions shape the expectation the user has towards a user interface. For the most part, these expectations are implicit and operated on an intuitive level. As with all these unconscious perceptions, they are very hard to change and inconsistencies on that level can lead to frustration and confusion for the user.
On top of the core functionalities, specific features are built that support specific requirements from a certain domain or context. Especially in business software, there are a number of features that are commonly unknown in standard consumer software.
Usually, words or icons are used to inform the user about the functionality a control offers. Example would be the label on a button, which describes the action this button triggers. Based on these terms (written or visual language like icons included), the user decides whether this is the right action or not. It therefore is essential designing a clear and concise terminology especially for the action-related screen texts. The more precise your terminology, the less processing time and errors for the user. For a start, one could think of collecting all frequent actions and important labels and consolidate them into a table that every designer should then have pinned to his monitor.
As initially mentioned, there is a general industry-wide consent about the usage of a large part of the controls. Available design systems (e.g. the SAP Fiori guidelines) describe purpose and scope of controls and also highlight potential confusion and mistakes (e.g. use links for navigation and not for action). If done right, these guidelines reflect the standard and extend it with industry- or company-specific requirements. It therefore is easy to borough your control taxonomy from any of the existing design systems available. Investing into a consistent control set early on and defining a consistent control taxonomy in the beginning of a project pays of as the applications grow as it avoids changes and adjustments later-on.
There is no need to start your control library from scratch but build on existing standards. Focus on the controls you really need, because managing and maintaining controls requires work to keep them consistent and harmonious. This work is never done as requirements evolve and usually there are implications of innovations that can affect larger areas of your design system.
Out of the roughly 200 controls specified for the SAP Fiori design language for web (that are available in the SAP UI5 control library) we have prioritized foundational controls like button, link, menu, toolbar, chart, tab, panel, form, busy indicator, label, text, title, list, message toast, check box, combo box, menu button, radio button (+ group), search field, select, text area to be the first that we would want to align across all products.
There are a lot of interactions within the controls as well as structural principles that have to be designed carefully, like for instance, behavior and positioning of labels, how fields open up for editing, what states does a control have and how are these states represented and animated. These aspects should be aligned across controls.
If you want to avoid patchwork design, ensure that you consistently follow guidelines on aspects like interaction states, interactive areas, transformations, behaviors like auto complete, sizing, responsiveness and others. You can use these criteria also for extensions as teams want to implement custom controls or use external controls to extend the design system for specific use cases. Be aware that this is a continuous and iterative process as control libraries continuously evolve.
In graphical user interfaces, pages are the canvas on which controls are placed, combined and assembled into applications. We are using the concept of floorplans for a long time now. It helps us to define page layouts that are optimized for certain use cases, like for instance showing a list of items, showing an individual item, etc.
Within floorplans we define areas on the screen that are reserved for certain purposes. These purposes might be covered with different controls (either freely or from a selection), similar to the furniture in a house’s floorplan. Floorplans therefore can be more or less rigid.
One of the biggest advantages of these floorplans is the fact that they can speed up design and development. It is easier to say I want to use this floorplan to display an object than to start thinking about the best layout to represent the object. Technical frameworks like SAP Fiori Elements allow creating such pages without programming even.
Floorplans also promote the consistency of applications because the variability can be controlled by the degrees of freedom defined in the definition of these floorplans.
Figure 3: This figure shows an overview of the floorplans we have specified in SAP Fiori today. There are additional floorplans to come but already these pages can cover a good part of the user cases our applications try to address.
If floorplans are too rigid or limiting, it might be the right compromise to define a common page structure that is used by all pages in your design system. Page structure is similar to a very open floorplan of a loft where only a few common features are defined like the door and the windows maybe. A page structure should provide common areas like title, toolbars, and content areas. It might also be necessary to define different types of pages like full pages and modals or dialogs.
Defining a consistent page structure helps the user to orient himself and identify the required functions much easier if they have pre-assigned regions and positions.
As part of the page structure, the placement of actions on the screen should be defined. What type of actions are placed where and in which order? What type of actions exist and where should they be placed? This includes the definition of toolbars on the level of the page and the alignment and order of the actions within the toolbars.
When aligning our different design approaches across our organization we found that most products used three types of actions on the page level:
Looking across our portfolio, we were able to classify two pages toolbars that could cover our requirements:
Other structural decisions are the alignment of the actions (left to the page or right) and the order of the actions with primary action either flush left or flush right. I will save you from the discussions we had around this topic but the final decision for the flush left option was primarily motivated by the accessibility argument that when using the tab chain, the most common action should be first.
These structural decisions can also prepare larger redesigns and alignments across a diverse product portfolio as the discussion helps agreeing on common terminology and conceptual models which facilitates the further work.
Operating systems (OS) like Microsoft Windows, Apple MacOS or iOS offer a lot of functionality that can be used across applications. This functionality can be encapsulated within an API and called from out of the application (like e.g. a search engine) or it can be integrated into the application using the OS-native user interface (for instance a window frame). I like to summarize these services or reusable functions as common functions as they should be consistently used across all applications within the OS.
If we develop applications that run in the browser, there is no operating system we can use. Web browsers due to security concerns offer only very limited and controlled interfaces for web applications. Also, one of the major arguments in favor of web applications, namely the independence of the OS and any device feature would be invalidated if web applications would make use of native OS features.
When building an application suite based on web technologies, you therefore also have to provide alternatives for the most basic operating system features like navigation and multi-tasking, search, help, messaging, or settings. Ideally, you will be able to embed the same services consistently across the entire application suite.
What sounds easy is in reality a huge technical challenge:
While creating these services and functions you also want to stay consistent with the standards for web applications making use of browser functionality, allowing links to be opened in new tabs or allowing back navigation, etc.
Productivity features like keyboard interaction are invisible in a demo but they can become existential in the day-to-day business. Keyboard interaction usually has no permanent visualization on the screen and has to be learned by the user to become more productive. Keyboard shortcuts are often used by experienced users that this way gain extreme performance wins. Maybe you are one of these hardcore Photoshop wizards that know all the keys for pallets and tools by heart? This advantage can be destroyed easily by an inconsistent or erroneous implementation of keyboard shortcuts. Who would be able to learn different shortcuts for a dozen different screens? Who would use a shortcut if the effect of it would be hardly predictable? A performance boost would become a risk.
It is highly recommended defining consistent rules for:
Defined very early on, these features can be implemented at a low price point. When identified later-on in can become costly adding them. More and more companies expect compliance to accessibility standards to ensure the enablement of their entire workforce.
While contents are often stored in data base columns and rows, contents aren’t only data base entries.
Enterprise data represents real facts that can decide on business success or failure. Businesses rely on this information and professionals make their million-dollar-decisions based on this information. Therefore, content is at the heart of what we design and everything we do has the goal to make this content shine. This is an often-forgotten fact so that content more than not isn’t treated with the respect it deserves, just as fields pulled from a database and put on the screen.
Our cognition operates on schemata, we are designed to take decisions based on similar patterns. Creating and adhering to consistent content patterns is our best way to allow our users work efficiently even with complex contents.
Consistency is one important aspect of quality in data presentation as only reliable presentation formats and rules allow precise and unambiguous consumption and understanding:
With this article, I wanted to give you an overview of the multi-facetted nature of consistency in design.
Consistency can be applied to every aspect of design ranging from the look and feel, on to the elementary building blocks of controls and floorplans and further on to the common functions like search, navigation or messaging. Within these dimensions there are many aspects that can support or compromise consistency and thus will have an influence on learnability, performance and error rates.
To keep track of the different aspects of consistency we need tools that support the design process and help us take consistent decisions in our daily work. A solid design system serves a foundation for guidelines, templates and tools that provide guidance and support to the designers in the company. Technical frameworks can further foster and promote consistency by narrowing down the design options for many mainstream tasks.
Design, however, can’t help if the content isn’t consistent. Therefore, it is important to ensure the quality and consistency of the contents in the first place.
In the following section I want to give an overview of different design aspects and how they can help establishing design consistency. With this, I want to share some of the insights and learnings I made. I would be happy to learn from your experience if you want to share that in the comments below.
Look and Feel
As mentioned in part 3 of this series, the visual appearance of an application is the most obvious aspect to achieve perceived consistency. Colors, shapes, fonts can be adjusted to match across the entire suite of applications and with that, visual integration can be achieved.
Figure 1: This example shows the work that has been done on the visual harmonization of SAP WebGUI (the web version of the SAP GUI) to match the SAP Fiori visual design theme called “Belize”.
However, what you see there, a pure visual alignment usually will not be sufficient if screen structures and the construction of controls don’t match. In most cases you will find that changes in the controls and floorplans are unavoidable. In this documentation the process of creating visual harmonization is described.
The most important aspects in the alignment of look are:
- Colors – Obviously, any visual design has to define a certain color logic and usage of these colors. This logic has to be translated to achieve the same results, which is problematic as the structure of the UI coding often differs between technologies.
- Typography / Fonts – Many visual designs make use of specific fonts to establish a certain brand identity. For SAP, this is our own font 72. The decision whether you want to use an own font or whether you want to use system fonts often has to be thoroughly evaluated because of a set of implications associated to it, such as the cost of designing, distributing and downloading an own font or the completeness of the font as you will have to support symbolic languages like Chinese as well if you don’t want to fall back to system fonts for these code pages.
- Iconography – The usage of Icons usually is a strong vehicle to create a visual brand. To achieve consistency, different aspects have to be taken into account: a) using the same icon style and where possible the identical icons; b) using similar icons for similar functions.
- Spacing / grid – The density and geometry of the screen plays an important role in the perception. Are alignments the same? Are the same heights used? How is the distance between screen elements? These aspects usually are covered by the spacing and the grid of the visual design. If these differ from screen to screen, this results in an unordered and restless appearance and problems for the user to direct his focus and understand the structure of the screen. In SAP Fiori, we even have a dynamic spacing depending on whether the application is running on a touch-enabled device offering a bit more space for the fingers.
- Brand elements – Applying the same brand logo to all screens is a very simple approach. In the context of business software, the vendor logo then usually is replaced by the customer logo. We therefore also strive for brand elements that are integrated into the UI functionality (Microsoft did something very smart with the ribbon or the home menu there). Ideally, these are aspect with a positive association.
An important technical aspect of the look is the theming capability. There is nothing as short-lived as a visual design. Usually, the market requests face-lifts after one year and redesigns after 2-3 years. If you have a variety of UI technologies that you want to keep visually consistent you can’t afford implementing a new visual design every two years for each of them. Therefore, it is important to establish a theming concept that abstracts the visual design and allows you to centrally change the visual design once and apply it then to all of your technologies. This comes with the nice side-effect, that you can allow you (internal or external) customers to have their own brand implemented at little cost. SAP offers for that purpose the Theme Designer, which offers different branding strategies for a multitude of our UI technologies.
When it comes to theming, you should not forget about accessibility themes like high-contrast white and black, which can also be implemented more easily if a proper theming concept is available.
The feel addresses the more interactive parts of the user interface as well as motion design. From my perspective, the most important aspects regarding consistency are the following:
- Transitions – As transitions are used to establish a sense of direction and hierarchy in the UI it is extremely important to ensure consistent use of them. Especially, as most user will not be consciously aware of these effects, inconsistencies can lead to disorientation and confusion.
- Micro-Interactions – triggered if a user interacts with the screen. These micro-interactions like small behaviors, movements, feedback are very subtle and are often not consciously perceived by the user. However, they create a certain haptics for the applications and again, people notice differences often without being able to put their finger on it.
- Loading or waiting indication – Depending on the connectivity and complexity of the processes in the backend, latencies are unavoidable. Loading indicators are used to provide feedback to the user that the system is still processing and ideally, how long this processing will still take (for a good overview of strategies how to convey system status to the user read this article on Medium). These waiting times are no positive experiences and should be designed as modest and minimalist as possible, and, it should be consistent. It is super annoying to have different loading indicator popping up with you knowing why. Infamous example is the beach ball in Mac OS which shows in case an application doesn’t respond anymore. Would an average user understand, why there are different icons for application-level and system-level waiting? I certainly didn’t for a long time…
Controls
With controls, I refer to all components that are used to compose a user interface. This includes layout controls, basic controls like a button and compound controls like a table or filter bar.
Figure 2: Overview of the controls described in the SAP Fiori design guidelines.
Controls encapsulate a lot of functionality in a reusable way. Controls represent something like the designer’s vocabulary out of which the interactions are constructed like the sentences of a language.
In today’s graphical interfaces we already have established conventions for controls, so that many controls exist in a similar way in different designs and technologies. They share a core set of features that behave in a similar way and we use them for similar purposes. These conventions shape the expectation the user has towards a user interface. For the most part, these expectations are implicit and operated on an intuitive level. As with all these unconscious perceptions, they are very hard to change and inconsistencies on that level can lead to frustration and confusion for the user.
On top of the core functionalities, specific features are built that support specific requirements from a certain domain or context. Especially in business software, there are a number of features that are commonly unknown in standard consumer software.
Usually, words or icons are used to inform the user about the functionality a control offers. Example would be the label on a button, which describes the action this button triggers. Based on these terms (written or visual language like icons included), the user decides whether this is the right action or not. It therefore is essential designing a clear and concise terminology especially for the action-related screen texts. The more precise your terminology, the less processing time and errors for the user. For a start, one could think of collecting all frequent actions and important labels and consolidate them into a table that every designer should then have pinned to his monitor.
As initially mentioned, there is a general industry-wide consent about the usage of a large part of the controls. Available design systems (e.g. the SAP Fiori guidelines) describe purpose and scope of controls and also highlight potential confusion and mistakes (e.g. use links for navigation and not for action). If done right, these guidelines reflect the standard and extend it with industry- or company-specific requirements. It therefore is easy to borough your control taxonomy from any of the existing design systems available. Investing into a consistent control set early on and defining a consistent control taxonomy in the beginning of a project pays of as the applications grow as it avoids changes and adjustments later-on.
There is no need to start your control library from scratch but build on existing standards. Focus on the controls you really need, because managing and maintaining controls requires work to keep them consistent and harmonious. This work is never done as requirements evolve and usually there are implications of innovations that can affect larger areas of your design system.
Out of the roughly 200 controls specified for the SAP Fiori design language for web (that are available in the SAP UI5 control library) we have prioritized foundational controls like button, link, menu, toolbar, chart, tab, panel, form, busy indicator, label, text, title, list, message toast, check box, combo box, menu button, radio button (+ group), search field, select, text area to be the first that we would want to align across all products.
There are a lot of interactions within the controls as well as structural principles that have to be designed carefully, like for instance, behavior and positioning of labels, how fields open up for editing, what states does a control have and how are these states represented and animated. These aspects should be aligned across controls.
If you want to avoid patchwork design, ensure that you consistently follow guidelines on aspects like interaction states, interactive areas, transformations, behaviors like auto complete, sizing, responsiveness and others. You can use these criteria also for extensions as teams want to implement custom controls or use external controls to extend the design system for specific use cases. Be aware that this is a continuous and iterative process as control libraries continuously evolve.
Floorplans
In graphical user interfaces, pages are the canvas on which controls are placed, combined and assembled into applications. We are using the concept of floorplans for a long time now. It helps us to define page layouts that are optimized for certain use cases, like for instance showing a list of items, showing an individual item, etc.
Within floorplans we define areas on the screen that are reserved for certain purposes. These purposes might be covered with different controls (either freely or from a selection), similar to the furniture in a house’s floorplan. Floorplans therefore can be more or less rigid.
One of the biggest advantages of these floorplans is the fact that they can speed up design and development. It is easier to say I want to use this floorplan to display an object than to start thinking about the best layout to represent the object. Technical frameworks like SAP Fiori Elements allow creating such pages without programming even.
Floorplans also promote the consistency of applications because the variability can be controlled by the degrees of freedom defined in the definition of these floorplans.
Figure 3: This figure shows an overview of the floorplans we have specified in SAP Fiori today. There are additional floorplans to come but already these pages can cover a good part of the user cases our applications try to address.
If floorplans are too rigid or limiting, it might be the right compromise to define a common page structure that is used by all pages in your design system. Page structure is similar to a very open floorplan of a loft where only a few common features are defined like the door and the windows maybe. A page structure should provide common areas like title, toolbars, and content areas. It might also be necessary to define different types of pages like full pages and modals or dialogs.
Defining a consistent page structure helps the user to orient himself and identify the required functions much easier if they have pre-assigned regions and positions.
As part of the page structure, the placement of actions on the screen should be defined. What type of actions are placed where and in which order? What type of actions exist and where should they be placed? This includes the definition of toolbars on the level of the page and the alignment and order of the actions within the toolbars.
When aligning our different design approaches across our organization we found that most products used three types of actions on the page level:
- Primary action: the main action on the page. Should also be associated with the enter key. This should be the most likely action a user will take on the page. There should be only one primary action on a page.
- Negative action: the negation of the primary action often leading the user off the page without committing any change (e.g. Cancel). There will be one negative action in most cases.
- Secondary actions: all actions that are neither primary nor negative.
Looking across our portfolio, we were able to classify two pages toolbars that could cover our requirements:
- Header toolbar: on the top with permanent actions related to the primary context of the page
- Footer toolbar: on the bottom for the process- or workflow-related actions that usually would lead the user away from the page.
Other structural decisions are the alignment of the actions (left to the page or right) and the order of the actions with primary action either flush left or flush right. I will save you from the discussions we had around this topic but the final decision for the flush left option was primarily motivated by the accessibility argument that when using the tab chain, the most common action should be first.
These structural decisions can also prepare larger redesigns and alignments across a diverse product portfolio as the discussion helps agreeing on common terminology and conceptual models which facilitates the further work.
Common Functions
Operating systems (OS) like Microsoft Windows, Apple MacOS or iOS offer a lot of functionality that can be used across applications. This functionality can be encapsulated within an API and called from out of the application (like e.g. a search engine) or it can be integrated into the application using the OS-native user interface (for instance a window frame). I like to summarize these services or reusable functions as common functions as they should be consistently used across all applications within the OS.
If we develop applications that run in the browser, there is no operating system we can use. Web browsers due to security concerns offer only very limited and controlled interfaces for web applications. Also, one of the major arguments in favor of web applications, namely the independence of the OS and any device feature would be invalidated if web applications would make use of native OS features.
When building an application suite based on web technologies, you therefore also have to provide alternatives for the most basic operating system features like navigation and multi-tasking, search, help, messaging, or settings. Ideally, you will be able to embed the same services consistently across the entire application suite.
What sounds easy is in reality a huge technical challenge:
- A search has to run on multiple systems and has to be able to performantly index and present various objects in a coherent and readable manner.
- Navigation has to be open to a flexible and role-based structure of content, providing guidance on the one hand and flexibility on the other hand.
- Content management has to be effortless while security has to be ensured. Business-critical data and transaction must only be available to authorized personnel.
- Help systems have to be context specific but at the same time extensible with customer content as many contents have to adjusted to customer processes.
- Settings have to be applied to different systems where the same physical person might have different users, to systems of different release levels
- Personalized data has to be stored and processed in accordance with international law and data protection rights.
- And many more…
While creating these services and functions you also want to stay consistent with the standards for web applications making use of browser functionality, allowing links to be opened in new tabs or allowing back navigation, etc.
Productivity features like keyboard interaction are invisible in a demo but they can become existential in the day-to-day business. Keyboard interaction usually has no permanent visualization on the screen and has to be learned by the user to become more productive. Keyboard shortcuts are often used by experienced users that this way gain extreme performance wins. Maybe you are one of these hardcore Photoshop wizards that know all the keys for pallets and tools by heart? This advantage can be destroyed easily by an inconsistent or erroneous implementation of keyboard shortcuts. Who would be able to learn different shortcuts for a dozen different screens? Who would use a shortcut if the effect of it would be hardly predictable? A performance boost would become a risk.
It is highly recommended defining consistent rules for:
- Tab chain
- Default action
- Keyboard shortcuts for navigation and function
- Hover and tooltips
- Context menu
- Gestures
- Accessibility support (WCAG, ARIA, etc.)
Defined very early on, these features can be implemented at a low price point. When identified later-on in can become costly adding them. More and more companies expect compliance to accessibility standards to ensure the enablement of their entire workforce.
Content
While contents are often stored in data base columns and rows, contents aren’t only data base entries.
Enterprise data represents real facts that can decide on business success or failure. Businesses rely on this information and professionals make their million-dollar-decisions based on this information. Therefore, content is at the heart of what we design and everything we do has the goal to make this content shine. This is an often-forgotten fact so that content more than not isn’t treated with the respect it deserves, just as fields pulled from a database and put on the screen.
Our cognition operates on schemata, we are designed to take decisions based on similar patterns. Creating and adhering to consistent content patterns is our best way to allow our users work efficiently even with complex contents.
Consistency is one important aspect of quality in data presentation as only reliable presentation formats and rules allow precise and unambiguous consumption and understanding:
- Consistent patterns for data presentation should be defined and ensured across all applications (e.g. how a person is presented, “Name <ID>” vs. “Name (<ID>)” vs. “<ID> - Name”). Even if single attributes might be context-specific, the structure and grammar should be constant.
- Consistent labeling of contents should be ensured and applied everywhere (e.g. “created on” vs. “creation date”)
- Consistent presentation of units of measure or abbreviations (e.g. “USD” vs. “$”, “EN” vs. “English”, “USD 100.00” vs. “100.00 USD”)
- Consistent ways of progressive disclosure to gradually reveal more information about an object by offering for instance a popup dialog.
- Consistent visual treatment or graphical decoration of similar contents (e.g. usage of icons or colors or graphical shapes)
- Avoid system-specific identifiers as only identifiers but try to combine them with identifiers that are globally used (e.g. try to provide global identifiers or better natural names in addition to system- [or status-] specific identifiers, like a company could have a supplier and a customer ID but still is the same company)
- Try to offer a consistent schema for object related actions across occurrences (e.g. offer access to master data sheet).
Takeaways
With this article, I wanted to give you an overview of the multi-facetted nature of consistency in design.
Consistency can be applied to every aspect of design ranging from the look and feel, on to the elementary building blocks of controls and floorplans and further on to the common functions like search, navigation or messaging. Within these dimensions there are many aspects that can support or compromise consistency and thus will have an influence on learnability, performance and error rates.
To keep track of the different aspects of consistency we need tools that support the design process and help us take consistent decisions in our daily work. A solid design system serves a foundation for guidelines, templates and tools that provide guidance and support to the designers in the company. Technical frameworks can further foster and promote consistency by narrowing down the design options for many mainstream tasks.
Design, however, can’t help if the content isn’t consistent. Therefore, it is important to ensure the quality and consistency of the contents in the first place.
2 Comments
| User | Count |
|---|---|
| 33 | |
| 13 | |
| 11 | |
| 10 | |
| 9 | |
| 9 | |
| 9 | |
| 9 | |
| 8 | |
| 8 |
