dynamicweb / swiffy-slider

Super fast carousel and slider with touch for optimized websites running in modern browsers.
MIT License
250 stars 29 forks source link

Add an infinite loop option #38

Closed SeoDeveloper01 closed 2 years ago

SeoDeveloper01 commented 2 years ago

I was going to use this lib in my project, but I had to refuse when I realized that there was no infinite loop option.

nicped commented 2 years ago

Yeah, that is one limitation due to the way this slider works. For this slider performance and load times are critical - implementing infinite sliders would be easy, but cost too much JS and not least DOM manipulation which will cause CLS which is bad for performance.

Since I primarily make websites that needs as high conversions and as low bounces as possible, in my view high performance will have a bigger impact on conversion and bounces than the infinite sliders.

Luckily there are several other options for sliders that offers what you need. But at a performance cost :-).

perdittmann commented 2 years ago

Would it be possible to insert a copy of the first slide after the last one (if not by DOM manipulation then by adding to the HTML by hand – and if a ".first-slide-copy" is not in a ".slider-infinite", we could hide it by CSS), and on successfully having slid to that last+1 slide, instantly move back to the first one (this time just a hard jump, not a smooth scroll), and then continue from there as if nothing happened? Or would this still be too heavy on performance? Or just too complicated to set up? Or did I just reiterate how every infinite slider already works anyway? (My smart talk exceeds my programming skills by far, I am sorry to say.)

nicped commented 2 years ago

Yes, I think what you describe would be the exact approach to solve this issue. It is also the best I have been able to come up with.

This would probably work relatively well. But then what if you show 2 slides per page or is using reveal - that would look weird and make things jump. And other things that would look like bugs. So even this approach would work for a clean 1 slide per page scenario, it would cause other issues in other situations.

This library already have an extensions JS file for mouse dragging. This infinite scroll feature could be added to that JS file as both these features are kind of the same thing - giving 'old fashioned' slider features that we think is great because we understand the complications of developing them - but has no UX benefits at all (in my view).

But it seems that infinite scroll is a big desire, so might be worth adding...?

nicped commented 2 years ago

One note to having both .first-slide-copy and .slider-infinite - I would probably keep this very simple and do something like .slider-nav-infinite would just move instantly to first slide after last slide has been shown. That's it.

If the CSS will start hiding and showing slides, calculations will start failing and then need to take hidden slides into consideration. That would again cause the JS to be larger and more complicated and then it starts to grow and grow to take all kind of odd things into consideration. The JS component decease :-).

perdittmann commented 2 years ago

I see, my view on the topic was very limited to the use case frontmost in my mind, and I understand that other use cases might make it way more complicated.

Actually, I personally don't need infinite scrolling, I prefer the extra bit of information "you have already seen everything, there is no use in staring at this any longer" when the slider "dials back". I had once been trying to get a pure-CSS slider work that way, but in the end, I decided it was not worth all the fuss. So my inserting myself with a follow-up question was merely academic, one could say. 😁

nicped commented 2 years ago

YES, I also think the UX with going back is much more explicit compared to going infinite.

But - you know in the world of developers, we have a tendency to prefer things that we think is cool because we know how difficult they are to make or how fancy the solution is. Not because the end user think it is needed!

I will lave the issue open to see if people just really want this - can be added to that extensions JS.

perdittmann commented 2 years ago

Yes, you are right about that. It seems you have been doing this for a while. 😄

And I really your the slider very much, by the way. It was like a prayer answered, after trying everyone's and their mother's sliders and shifting from compromise to disappointment and back (and wondering wether to tell all my customers sliders were a thing of the past 😉). There was nothing even close. Thank you so much! (And now I will try to refrain from capturing this thread with idle chat.)

nicped commented 2 years ago

Thanks!.

I actually consider Sliders in general as a thing of the past except for a few scenarios. Product images, news tickers and photo galleries as acceptable scenarios.

Having sliders on the frontpage with different "buy my product" messages is usually a hope for additional sales more than a proven way to increase sales. No one reads the frontpage anyways - they search or navigate. Carousels on frontpages has been measured many times to see if they increase conversions or decreases bounce. And they don't... Rational vs Emotional web design 😉

