Component: Stepper - Githubissues

macandcheese commented 5 years ago

This is a good candidate for inclusion in Calcite Components - it's used widely across apps and is inconsistently implemented. We'd probably want to support:

title
subtext (useful for persisting small contextually relevant data from past steps for a user to see without navigating back, especially on mobile)
"returnable" - that is, are previously completed steps available to click on to view again
incorporate mobile designs
support for "error" (red) state on steps
possibly include ability to add icons
slot for step "content" similar to tabs
should have a vertical orientation available at desktop size (pretty similar to mobile designs)

The latest designs should be on the invite members workflow. I think we can adjust the spacing a tiny bit in our version of the component to utilize our spacing and sizing, and allow the component to be used inside a modal/takeover with a little tighter spacing.

macandcheese commented 4 years ago

Configurable apps has a need for steppers with indication of step state (complete, incomplete, partially complete).

cc @kstremel

-- Monitor has a need for a vertical alignment - should be visually similar to the eventual mobile implementation.

ehusaint commented 4 years ago

Also allow enable/disable tab as you move along the steps. Step 2 is disabled until Step 1 is not completed.

macandcheese commented 4 years ago

@evanmosby @ehusaint did you all have any other requirements for this component?

evanmosby commented 4 years ago

I think you have all the bases covered by what's been written above. Perhaps consider optionally decoupling the stepper and content, allowing the stepper to be controlled independently. I'm thinking the Monitor post install we're working on, as an example, where the content might be positioned away from the stepper itself:

abc123

ehusaint commented 4 years ago

Adam - Where are the requirements for stepper? Can I get a link to read through those?

On Tue, Jan 14, 2020 at 5:47 PM Evan Mosby notifications@github.com wrote:

I think you have all the bases covered by what's been written above. Perhaps consider optionally decoupling the stepper and content, allowing the stepper to be controlled independently. I'm thinking the Monitor post install we're working on, as an example, where the content might be positioned away from the stepper itself:

[image: abc123] https://user-images.githubusercontent.com/28676725/72397424-ba13c780-36f4-11ea-8603-3c64b174af56.png

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/Esri/calcite-components/issues/55?email_source=notifications&email_token=AFSH7E45IAY22YEEX3NW3ALQ5ZTLBA5CNFSM4HXKXNG2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEI6YLVY#issuecomment-574457303, or unsubscribe https://github.com/notifications/unsubscribe-auth/AFSH7E2JWR4ULTB4M3ZSNW3Q5ZTLBANCNFSM4HXKXNGQ .

-- Abde Syedna (TUS) Husain Tapiya

"Dream as if you'll live forever, Live as if you'll die today"

macandcheese commented 4 years ago

There aren't reqs / specs from a product driver, but it will generally follow the current stepper design used in the Invite Members workflow in Online, with a lot of additions and added functionality such as what is listed above.

I'll open a draft PR for API feedback after it gets built out a bit!

macandcheese commented 4 years ago

Proposed API

 <calcite-stepper icon numbered id="my-example-stepper">
    <calcite-stepper-item item-title="Choose method" complete>
    Step 1 Content Goes Here
    </calcite-stepper-item>

    <calcite-stepper-item item-title="Compile member list" complete>
    Step 2 Content Goes Here
    </calcite-stepper-item>

    <calcite-stepper-item item-title="Set member properties" item-subtitle="Some subtext" active>
    Step 3 Content Goes Here
    </calcite-stepper-item>

    <calcite-stepper-item item-title="Confirm and complete">
    Step 4 Content Goes Here
    </calcite-stepper-item>
</calcite-stepper>

Icons and numbers are opt-in, and can be combined.
item-subtitle can be used to persist contextual information for a use while the step is not active (useful for showing a key bit of info from a recently completed step, for instance)
Each step can have complete, disabled, or error state which affects styling, and in the case of disabled, navigability. They can also be combined (for instance, if you want to prevent navigation to an already completed item, you can combined disabled and complete)
Layout is horizontal / vertical: -- In horizontal, steps function as tabs with a shared content area in which requested step content is display -- In vertical, content is contained within the step
Either stepper orientation can be used on its own with no wrapped content, with a developer using emitted events with a detail of the active step to determine content to show in a separate area not controlled by the component.
Items with disabled attribute should not be navigable to by keyboard, or mouse, and display a not-allowed cursor on hover.
Methods used to navigate between steps (besides click / keyboard) for navigating with with buttons / other elements are: goToStep(#), nextStep(), prevStep(), startStep(), endStep()

Not sure the best way for devs to assign state (complete, disabled, error) - I'm leaning towards just letting folks set attributes on the <calcite-stepper-item> themselves vs. doing so with Methods

Keyboard:

Left / Right / Up / Down / Home / End navigates
Enter / Space activates currently focused item

Thoughts @ehusaint @evanmosby @Esri/calcite-components

Current sticker sheet:

note that the step content has no styling - in the examples below the step content just happens to be instances of calcite-notice components which adds the shadow, bg, and border.

driskull commented 4 years ago

The API looks good!

I'm leaning towards just letting folks set attributes on the themselves vs. doing so with Methods

👍

I'm guessing this would be a aria role of list/list-item?

Suggestions:

Maybe instead of item-title it could just be heading?
Can the generated number be exposed as a non attribute prop so that a user could access that step number incase they want to reference it in the content?
Should there be support for number type? Like this
Should there be support for reversing the list numbering? reversed?

macandcheese commented 4 years ago

Cool, thanks

Maybe instead of item-title it could just be heading?

I used item-title and item-subtitle to match Accordion Item.. we could switch to heading and sub-heading?

Can the generated number be exposed as a non attribute prop so that a user could access that step number incase they want to reference it in the content?

Yep, makes sense.

Should there be support for number type? Like this

Hadn't considered that... roman numerals make sense, are there translation considerations for "a,b"

Should there be support for reversing the list numbering? reversed?

Also hadn't considered that.. what's the use case? Reverse the numbers themselves or the order of steps as well

driskull commented 4 years ago

are there translation considerations for "a,b"

Yeah probably a different alphabet set.

what's the use case? Reverse the numbers themselves or the order of steps as well

I'm not sure, i was just thinking about the stuff you can do to a native <ol>

evanmosby commented 4 years ago

Looks great! Really like the state combinations and how they affect the nav.

Not sure the best way for devs to assign state (complete, disabled, error) - I'm leaning towards just letting folks set attributes on the themselves vs. doing so with Methods

Attributes will work very well - it would be fairly trivial to write controller methods that govern those attributes within a framework like Angular or Vue, if the workflow is more complicated. I also like the methods to advance the stepper, though attributes offer much more flexibility. An alternative to that might be a "current-step" integer property that can be set by the developer, though the same thing can be accomplished via state attributes.

Regarding property naming (item-title vs heading), my experience from other component libs has been "item-*", through I couldn't tell you why that choice was made.

Good stuff!

macandcheese commented 4 years ago

Great, thanks for feedback.

I failed to mention 'active' itself is also just an attribute, methods are just helpers for setting that on first / last / next / prev / goTo(#).

Adding 'active' on a stepper item will remove 'active' from all others, but leave any other attribute intact.

Additionally, if at initial load, 'active' isn't present on any stepper items, the component will set 'active' on the first item.

I figured we shouldn't let steppers exist in a state with no steps active, thoughts on that?

evanmosby commented 4 years ago

Oh cool -thanks for the clarification. The goTo(#) will be super handy for sure.

I figured we shouldn't let steppers exist in a state with no steps active, thoughts on that?

Makes sense to me! #TakeMyMoney lol

Esri / calcite-design-system

Component: Stepper #55