feat: add ProgressStepper component

[lilbitner]

Purpose of PR

The purpose of this PR is to add the ProgressStepper component to the F36
component library.

Why: There are already lighter versions of this component built and utilized within the current Contentful web application, so in an effort to share the love and enhance the consumable ease of this component, Ciarán Brady proposed the designs and initiative for this component to be included in the F36 component library.

Who: This has been a joint effort by @lilbitner, @whitelisab, @CiaranbradyBER, and Emily McCammon.

What: This PR introduces the overall ProgressStepper component, to be used as a purely visual representation of progress made in a series of steps. It is not an interactive component (at this time). A secondary component, Step, is also introduced here to be only consumed as a child of ProgressStepper.

Approach and overview

After researching a variety of other design systems, in addition to the current implementation of the component in the contentful web application, we decided to create the ProgressStepper as a compound component with a Step subcomponent. With this structure, the Step subcomponent is clearly tightly coupled to the ProgressStepper itself, with the Step being a child only of the ProgressStepper parent. This helps to lay out a clear path of implementation for the user.

We also followed a common pattern in both other systems and the current web app implementation, to limit extraneous html and instead leverage pseudo elements, before and after, as well as CSS grid to effectively layout each piece of the component, and create the connecting line itself. You can find this implementation within the Step.styles.ts file.

The props defined for the ProgressStepper component are fairly straightforward and self-explanatory. The props defined within the Step subcomponent are a bit more nuanced. We intended to only expose the variant and labelText prop to the user consuming the component, as all other props are utilized by the parent ProgressStepper to pass on relevant information defined at the parent level. However, all Step props are listed on the website documentation, both private and public, as this is a fairly automated process within the website functionality at this time. We are happy to investigate this more, but wanted to prioritize opening this PR and gathering and feedback on these details.

It is necessary, especially for the vertically oriented component, that the user defines a height at a parent level. This ensures that the component takes up 100% of the height allotted to it.

For the horizontally oriented component, one small nuance that we want to mention is that there is extra width on both sides due to the hidden before and after pseudo elements. Given that the label text in the horizontal orientation is centered under the step, there will need to be extra width on the sides, but currently there is more width beyond the label. We would appreciate getting feedback on whether this is something that we should address. For possible solutions, we discussed whether we can change the positioning of the labels in the horizontal orientation to make them left-justified under the step or whether we could have modes for when the stepper has labels vs. no labels, and only have the extra width on the sides when labels exist. We are also open to other thoughts on this if this is something to be addressed.

Example of extra width with and without labels:

Following the pattern of other components recently introduced to Forma36, we created this component as an alpha component. We have noted that it is an alpha component in the package.json file and in the README. We would appreciate guidance on what other steps we need to take to ensure that it is published properly as an alpha component when we are ready to merge this PR.

ProgressStepper website page

Screen.Recording.2024-06-27.at.2.16.52.PM.mov

PR Checklist

• I have read the relevant readme.md file(s)
• All commits follow our Git commit message convention
• Tests are added/updated/not required
• Tests are passing
• Storybook stories are added/updated/not required
• Usage notes are added/updated/not required
• Has been tested based on Contentful's browser support
• Doesn't contain any sensitive information

[vercel]

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name	Status	Preview	Updated (UTC)
forma-36	✅ Ready (Inspect)	Visit Preview	Jul 10, 2024 3:41pm

[changeset-bot]

⚠️ No Changeset found

Latest commit: af3a785

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

This PR includes no changesets

When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR

[wiz-inc-38d59fb8d7]

Wiz Scan Summary

IaC Misconfigurations
Vulnerabilities
Sensitive Data
Total
Secrets

[github-actions]

size-limit report 📦

Path	Size	Loading time (3g)	Running time (snapdragon)	Total time
CommonJS	135.98 KB (0%)	2.8 s (0%)	147 ms (+51.56% 🔺)	2.9 s
Module	132.24 KB (0%)	2.7 s (0%)	158 ms (+48.96% 🔺)	2.9 s

[Lelith]

Looks all really good to me, only one small comment about the stepper wrappers accessibility. You could also add a small unit test that runs the axe checker over the component like so https://github.com/contentful/forma-36/blob/main/packages/components/avatar/src/AvatarGroup/AvatarGroup.test.tsx#L116

[denkristoffer]

Wow, amazing work team! Is "progress stepper" an established name for such a component? I haven't run into it before, I usually know them as wizards, which admittedly is a pretty bad name 🤷

[cf-remylenoir]

This is great, thank you 👏

On top of @Lelith a11y-related comments, I would recommend checking the properties' names with the Technical Writing and Product Design teams, to ensure we are aligned between Design-Code and follow the same patterns across our components. There was some audit work done in the past by @aromanko, she could be of help.

[lilbitner]

This is great, thank you 👏

On top of @Lelith a11y-related comments, I would recommend checking the properties' names with the Technical Writing and Product Design teams, to ensure we are aligned between Design-Code and follow the same patterns across our components. There was some audit work done in the past by @aromanko, she could be of help.

Thank you for this suggestion @cf-remylenoir ! We have reached out to Anna to ensure we are aligned on the naming 😃

[lilbitner]

Wow, amazing work team! Is "progress stepper" an established name for such a component? I haven't run into it before, I usually know them as wizards, which admittedly is a pretty bad name 🤷

Thank you @denkristoffer ! We did see one example of this naming used in this design library, but are aligning with our technical writing team now to ensure we name it appropriately!

[damann]

The term "progress stepper" is commonly used in design systems to refer to the component that indicates the progress and allows navigation between steps in a multi-step process, such as a wizard pattern. This component can also be called a "stepper," "progress indicator," "step indicator," or "multi-step progress bar."

The exact terminology can vary between different design systems and organizations, but "progress stepper" is a widely recognized and understood term within the context of user interface design.

Examples of design systems using similar terminology include:

Material Design by Google uses the term "Stepper" to describe a component that displays progress through a sequence of logical and numbered steps.
Ant Design uses the term "Steps" to describe a component that can guide users through a complex process.
Carbon Design System by IBM uses the term "ProgressIndicator" for a similar component.