Progressive Form

[rachael-phillips]

Request from the OpenShift team for a progressive form.

[mcarrano]

Today @rachael-phillips @lizsurette @serenamarie125 @ajacobs21e @kybaker and I met to discuss requirements and concepts for a progressive form component that can be offered as an alternative to a standard step by step wizard. Some requirements are captured here: https://docs.google.com/document/d/1If6pbpu3mzxwfR8D--frpH22q8sAM6cwTyCasFONrxo/edit?usp=sharing

This may be delivered as a new component or as an extension to the Wizard. Requires prioritization and placement on the PF4 roadmap.

[ajacobs21e]

@serenamarie125 and I talked through a few more details since the visual design meeting. I've added in buttons to clear all (start entire wizard over) and skip to beginning and end. These would be optional based on the app's use case. Skip to end would only show if there are no more required fields / steps. Here's a generic version

Here's the version with the Customer Portal use case

@kybaker what do you think of the visual design of the stepper and the color of the bottom bar? Does grey make sense?

[ajacobs21e]

Some outstanding questions:

• [x] Is there a use case for the "Skip to Beginning" [ << ] and "Skip to End" [ >> ] buttons? No - Use progress stepper to navigate

• [x] Is there a use case for a Start Over / Clear Form action? No - This could be an optional step added in later

• [x] Design of progress & button bar Use words instead of arrows options exploration

• [x] Progress stepper- should this be clickable to navigate to other steps? Need to test accessibility and click size

• [x] Accessibility - do we need the user to make an explicit action (Next button or hit enter / tab) to progress to the next page/step? Feedback from Mark is that it would be jarring to a screen reader user for the form to progress without a user action.

• [x] Should results be a separate step? Serena's testing showed that users expect results to be part of the same step as the input leading to those results rather than on a separate page. In the Portal context the user has to submit / confirm info before being shown results and I separated them into two pages. Is this something that should be prescribed by the pattern or left to each use case to decide?

• [x] Mark required fields or optional fields? From PF website: "If all fields on a form are required, do not use an asterisk for every field. Instead, provide a message at the top of the form stating, "All fields are required." If all field are optional, the message should state, "All fields are optional.""

  @rachael-phillips @lizsurette @serenamarie125 @ajacobs21e @kybaker @mcarrano Can you review these items and provide feedback here? Or if there's more discussion needed I can schedule a meeting. Thank you!

[ajacobs21e]

https://redhat.invisionapp.com/share/RHR7P36BUKT Updated based on feedback so far. Next step is to schedule a review meeting.

[ajacobs21e]

@kybaker I swapped the buttons and stepper and now I think it's a little weird how the stepper length can change in a progressive situation. I played around with two other ideas. Can you take a look please and let me know what you think?

https://redhat.invisionapp.com/share/RHR7P36BUKT

Thank you!

[alimobrem]

Can we get this to be more like https://www.typeform.com/? fyi...@beanh66 @serenamarie125

[kybaker]

@ajacobs21e I like the options you have there. I understand your concern about the steps shifting, but I still prefer the bottom positioning because it seems clearer that these are steps not somehow tied to the content like when on the left.

[beanh66]

@ajacobs21e I think you have some really nice design options! In general it feels like a wizard to me though, so wondering if these should be options built into the wizard documentation for optional cases such as (1) when you don't want or need the full side panel of steps and want progress shown more subtly or (2) when you don't know the number of steps and just want to show the current and previous. Is that the plan or will this still be a separate pattern?

I might be off on this but I thought the push from @mcarrano for making it separate from wizard was because of the difference in allowing a user scroll up or down in a form as desired. I realize it's also hard to show this case with Invision so you may have already accounted for it, in which case ignore me :)

[ajacobs21e]

Thanks @beanh66 ! Yep these screens are showing the interactivity well. Here's an example of an Axure mockup that uses an outdated design but maybe can help show the intended scrolling behavior: https://nn4o0c.axshare.com/issue_2.html#ScrollPosition=0&CSUM=1

[ajacobs21e]

