Live data from Hacker News

Jelly UI: Soft-body physics for native HTML form controls

jelly-ui.com

61–70 of 209 posts

Re: Jelly UI: Soft-body physics for native HTML form controls

#61
post #43

Please never use scroll-snap as is done on this demo page (unrelated to the soft-body physics). It leads to an awful experience for a large fraction of users. It improves things in one or two scenarios, but at the cost of far more common great frustration. Scroll-snap is a really risky feature, very niche in its reasonable applications. This is definitely not a suitable place to use it.

> It leads to an awful experience for a large fraction of users. can you give an example of why/how? I thought it was well done and enjoyable. Regular fast scroll was still as expected, and then the slower interactions felt like slide changes.

Navigating by clicking and holding a desired position on the scrollbar is completely broken.

Re: Jelly UI: Soft-body physics for native HTML form controls

#62
post #43

Please never use scroll-snap as is done on this demo page (unrelated to the soft-body physics). It leads to an awful experience for a large fraction of users. It improves things in one or two scenarios, but at the cost of far more common great frustration. Scroll-snap is a really risky feature, very niche in its reasonable applications. This is definitely not a suitable place to use it.

> It leads to an awful experience for a large fraction of users. can you give an example of why/how? I thought it was well done and enjoyable. Regular fast scroll was still as expected, and then the slower interactions felt like slide changes.

It's completely broken if you use it with a mouse that has a scrollwheel.

Re: Jelly UI: Soft-body physics for native HTML form controls

#63
post #43

Please never use scroll-snap as is done on this demo page (unrelated to the soft-body physics). It leads to an awful experience for a large fraction of users. It improves things in one or two scenarios, but at the cost of far more common great frustration. Scroll-snap is a really risky feature, very niche in its reasonable applications. This is definitely not a suitable place to use it.

> It leads to an awful experience for a large fraction of users. can you give an example of why/how? I thought it was well done and enjoyable. Regular fast scroll was still as expected, and then the slower interactions felt like slide changes.

For me, I scrolled, clicked, but the page hijacked my screen, moved its position by force, and I was not certain which pane I was on immediately. It broke my sense of continuity.

I am only being literal when I say this, but as someone who is actively keeping an eye out for this sort of thing (CSS frameworks, UI kits), I lost interest pretty immediately when I saw that and closed the tab immediately. Assuming the people who made this page also made the UI kit, it tells me their web design values run contrary to mine.

I don't even fall into one of the exceptional cases, and this was a very bad using-a-website experience for me.

Re: Jelly UI: Soft-body physics for native HTML form controls

#65
post #43

Please never use scroll-snap as is done on this demo page (unrelated to the soft-body physics). It leads to an awful experience for a large fraction of users. It improves things in one or two scenarios, but at the cost of far more common great frustration. Scroll-snap is a really risky feature, very niche in its reasonable applications. This is definitely not a suitable place to use it.

> It leads to an awful experience for a large fraction of users. can you give an example of why/how? I thought it was well done and enjoyable. Regular fast scroll was still as expected, and then the slower interactions felt like slide changes.

On a desktop or laptop computer, most trackpads have an immediate response curve. I am using one now, an Apple Wireless Trackpad. A very large amount of engineering effort over decades of time and millions of lifetime hours went into making it behave that way over a common wireless medium. I scroll a little bit, it scrolls a little bit, immediately, I scroll a lot, it scrolls a lot, immediately, and if I flick my finger from the bottom to the top and let go, it behaves as if I swiped a page of paper on my desk in the same fashion, with inertia taking over, proportional to how fast I flicked.

There is therefore an intrinsic physical link between the actions of my fingers, and the motion on the web page. My finger moves, and an immediate, proportional response is observed. This is an utterly base level of how most humans interact with the world. It is why using a mouse or trackpad came quite easy to many people (and why some can flick a mouse in a shooter, turn a precise 274.9 degrees, move up 14.2 degrees, and click on the head of an enemy player in fractions of a second with pinpoint accuracy). It is also why even a toddler can use a touchscreen; direct manipulation is inherently understandable to even a baby.

When I am turning in a screw by hand with a screwdriver, the feeling of the screws threads through the handle into my fingers, the immediate force feedback, the observable, feelable progress of the screw in or out of its screwhole, forms this same interface. Where human and tool meet, latency and unexpected behavior, especially if divorced from the input force, are undesirable qualities of a tool.

Scroll jacking is to a trackpad or a fine scroll wheel as turning a screwdriver handle by twisting a bungee cord is to using a screwdriver. It unhooks the immediate, direct feedback from the motion of my hand; its jarring, unpleasant, frustrating. On this page, I immediately put two fingers on the trackpad and moved them less than a centimeter, and didnt let go, and the entire screen cycled its view, as if I pressed a button "move to next item". Except I didn't (and why would I want that in the first place???), I just moved my fingers less than a centimeter. Nothing in the real world moves like that except for things less than a centimeter away from falling out of balance. And it feels the same. Precarious. A common human reaction to things moving out of proportion to our body is nausea!

I think a better question is, can you give an example of "why/how" this solves any actual problem someone would have had scrolling this website had it not used scroll snapping? Would the top comment have been "Boy I wish this site had used scroll snapping, it would have been more well done and enjoyable that way"?

Re: Jelly UI: Soft-body physics for native HTML form controls

#67
post #62
post #43

Earlier quoted context omitted.

> It leads to an awful experience for a large fraction of users. can you give an example of why/how? I thought it was well done and enjoyable. Regular fast scroll was still as expected, and then the slower interactions felt like slide changes.

It's completely broken if you use it with a mouse that has a scrollwheel.

I had no problems moving one tick at a time with my mouse wheel.

Re: Jelly UI: Soft-body physics for native HTML form controls

#68
post #6

I'm having trouble identifying any physics at all in this UI design system.

The library does respect the client-side reduce motion setting (by disabling all animated effects).

Wow I actually like it just fine with motion reduced, but it's unbearable with full motion.

Re: Jelly UI: Soft-body physics for native HTML form controls

#69
post #62

Earlier quoted context omitted.

It's completely broken if you use it with a mouse that has a scrollwheel.

I had no problems moving one tick at a time with my mouse wheel.

This is why you don't override basic interactions like scrolling. Good luck ensuring that your setup matches everybody else.

Re: Jelly UI: Soft-body physics for native HTML form controls

#70
post #43

Please never use scroll-snap as is done on this demo page (unrelated to the soft-body physics). It leads to an awful experience for a large fraction of users. It improves things in one or two scenarios, but at the cost of far more common great frustration. Scroll-snap is a really risky feature, very niche in its reasonable applications. This is definitely not a suitable place to use it.

> It leads to an awful experience for a large fraction of users. can you give an example of why/how? I thought it was well done and enjoyable. Regular fast scroll was still as expected, and then the slower interactions felt like slide changes.

Some of the "slides" have more content than fits vertically in the viewport, and trying to scroll to the bottom to see it without getting bounced to the next slide or back to the top is very touchy and tedious.
Post reply on HN