docs: Add tui-slider widget to showcase

[sorinirimies]

This PR introduces a new tui-slider documentation and demo tape. For detailed documentation please visit https://github.com/sorinirimies/tui-slider

Tui Slider Features:

• 🎚️ Horizontal and Vertical sliders - Support for both orientations
• 🎨 Border styles - Multiple border style options with customizable symbols
• 🎯 Title alignment - Left, center, and right title positioning
• 📊 Value alignment - Flexible value display positioning
• 📍 Vertical positioning - Label and value positioning for vertical sliders
• 🎨 Progress bars - Use as progress indicators without handles
• 📊 State management - Built-in state for value tracking

[orhun]

This is pretty cool! Feel free to add it to https://github.com/ratatui/awesome-ratatui as well

[sorinirimies]

Thx @orhun I took my time to make it as configurable as possible. Yes, I also added the docs in the awesome-ratatui ratatui/awesome-ratatui#226

[joshka]

I'd suggest make images smaller - take a look at your repo's readme on your phone and see if the images really highlight the look and feel or just look overly resized...

[sorinirimies]

@joshka given that the slider is highly configurable and has many permutations I really wanted to highlight this through the examples. I just checked on mobile and compared my pictures with some other ones in your project and don't really see an issue with the size of my pictures tbh. There simply is allot of configuration, customization and wanted to make that as clear as possible through the examples. I therefor prefer the way I created my examples as in this case it was intentional and purposeful.

[joshka]

My rationale for this is that I've looked at a lot of screenshots and how they show up on GitHub readmes. The space available is about 1000 pixels wide, even on laptops and larger screens,. Ive found that using a width between 800-1200 pixels with the default VHS font size settings is about right. 1600 is much too big. Smaller images make your content shine much brighter, which is useful for a widget library. Finding ways to not show all the possible combinations of things is often a good idea, especially on the showcase part of the site, or your initial read me screenshot.

My observation of looking at this on my cell phone is that I can't distinguish what makes this useful over the built-in widgets as the parts that make this library special are too small to make out in the images.

[joshka]

