Trying to spruce up this 3d ticker wheel

[Shikkediel]

Hi all, I made this demo of a rotating counter and looking for some design tips to make its appearance as slick as possible. It’s pretty neat in itself but I’m not too happy about the styling:

https://codepen.io/Shikkediel/pen/qpjGyq

As opposed to this flat version which is less nifty but looks nice just by its background:

https://codepen.io/Shikkediel/pen/avVJdG

You can give it a whirl (the first pen) and it’ll start rotating as given speed. The second demo (which is the original version) is a bit more static but responds to dragging as well.

I gave the numbers a background image with a slight gradient at the bottom. And the parent an :after pseudo to add some overall shade. The edges seem to be a bit pixelated here and there – no matter if border, a png or svg is used.

Any suggestions for improvements are welcome and appreciated.

[Shikkediel]

Side note, I discovered that using perspective gets rid of that annoying little after-twitch you often see at the end of a transition in Firefox. That might be useful in the future because using a minute rotation (the usual approach) doesn’t always solve it.

It’s the top part especially that could use some improvement. The angle being quite large (36 degrees) in combination with a flat surface, makes the number at the top look off a bit.

I was thinking some border-radius to start with, even though that could be complicated…

Upper demo can now be mouse wheeled as well by the way.

[bearhead]

Maybe try with the reels sharing the same perspective?

[Shikkediel]

I’ll have to read up on it a bit more, as I’m not sure what you’re aiming at. Appreciate the reply of course. Tried a bunch of things and “accidentally” stumbled upon using perspective.

Having made the top and bottom edges of the background image quite subtle, as opposed to a harder edge, looks like an improvement too. The lower ends look quite alright, almost rounded even, despite it really being the same item as the one on top. May have to experiment with more gradients…

[Shikkediel]

Messing about with a :before pseudo, I happened to end up with something similar as the background for the second pen in the original post. For some reason just making it a bit darker works a small wonder. Not super happy but it’ll do, unless someone has a good suggestion.

Not sure there’s a trick to make it look slightly less angular. Border-radius doesn’t seem very suitable for that.

[Shikkediel]

sharing the same perspective

I see what you mean now, play around with that and perspective-origin perhaps…

Edited – I think my eyes are now starting to deceive me. :-/

[Shikkediel]

Getting there… made the reels smaller which I think improves the look and went from the background image showing borders to adding actual CSS borders – with an additional transparent pixel of outline that should prevent any jagged edges.

The edges seem to be a bit pixelated

I’ll still look into giving them a single perspective too but IE is spoiling much of the design process when it comes to inheritance.

Doesn’t look too shabby by now, much better than when I posted the question in any case.

[bearhead]

I was thinking something like this:
https://codepen.io/kvana/pen/ypoENq

But you’ll have to play with the shadows to get them to look right

[Shikkediel]

That does look pretty sweet when the perspective cascades with transform-style: preserve-3d:

It’ll need a workaround (if possible) for stupid IE not supporting the property though.

Hmm… jagged edges still. Not a full proof approach that I mentioned earlier, I guess.

[Shikkediel]

Figured it out by giving each reel it’s own perspective-origin, making it overall (mostly) originate from a single point. B-)

One little thing that’s bugging me now though – the side views show a tiny dark triangle that is the edge of the pseudos when you turn the cogs. If anyone can help me figure out how to create the same gradient, with the exception that it is a fraction less wide, I’d be grateful. I think I need a radial gradient for that but am having trouble getting it to match…

codepen.io/anon/pen/jYLXEr

[Shikkediel]

Haven’t had much success with that gradient yet. Too bad you can only set one direction for a linear gradient. Rather content with the overall result apart from that tidbit.

That aside, I was wondering if someone could do a little test to see if the first demo works alright with a trackpad. I got reports of a glitch and have throttled the wheel event but haven’t heard back if that fixes it. Thanks in advance.

[Beverleyh]

The main reason I haven’t responded to this thread yet is that I haven’t got back into the office yet to try on desktop. I’ve been on mobile (iPhone 6s plus) all Xmas and I’m not sure what behaviour the wheels are supposed to exhibit – mouse vs touch. I have nothing to compare to yet.

For me, the only wheel that moves is the right side one, but only when I flick downwards on the middle wheel. The others don’t budge. :(
When the right one moves, it’s only intermittently responding to down-swipes. Sadly it “feels” a bit “stuck”.

On the visual side of things, I like the gradients you have going on. I can see how the neautral greys would be more fitting in more environments. I think I’d add a bit of warmth with ivory-ish shades to the base wheel though. I’m more of a magnolia-on-the-walls person than a plain white paint choice :)

[Shikkediel]

Hmm… that doesn’t sound good at all. Thanks for the feedback though. You should be able to directly drag each wheel and give them a whirl, both with mouse and touch events. Additionally, mousewheel if the device allows it.

It seems to work perfectly fine on my desktop and mostly fine (I just noticed a bit of a jump) when I emulate several iPhones with Chrome. Not a clue what would make things different on an actual mobile… the basic script to keep track of touch events was ultra tested and glitch free on Android 2.3 even. Back to the drawing board, I guess.

I’ll see if I can put some more color into it too. :-)

[Shikkediel]

Testing on old Android (partially, because it doesn’t support 3d transforms) I noticed there is a threshold of about 15 pixels before the touchmove event starts firing. Also known as “touch slop”, which is absent with desktop and mousemove events of course. This may have interfered with calculating the speed and the sensitivity of the flickability, so I lowered the additional threshold in the script itself – the base value isn’t accessible. No doubt iOS has a similar functionality built in to distinguish between swipe and tap.

the only wheel that moves is the right side one, but only when I flick downwards on the middle wheel.

For this I have no explanation yet, each reel should handle its events separately…

[Shikkediel]

No doubt iOS has a similar functionality

Apparently it’s called “hysteresis”… pretty interesting to read this:

http://www.malacria.com/media/pdf/roboscroll.pdf

Both systems also apply a ‘slop’ (Android) or ‘hysteresis’ (iOS) threshold that requires a minimum touch displacement before interpreting the input as a scrolling action (Android: 8 dp, iOS: 10 points) to prevent accidental or noisy input channels.

It’s also contains some info I was looking for earlier – how to normalise the touchmove input to get a good estimation of the average speed. I went with mean absolute deviation for outlier detection but iOS seems to rely on linear least squares. See if that improves things…

[Author]

Posts