Check the process at Hi Masterclass #9.
To better understand a UI Component, we should provide more contextualized and general information about the overall picture and where they belong. As the word says, UI components belong to the User Interface of any websites, web applications, or anything that the user will interact with digitally. They are interactive building blocks for creating a user interface. They can sometimes be made up of only one HTML element, like buttons, or a group of HTML elements, like more complex ones as cards that can be made of text, images, and even buttons.
What is a UI Component
“Components let you split the UI into independent, reusable pieces, and think about each piece in isolation". (source: Facebook)
We can find UI components in any web application that follow the standard practices of modern web design. We could go about UI components as the middleman between a smaller and larger ecosystem. We can think about Lego, and when we want to build anything with Legos. One of the approaches that we can take is to dump all the pieces and start identifying the ones we need. For example, if we want to build a car and start thinking about all the elements that will make the building blocks of the car, here is where we'll have our building blocks (UI components). We won't randomly assemble pieces after pieces of Lego, but we will follow a structure and start creating those building blocks like doors, windows, wheels, etc.
In the beginning, we had just random pieces stacked upon each other. Then several building blocks. And at the end, we had our cars assembled by all these building blocks. The most important takeaway from this example is that our UI Components, our building blocks, will be reusable even if we want to build any different car.
The example of the car could help to understand better how we approach the design and development of any modern web application. We don’t just start from scratch and begin designing navbars, headers, titles, or cards randomly. Every current web application that wants to provide a unique and coherent user experience will have an efficient design system. That will be made out of a collection of UI patterns ultimately made of UI Components.
Why do we componentize our UI?
As we have seen, User Interfaces can be broken down into UI components, following the atomic design principle, which is building blocks that can be reused on every page of a web application.
Besides the underlying layout of a user interface, these components build the basis for user interaction. As “making the user feel in control” is one of the meaningful aspects of a good user experience, consistency in style and behavior is essential. Creating consistent UI components isn’t only about a visually unified and professional presentation of our product across the whole user journey. There are many other benefits:
- Consistent UI components reduce cognitive load for users. Therefore, more attention is on our content. Using consistent interfaces is usually faster because users don’t have to learn something new every time they use our product.
- Using an interface that feels familiar is less likely to result in user errors.
Based on this, the development of user interfaces needs to be set up to ensure and support consistency. As design updates are now more frequent, a well-chosen setup enables rapid implementation of updates across the entire product, all web entities, and design resources.
Two Types of Components
It can be helpful to distinguish between two types of components from a design perspective to help us separate concerns:
- Foundation Components are the primary expression of the design language of the system. They’re the defining parts of the experience and very targeted in scope. They ensure a consistent underlying interface. They can be single HTML elements, like text, buttons, links, or paragraphs.
- Composed Components are more complex, and they can be made from a combination of different HTML elements, like accordion or carousel, and can be more customizable.
To better understand the process of building a single UI component, we will show you one of the UI components made by Hi-Interactive using the low-code OutSystems platform.
The development of UI components using low code platforms, such as OutSystems, make the perfect combination because they enable the so-called reusability of code and repositories of component libraries. These represent the most crucial aspect of low-code platforms where developers can build UI components and boost application development time. We can define a UI component as a reusable object that accelerates the process of development and delivery.
Practical example: Hi-Credit Card
We’ll start showing how to build a UI component using OutSystems. The UI component we will show is the Hi-Credit Card which comes from the UI Components library created by Hi-Interactive.
This specific UI Component is an excellent example because it shows how fully customizable it can be. This one, in particular, can be used for a vast variety of websites and web applications, anything from e-commerce shops to subscription-based services.
It has a fully customizable design and logic because it can be used to wire any credit card to make an online payment, and we can change the card's design quite a bit.
Let’s see how we can start first thinking about the component itself, trying to dissect and isolate the single elements that make it up, and then we’ll build it.
Develop Hi-credit card component
Before developing a UI component, the first thing is defining how it will be used and what for. Start by thinking about the options that should have, the default behavior, and what are the most important use cases.
A component is a set of containers and placeholders most of the time. For example, if you want to modularize your code, then, most likely, your component will be a new block.
One important rule is that any UI component should be developed without implementing any business logic to be entirely reusable for many purposes.
Considering the Hi-Credit card, the most critical step is to analyze the design and figure out how many placeholders we will have to use and how we are going to structure our CSS.
As we can see from the image above, we can dissect the component into five isolated parts:
- CardImage: where we are going to place the background image of the credit card;
- CardNumber: will contain the credit card number;
- CardContentLeft: extra content as validation date;
- CardContentRight: extra content as an expiration date or a CVV;
- CardName: area that will include the name of the card owner.
Now that we have identified the areas, we have to decide whether these will be placeholders or input properties. We could say that this is one of the trickiest questions to solve during the design phase of a UI Component. Usually, the answer is nearly always: Depend!
In this specific case, we will use placeholders for all the areas, except for the CardNumber, because, most likely, this number will come from the database, and it will be an integer.
It will be much easier to show it as separated groups of four digits if this part is an InputProperty. On the contrary, if we were going to use a different method, then creating four groups of numbers would be done during development. Yet, since we believe that the objective of using UI Components is to speed up the development phase, more is done during this phase, and less time the developer will spend creating the final application.
That will be a combination of containers and dynamic expressions that accept integers as data types.
UI components could be created on a single application, or you could have a specific module for all your UI components.
The process for creating a new UI component is the same as creating a new block. Although we call it a UI component, it’s just a Block.
To begin with, we need to add the input parameters to customize the Card.
The first one we already talked about, the CreditCardNumer, will receive the credit card number.
After that, we need to create the IsTextDark and IsSmall input parameters. Those will be boolean data types. We'll use them to apply different CSS classes depending on the background color dynamically and ensure the text's readability or if we need a smaller card preview.
Obviously, the only mandatory value will be the CreditCardNumber input parameter, and the others will be optional because we will use them only for different use cases.
To be more dynamic, we always add an ExtendedClass input parameter. That allows the developer to add extra classes without changing the CSS Theme. For example, adding a border, additional padding, or margin to the card.
After we determine the number of input parameters that we need to use, we can then proceed with the HTML structure of the component. That is done in the widget tree, and it will have the following structure:
As you can see from the image above, we place a series of containers inside our Block. And to each container, we assign some specific CSS classes that we created to style our credit-card component.
Notes: Always follow the same name convention in all components, like BEM. That will maintain consistency in all CSS and make it easier to read for all developers.
Basically, we create an outer container that will include the image placeholder for the image background of the credit card. Inside that, we insert another container that is for the content of the credit card, which includes: the credit card number, the credit card left content, the right content, and the credit card name.
As you can see, the container for the credit card number includes four expressions widgets and is not a placeholder. That's because we receive this value as an input parameter. In this case, we are splitting the value of the card number into four strings, separating them with a space. Also, because it's an input parameter, we can create some logic on it, like detecting the payment companies (VISA, Mastercard, etc.).
Finally, we use a placeholder for the name of the credit card owner.
To finish with the HTML and CSS structures, the placeholders that won't change are the outer container, the image placeholder, and the container with the four blocks expressions widgets of the credit card number.
We apply a specific CSS class "ph" in the other content placeholders, which determines if those placeholders have content, and if not, they won't be shown.
It is vital to test it before shipping our UI Component into production and making it available to our UI component library. We have to make sure that our component is fully functional and, above all, fully responsive and works in every screen size and on different devices.
If any company is serious about their product development, they need to invest extra time and effort in testing. Not only to deliver the best quality but above all to prevent those numerous bugs and malfunctions that will cost an enormous amount of money that could have been saved.
So now that we have our credit card component built and ready to be used in any application, the last part of creating a UI Component is the documentation.
This last part can be considered one of the most significant UI Component development. It represents how a specific UI component can be used and which parameters the developers must use. It shows how the developer can customize the component.
In the images above, you can see the preview of the different types of customization styles we can give to the Credit Card component. Usually, it's good practice to leave documentation of the API design of the component:
That was a pretty brief introduction on how to develop a UI Component. It can be quite challenging to talk about only UI components without mentioning important concepts (atomic design, design systems, etc.) and why it's becoming essential every day. Design systems and UI components libraries can be considered vital aspects of any digital product that wants to provide a seamless user experience and have the capability to scale at large in the future. To conclude, we can start considering design systems and UI components libraries as single products that serve the creation of web applications and software.