Pricing page is to make the user make a quick buying decision, not distract the user with a features tour. You do that elsewhere.
But the tooltips and small gifs are an awesome idea!
Every pricing page should have GIFs
211–220 of 228 posts
Re: Every pricing page should have GIFs
#212Am I the only one who thinks the actual essence of the article is not the technical detail of using GIFs on hover, but the fact that you see a quick visual demo of yhe thing you are paying for on a pricing page? On that matter, great idea sir! Will have it in mind
No you are not the only one. Seems half the comments here miss the point. It's a clever addition!
Re: Every pricing page should have GIFs
#213Earlier quoted context omitted.
Gifs look like garbage for video though, and take up 10x the space. I'm the opposite. I wish they'd just deprecate gif everywhere and then we'd see better video support. CPU usage shouldn't be an issue for small web video clips on any semi-recent device, my phone records 4k 60fps HEVC HDR10+.
> Gifs look like garbage for video We're speaking of animated graphics, right ? > my phone records 4k 60fps HEVC HDR10+. Reminds me of the rant of one of the Google camera app devs on a podcast, where they tried to see with the android guys if there was any way to just force kill every other app processes while the camera app if on the foreground to guarantee it would have enough resources upfront to do its job. Now…
>We're speaking of animated graphics, right ?
Hmm, wouldn't proper video codecs be better in any case?
Whatever settings they use for animated cartoons would be good for animated graphics. I can't imagine a modern codec could be less efficient than gif.
>Now playback efficiency should mostly rely on the codec and wether it's hardware supported, but I wonder if there would be a pipeline effect when you're trying to play 25 videos at the same time and they all need to go through the hardware decoder.
Hopefully it would stop playing them when they're not visible. But you're right, that is a good question as I doubt the decoders have really been designed with that usage in mind, rather to optimize for a single aforementioned high-res video.
Re: Every pricing page should have GIFs
#214There's a UX problem on mobile. I have to click on something to make the GIF appear. What do I click? A link. Expected behavior of a link is to link me elsewhere, not to show a pop-up GIF, so I'm immediately confused when that happens. I also can't figure out how to make the link actually link. Does it link anywhere? Is it even a link or just Jscript onClick thingy? Do I have to click on the GIF to make it link, beca…
Site author here. Thanks for the feedback! I just pushed an update to improve the UX on mobile :)
Re: Every pricing page should have GIFs
#215I saw this on blackmagic.so a few days ago, was super impressed. Works very well in this limited use-case, especially targeting desktop.
Uses text decoration dashed as an indicator that something is going to happen on hover.
It's probably worth just disabling this behavior on mobile, mostly because tooltip direction gets awkward on small screens. Nice tap to toggle on iPad, though.
Could be improved a bit by using video tags, these are 300k-500k each. Pretty large. But, then you have to create multiple versions of each to target multiple platforms, I can see why you might skip this.
Re: Every pricing page should have GIFs
#216I can see the desire to visualize a benefit to the service easily, but I feel like having an GIF start on hover is an unexpected behavior and might be a turnoff to some users.
It seems very much like something that could easily be overused/abused without much effort. Maybe a better solution would be to contain the GIFs to a single page that is linked from the pricing page?
Re: Every pricing page should have GIFs
#217Earlier quoted context omitted.
Do they work if the user has disabled autoplay in browser media settings? This is one of the first things I do when setting up a browser.
Yes, at least in Safari on iOS. If you properly mark it muted it will autoplay when asked. I believe the user can change the setting to "Never Autoplay" instead of "Stop Media with Sound" but the default only affects with sound.
Have you tested if that works in low-power mode? I know low power mode usually disables autoplay, and a lot of users have it on for significant parts of their daily usage
Re: Every pricing page should have GIFs
#218There's a UX problem on mobile. I have to click on something to make the GIF appear. What do I click? A link. Expected behavior of a link is to link me elsewhere, not to show a pop-up GIF, so I'm immediately confused when that happens. I also can't figure out how to make the link actually link. Does it link anywhere? Is it even a link or just Jscript onClick thingy? Do I have to click on the GIF to make it link, beca…
Either it’s fixed, or it was never a problem to me. The dotted lines indicate ‘click here to see more’ to me. And I can go directly from one to the next item by just tapping the next one.
[deleted]
Re: Every pricing page should have GIFs
#219Earlier quoted context omitted.
Yes, in the GIF format you can update just a window inside the image rather than the whole image for each frame. There are also control blocks that specify that a particular colour value is to be treated as transparent (within the logical image) and that the background image should be restored after the window is drawn. So for example a moving pointer can be very efficient if the encoder is able to take advantage of…
Every major video codec does this exact thing. Can you please stop spreading this misinformation all over the thread?
I don't believe I have made any factually incorrect statements, but please enlighten me if I have.
Have a look at the following two encodings of the same screen recording from the article, compressed to the same file size and the same framerate: https://tempklasjdf.s3.eu-west-2.amazonaws.com/most-engaging... https://tempklasjdf.s3.eu-west-2.amazonaws.com/most-engaging...
To my eyes the GIF version preserves a little more of the sharpness of the text but there's not much between them. And GIFs are simple and intrinsically support looping.
As an aside, there is currently a proposal to bring some features from GIF (and a few additional ones) to HEVC to better support screen recordings: https://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.71...
Colour palettes and efficient spatial (rather than frequency domain) coding are being considered, both features of GIFs. Also support for RGB colour space rather than YUV420 to better preserve the colours (just like GIF!).
Re: Every pricing page should have GIFs
#220Earlier quoted context omitted.
> Gifs look like garbage for video We're speaking of animated graphics, right ? > my phone records 4k 60fps HEVC HDR10+. Reminds me of the rant of one of the Google camera app devs on a podcast, where they tried to see with the android guys if there was any way to just force kill every other app processes while the camera app if on the foreground to guarantee it would have enough resources upfront to do its job. Now…
>We're speaking of animated graphics, right ? Hmm, wouldn't proper video codecs be better in any case? Whatever settings they use for animated cartoons would be good for animated graphics. I can't imagine a modern codec could be less efficient than gif. >Now playback efficiency should mostly rely on the codec and wether it's hardware supported, but I wonder if there would be a pipeline effect when you're trying to pl…
Most video codecs, including H.264 and H.265, encode in frequency space (after DCT transform) on a block-by-block basis, discarding high-frequency information (the edges of text and graphical elements are high frequency information). That's why you can see blurriness and ringing around edges in text and graphical images with a video codec. It's not what they are designed for.
GIF uses Lempel-Ziv compression, meaning it can encode repeating information efficiently ("the next 10 pixels are the same colour as the last 1"). Efficient if there are a lot of areas of the same colour or repeated patterns.
GIF uses RGB colour space just like your screen, so there is no loss of colour information if there are fewer than 255 distinct colours per frame (typical for text & simple screen graphics!). Video codecs (like H.265) typically use YUV420 colour space, meaning that colour information is encoded at lower resolution than brightness.
Palette based colour encoding (like GIF uses) is quite efficient when there is a small number of distinct colours in an image / video (like in the videos in the article...).