In a rapidly changing world, to keep the audience glued to websites, designs are frequently changed, and more features are constantly added. As such, rapid shipping is the norm. When designs change frequently, or new components get added, a system/workflow needs to be in place to enable such rapid changes.
Our cases:
We have been working on a website with 1000+ pages. The pages common to all users are static (about 800), and the user specific pages are server side rendered (about 200). All pages are driven by a headless CMS. The website is multilingual. We’re currently using NextJS and Strapi.io.
We’re working on a product suite. Every product in the product suite has a different theme. Except for the theme, the component APIs can be 100% and using the same component across all products implies saving development time.
Challenges:
Enabling development of frontend components and viewing those components with multiple themes during development.
Enabling component UI/UX review with multiple themes.
Check and improve accessibility at component level.
The CMS is used by stakeholders across all departments. Several departments lack a web development background. This means any new feature that we ship requires that we document so that the usage can be propagated across the stakeholders. So, an easy to use documentation.
Multiple developers ship code, including interns, junior developers and senior developers. This adds a risk that a change in one place can cause regression at multiple pages across the website. Understanding that changing one component doesn’t cause any change in any other component with as little effort as possible. Understanding if the components are accessible and mobile responsive is equally important.
Our solution:
For every new component UI/UX design,
We develop the frontend component using Storybook. Storybook gives us an isolated way of developing components. Using Storybook, at the component level we can understand the accessibility issues, if any, and address those. Build components that work well across different themes.
We build & publish the Storybook to Chromatic.
Chromatic enables us to understand what changed by checking the snapshots. This is useful to understand if any change has caused any regression.
We get a UI/UX review within Storybook before merging the feature branch to target branch.
On UI/UX approval, then build the same component on CMS.
When the stakeholders managing the content access CMS and see the new components that could be used, they refer to the Storybook hosted on Chromatic to see if the component suits their content needs. When there are large additions, the stakeholders scroll through available components and identify components they could use on a particular page.
Once a component is identified on the Storybook, they then check the Storybook docs to understand which field relates to which content on the component. Referring to this, they can easily add/update the content in CMS.
This process enables the stakeholders to easily add/edit CMS content, without a difficult-to-read documentation. Storybook essentially serves as our component documentation here.
With this, we don’t have to document anything component specific. We still document other aspects of the website like:
Overall structure of website - an overview of our site in relation to the internal jargon.
Details on identifying the content type within the CMS from the url structure of an existing page on the website.
Specifics on pages that have content populated based on the relations created between different entities.
The Storybook acts as a component documentation for the developers as well. That way, developers can use components across all products.
Summary:
Storybook + Chromatic combination enables component development, testing and documentation. It enables development and testing with different themes, accessibility and creating documentation with ease.
Comments