An example of this being a bit better sized (based on the horizontal tape file in your repo, removing a bunch of whitespace, padding, default font-size, 1200 x 1040, etc.

See #986 for more details on our standards for apps. The same thinking on this applies to widgets. We want the widgets on the showcase to be clear. Large images with small fonts are not good at showing why you might want to use a widget.

Aside: you may want to consider hosting your images not in the repo to avoid bloating your git history. You can't reduce the size of previous images without rewriting history. Consider VHS hosting, hosting as attachments on git issues, or using git-lfs to store the images that you use rather than directly in the repository.

[sorinirimies]

@joshka thx for the tips will try something out and get back to you. Regarding storage I was thinking of git-lfs, I am familiar with it as we use it internally at Porsche for our screenshot tests, so i could try that.

[sorinirimies]

@joshka I refactored the tapes and adapted the layouts to be more mobile friendly.

[sorinirimies]

Hi guys @joshka & @orhun , so how do we proceed here?

[orhun]

I think this looks good. I pinged Josh for another review.

[joshka]

1600 is too wide for the showcase page. Please make this work with 1200 and the default VHS fontsize.

[sorinirimies]

It's wider because I have 2 pages the 2nd one being the vertical sliders. So if I make it more narrow then the vertical sliders are squeezed together. The width set to 1200 makes the 2nd page look like this:

[joshka]

This is insufficient time to read all the text on the page. Use longer dwell times when there are many labels on the screen. The animation should make it easy to read each of the labels so that users can get an idea of what the options are.

[sorinirimies]

I profoundly disagree. The demo is showcasing the shape and behaviour and given the huge amount of content and variations 1.5 is enough. There are other widget examples where the demos are similar or faster in speed.

[joshka]

Primary guiding principal for the showcase: does this make me want to use this.

The text size is much smaller than the other items on the showcase. It looks out of place. The text should be larger. Use the default vhs text size and max width of 1200 (I'd suggest for this sort of widget 800-1000 is probably better). Think about how much of the screen is occupied by the actual widget and how much is occupied by not the widget and try to increase that.

The grey text on this makes it difficult to read the titles on each of the configs on this.
There's no need to have a strong contrast for the selection box on the demo (or perhaps there's no need for one at all.
The movement between screens is too fast and doesn't allow enough time to actually look at each option. The show case is not about animation. It's about showing how TUIs look. For the most part these are static. It's fin to show some interaction, but it's not the goal of the page.

[sorinirimies]

Naaah, will change ZERO, I like it how it is now. It's fine not to merge it, just disappointed on the nit picking bullshit that's all.

[joshka]

I think part of the disconnect here is on me. I’ve been giving fairly specific feedback (image size, font size, timing, etc.) without doing a great job of explaining the underlying reasoning behind it.

Stepping back a bit, what I’m trying to optimize for in the showcase is something closer to basic design principles rather than specific rules. Things like:

• legibility at smaller sizes (especially when the page scales things down)
• strong contrast (dim text and thin lines tend to disappear when resized)
• clear visual hierarchy (what stands out in the first second or two)
• keeping the signal high (fewer variations so the core idea is obvious)
• calm, readable motion (enough dwell time and not too many rapid changes)

The mental model I have is: I want someone to see the gif, immediately understand what’s interesting about it, and click through to your repo/docs/crate to learn more, rather than just scrolling past it.

Looking at these in context (e.g. https://ratatui.rs/showcase/third-party-widgets/), when we try to show a lot of configuration at once, it tends to have the opposite effect. The details get smaller, contrast drops, and the thing that makes the widget compelling is harder to pick out.

This is especially noticeable on mobile, but I’m also seeing it on a 16" MacBook Pro. The current version feels quite busy and hard to parse at a glance, and the lower contrast + smaller text makes it harder to quickly understand what’s going on.

Similarly, when there are a lot of fast or simultaneous changes in the animation, it becomes harder to follow what’s happening. You don’t really get enough time to read or understand each state before it moves on.

That’s why I’ve been pushing on things like reducing width, simplifying layouts, increasing dwell time, etc. Those are really just proxies for the above, not goals in themselves.

Also, this isn’t unique to your PR. We already have a couple of items in the showcase (e.g. ratatui-image and tui-checkbox) that I think have the same issue, and I’d like to bring those more in line as well.

I completely get that your examples are intentionally showing the flexibility of the widget, and I think that makes a lot of sense for your repo. For the showcase though, we’re aiming for something more like a single strong “hero” representation that draws people in.

Happy to iterate on this together, and also very open to better ways of expressing or applying these principles, since I’m still figuring out how to communicate this clearly myself.

[sorinirimies]

@joshka I see, I thought the expectation was to also change the presentation in my repo internally but I understand now it was meant only for the gif in the presentation here. If that is the case then I retreat my accusation of being nitpicking and apologize accordingly.
I would agree with PlaybackSpeed being set to 1 and using the default VHS font size for this showcase.
Reducing the width to 1200 is problematic because I am showing both horizontal and vertical sliders in the same tape and setting it to 1200squeezes the vertical examples together and breaks the presentation.

[joshka]

@joshka I see, I thought the expectation was to also change the presentation in my repo internally but I understand now it was meant only for the gif in the presentation here. If that is the case then I retreat my accusation of being nitpicking and apologize accordingly.

No problem - I totally understand how the points I've made here seem arbitrary / nit picky without the grounding of the background. We're trying to clear that up a bit in #1104 and would value your feedback on whether it might have helped avoid this.

Reducing the width to 1200 is problematic because I am showing both horizontal and vertical sliders in the same tape and setting it to 1200squeezes the vertical examples together and breaks the presentation.

Falling back to the above point. I'm not asking to change your repos demos - that's your call. What I'm suggesting is to find a way to make it so the widget parts of the widget take up as much of the screenshot space as possible / reasonable. That might mean dropping the borders, and perhaps changing the labels so they're narrower (e.g. LFO / Cmp/ Atk / Dec/ Sus / Rel) instead of being super wide (13-14 cols or so).