In my opinion, the definition of a good component library is determined by several key factors:
- What is the process behind your component design?
- What is your team?
- What is your focus?
- What is your testing strategy?
- What is your adoption strategy?
- The list goes on and on…
I know each of us can make our list, but still, having a GitHub project is just the beginning, and as a wise man once told me:
Yes, definitely not easy. These projects are like complex living ecosystems and a great piece of technology is just the seed. Without an ongoing supply of air, water, sunshine, and gardeners, that seed won’t reach its potential.
— Craig Federighi –.
If you read my previous article, you may have already gotten some idea of where I’m going with some of the points. Your UI component library is as good as the people who use it, and you need to develop both.
How we work
First let me say that the entire user interface in SAP should speak the same design language, which we call SAP Fiori 3, and this is where we need to start.
We take SAP Fiori 3 UX specification, we can go through a few iterations with designers, and then we turn this into a light-weight presentation layer that consists of styles and HTML templates. This is our Fundamental Library Styles open-source project.
By the way, this is also the most used layer adopted by other major SAP UI frameworks in this fundamental family but not limited to it. The contribution on this level is pretty impressive. More than 4 LOBs are contributing towards a common goal and others are joining such as Hybrids (BTP), Concur, Ariba, Fieldglass, and I am sure I forgot somebody…
At this stage we have Fundamental Library Styles implementation ready, so what’s next? Well, we just haven’t started the implementation yet. We need to do the technical design first! But how do you create a design for the UI component? We start with the thing, which is the most visible to our end consumers and this is the component signature.
It’s pretty much the same approach when you design your API and you also care how this API feels here. TDD approach could be a good start.
During this design phase we focus on the following:
- Do we understand well enough when & how this component is going to be used?
- We look at the outer component signature from different angles to cover different scenarios
- We try to understand and consult what accessibility requirements need to be implemented
- What about i18n? Do we need to do anything special here?
- Inputs and Outputs. Did we use come up with good naming? Do we really need this input when we have that one?
- Any other technical implementation consideration that we need to be aware of?
Once a technical design is ready, it goes to the front of a group of 20+ UI engineers, and we try to challenge the designer. Many times, we do several iterations until it feels right.
Once everyone (or the majority of us) is happy with the design, we mark it as “Approved”, and schedule it for the development.
Who we are
Now let me talk about another aspect which most of us don’t realize. Developing a library or reusable UI components is a special discipline, and you need to apply a different skill set compared to developing an application. Our work is made to be used over and over so the application developer needs to create an application without additional overhead.
I would say anybody can learn it, it’s not rocket science but…
You really need to get the feeling for someone who is going to use your work!
Other than this we are a pretty distributed and dedicated team which sometimes works 7 days a week, we use Slack, Zoom, MS Teams to get things done.
Know your consumers
I have already touched on this in my previous article, and I cannot stress this enough “You need to have some expectation about who is going to use your library”.
If you expose too much implementation details, you are introducing additional overhead, and developers will be forced to build abstraction layers on top of your library. It shouldn’t be this way.
If you provide too much abstraction, the library becomes unusable, and developers will try to figure out different ways to hack your work, how to override this and that. It needs to be just right.
To achieve this, we carefully look at our core layer from the library owner point of view. We do this to make sure it provides enough freedom to be able to build additional things on top of it. And let’s not forget about balancing between flexibility and complexity.
Platform layer is more driven by enterprise application requirements, and we work with our application teams here who are adopting it. Working with core users helps us tremendously, as we are able to gather additional requirements as early as possible.
We always try to follow this simple set of rules:
- Make sure we have Fundamental Library Styles implementation before we start working on the Fundamental Library for Angular component.
- Components need to exist in the core layer first;
- Don’t copy every component to the Platform layer unless you can clearly demonstrate there is some added value.
How we do testing
This is the topic on its own, and we will expand on it in a separate article. But what I can share now is the following:
- We look at our test coverage and make sure we have enough meaningful unit tests;
- We use cloud testing platform called Sauce Lab to cover different environments and all kinds of browsers;
- In parallel, we write E2E tests to make sure our components work together with other components and under different scenarios.
- We have a separate stream where we try to also automate accessibility testing, but this is too specific, so we as well work with other teams who manually tests different accessibility requirements.
Adoption represents any actions or activities which help broader usage of our component library.
This usually starts with having documentation and examples ready, so that the application teams can start using components right away. Documentation with examples is crucially important, it makes component library extremely easy to use.
It’s not the “here are the components, and from now on you are on your own”, but “we are in this together. If you are not successful we don’t succeed either”.
UI Components are one of the main building blocks from the Fundamental Library for Angular and probably the only thing now which comes to your mind when you hear @fundamental-ngx! But it does not end here. We will show you other areas we are working on to make this library a true end-2-end solution for any enterprise project.