Scaling user interfaces (UI) is hard.
While a simple application can be thrown together, there’s a surprisingly deep level of complexity once you grow. You need tests to validate functionality and consistency in UI elements across all app screens. And don’t forget to consider edge cases.
When an application gets large enough, front-end teams will regularly reach for a UI component system to make development more streamlined.
However, not all off-the-shelf tools are perfect for every scenario. Many teams end up writing their own UI component system to solve these problems.
Unfortunately, building your own UI component system comes with its own set of challenges.
CoderPad Developer Advocate Corbin Crutchley recently sat down with Developer Advocate Esther Agbaje of Chakra UI, an open-source component library, to discuss the challenges of making UI design systems that can scale.
One of the most significant benefits of using component libraries is that it’s easier to build accessibility into your application than pinning it on as an afterthought.
The Importance of Accessibility in UI components
Web accessibility is not a side issue or a nice-to-have. It’s essential for our modern digital lives.
From making web pages readable for colorblind users to allowing pages to be easily translatable for readers whose first (or even second language) is not English, accessibility opens up the web experience for those traditionally excluded from it.
However, it’s not only a case of “this is the morally right thing to do” – many countries also have legal requirements for creating accessible web pages.
These requirements are often driven by the standards and specifications outlined in the Web Content Accessibility Guidelines (WCAG) established by the Web Accessibility Initiative (WAI).
While these guidelines attempt to make the accessibility process more manageable, it can be overwhelming for new developers or anyone unfamiliar with web accessibility.
Things like right-to-left (RTL) text support, color contrast, and assistive technology support are just a few of the accessibility considerations developers have to contemplate while designing their sites and applications for accessibility.
That’s where component systems like Chakra UI come in.
One of the first points that Esther brought up was the accessibility of Chakra – Chakra wants to make design systems available for everyone to use, no matter their circumstances.
It follows the Web Accessibility Initiative’s Accessible Rich Internet Applications Suite. This internet standard defines ways to make web applications more accessible for people with disabilities and across different cultures.
Meeting the specifications for this standard is not easy, as Chakra had to consider how their application would work not only on various browsers but also across various languages.
One example of this is Right-to-left (RTL) text support. Many of the world’s languages – Hebrew, Arabic, Persian, and Urdu, to name a few – are read from right to left rather than left to right, like with English and other European languages.
UI developers often need to code these different language structures into their application, but with a plugin like Chakra UI, they can automatically flip the margin based on the language type.
As Corbin has discussed previously with accessibility expert Ben Myers, an excellent accessibility experience isn’t added like ice cream on the top of apple pie – it’s baked in like the cinnamon sprinkled in the apple filling itself.
Using components that already have the accessibility standards baked into them, like Chakra’s components, not only improves the experience for users who have disabilities but also for everyone else.
Advice for maintaining project documentation
Open-source documentation can be challenging for many reasons:
- Inconsistent contributions – getting people motivated to contribute, especially when you need it most during a new feature release or update, can be challenging.
- Communication difficulties – you have a limited number of subject matter experts and contributors who may be working across multiple time zones and in various languages.
- Inefficient processes – not having a thought-out formal process for how contributors should add to the documentation can prevent timely and regular updates.
Esther and her team at Chakra UI ran into some of these obstacles. Initially, their documentation was in the same repository as their code base, but they were having trouble getting contributors to help with the documentation – the process of cloning the repo and then pushing documentation changes was too cumbersome.
So they moved to have two separate repositories, one for the documentation and one for the Chakra UI code base. This not only helped get more people to contribute, but it also made translating the documentation into other languages a lot easier.
Some other tips for overcoming those obstacles listed above:
- Use a library to generate automatic changelogs every time your code is updated. Chakra UI used Changesets.
- Create a formal update and review process for your documentation. There is no one-size-fits-all approach, so you should tailor the process to what works best for your team of contributors and maintainers.
- Similarly, do what you can to make it as easy as possible for contributors to update the documentation.
Design advice: Popovers vs. Modals
After discussing their documentation process, Corbin then asked Esther about a UI topic he had been thinking about recently – when do you use a popover versus a modal to notify a user within an application?
Popovers and modals are tools to display information to the user. A popover is simply a box that pops up when you click on an element on the webpage. However, a popover still allows you to scroll up and down the page while the popover is active. On the other hand, a modal freezes scrolling until you click on an action on the modal.
Esther recommends reserving modals for alert dialog where you want a user to take (or not take) a critical action or to inform them of something important before they continue scrolling.
Popovers can be used for less urgent messages where a user’s action will have minimal impact on the future state of the application.
For example, if a user wants to delete a vital piece of information from their account, such as a bank account number, this would call for a modal where a user has to confirm that they want to delete their bank account number.
Everyday use for a popover would be linking users to a website for more information – for example, linking a form to a documentation page that explains what all the fields of the form are for.
What’s next for Chakra UI?
Corbin ended the interview by asking Esther what was next for Chakra UI.
Esther mentioned that they completed their first successful hackathon and had a whole list of initiatives to make the web development experience even easier for front-end developers.
Among the things they’re working on now:
- React 18 support
- Improve color mode
- Adding even more components, like pagination and carousels
- Integration with web component API provider Zag
If you’re looking for more information on how to use Chakra UI, you can start by checking out their web page here.
Top comments (0)