@kybaker I'm not sure what you mean by "it seems clearer that these are steps not somehow tied to the content like when on the left." Is it because there wasn't a divider?

What if the vertical stepper looked just like the regular wizard just without step names? That'll be more consistent, more flexible if the number of steps is variable, matches the flow of moving downward, and we don't have to worry about the weirdness of a right aligned stepper for variable steps.

[kybaker]

@ajacobs21e Yes, I really like this solution. Much more expandable and makes sense as a variant.

[mcarrano]

I guess that my only issue here is how is this different from the wizard? Haven't you just created a variant of a wizard with the step titles hidden? Do we need a unique component for this @ajacobs21e ?

[ajacobs21e]

@mcarrano I kind of view this as a variant of a wizard that progresses vertically and you can navigate by scrolling. I think the interactivity, which invision isn't showing well, is the biggest difference.

Maybe it's worth comparing the requirements for this design to the requirements for wizard?

[mcarrano]

Yeah, I can see where this would be hard to model with InVision @ajacobs21e. I'm going to set up a meeting where we can talk this through a bit. I'm starting to see this as more like an alternative to the standard wizard. Agree that comparing the requirements would make sense.

[serenamarie125]

@ajacobs21e , agreed that the largest difference is the interactivity. Whether we decide this is 2 variants of a wizard or 2 unique patterns, we may want to do further research as to why we would suggest a traditional wizard versus this new interactivity so that we can provide appropriate guidelines which match user expectations.

[ajacobs21e]

@alimobrem Typeform is the inspiration Serena & I are working off of and creating an experience that's consistent with the rest of PatternFly. We're trying to nail down some of the visuals and then I'll create an interactive prototype that will capture the flow.

[ajacobs21e]

@kybaker Serena and I chatted yesterday and we propose using step indicators connected with a line down the left side. The connector makes them look less like floating circles and reinforces the vertical scrolling interactivity. Not having numbers gives flexibility to add or remove steps based on user selections.

I tried to match the visual design from the wizard but have two questions: 1) Wizard doesn't seem to have active future steps (step 2 in above example). For this use case I tried a blue outline. What do you think? 2) Wizard uses a white background for disabled future steps. In this case I tried a grey outline #d2d2d2 - is it too light? I think a grey fill is too much.

Thanks!

FYI @beanh66 @serenamarie125

[beanh66]

I like it @ajacobs21e! Will be interesting to get the summit test results!

[ajacobs21e]

@jgiardino An accessibility question that came up from Krystal on the dev side is how to handle the tab order with the scrolling functionality. If the next button is sticky to the bottom of the screen, when tabbing from the bottom of a step, the next DOM in order would be the subsequent form, not the 'next' button. Do you have a suggestion for how to handle that? Here's an example of an interactive prototype (works best on a laptop screen or if you make the browser window a little shorter on a big screen): https://6ci2bv.axshare.com/

Thanks!

[jgiardino]

If the next button is sticky to the bottom of the screen, when tabbing from the bottom of a step, the next DOM in order would be the subsequent form, not the 'next' button.

Yes, that would be the default behavior that you would get with the browser. I would suggest you implement this without overriding the default browser behavior, and test that flow before considering any changes to that. My expectation is that the default behavior will feel normal and expected, whereas trying to implement something that behaves different from that could actually result in an experience that seems weird and unfamiliar.

[ajacobs21e]

Thanks @jgiardino !

[beanh66]

FYI @matthewcarleton this is the progressive form pattern we could look at for OpenShift to see if it fits your needs for the vm creation. I think @serenamarie125 will be using it on the dev console side for the more lengthy catalog forms.

[ajacobs21e]

@kybaker I updated the stepper visuals with the new blue and also slightly darkened the line and future state grey colors:

Krystal suggested using #06c for the line when the next step is available.

I'll set up a meeting for us to discuss. Thanks!

[ajacobs21e]

I met with @kybaker and these are the finalized state colors:

Thanks Kyle!

[ajacobs21e]

Updated prototype link: https://marvelapp.com/4010if2

