[RFC] Carousel Component Requirements

[gabrielwalt]

[Request To Comment] To anybody who intends to use the Core Components, please provide your feedback about the following requirements for the Carousel component. We want to make sure that we build a component that fits your needs, so don't hesitate to tell us how that component should work, so that you will be able to use it.

User Story

As an author, I want to create a carousel on my page, so that a rotating list of teasers is displayed to the visitors.

Acceptance criteria

Behavior for the page visitors

• Display the teasers sequentially one after the other with a sliding animation:
  • don't slide to the next element when the visitor moves the cursor on top of the carousel (eg. reset the slider's timer)
  • in case there's only one item in the carousel, don't slide anything
• Allow visitors to control the displayed item:
  • slide one step forward or backward with arrows on the left and on the right
  • slide to any step by clicking on the bullets (which feature a title attribute that corresponds to the item's title)
  • if there's only one item in the carousel, don't display the carousel controls
• Meet the WCAG 2.0 accessibility standards

Editing capabilities for the authors

• Allow to easily add, remove and reorder the carousel items.
• For each carousel item, provide the same authoring options than the Teaser component offers:
  • same editing options on the page
  • same policy configurations options
  • same in-place editing options
  • same drag&drop options from the content finder (eg. for image and page mime types)
• For the item images, feature the same capabilities than the image component offers:
  • same in-place editing options
  • choosing of the optimal allowed size
  • but make sure to not flash the images as they are moved into the view (some pre-loading is needed)
• Support content targeting within the carousel (so you can use Adobe Target or client-side rules to test/target various banners).

Notes

• This new carousel component will serve as replacement for the foundation carousel (foundation/components/carousel) and slideshow (foundation/components/slideshow) components.

Wireframes

Example of a possible appearance for page visitors:

Possible authoring with placeholders that unfold like accordions to edit the different carousel items:

Possible edit toolbar dropdown to select the item to edit:

Possible authoring with the different carousel items as tabs in the edit dialog:

[vladbailescu]

I would rather we don't enforce the type of component that can be used for the carousel and accept any component (text, title, image, teaser, list etc.). What would make the carousel different from the container would be the possibility of switching between items (manually or automatically). For editing the items I would rather we rely on the native editing dialogs of each component.

[reusr1]

you may want to consider placement and alignment of the overlay text as left, right, center. It should be easy to allow for full page with and height of the carousel and allow for videos to be placed into a carousel. It may also be a good idea to use a separate editor view to manage just the slide show to make editing large slide shows easy (use case for 10 to 100 slides).

[jckautzmann]

@reusr1 Thx for your feedback. WRT editing of a large slide show (100 slides), what exactly do you have in mind? A grid view made of small cards for each slide? Something else? Sketches are welcome :)

[anthonycaccese]

Reading the page visitor notes is it safe to say that one of this components core use cases is being as a teaser/promotional list of pages?

If so I figured it might be helpful to show a walkthrough of how we handle the authoring aspect of components like this in our current instances.

Essentially we built a custom touchUI interaction using the combination of an accordion and a multi-set.

And we did that to allow for the following workflow patterns:

• Drag and Drop of pages into path fields that automatically bring in metadata of the associated page (its image, title, URL, etc...). We do this to save our content creators time from duplicating the context they have already added to the page they are referencing.
• Reordering of promotional items through drag and drop using the accordion
• Allow for a flexible amount of items to be added (1 or many). We do this so our content creators can focus on promoting the stories they want to tell while we automatically adapt the UI based on the number added

Here is a video walkthrough: https://www.dropbox.com/s/7ycvovunxxo7nlx/f5a4e7efb3414d048f456e03796d9bc1.mp4?dl=0

Granted our implementation doesn't yet account for inline editing so we are starting to think through inline edit applied to the workflows I demo in the above video (drag and drop, metadata update and overrides). And also this is fairly custom currently so we are looking at ways to build a pattern like this more natively in touchUI if possible.

Hope this helps think through possible options for an authoring pattern and please if you have any questions I am up for talking any time.

[jckautzmann]

@anthonycaccese Thx a lot for your feedback and for your valuable demo! We have something similar in mind and are considering using a multifield widget to edit the slide title and to re-order/delete slides. Editing the slide would happen on the page by selecting the slide and opening the edit dialog of the slide component. Adding a slide would happen by dragging & dropping an allowed component directly to the page. We'll hopefully soon provide a "skateboard" version of it, stay tuned!

[vladbailescu]

One of the ideas we're exploring in parallel to the edit dialog is to provide a toolbar widget/dropdown that allows switching carousel items and reordering them:

https://drive.google.com/file/d/1yLCGqOUm93ZkbvTmiUc6lpxD43kpyK3C/view?usp=sharing

For adding, editing and removing slides/items in the carousel the normal editing options would be used. You can check a proof-of-concept at https://github.com/Adobe-Marketing-Cloud/aem-core-wcm-components/tree/carousel-toolbar-dropdown

[znikolovski]

Have we considered a use case where we construct a carousel out of a collection? We could provide a specific carousel item structured content fragment which could be included in the collection (to denominate whatever non-DAM asset we want to reference within the Carousel).

Collections are also orderable and similar to the way the Experience Fragment component toolbar allows to deeplink into the associated XF, so too the carousel can link back to the collection.

Lastly, this would mean that we can reuse the collection for more than one carousel (without the help of experience fragments)

[richardhand]

Thanks to all who contributed ideas to the Carousel [RTC]! With the recent 2.2.0 Release of the Core Components we have a first version of the Carousel Component available and will therefore be closing this issue.

The great ideas here that didn't make it into the release (ability to define Carousel items from a collection / improved editing of large scale slideshows etc.) we have tracked and hope to introduce as future enhancements.

For future ideas for the Carousel, or any other component, feel free to create a new GitHub issue.