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:
As opposed to this flat version which is less nifty but looks nice just by its background:
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.
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.
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
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…
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.
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.
That does look pretty sweet when the perspective cascades with
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.
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…
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.
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 :)
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. :-)
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…
No doubt iOS has a similar functionality
Apparently it’s called “hysteresis”… pretty interesting to read this:
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…
You must be logged in to reply to this topic.