đŸ Archived View for dioskouroi.xyz âș thread âș 29348328 captured on 2021-11-30 at 20:18:30. Gemini links have been rewritten to link to archived content
-=-=-=-=-=-=-
________________________________________________________________________________
There'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, because that's 2 clicks when precisely one is accepted link practice. Clicking to engage and then clicking again to disappear is super aggravating, especially on mobile screen, especially on such a long list. Click, click, click, click, click click, click, click. Ahhhh!
This works well if I can hover over the links with a mouse to engage the pop-ups, which then disappear when I hover away. If I have to click on the links, like you do on mobile, then click again to dismiss, neither click actually linking to anything, it fails UX.
Also, too much info in too small a space on mobile. Too much being communicated. Too dense. What UX test calls engineeritis. You need drill down pages for these links. If I click one, I expect a page with detailed information, a drill down, not a pop-up summary GIF.
Mixed UX metaphors. Not lethal, but not quite there yet. Very cool, though, especially for the rapidity with which you were able to implement it, but it needs a bit more test on the UX side on mobile.
A button toggle that displays a responsive, inline GIF as a drop-down, not pop-up, is perhaps the better solution, even if it's not quite as neat as what your creativity created. That would work as expected without damaging your intent, but that still involves click click click.
> There'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.
The underlines being dotted, it's closer to an <abbr> element (
https://developer.mozilla.org/en-US/docs/Web/HTML/Element/ab...
), which does not act as a link.
another option would be using this â
User will click/tap and the modal of the gif will show
> User will
No they won't.
I don't mean this cynically, every test I've seen with a feature like that has had _very_ low engagement.*
This is the problem with features that "get out of the way" - they are underused and the intended value is lost.
It's a conundrum, because I totally agree in terms of interaction design but what good is a (well designed or not) feature that isn't used?
Maybe those users simply aren't interested enough in your product? I think adding a simple note "click on the labels to see a demo" should be enough discoverability.
Any UX designer will tell you that users don't read notes.
I'm a big fan of this solution, and I've used it quite a few times.
Ideally I would like to use drop downs where possible like GP describes, since a > icon (or similar) before some text unambiguously indicates how to get more information, but sometimes the implementation is non-obvious. I've had issues when my data is tabular (like this pricing page). Where should the drop down appear? Sometimes you have a 3rd party table (or template, like this article describes), and the customization options might not be there. At the very least you have to spend time styling both the additional information AND figuring out how it fits into the document flow.
The great thing about a tooltip is that it's out of the document flow. You can just ignore the rest of your application, resulting in (usually) faster development speed. However, as GP points out, you have to consider mobile, and it's not always obvious how to indicate _in_ the context of your document that something is hoverable.
â is a best of both worlds solution IMO. It's totally unambiguous on both desktop and mobile that hovering, clicking, or tapping will bring up more information, AND you get the development speed of using a tooltip.
This is really the only correct solution in the context of modern UX.
It's a feature comparison page, so that's the fundamental design issue.
The GIFs add pop, but the intent is to clarify. How does showing this info. on onHover or onClick in any UX achieve that result?
It doesn't.
As designed, it's an ad. It is. Look at it.
If I'm comparing a product with a full page of features, I'm going to be scrolling up and down. The one thing I absolutely won't do is hover over 16 onHover information panels while trying to compare and contrast an extensive set of features, costs, and licenses.
I'm just going to get aggravated that the information I need to make a decision keeps disappearing from view when I click or hover elsewhere.
Also, that's the kind of page you print and underline and circle things on, and give to your boss as a reason for purchase. If half the information is invisible when the page is printed, what use is it?
Yep, you said it, the pricing page is, in fact, an advertisement of the product.
It's not like you can easily compare the prices between two different products in the same segment.
It's an ad. Embrace it. Leaving out the GIFs doesn't make it less of an ad. It just makes it⊠a worse ad?
Also, does your boss not have a computer?
He does. He just likes the printer more. He also surfs the web on a Texas Instruments TI-85 graphing calculator, so go figure.
I'm not referring to the page as an ad, but fair enough. I see him applying a pop-up advertisement using the wrong UX element to a grid of information that doesn't benefit from it.
Wrong is the wrong word, as apparently a dotted link is and isn't a link. Indicates multiuse? That's clear as mud.
This feature is effectively a <details>/<summary>. Usually they are displayed with as (ⶠcollapsed) and (⌠expanded) triangles. I do wonder if the circled i â has more engagement as a well placed triangle/chevron.
I'm staring at this conclusion with the most bemused expression on my face. I'm thinking of the lines painted on the highway, wondering what tragedies would result if yellow line, white line, dotted line, and solid line were similarly ambiguous.
Sometimes liberties are taken here, such as California originally separating carpool lanes with yellow lines (when they should have been white).
Presumably they felt that even though yellow was incorrect, it sent a clearer "do not cross" message to drivers.
They were later ordered to change them to white.
Were there mandatory prescriptive federal guidelines on HOV lane line colors when California introduced carpool lanes, or did they only come after California had been using yellow lines?
Personally, I do find yellow lines are a stronger border, but then I grew up in a culture of yellow carpool lines. I feel like white lines are almost always ok to drive over, and yellow lines usually aren't (although yellow dotted lines are a sometimes drive over (if safe, to pass on a two lane undivided highway), and yellow solid + dotted is also ok to drive over (if safe, to get into a shared median lane for an unprotected left turn)
I think it's because yellow is supposed to indicate traffic moving in the opposite direction. That's why it's a stronger signal (in theory), but not "correct" for an HOV lane moving in the same direction.
California should have closed the lane once a year for one minute to run a single vehicle down the carpool lane in the wrong direction. Then they could justify that the lane marking was the right color (since in theory, the lane can be reverse-flow at any time, and hey sometimes they even do it).
> I feel like white lines are almost always ok to drive overâŠ
Single and double solid lines parallel to the flow of traffic, of any color, almost always mean "do not cross".
A single dashed line, or a double line where one or both halves is dashed, can be crossed under at least some circumstances. The rules for crossing these vary depending on context, e.g. one-sided passing and center turn lanes use similar markings but with the solid and dashed lines flipped. (You pass from the dashed side but enter the turn lane from the solid side.)
White lines separate traffic going the same direction. Yellow lines separate traffic in opposite directions. This is independent of whether the lines can be crossed.
My funny anecdote around that: The road in front of my house has a dual center yellow line, but the reflective additive they used in the paint shows up white. At night all of the lines are white. VERY confusing.
That sounds like something you should report to an authority. It could even be a whistleblower issue if the contractor shorted the city with substandard glowy stuff and it's causing serious safety issues.
I've driven through places where the lanes change directions or get closed based on traffic flow, most often near sports/entertainment arenas, and they tend to have one or two lanes with dashed white lines which are always open and the rest of the 3+ lanes are dashed yellow. I've always wondered if this is an exception to a rule, or if there even is a definite DOT rule (or if localities can override DOT regulations, such as in the case of rainbow crosswalks). I do recall in my driver's education classes 20+ years ago that a dashed yellow is "allowed to enter and exit but not for travel" but again that may have been a local rule.
I noticed that change recently and assumed it was motivated by Tesla. There are certain things we all take for granted when driving. A huge one that we probably donât give much conscious thought to us this:
How do we know if the lane to the left is ok to go in, or if it actually is for carrying oncoming traffic?
Youâd like to think that _one_ way though not the only way, is to look for a double yellow line. As in, double yellows always separate opposing traffic so _never_ cross them.
In CA though, double yellow was also chosen to separate the carpool lane as OP mentioned. So there was actually a really mundane case where driving to the left of a double yellow was actually fine. Seems very confusing to an autonomous car thatâs operating at the mental-level of an 18mo old.
You are giving way too much credit to autonomous vehicles in this theory. Line colours are standard throughout all of North America (that Iâve seen so far). Yellow means what it means. This carpool line experiment would have been confusing to any driver seeing it for the first time.
Imagine a tourist on that highway for the first time, at 3am, when thereâs no traffic. Can they use that lane? Can they pull a sneaky u-turn and start driving the opposite direction?
What if Iâm driving down the highway, effectively on mental autopilot, and suddenly become aware that Iâm on the âwrongâ side of the yellow line? How would I be likely to react?
The opportunities for misunderstanding by normal humans seem plenty.
_I noticed that change recently and assumed it was motivated by Tesla._
My '11 Nissan Leaf couldn't even have LED taillights because the Feds said "no". Tesla isn't going to march into some DOT office and demand that the color of the lines be changed to accommodate them (I mean, they could, but the laughter would drown out the conversation).
CA changed it because not only was yellow against federal guidelines, but also because I personally believe it was a stupid choice to begin with (for reasons others have already listed).
Yellow lines separating oncoming traffic is not universal though? I believe in the UK that the center lines are white?
Living in Germany and having only driven in Mexico (City) as far as the Americas go, I admit to not understand what yellow lines signify to US drivers, like at all ;) At my place, they're used for temporarily "overriding" regular white lines eg at construction sites, and only for that purpose.
Works pretty well.
https://www.anwb.nl/verkeer/veiligheid/strepen-op-de-weg
It reminds me that we don't see "floating" touchscreens anymore.
The Galaxy S5, and probably other phones had this feature where you could actually trigger hover targets by hovering your finger above the screen. I just tried it on my Galaxy S5 the linked page and it works flawlessly.
It may be one of the gimmicks Samsung loved to put in their phones at the time, but as we can see, it is not completely useless. And it also doesn't look like there is any downside to it, except maybe a very small increase in price.
onHover has always been a psuedoschizo decision. There are places where nothing is more useful, but misuse it and it aggravates the hell out of everyone, not unlike browser frames/iframes/etc 20 years ago.
What is a "psuedoschizo" decision?
A conflicting decision. Please ignore the word, my brain made it up.
Make your next one a coffee?
Almost schizophrenic. Made sense to me.
Ok, so how is something being misused "almost schizophrenic"?
Not using fancy made-up words around you ever again.
If you can't even define them, then that's probably for the best
You don't need to freak out every time someone invents a new word construction. I understood the comment perfectly the first time, which brings us to 2/3 other commenters having grocked it immediately.
Wait, grocked is a made up word too. Pretend I said understand.
The page is a disaster on a desktop, too. It does something weird to the scroll, so I can't use either my arrow keys or my Vimium keys in the normal way. Note to web authors: I'm sure I'm not the only one who left quickly after I saw that my scroll was hijacked. If you want people to read your stuff, try dialing back the user abuse.
I endured the hijacked scroll because I was curious about what he meant.
It looks like a good idea, but in a very user-hostile interface, what wasn't surprising at all. If I had to guess, the author is honestly trying to increase his site's usability by overriding the default behavior, he is just failing spectacularly.
I was surprised when my arrow keys didn't work properly. Now I see you had the same issue. Using an old laptop, I'm often navigating through pages with keyboard track-pad on these old laptops is trash.
Point taken about making it clearer it's a popup rather than a link but...
> You need drill down pages for these links. If I click one, I expect a page with detailed information, a drill down, not a pop-up summary GIF.
I disagree here and much prefer browsing the summary information with a gif to having to click through every single feature into a new page.
Yes, I am rather stuck on the use of that link as a link-button. I argued furiously against them back in the day and, obviously, lost.
There's somewhat of a convention to use a dashed underline on links that have behaviour like this; perhaps that would be an improvement.
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.
>Expected behavior of a link is to link me elsewhere
That may be true, but I certainly wasn't confused when I tapped it and saw the popup. On mobile, you could make the popup take up the whole screen with an easy X button and perhaps it would solve that issue
(Minor as it may be)
>Mixed UX metaphors. Not lethal, but not quite there yet. Very cool, though, especially for the rapidity with which you were able to implement it, but it needs a bit more test on the UX side on mobile.
It's definitely a good idea but agree that it's just a bit off. The videos are small and hard to see and there's no way to share a direct link to a video.
It should be an accordion that opens a detail view.
I like it more when items stay opened, instead of closing again when another item opens (like with an accordion).
I'm chuckling at this because, every time I've launched a broadside against onHover, a crafty developer replies with an accordion.
You sly dogs.
Navigating on mobile is something you do on the go, when there are no other options. Of course it's going to be a downgraded experience.
Is it?
_Mobile devices drove 61% of visits to U.S. websites in 2020, up from 57% in 2019. Desktops were responsible for 35.7% of all visits in 2020, and tablets drove the remaining 3.3% of visitors.
Globally, 68.1% of all website visits in 2020 came from mobile devicesâan increase from 63.3% in 2019. Desktops drove 28.9% of visits, while 3.1% of visitors came from tablets. However, desktop devices remain very important, as they drove 53.3% of total time on site in the U.S. and 46.4% of total time on site globally._
https://www.perficient.com/insights/research-hub/mobile-vs-d...
Also, use WebM, not GIF, for better compression. GIF is obsolete trash from the 1990's internet.
You can have a GIF fallback but 99% of browsers don't need it.
well... 99% perhaps not. mobile safari is pretty important
Not a bad idea in and of itself, but _screw hover effects_.
I've come to really hate everything involving hover. On all sorts of websites there's some menu bar at the top or the side where it's way too easy for me to accidentally move my cursor over it and suddenly 1/5 of the page is blocked. I really wish that these things could just be replaced with a click. If I want to view a dropdown or something with dense details, I can jolly well click or tap on it.
EDIT: Interestingly, it appears possible to intercept and nullify mouseover events.
document.addEventListener('mouseover', (e) => e.stopPropagation(), true);
Works on wellsfargo.com, making their menus work like I think they should. Obviously it wouldn't work for CSS-based hover.
Maybe I'll make this into an extension.
> Not a bad idea in and of itself, but screw hover effects.
Article title implies inline images as a 'preview' but delivers tooltips.
Thumbnails would be better still.
Let me double down by saying: if your selection page has so many entries that thumbnails make the design unworkable, then you have too goddamned many options for people to choose from.
Go re-read The Paradox of Choice, come back and start bundling some of your options up.
For this kind of thing, I would rather something like the HTML details element where you click the title and it expands the details. You have the chevron to indicate it's expandable, it works on mobile and desktop, and is universally recognized without being obnoxious. I hate sites that make me play the game of "where can I put my mouse where it won't trigger something annoying"
Don't use GIFs, use audioless mp4s instead. They can be made to work in the exact same way as GIFs (autoplay, loop or not, etc) but are a fraction of the bandwidth.
If you do this, please make extra sure there's no audio track _at all_. (Not just silent audio.)
Browsers use the presence of an audio track as the trigger to decide whether or not to prevent Windows computers from going to sleep while a video is playing.
I filed a bug on Firefox, but they consider it to be pretty low priority:
https://bugzilla.mozilla.org/show_bug.cgi?id=1684718
This is exactly what we do on
https://www.soundslice.com/features/
(the minivideos below the main hero section). Would definitely recommend using MP4s instead of GIFs, for the bandwidth savings.
Second the mp4 part. We started with gifs on bugasura.io and ended up with a pageinsights at 20!
Apparently these gifs are loaded along with the other assets and lazy loading them is not simple.
We moved to mp4 and the scores have increased quite a bit.
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.
Some (all?) browsers will still play autoplay videos as long as there's no audio track (or if it's muted by default)
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.
Iâm curious, would you disable GIF autoplay if the browserâs settings offered it?
No.
Like, i get that they are the same in effect, but I still believe in the semantics different between a moving picture, and a audio-track-less video.
A gif can never have audio.
A img tag can never have audio.
mp4s, m4as, webm, embeds tags, video tags, etc, can either have or not have audio, its a surprise.
Because they are _videos_, not moving/animated pictures.
Anywho, apng is a real standard now, so one can just use that instead of gifs.
Yes. The performance of playing gifs is awful. Even better if gif autoplaying could be gated by the dimension of the gif. Under 100x100? That's fine, autoplay it. But some nutjob's 1000x1000 gif? Please spare me.
Yes please.
encoding an MP4 to work on all platforms is not as easy as exporting gif. gif will work on all platforms past and future, 10x the size tho they may be
(I encode as MP4 but i have to say itâs annoying to find it doesnât work on some version of safari)
IIRC, ~everything other than Apple devices works with vp8 and webm. Apple devices like mp4 and x264.
Non apple devices are also fine with h264. AFAIK itâs the video codec with the most support and what I would pick if Iâm going to be throwing the one same file at every device.
Most linux distros do not support it by default. I would encode in both h264 and vp9 which would cover everything and the browser should be able to pick the file it supports.
> _Most linux distros do not support it by default._
Sure, but the number of end users who don't install nonfree codecs on their own must be numbered in the dozens.
I didn't have them installed for years and found almost everything still worked. I think the only website that didn't was twitter which I don't really use.
Can they be used exactly like gifs? I have seen a few sites with mp4s but Firefox blocks them.
I do not think even sites like Dribbble have figured it out. I have a lot of issues there with videos.
Well, Firefox blocks gifs to me too.
It depends on how you configure it. Any option you choose, make sure the first frame is informative.
The vast vast majority of people don't configure their browsers at all.
What matters is what the defaults are.
Maybe they had sound, even if it was silence?
https://support.mozilla.org/en-US/kb/block-autoplay
Firefox doesn't block any MP4s for me. Sounds like your addons, or a cross site security error.
In what way does Firefox block them? If you mean they don't autoplay: that is how it is meant to be. Please do not annoy your users.
They may have tried to open arbitrary mp4s and had Firefox not render it.
Firefox seems to only render MP4 files that use yuv colorspace and aa3 audio channels, which require specific ffmpeg flags during transcoding. It took me a day of grinding whackamole to find the magic set of arguments to make all recent, popular browsers actually display a video:
https://github.com/photostructure/photostructure-for-servers...
Possibly a useful doc for ya then:
https://developer.mozilla.org/en-US/docs/Web/Media/Formats/V...
. And beyond that it depends on the OS, so windows/linux/mac/ios/android/etc will all vary.
Some of this is also probably due to using ffmpeg directly, tbh. It's very happy to produce irrational combinations of things that are technically allowed by specs but not implemented anywhere in practice, often exacerbated by it trying to preserve metadata / colorspace / etc where technically possible.
More specifically, most devices will want _4:2:0_ Y'CbCr. It's highly unlikely that FFmpeg gave you anything that's not Y'CbCr (H.264 can technically encode RGB, but I've never ever seen it in use). And if it chooses 4:2:2 or 4:4:4, you get a warning.
FWIW, if you really want to encode your video in Rec. 2020, you'd almost certainly want a 10-bit encode, and then you're outside what e.g. iOS devices will render again. Rec. 709 is the safe choice.
I have issues with videos on Twitter. It's not every video, but about 10% refuse to play in Firefox.
Not for screen recordings, unless you're doing a screen recording of photos or videos a GIF will typically be more bandwidth efficient (as there will be large areas of single colours and few changes between frames which GIF is good at).
Modern video codecs certainly employ the ancient tricks known to gif; they also compress regions of the same color and encode differences between frames. Plus they don't have a limited 256-color palette per frame, so the result doesn't have to look like washed out garbage.
> as there will be large areas of single colours and few changes between frames which GIF is good at
Pretty sure that's how modern video codecs work too. A lot of movies have regions that don't change much between frames (e.g. backgrounds, or some dude's face staring at the camera all dramatically).
What GIF gets you is a lossless video, which is overkill for most applications. Video codecs can achieve a similar perceptual quality at a tiny fraction of the size, which is why services like gyfcat and imgur will often auto-convert gifs to videos for browsers that support it.
Take this 2MB GIF (
https://blackmagic.so/assets/sidebar/most-engaging-hours.gif
) and put it through an online converter:
https://ezgif.com/gif-to-mp4/ezgif-7-68b177ec1944.gif
WebP: 1.64 MB
MP4: 300 kB
AVIF: 274 kB
Yes indeed all modern video codecs are based on encoding differences between key frames. GIF has the most basic implementation of that (it can update only a window in the image instead of the whole image).
The original GIF can actually be compressed losslessly down to just 1.4MB with a better compressor like
.
MP4 (and similar codecs) are not typically very good at compressing regions of constant colour, while GIF is very good at that. However I have to admit that the output of that converter is acceptable in MP4, better than I would have expected (though noticeably worse quality).
BTW curiously (likely to better performance on regions of constant colour) the non-lossy WebP does better on this example coming in at just 1.2MB!
2 MB is huge over mobile for a simple graphic illustrating one of many, many features.
If you really want to use GIF, it would make more sense to manually create an animation out of frames you define, switching between highlights of that feature, rather than a screen recording that captures every minor, irrelevant animation and follows the hover popup as it moves around a few pixels. That's just a waste of bandwidth. A manually curated GIF of that size could be like 40 kB or so, not megabytes.
Otherwise, I'd argue MP4 is by far the superior option for this use case given its far smaller size, where visitors just need to know at a rough glance what a feature does, not examine it for pixel perfection. An imperfect video that loads in 20% of the time is preferable than waiting forever for a huge gif to load.
All I know is that when I find an actual gif it's really easy to save and share, but when I find a "gif" that's actually a video, shit never works right.
Keep gifs. More gifs, even. Down with videos where gifs would do.
Also, raw size isn't everything. What's memory use look like during playback? CPU use? Higher? Spikier? I know there's hardware decoding for common codecs but wouldn't be surprised if videos _still_ use more CPU than gif, in practice.
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 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.
As another example the encoder at
does a quite impressive job at compressing the GIF if allowing some loss of visual quality.
Taking the number of colours down to 14 and allowing lossy compression I got the file size down to 386kB:
https://compress-or-die.com/gif-process?expert-mode=no&exper...
I'd consider that a good trade-off given the universal compatibility of GIFs, and no ringing in the decoded video.
Massive gifs of screen recordings embedded in github readme pages is really obnoxious. Gif is a terrible format for these, the files are frequently several megabytes where a modern video format might have it crisp and legible under 100KB.
You have to encode it in multiple formats because many systems do not support proprietary codecs.
The problem is mostly the Apple devices which don't support _non_-proprietary formats. H.264 is probably the most universal codec, but it's proprietary and requires a license for commercial use. The non-proprietary VP8 codec is supported by most browsers, but Safari support (outside of WebRTC) requires version 14.1, which was only released this year. And that's only on Mac OS, not iOSâthough we _might_ see WebM support for mobile Apple devices in the next release. And then there are complicating factors like "Edge support for VP8 requires the use of Media Source Extensions" and "Firefox only supports VP8 in MSE when no H.264 hardware decoder is available"[0] which stand in the way of a one-size-fits-all solution.
[0]
https://developer.mozilla.org/en-US/docs/Web/Media/Formats/V...
Is there a format that is not proprietary and works for this purpose?
AV1 is the proposed future. But Apple has been holding back universal free formats for a while now. Apple is on the AV1 group so in theory they should support it later but they do not yet.
What do you use to encode the MP4s?
ffmpeg
Here to vote on the "please don't do this" option.
Can you just accordion the indicators in between the rows so that a user can choose to expand?
I find the popup insanely annoying and un-asked for. If I want something, I'll click it, please don't force it on me.
But that's just me.
Someone linked to a page doing the accordion. I don't like that it shifts the contents of the page. I much prefer the tooltip style, but I would combine it with making a click bring you to the relevant section of a "Features" page.
Strongly agree. Clicking though these, click off to close it, and waiting for pad the gif would have me off the page in seconds. Not to mention accidental clicks.
Agree, an accordion feels like a good use case here
It's really annoying when I'm browsing a page and my mouse "accidentally" moves over something and a giant thing pops up in front. Terrible UX. End up having to play dodge-the-mines with my mouse
I agree but I think there's a good balance: have a little "hover over me" widget. If you hate popups it's easy to avoid the widget, and it makes the hover experience more consistent as you move from line to line (assuming the widget is at the front so they all line up vertically)
I prefer clicks to hovers for this reason. A simple (Show example) button or (?) clickable question mark that spawns a small modal in-place and takes focus is more accessible, and there is no ambiguity of intent.
And what about the visually impaired ? You add a soundtrack ? So basically a video. Of course the a transcript is available, right ?
So instead of going full circle, how about a good old text in the first place ?
Seems like all these shiny new ideas completely forget about ADA / accessibility legal requirements. There are real monetary repercussions for neglecting this [1] [2].
[1]:
https://www.cnbc.com/2019/10/07/dominos-supreme-court.html
[2]:
https://www.diverseeducation.com/demographics/disabilties/ar...
Exactly. And similarly with the charts and graphs, how about just the good old raw csv data
CSV data? Psh; you're going to have to change it eventually, which means you need historical pricing data⊠Just have a detailed description of your pricing philosophy, and let the reader determine whatever information they need from that.
Why bother laying out a website? Just send people an email explaining the offer, right? Hell, just tell them in person! That certainly will be accessible.
Off-topic: Why are you putting spaces before your question mark but not your period or comma ?
For your off-topic: Maybe they are French.
https://en.wikipedia.org/wiki/Question_mark#Stylistic_varian...
My assumption, as a french-speaking Swiss, where we don't do put spaces before symbols with 2 strokes (;:?!) like they do in France:
https://french.stackexchange.com/questions/46/pourquoi-place...
The problem with this kind of UI is that when you scroll the page, you inadvertently mouseover the links as you scroll.
So different pieces of the content you are trying to read keep getting hidden in a frustrating way as you're trying to read it.
You can see this in the OPs video right at the beginning - after the very first mouseover he moves his mouse out of the colum, to the right, in order to see the column for his first scrolling motion.
I always scroll every page along the whitespace on either side for that very reason
Wouldn't it be nice if we had always visible scrollbars again? Although maybe this time with a better way to tell how big they are so that we don't have to use weird margin and padding hacks and take a random guess at how the OS renders them.
I have to admit I absolutely loathe that kind of mouse-cursor-dragging tooltip image. Anything that obscures the very text that I may want to read to decide what to look at next seems crazy to me. You can even see it in the example video, as soon as the overlay shows up you canât read much of the text in the column it triggered from.
I don't understand this article at all. It says every pricing page should have gifs, but doesn't say why. Maybe it says in the images, but they don't load at least under my current adblock configuration. For that matter, JS and gifs of any sort on a web page are effectively another annoying captcha when I just want the information. For pricing, please just post a CSV or equivalent, and get out of the way.
yes they do, in the very first few paragraphs.
>When evaluating a SaaS, I often just skip the landing page and all of its marketing fancy words and go straight to Pricing page.
>Usually, I will find what I need there: what features does the SaaS has, and how much do I have to pay to get what features.
>For that reason, I added GIFs to every single feature of my SaaS pricing page:
They just didn't spell out the connection between the two premises, that because _they_ tend to ignore the demo/about/landingpages, and jump straight to the pricing page, other people likely do so as well, and you should turn said pricing page _into_ your demo page/landing page to target such people with that info since they won't get it from the normal page thats dedicated to conveying that info.
The video demo makes the article make a little more sense. But essentially there is a GIF tooltip for every feature listed on the pricing page so that you know what the listed feature in the comparison matrix, it's talking about.
Ah thanks. Is the GIF tooltip somehow better than a plain HTML table with a header over each column saying what it is? Video, ugh ;).
I mean an image is worth a 1000 words, and a GIF is multiple images spliced together.
Am 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
It even works on mobile!
Recently I've been having trouble pinpointing sarcasm on the web. That can't be real, can it? Mobile traffic has been larger than desktop for over a decade. We've been hammering mobile-first for almost that long. If that was a joke, sorry it passed right over my head.
Also, GIFs⊠in 2021? We've had <video>, <canvas>, <svg> for what, 15 years?
> _Mobile traffic has been larger than desktop for over a decade._
For cat videos - most likely.
But for sites selling (enterprise) software and services - almost certainly not.
> _We've been hammering mobile-first for almost that long._
Do you work for Google? That's pretty much the only "we" that's been hammering that.
>For cat videos - most likely.
Not at all
[1]
https://techjury.net/blog/mobile-vs-desktop-usage/#gref
[2]
https://www.statista.com/statistics/277125/share-of-website-...
>Do you work for Google? That's pretty much the only "we" that's been hammering that.
Nope. It's just everyone, really.
[3]
https://developer.mozilla.org/en-US/docs/Web/Progressive_web...
[4]
https://xd.adobe.com/ideas/process/ui-design/what-is-mobile-...
[1] talks about using mobile devices to "close deals", which is not the same as a b2b web traffic.
[2] doesn't talk about b2b segment at all.
People who are buying products and services, especially of IT nature, sit in the office in front of their laptops and desktops. We have an installable desktop product. Guess the percentage of mobile traffic on its website? It's 5%. Five.
So, yeah, "it even works on mobile" makes for a good quip.
There are exceptions to every rule, of course, and b2b/enterprise is its own little world with infamous idiosyncrasies.
But a low percentage of mobile traffic could also be a self fulfilling prophecy. If your mobile site sucks, well, guess who's going to use it.
Also, it's not that hard to make a good mobile site, you actuality have to a get out of your way to make a bad one if you follow best practices. I wouldn't mind an easy increase in my income, even a few percent.
When I'm browsing on my phone, I usually find myself opening a site with a "mobile" ui in desktop mode, because the mobile version is usually inferior to the desktop version.
> Do you work for Google? That's pretty much the only "we" that's been hammering that.
Apple and Microsoft too. And Microsoft doesn't even have anything competitive to offer there.
But yeah, the rest of the world has been busy ignoring those 3.
I think the point of this comment was to distinguish the interaction on desktop (hover) versus mobile (click).
Desktop users are used to hovering on stuff to see what happens. You can't do that on mobile so you have to do something else (click) which is kind of counter-intuitive on mobile (clicks are supposed to navigate).
I like the demo of each feature, but hate the box of text and video hanging off my mouse cursor. There must be a better implementation then that.
Maybe a short, abstract svg animation of how a certain feature would look like and behave? Probably a little more work to implement (well) and keep up to date but I've liked that sort of thing on the few sites I've seen it on in the past. Sadly can't think of any right now though.
I also remember algolia having some sort of movie search demo as their top banner a few years ago. Including their completion and such. Always struck me as a good way to introduce their service in particular.
I feel like this much content needs it's own section. Having the onhover on my cursor that resizes and moves around so much as a move the mouse or page up/down is pretty horrible UX. I'd do something like how MS Excel has Task Panes on the right of the window. Then each thing can have an image/video and a paragraph explaining and showing what it is. The main issue here though is he's trying to explain/list all these tiny little features instead of just simplifying the page which is probably causing analysis paralysis and hurting conversions, so adding more information is probably just salt in the wound. He really just needs to get people to sign up and see the features and they'll be self explanatory, up sale from there.
Telegram always uses GIFs very effectively for explaining new features.
The animations are always kinda cutesy, but still very good at demonstrating the feature.
https://telegram.org/blog/shared-media-scrolling-calendar-jo...
(both look better in Telegram than on the web, but it gets the idea across.
> Every pricing page should have GIFs
Given that you have a slick UI product with charts. Maybe not _every_ pricing page.
Also, mobile.
So this is how I find out about LICEcap[0]. After years of thinking byzanz-record[1] was the only way to record a decent quality gif.
Justin Frankel, you're an awesome dude.
[0]:
https://www.cockos.com/licecap/
[1]:
https://linux.die.net/man/1/byzanz-record
If you're on MacOS: I used to use LICEcap but then I found myself wanting more (still basic) features, like the ability to trim recordings, export to video formats etc. Now I use Kap, it's the perfect balance of simplicity and features (for me):
On Windows there's also ÎŒGiffer -
What on earth did this site do to scrolling? Spacebar doesn't work, arrow keys work really weirdly...
Spacebar: replaced by GIFs.
Arrow keys? Believe it or not, also replaced by GIFs.
It's a Notion-published site, so arrows select "blocks" (pieces of content) on the page.
Amusingly the demo video only showed "this video can't be played" message, thanks to uMatrix blocking the third-party media requests.
If he'd made it a GIF it would have worked...
Elsewhere in this thread:
> Don't use GIFs, use audioless mp4s instead.
I use uMatrix to block 3rd party image requests by default, so gifs would have the same "problem". Of course it's not actually a problem at all, if the user chooses to block 3rd party images or video, that is their prerogative.
I like the idea of explaining what features are, I don't like this method of doing it, as many others have commented, it's super annoying. Just provide clickable things to get descriptions
If you are selling an UI option, a screencap is pretty much a must.
If you are selling non-UI options, simple click-to-view explainers go a long way too, e.g.
What is going on with this Notion site? It doesn't scroll. Notion is kind of a big company now; I find it kind of inexcusable that they've gone out of their way to break the browser's default (working) functionality.
I'd be interested to see if there's any research that would lead you to believe that conversions are increased by this change.
It's an interesting proposition, but I wonder if we're really getting to the core of the stakes here. I'm not a huge fan of the hover state tool tips. It feels like this information design here could be more considered.
If we're going to think of the GIFs as tool tips, then we're talking about them as non-essential information for motivated users. The thing is, I think that works well when it's used sparingly in context, but not for every single list item on page. It's a bit of a pain and it looks messy to read each header and then hover, one-by-one to get more context.
If we made a more firm decision about the role the GIFs play, then we could take a stronger strategic approach to their implementation. If they are essential, they should be part of the displayed design. There are certainly methods to format text and images that make the document easily scannable. That said, I think what might be more applicable here would be a drawer strategy with a section that expands for more information.
At the end of the day, I think what's most relevant is that there are 30+ features to highlight and that seems like way too many for a pricing page!
Also if you are not doing it yet, demonstrate and announce every new feature in Slack to your team in a dedicated channel. With gifs.
I do think visuals are a good way to describe features in a lot of products, the examples here definitely benefit from a graphic. "Most engaging hours" doesn't sound nearly as interesting as that graph in the mouseover. But I think for most features of most products you probably don't need a GIF and I'd typically prefer a faster loading image in most cases.
A cool way of demonstrating features that are more or less represented by their respective GUI widgets could be by dogfooding the actual React components you use in production (just pass fake demo data in props/context). That said, demonstrating them in action is a bit trickier, since thereâs no ready-made solution that could animate a virtual mouse cursor and simulate pointer events in accord.
The website asks me to enable mp4 video. It does not contain gifs. Oh the irony.
We might be at a point where tiny looping MP4s have been called GIFs for so long that a whole generation is emerging not knowing what a GIF is.
We should define a media pseudo-format, or at least attributes for the âvideoâ tag, which would say that the video will play without soundâwith it being enforced by the browser and without the option for the user to turn sound on. This way, modern codecs can be used for short animations instead of the format for moving 16x16 icons from '87âwhile still allowing users to block regular videos. Maybe even force-limit the duration to thirty seconds or so.
Right now, it doesn't make much sense that GIFs are allowed to play automatically, but decent codecs aren'tâif I want to evade videos, that is.
(Though OTOH the size of GIFs might serve a purpose in limiting site-authors' appetites for trashy animation, but I don't see bandwidth being much of a concern for them lately.)
The `muted` attribute of the <video> tag already does that.
It's an important attribute because it's necessary for videos to autoplay under Chrome. If you don't mute the video autoplay will only work if some special conditions are met (e.g. the user already played video with sound before on that site, etc.)
Eh, sites still just play long videos, but mutedâexpecting that your attention will be inevitably drawn by the movement, and you'll enable sound. It's just part of all the flashy junk immediately distracting the visitor from whatever they wanted to do on the page.
Instead, videos shouldn't play unless they have a âmuted-foreverâ attribute, with no way to enable sound. This way they will be the same as GIFs, but with better codecs.
I hope the author is tracking how often those gifs are loaded, and (after the HN hug-of-death dies away) they pay close attention to whether or not users are seeing that they're there at all. I hope it works out, because it's pretty well implemented - it doesn't slow the page down, popups all work (kind of.. it's weird if you don't stop on each item), and it's a nice design.
In my experience any feature on a website that isn't _really_ obvious tends to get single-digit-percentage engagement, and sometimes none at all. Users don't explore UIs. They want things to be clear, simple, and obvious. If it isn't then it might as well not exist...
I know this is a probably overtly provocative title, but still...
This makes the assumption:
- That everyone navigate a SaaS website in a particular way
- That no-one uses text-to-speech accessibility software when navigating websites
- That everyone wants a picture/gif to know more about a feature
Basically, a quite inconsiderate approach to UX design.
What about using video with control instead? Furthermore what about performance?
I think the point is that it autoplays and gives you a very quick rundown on the specifics of the feature/pricing. The way they're using gifs in the demo, it doesn't look like controls would make sense, but I think the message of this article is more about providing meaningful information about services and pricing than the gifs themselves.
Yeah, it's more of an implementation detail.
But indeed, if I implemented this myself I wouldn't use GIFs. It's a joke of a format which produces bloated files, very limited colours (slightly less limited if you employ some creative hacks), no proper alpha support. We should put it in the bin and move on. Whether that's <video> elements with no controls using something like AV1 (neat but no alpha AFAIK), APNG or VP9, I don't really care.
For a screen recording of a UI, it's the perfect format unless you're demoing a video/photo editing application.
You don't need alpha or many colours and screen recordings are quite efficient in a GIF.
This is just not true.
I think for many tech-savvy users, video = long-winded, annoying, work to scrub through for the good parts, etc. Whereas these brief animations are a helpful visual teaser of exactly what the feature is.
It's not unlike a modern Assassins Creed game, where the skill tree shows a little silent video of what the move you're about to unlock looks like in action. You feel more confident that you know exactly what you're getting for your doubloons.
Fable 1 did this too
Would performance with video be better than gifs?
Yes, video codecs are way better at generating smaller file sizes. GIFs are literally like flip-books of images.
You can also autoplay videos without controls and loop them, but you have to mute them.
Most "GIF" hosting websites actually use videos. Especially when it's "GIFs with sound".
That's actually not correct, GIFs can encode the differences between frames and quite efficiently for screen recordings.
A GIF will be more efficient for a screen recording so long as there are small changes between frames.
Real video codecs do temporal compression too, and considerably better than GIF.
The situations where GIF can be smaller or more efficient than real video codecs are generally esoteric, to the point where Iâm happy to say that no one should _ever_ use GIFs for block-level graphics.
Oh, interesting. So it does some encoding, but not very efficiently?
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 all these features.
A better encoder can take the images from the article down by a lot (I got 80% reduction with minimal reduction in quality using
).
Every major video codec does this exact thing. Can you please stop spreading this misinformation all over the thread?
> Most "GIF" hosting websites actually use images.
I think youâre mistaken - I think they mostly actually use videos these days and âGIFâ refers to short and small videos generally, not the specific file format.
You're right. I meant to say "videos", fixed it.
And he didn't mention a change in conversions - which would be far more convincing.
If I can click elsewhere to get them to go away, maybe they aren't too bad. First reaction was to wonder if this was satirical, though. :)
Also in documentation, I always loved the Grafana documentation for being sprinkled with short gifs to demonstrate different features.
This is an interesting idea, and I can see the value... But how does this work for those with disabilities? Will screen readers describe the image in the mouse over as well? (I imagine so, if alt tagged, but I'm not sure and would love to know)
I imagine they can read the text parts with a screen reader. Doubt this is any different than adding an image anywhere else
Sure, but a screen reader picking up on alt text won't convey the same amount of information as the visual would. Neither would an embedded movie.
But, that's all just begging the question: what _is_ the practical, accessible alternative that _does_ serve the needs of the blind and visually impaired?
Blind people canât see. Alt tags donât change that.
How do you sell paintings to blind people? Maybe the answer is â you donât.
If youâre selling charts to visualize data, blind people arenât your audience.
Just like if youâre selling shovels to dig ditches, youâre not marketing to people in wheelchairs.
Just because some people canât use a product, doesnât mean you shouldnât be allowed to sell it.
At risk of sounding like a SJW here, I think it's an interesting point you made that merits further discussion.
It seems to me that you're arguing about blind people as a market segment. By virtue of being blind there might always be products that blind people just won't benefit from, I get that.
But there's a reason (offline) accessibility is regulated by law and somewhat incorporated into daily life (e.g. wheelchair ramps). If it weren't, blind people (and others with disabilities) would be even more marginalized than they already are.
Would it be okay if Walmart made their stores inaccessible to blind people? I guess they already do, it seems pretty difficult to navigate those aisles with product tags.
While modern life outside of the internet has been developed for a long time, the internet is still relatively fresh, and making sure those who are blind aren't prevented from participating in the internet is generally a good thing, I think.
But perhaps your stance is that the problems of those with disabilities should not be the responsibility of those who do not have those problems, which is a valid argument.
Alt tags don't change whether blind people can see and they're not supposed to either, but they do allow people who would otherwise be prevented from being a customer, to be one.
You don't have to sell paintings to blind people, but they do buy them; 3D paintings, extra-textured paintings, even paintings with braille.
Selling charts to visualize data is a certain way of making data more accessible to certain customers, why not extend that to the visually impaired?
>Just because some people can't use a product, doesn't mean you shouldn't be allowed to sell it.
You're definitely allowed to sell a product, the question is: should you be allowed to exclude potential customers based on factors they cannot control? Marginalized groups have better lives than they used to in history, but I'd argue a lot of progress can still be made.
Whether the onus should be on the people (blind or not) themselves, corporations or the government, is a very different discussion about responsibility and the limits of choice that I'm not gonna go into here.
Again, I do see your point as well. Just wanted to point out some things.
"Selling charts to visualize data is a certain way of making data more accessible to certain customers, why not extend that to the visually impaired?" Royally messing up a product for the blind by not hiring real blind people would be worse. Without the market data that this would help the product survive, it's hard to take this as seriously as it demands. There's a reason people build for people like themselves - it's surprisingly easy to get things wrong for people unlike you
This reminds me a useful feature of Lotus Word Pro 96:
If you selected a tool and did nothing for 2-3 seconds, the mouse cursor changed into an animation that hinted what you could do.
Anything you can do to help people figure out what your software does, and how to use it is 100% worthy.
This isn't good UX and it's not accessible or web-friendly either.
I always assumed that the pricing pages were intentionally vague so that the buyer could take a small set of true words and imagine what they want the feature to be, rather than what it actually is.
Of course this can frustrate users. But that's not to say that this ends up being a net positive anyway.
I noticed Notion sites have some problems loading on mobile lately so I made a site from this post using Notaku [0]
https://gifthing-69a3.notaku.site/
[0]
Why 20 MB of GIFs when you can have 200 KB of videos?
I think this is neat. Itâs probably not always useful for everything, but definitely very cool for many kinds of apps, nice work!
I like it. Makes complete sense.
Sure, this and that could or should be improved. But only ever focussing on those things is depressing.
No, it should not.
Neat idea. Couldn't find any evidence whether it helped sales?
Every site that's not an application, just a way to display text and media, should progressively enhance it's function with javascript, not require it's execution to see anything at all.
This tdinh.notion.site fails that very low bar and is just a blank white page. It both fails to communicate it's desired message about GIFs and communicates that it's not a voice to listen to on this subject regardless.
Quick sidenote here, if you're on Linux and want to record gifs like this, Peek[0] is what you're looking for. It's a lifesaver!
[0]
the only thing you need to do is measure your landing page and optimize it for number of qualified leads per day/week/monthâŠ
Maybe first try rendering literally anything when javascript is disabled. Then worry about adding GIFs.
GIFs are outdated...
https://old.reddit.com/user/anti-gif-bot/
yeah that's nice, but you only reaally need one gif,
https://archive-media-2.nyafuu.org/vp/image/1522/39/15223952...
The loading lag in the example is ugly and confusing.
I imagined this _very_ differently based on the title and expected GIFs all over. This is actually a good idea as presented, but probably won't work well on mobile as another commentor mentioned. Mobile would be better served with something like the expanders Wikipedia uses on the mobile site.