[ajacobs21e]

Proposed new visual design for the Progressive Form & Wizard stepper states from @kybaker & Krystal Moore: Completed - blue with check mark Active - blue filled Future - grey filled

This proposal would remove the "available" state. @serenamarie125 would that be ok for your use case?

Issue for the stepper update, which would be applied to the wizard as well: https://github.com/patternfly/patternfly-next/issues/1970

[ajacobs21e]

I started a doc to gather questions we want to test: https://docs.google.com/document/d/12WiHP-cvhgJ6bxDabM8l5H4-cEpzOLeFZrBma8Njwm8/edit?usp=sharing

@mcarrano @LHinson @rachael-phillips @serenamarie125 @beanh66 Please add any thoughts you have!

[julienlim]

I like seeing where the progressive disclosure form design is headed 👍

[mcarrano]

Met today with @ajacobs21e @matthewcarleton @sjcauffm and Kristal Moore to review the proposed stepper design shown above. Some questions that were raised:

• Should the stepper include numbers and labels as does the wizard. Without this, the control has limited use as a navigator. Should this be brought more in line with the wizard as a common component for both designs.
• Need to consider accessibility for keyboard and non-sighted users.
• Do we need both future/disabled and future/active states as for the wizard.
• Should the target approach be more or less consistent with a wizard? Currently feels like an awkward middle ground.

RH Customer portal implementation can be found here: https://access.redhat.com/solution-engine

[mcarrano]

Met today with @serenamarie125 to better understand OpenShift requirements. The following is a demo of how the progressive form is used to create a new Image in OpenShift: https://youtu.be/EdEZ6xsnxvg

We should consider whether this is best built as a demo in PatternFly that elaborates a form component by adding anchor links, and the ability to scroll the form using keypress events. May want to consider whether a sticky footer or floating actions will improve usability (eliminate the need to scroll to find submit button).

[mcarrano]

A usability study was completed to compare performance and user preference for a progressive form vs a wizard in a simple object creation use case. A report on this study can be found here: https://docs.google.com/presentation/d/1pU5XdhtzHCA8hgIPY74egypj8dUJ8_M10_25zOqMKww/edit?usp=sharing and prototype for testing here: https://preview.uxpin.com/cc889a55d206dbb2a21f4c01351624e9c513f212 The prototype presented a step-wise task as a single scrollable form without including Next and Back buttons. The user could use the keyboard as well as the mouse to scroll through the form. Completion was via a submit button at the bottom of the form. A stepper located in the left-hand margin allowed the user to jump around within the form by scrolling to a pre-defined anchor upon click.

Some high-level take aways:

• The progressive form performed marginally better than the wizard and was the preferred approach for most users. Participants liked the ability to have all settings presented on a single scrollable page rather than broken into smaller chunks. There was some concern that this advantage might break down for very large tasks (more than 10 steps), however.

• Numbered and labeled steps were important as well as providing a clear sense of where the user currently is in the process (e.g. percent done).

Recommended next steps:

• Further refine the design of the stepper navigation leveraging some of the earlier work done here. It would be desirable to reuse the same stepper between the progressive form and wizard.
• Build a Progressive Form demo that mimics the prototype used for testing. Other than introducing the stepper, it should be possible to build this from existing components.

Need to assess roadmap priorities for this.

cc @rachael-phillips @LHinson

[andrew-ronaldson]

@mcarrano Here is a link to the latest mockups using jump links instead of the Wizard styling. I'll record a separate demo and share soon.

[andrew-ronaldson]

Here's the demo recording. https://user-images.githubusercontent.com/28658548/164783252-a75d2163-aa21-4546-a5d0-98b094a2bc54.mov

[mcarrano]

Thanks @andrew-ronaldson . I have opened https://github.com/patternfly/patternfly/issues/4805 to move this along and create a demo that shows how to make this. @mmenestr we will probably need a design doc issue also for follow up.

[mmenestr]

Design doc issue: https://github.com/patternfly/patternfly-org/issues/2962