DataForm: Develop a wizard pattern

[jarekmorawski]

Across the WordPress ecosystem, the wizard UI is widely used in plugins, particularly for onboarding, setup, and feature guidance. Currently, there’s no standardized approach to wizard implementations, leading to inconsistencies in user experience and requiring developers to build unique solutions for similar needs. This proposal suggests creating a shared Wizard UI pattern as a variant of the existing Page component, incorporating elements of DataForm and DataViews for an adaptable and cohesive interface.

Problem to solve Many plugins incorporate wizard UIs, but their implementations differ significantly, which can lead to:

• Varied navigation patterns (e.g., different locations for "Next" and "Back" buttons).
• Inconsistent styling and layouts, which may interrupt the user's flow as they switch between plugins.
• Repetitive code for common flows, which adds maintenance overhead and makes it harder to achieve a polished, accessible UI across plugins.

Proposed solution A shared Wizard UI pattern would streamline the user experience and improve developer efficiency. Building on the Page component, this variant could:

• Define consistent button placement and section headers to create predictable flows across all of wp-admin, no matter if the screen is part of WordPress or a plugin.
• Integrate components from Page, DataForm, and DataViews into a single reusable pattern.
• A standardized pattern would facilitate accessibility improvements and ensure mobile-friendly design.

The attached designs illustrate a potential flow and layout for this pattern. It's based on some use cases I've observed across WordPress, WooCommerce, and several other plugins I interacted with over the years, but it certainly doesn't satisfy all possible needs.

What do you think is missing? How do you currently use the wizard UI in your plugin that you think could be useful to others? Please share your ideas, sketches, and designs!

[carolinan]

I love this, but I would like to see an approach based on the user needs for onboarding and setting up a site and theme in core, instead of a design first approach where feedback is requested from plugin developers.

[carolinan]

The consistent design is important, but without knowing what types of components that will be needed, how can you design them?

[jarekmorawski]

Thanks for sharing your thoughts, Carolina. 🙏 The goal of this issue is to collect use cases for such a component and figure out what's needed to build it.

Having worked in the ecosystem for a while, I encountered countless situations when it'd be useful. Theme onboarding is certainly one of them, but there are more: new item creation flow, multi-step setup process, feature configuration, etc.

I'd leave site onboarding on the side for now since it's a large project that couldn't be completed with a single component. Moreover, it's probably best tackled by hosts and plugins who know their audiences through and through and will want to build a more tailored UI anyway.

That being said, whatever component we come up with as part of this work could serve as a reference. Details like paddings, button placement, and form behavior should be shared across the whole admin experience, including isolated onboarding flows.

The consistent design is important, but without knowing what types of components that will be needed, how can you design them?

Great question. Wizard/steppers are a common UI pattern across the web and usually consist of the same elements: title, form, prev/next buttons, and some type of progress indicator (dots, badges, progress bar, etc). I'm not saying we can (or should) design the perfect component, but I'm sure we can at least align on a foundation we'd feel ready to put in the hands of users.

[annezazu]

Tagging in @WordPress/outreach as this is an interesting proposal to leave feedback on.