range slider component about react95

[arturbien]

@benwiley4000 that would be great man! I think it's doable with styling alone, without any images. As I can see it- you could make the handle with one rectangle with styled borders (just like in buttons), and apply some pseudo element on it and rotate it? If not, you can always do a rectangular one, and we gonna find some CSS ninja to help us out some time later 😂

[benwiley4000]

Here's the Cassette ProgressBar component. It doesn't contain any styling in its own but it handles all the mouse/touch interaction logic. As mentioned it might be a good idea to use a range input since that obviates pretty much all of this code. https://github.com/benwiley4000/cassette/blob/next/packages/components/src/ProgressBar.js

[benwiley4000]

I would be willing try to work on a PR for this but I'm not sure how to get the slider handle.

[benwiley4000]

Ok, I'll try a few things and get back.

[benwiley4000]

I'm currently working on implementing something for the media player component I'm building, and when that all seems good I plan to extract it as something useable with this library.

Something that's a bit challenging is the tick mark/label placement. Windows seems to implement some pretty complicated logic there..

Here are a few observations I have based on trying several pieces of media of different length and resizing the window:

1. Depending on the size and width of the range selector you will have intervals like 0.1, 0.25, 0.5, 1, 2, 5, 10, 15, 30, with a tick above each label
2. Sometimes the ticks get too crowded and there isn't room to print all the labels so it just prints every other label.
3. In the media player you will almost always see the second to last label hidden since the last tick doesn't fall on the standard interval - instead it marks the end of the track length, so is located physically close to the tick before it.
4. In some cases (like making the window veeery small) it might have multiple ticks in a row that can't display.
5. It seems like they tried to design their UI so it would switch to a larger tick interval as soon as the ticks become too crowded, but maybe it didn't work so well and so they have this auto label hiding mechanism to deal with it. It really seems to reflect which labels can be physically drawn to some extent... But I can't imagine it would be performant to measure that on the fly, so they probably have some formula for all of it.
6. I can't tell if the numbers are monospace but it does seem that every label takes about the same amount of width, which would simplify the formula.
7. I think an ideal re-implemented version of this would get rid of the case where ticks are too crowded and labels can't all be drawn - as soon as the labels are too crowded, we switch to a larger tick interval.
8. The exception would be the second to last tick in the case of something like media.. there's no way we can draw that one.
9. My brain has been hurting trying to think about how to encode these rules in JavaScript... Any ideas? Haha
   10. There's no tickmark or label for 0 idk why I wrote this, not true lol

I have a Google drive folder with a bunch of windows95 screenshots which helped me figure out how these rules worked. Several of the adjacent pairs of screenshots demonstrate breakpoints. https://drive.google.com/folderview?id=1_AMs259O1kHc-ov2JIcLi3e6drNDt7Cm

For example, in one screenshot, we have ticks displaying at 2 second intervals - 0, 2, 4, 6, 6.12, and only 6 is hidden.

When we make the window a bit smaller, we have the same ticks but now only 0 and 6.12 can be drawn as labels (2, 4 and 6 are hidden, although 6 would always be hidden regardless).

Finally, we make it just a bit smaller and the breakpoint kicks in.. now it's a 5 second interval, but still the only labels we show are 0 and 6.14, because 5 is too close for them both to be drawn (this is probably the same rule as we've discussed before with second-to-last).

For all the other cases I found, it tends to only hide every other label, so it's possible that's something simple enough to encode.

But again, as I said, the simpler implementation would probably do away with any variable logic on which labels get drawn or not. It's highly possible it wouldn't ever stand out aesthetically as a meaningful difference. The big question is if it somehow takes away from the user experience to have fewer tickmarks?

[arturbien]

@benwiley4000 any progress? 🕵🏻‍♂️

[benwiley4000]

Now that I've written all that up I'll definitely be referring back here. 😄 But yeah, any thoughts?

[benwiley4000]

Perhaps the "should I draw or not" logic is,

1. Can labels be drawn at the tick interval without overlapping? Draw them all (except the second to last)
2. No? Then draw labels for every even-indexed tick (starting at index 0) but stop drawing as soon as a label would overlap with the label for the final tick, which we must draw
   • I think that nuance explains why we can't draw the label at 4 seconds in the 2nd screenshot above

[arturbien]

@benwiley4000 now that's a great essay 😂 Remember we are not trying to exactly recreate every aspect of Windows95. The most important thing is to make it work on mobile devices so we shouldn't get too fixated on small details like how it originally worked in Windows.

We should have 3 variants of the Range component:

• no ticks && no labels (I think this variant will be used the most especially in mobile apps)
• ticks && no labels
• ticks && labels

As for the tick/label thing- most of chart libraries like Recharts implement such behaviour that tick intervals and labels change/hide when the chart is resized, so we could borrow some code from them 🤷‍♂️ Example here.

Another idea 🔥 We could show currently selected value when the user is interacting with the slider (we could use a <Tooltip /> component for this) just like on the sliders below:

[benwiley4000]

I was going to share this awhile ago and forgot. I don't know when I'll have time to tackle this for React95 but in the meantime I can share the code I used to implement this for my own project. I'm using a MediaProgressBar from cassette internally so that would need to be replaced (potentially with a similar implementation) but we also might be able to just use a styled version of <input type="range">, which has the advantage of letting us avoid a bunch of fancy event handlers.

Anyway this is what I have:

• ProgressBar
• ProgressRuler

[arturbien]

closed by #79