perdittmann commented 2 years ago

Absolutely. And when the reason to put a slider there is often mostly emotional (and in many projects I end up getting paid for what the customer wants, not what they need, despite my best efforts), it is even more important that it doesn't affect performance any more than necessary, while working the way they'd expect.

nicped commented 2 years ago

Love your approach!

I just made an example of infinite scroll using a bit of custom JS and an event listener: https://swiffyslider.com/examples/#infinite

The first slide is also the last - and then just move first when last is reached.

Works 'like a charm'

perdittmann commented 2 years ago

That looks great, congrats! I'd even add a .slider-indicators button:last-child{display:none} – that way, there is no last indicator that does not work exactly as expected. But probably that's just me and my limited view on use cases. 😉

nicped commented 2 years ago

Yes, of course. Added your css to the example. Thanks!

nicped commented 2 years ago

And also changed the script a bit to automatically create slide 1 as slide last...

perdittmann commented 2 years ago

But wouldn't that mean that the added slide in the HTML code could be left out? Or is there something I miss?

nicped commented 2 years ago

It is not there - but it is being inserted on 'load' event. So when you inspect with dev tools you can see that slide, but if you check the source, you will only see 5 slides: https://github.com/dynamicweb/swiffy-slider/blob/7b9a73247d51c9e3d743c6460253f4cd53c54e19/docs/examples/index.html#L1196

perdittmann commented 2 years ago

Ah, I see! Thanks!

perdittmann commented 2 years ago

Yes, of course. Added your css to the example. Thanks!

Ah, and for the sake of the demo page, better make that #infiniteSliding .slider-indicators button:last-child{display:none} 🤓😇

nicped commented 2 years ago

Yikes! My QA guy 😄

pneumotube commented 2 years ago

A quick question: does Swiffy slider support sliders loop by default? By the loop I mean switching to the first slide after the last. If it doesn't than why there's the "slider-nav-noloop" option to disable it? A little bit confused here.

And what is this infinite loop, the first slider on the examples page seems to have infinite loop with default settings.

nicped commented 2 years ago

By default Swiffy slider loops from last to first slide - by scrolling back as that is default browser behavior for scrolling containers. This example (https://swiffyslider.com/examples/#infinite) though mimics so it looks 'infinite' by adding a bit of custom JS that will copy the first slide as the last and 'ninja' jump back to the first.

Just to sum up - this slider is meant to be performant, accessible and focus on important stuff. I do not consider infinite important because it would mean DOM manipulation that causes additional JS complexity, increased download size, browser load times, CLS issues, accessibility issues and a whole range of things I believe should be avoided - to keep the website snappy, responsive and with superior UX on all devices.

I'll be happy to suggest custom work arounds - alternatively there are other great sliders out there with tons of JS that can do these things :-).

pneumotube commented 2 years ago

Loop from last to first slide is just perfect for me, glad to hear it's default behavior. Just got a little confused because on my test page the loop doesn't always work, but we are already discussing this with you in another issue. I'm sure that's something wrong on my end.

mhennessie commented 1 year ago

Just came across this when trying to accomplish the infinite scroll. I could not get the example to work as is, not sure why but I couldn't see any differences in my html structure and the only difference in the script was that I need to loop through multiple sliders on the page. Anyways, I ended up changing the infiniteScrollToFirstWhenOnLast() function slightly since it was never detecting that I was on the last slide. I decided to base position on the right scroll position as such:

const infiniteScrollToFirstWhenOnLast = () => {
    const rightScrollPosition = container.scrollWidth - (container.scrollLeft + container.clientWidth);
    if ( rightScrollPosition === 0 ) {

        container.scroll({
            left: 0,
            behavior: 'instant'
        });
    }
};
nicped commented 1 year ago

I think you cannot make it work because you are missing . slider-nav-animation from the slider - because that will enable the .slide-visible class that is used in that example.

Your approach is probably better since it does not require that additional setting.

Thanks - I will update the example to use this approach.