Add Block: Slideshow

[karmatosed]

Relating to #744, here is what a slideshow block could look like.

A few points:

• I have looked at what slideshow plugins offer and tried to distill the options we offer. What we do is probably a point of debate.
• Ideally this would be responsive out of the box, Flexslider can teach us a lot there: https://woocommerce.com/flexslider/

[melchoyce]

Very cool!

Some feedback:

• Per Porting widgets to blocks: Standards #1011, I think we've decided to exclude block titles, so you won't need the "My slideshow:"
• What if the slideshow settings didn't appear until an image has been selected, to streamline the process of getting started?
• We should standardize either "show" or "display" in Inspector labels. I've been using them inconsistently in my mockups, but we should pick one and stick with it.
• I'm not sure just from reading the settings what the difference between "dot" and "image" pagination is; is "image" different than "arrows?"
• What's your plan for showing titles, captions, and links? Overlaying the slides, above and underneath, etc.
• "Slide speed in seconds" sounds a little weird when I read it; maybe "Slide duration (in seconds)"?

[karmatosed]

Thanks for the feedback!

Per #1011, I think we've decided to exclude block titles, so you won't need the "My slideshow:"

Ah good, let me iterate there.

What if the slideshow settings didn't appear until an image has been selected, to streamline the process of getting started?

I was torn as think I have seen behaviour vary in blocks, but I do like that and lets try and bring some consistency.

I'm not sure just from reading the settings what the difference between "dot" and "image" pagination is; is "image" different than "arrows?"

The idea is either you see dots or actually the photographs to click through. I agree that a lot of the wording could be vastly improved. Lets fix that :)

What's your plan for showing titles, captions, and links? Overlaying the slides, above and underneath, etc.

Yes that would be the plan. I think initially having them in a fixed place avoids spiralling options, but interested in exploring the fine line that is limiting those.

"Slide speed in seconds" sounds a little weird when I read it; maybe "Slide duration (in seconds)"?

Much better! Thanks.

Here are the iterations:

[getsource]

The last time around that this came up, it was decided that this was a bad practice for users, and not a good fit for core. What has changed here?

[AdsonCicilioti]

Would the idea be a SlideShow just to present images? I think I could support blocks with rich content: image, caption, Description (excerpt), Buttons, background, layout options ... Just my suggestion.

[StaggerLeee]

A one big YES for this block.

I am so tired of all those slider plugins that convert whole backend to one colorful circus. They all have PRO/Premium version, and they simply dont know when it is time to stop pushing unnecessary things under people`s noses.

[StaggerLeee]

I'm not sure just from reading the settings what the difference between "dot" and "image" pagination is; is "image" different than "arrows?"

Images are small thumbnails under slider. If I understood right your question,
Beside this you have to hide thumbnails in mobile. Or take care of mobile display in some way, but it is not easy. Hiding is best solution.

It is here in this Flexslider example.
http://flexslider.woothemes.com/thumbnail-slider.html

They decided not to hide them in mobile display. I have no opinion about it, taste thing. Specially because it is easy to hide them if needed.

[melchoyce]

The last time around that this came up, it was decided that this was a bad practice for users, and not a good fit for core. What has changed here?

Couple thoughts on this:

• The older I get, the less concerned I am with the "purity" of websites. People are going to add what they're going to add because they want it. Our job is to make sure that when they do, we provide both the best user experience for both content creators and site viewers, and best practices for modern browsers and devices.
• By providing a basic slideshow block for folks to use, they might be discouraged from looking for alternatives that aren't providing a good experience, or using best development practices.
• By making this block, we also might be providing a better template for plugins to work off of.
• Honestly, I think there's a (small) difference between slideshows and sliders. Sliders are dynamic banners. Slideshows are galleries with progression, either manual or timed. Sliders are informational, slideshows are presentational. The second use case is, IMO, totally valid.

[karmatosed]

The older I get, the less concerned I am with the "purity" of websites. People are going to add what they're going to add because they want it. Our job is to make sure that when they do, we provide both the best user experience for both content creators and site viewers, and best practices for modern browsers and devices.

This really is how I feel too, so well put! Time and time again we have all seen users add slideshows to sites with varying success. This gives us a chance to install those best practices.

Honestly, I think there's a (small) difference between slideshows and sliders. Sliders are dynamic banners. Slideshows are galleries with progression, either manual or timed. Sliders are informational, slideshows are presentational. The second use case is, IMO, totally valid.

I also feel this is a really good point and worth thinking about.

[StaggerLeee]

Clients ask for slideshows, so what to do about it. Nothing.

Actually they regard them as some NASA cutting edge coding technology. Believe in some way web companies make slideshows from scratch, line by line of own code specially for his/her website.
And they are very shy and ask about them carefully. Have no proof why, my feeling is most of them think it is something extremely expensive to pay. They regard it as most expensive part of website.

[ellatrix]

I think it was brought up a while ago: should this be a version of the gallery block? Or a setting in the gallery block? Should it maybe be so, while providing a shortcut in the inserter, much like embed blocks? Or should there be some kind of proto-gallery block, so both (or more) share the same data type, and so we can add the possibility to switch between them? Maybe this is just providing too many possible flows, and you could just delete it and start over... I just want to bring it up.

[StaggerLeee]

If I can ask, please let developers (or Admin) by simple filter chose if galleries will be forced as WP native gallery (new block now), or as slideshow.

Giving Users freedom to mix those two, one Post with old gallery, next Post with slideshow is allways bad visitor experience. And looks amateurish besides.

At the end, if we get what is promised, to be able to remove specific blocks. Then this problem is easy solved. Simply disable old native Gallery block.

[hedgefield]

Looks good @karmatosed! I agree that a slideshow block is something that photographers and illustrators will want with high probability. They are different from sliders, but I guess could be used similarly, that's up to the people who want to use them. We can't make that decision for them.

About the actual design, looks like it has all the features I'd look for in a slideshow. I would center the arrows vertically on the sides, possibly making their click target extend along the entire height, I always appreciate that. They should only appear on hover. The rest looks good - dots/thumbnails, timed automatic progress, caption overlays, all there.

[robbisy]

@karmatosed is it possible to add categories select option in order to choose which post categories to display ?
And more broadly a code snippet for categories select option because it can be used in other blocks like latest posts in order to easely add or remove for those who don't want it

[karmatosed]

@robbisy it could be but I am wary of adding complexity to the block in v1.

[karmatosed]

As the project moves towards merge proposal, we are moving issues that aren't needed for that to projects. This doesn't mean they won't get done, they totally can and that's why we're moving to projects. This allows us to focus on the issues that have to happen to Gutenberg. I am closing this but it will live in projects.

[strarsis]

#6608

[Chris2011]

As I see your comment @karmatosed that you moved the issue into a project and closed this issue, what is the progress of that? I mean what happens with this ticket/project card?

[strarsis]

@tg-ephox: Have I unassigned you somehow? I just noticed this in the log above and I find it confusing.