[HN Gopher] Every pricing page should have GIFs
___________________________________________________________________
Every pricing page should have GIFs
Author : trungdq88
Score : 317 points
Date : 2021-11-26 08:14 UTC (4 days ago)
(HTM) web link (tdinh.notion.site)
(TXT) w3m dump (tdinh.notion.site)
| ichydkrsrnae wrote:
| 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.
| treis wrote:
| >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.
| jjeaff wrote:
| >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)
| [deleted]
| jonahx wrote:
| 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.
| ichydkrsrnae wrote:
| 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.
| tempestn wrote:
| There's somewhat of a convention to use a dashed underline on
| links that have behaviour like this; perhaps that would be an
| improvement.
| leephillips wrote:
| 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.
| mahdi7d1 wrote:
| 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.
| marcosdumay wrote:
| 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.
| GuB-42 wrote:
| 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.
| ichydkrsrnae wrote:
| 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.
| Minor49er wrote:
| What is a "psuedoschizo" decision?
| fuzzer37 wrote:
| Almost schizophrenic. Made sense to me.
| Minor49er wrote:
| Ok, so how is something being misused "almost
| schizophrenic"?
| ichydkrsrnae wrote:
| Not using fancy made-up words around you ever again.
| Minor49er wrote:
| If you can't even define them, then that's probably for
| the best
| ichydkrsrnae wrote:
| A conflicting decision. Please ignore the word, my brain
| made it up.
| metafunctor wrote:
| Make your next one a coffee?
| vadfa wrote:
| 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.
| ichydkrsrnae wrote:
| 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...
| kevin_thibedeau wrote:
| It should be an accordion that opens a detail view.
| svdr wrote:
| I like it more when items stay opened, instead of closing
| again when another item opens (like with an accordion).
| ichydkrsrnae wrote:
| 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.
| pyronite wrote:
| > 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.
| antoniuschan99 wrote:
| another option would be using this i
|
| User will click/tap and the modal of the gif will show
| Griffinsauce wrote:
| > 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?
| stronglikedan wrote:
| This is really the only correct solution in the context of
| modern UX.
| ichydkrsrnae wrote:
| 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?
| metafunctor wrote:
| 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?
| ichydkrsrnae wrote:
| 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.
| codemonkey-zeta wrote:
| 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.
|
| i 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.
| [deleted]
| ichydkrsrnae wrote:
| 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.
| oauea wrote:
| Works pretty well.
| https://www.anwb.nl/verkeer/veiligheid/strepen-op-de-weg
| k1t wrote:
| 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.
| jimmygrapes wrote:
| 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.
| lsaferite wrote:
| 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.
| ichydkrsrnae wrote:
| 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.
| matt-attack wrote:
| 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.
| mikestew wrote:
| _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).
| tobyjsullivan wrote:
| 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.
| throwawayboise wrote:
| Yellow lines separating oncoming traffic is not universal
| though? I believe in the UK that the center lines are
| white?
| tannhaeuser wrote:
| 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.
| [deleted]
| toast0 wrote:
| 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)
| ubercore wrote:
| 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.
| jrockway wrote:
| 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).
| nybble41 wrote:
| > 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.
| [deleted]
| dheera wrote:
| 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.
| pineconewarrior wrote:
| well... 99% perhaps not. mobile safari is pretty important
| InsomniacL wrote:
| 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.
| conductr wrote:
| 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.
| flxy wrote:
| 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.
| gtsop wrote:
| 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
| ldoughty wrote:
| 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)
| ludamad wrote:
| I imagine they can read the text parts with a screen reader.
| Doubt this is any different than adding an image anywhere else
| actually_a_dog wrote:
| 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?
| fijiaarone wrote:
| 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.
| byvirtueof wrote:
| 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.
| ludamad wrote:
| "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
| daralthus wrote:
| 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.
| ollybee wrote:
| Also in documentation, I always loved the Grafana documentation
| for being sprinkled with short gifs to demonstrate different
| features.
| onion2k wrote:
| 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...
| wscott wrote:
| 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...
| https://t.me/s/TelegramTips
|
| (both look better in Telegram than on the web, but it gets the
| idea across.
| ravenstine wrote:
| 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.
| Gigachad wrote:
| 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"
| hinkley wrote:
| > 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.
| randallsquared wrote:
| 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. :)
| tomcam wrote:
| Neat idea. Couldn't find any evidence whether it helped sales?
| tambourine_man wrote:
| >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?
| huhtenberg wrote:
| > _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.
| tambourine_man wrote:
| >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-...
| huhtenberg wrote:
| [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.
| slantyyz wrote:
| 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.
| tambourine_man wrote:
| 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.
| marcosdumay wrote:
| > 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.
| tantalor wrote:
| 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).
| mcintyre1994 wrote:
| 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.
| aloisdg wrote:
| What about using video with control instead? Furthermore what
| about performance?
| loceng wrote:
| And he didn't mention a change in conversions - which would be
| far more convincing.
| mikepurvis wrote:
| 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.
| aloisdg wrote:
| Fable 1 did this too
| spcebar wrote:
| 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.
| lol768 wrote:
| 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.
| janekm wrote:
| 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.
| chrismorgan wrote:
| This is just not true.
| fijiaarone wrote:
| Would performance with video be better than gifs?
| BasilPH wrote:
| 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".
| janekm wrote:
| 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.
| chrismorgan wrote:
| 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.
| BasilPH wrote:
| Oh, interesting. So it does some encoding, but not very
| efficiently?
| janekm wrote:
| 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 https://compress-or-die.com).
| mdoms wrote:
| Every major video codec does this exact thing. Can you
| please stop spreading this misinformation all over the
| thread?
| chrisseaton wrote:
| > 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.
| BasilPH wrote:
| You're right. I meant to say "videos", fixed it.
| boomskats wrote:
| 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
| remorses wrote:
| 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] https://notaku.website
| [deleted]
| aasasd wrote:
| 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.)
| elondaits wrote:
| 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.)
| aasasd wrote:
| 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.
| SavantIdiot wrote:
| 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.
| gennarro wrote:
| 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.
| elcamino44 wrote:
| I think this is neat. It's probably not always useful for
| everything, but definitely very cool for many kinds of apps, nice
| work!
| Kye wrote:
| 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.
| [deleted]
| DoneWithAllThat wrote:
| 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.
| keithnz wrote:
| 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
| Waterluvian wrote:
| 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.
| strogonoff wrote:
| 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.
| lunch wrote:
| Maybe first try rendering literally anything when javascript is
| disabled. Then worry about adding GIFs.
| imwillofficial wrote:
| The loading lag in the example is ugly and confusing.
| robertoandred wrote:
| What on earth did this site do to scrolling? Spacebar doesn't
| work, arrow keys work really weirdly...
| EForEndeavour wrote:
| Spacebar: replaced by GIFs.
|
| Arrow keys? Believe it or not, also replaced by GIFs.
| judge2020 wrote:
| It's a Notion-published site, so arrows select "blocks" (pieces
| of content) on the page.
| smoldesu wrote:
| 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] https://github.com/phw/peek
| barrenko wrote:
| No, it should not.
| eb0la wrote:
| 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.
| magicalhippo wrote:
| 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...
| bhelkey wrote:
| Elsewhere in this thread:
|
| > Don't use GIFs, use audioless mp4s instead.
| throwaway81523 wrote:
| 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.
| nhumrich wrote:
| 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.
| throwaway81523 wrote:
| 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 ;).
| waynesonfire wrote:
| yeah that's nice, but you only reaally need one gif,
| https://archive-media-2.nyafuu.org/vp/image/1522/39/15223952...
| b20000 wrote:
| the only thing you need to do is measure your landing page and
| optimize it for number of qualified leads per day/week/month...
| rytcio wrote:
| 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
| city41 wrote:
| 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)
| vehemenz wrote:
| 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.
| SimeVidas wrote:
| Why 20 MB of GIFs when you can have 200 KB of videos?
| authed wrote:
| GIFs are outdated... https://old.reddit.com/user/anti-gif-bot/
| sam1r wrote:
| >> Every pricing page should have GIFs
|
| Given that you have a slick UI product with charts. Maybe not
| _every_ pricing page.
|
| Also, mobile.
| rsync wrote:
| 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.
| airstrike wrote:
| I always scroll every page along the whitespace on either side
| for that very reason
| jimmygrapes wrote:
| 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.
| franciscop wrote:
| 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.
| capybara_2020 wrote:
| 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.
| hateful wrote:
| Maybe they had sound, even if it was silence?
| https://support.mozilla.org/en-US/kb/block-autoplay
| devmor wrote:
| Firefox doesn't block any MP4s for me. Sounds like your
| addons, or a cross site security error.
| gpvos wrote:
| 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.
| mceachen wrote:
| 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...
| Groxx wrote:
| 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.
| Sesse__ wrote:
| 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.
| marcosdumay wrote:
| 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.
| astroalex wrote:
| I have issues with videos on Twitter. It's not every video,
| but about 10% refuse to play in Firefox.
| nfriedly wrote:
| 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
| janekm wrote:
| 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).
| oefrha wrote:
| 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.
| technobabbler wrote:
| > 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
| handrous wrote:
| 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.
| janekm wrote:
| As another example the encoder at https://compress-or-
| die.com 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.
| janekm wrote:
| 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
| https://gifcompressor.com .
|
| 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!
| technobabbler wrote:
| 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.
| Gigachad wrote:
| You have to encode it in multiple formats because many systems
| do not support proprietary codecs.
| wildrhythms wrote:
| Is there a format that is not proprietary and works for this
| purpose?
| hahamrfunnyguy wrote:
| What do you use to encode the MP4s?
| SSLy wrote:
| ffmpeg
| jazzyjackson wrote:
| 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)
| dehrmann wrote:
| IIRC, ~everything other than Apple devices works with vp8 and
| webm. Apple devices like mp4 and x264.
| austhrow743 wrote:
| 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.
| Gigachad wrote:
| 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.
| adrianh wrote:
| 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.
| avinashjn wrote:
| 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.
| throwawayboise wrote:
| 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.
| ezfe wrote:
| 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.
| Rebelgecko wrote:
| Some (all?) browsers will still play autoplay videos as long
| as there's no audio track (or if it's muted by default)
| SimeVidas wrote:
| I'm curious, would you disable GIF autoplay if the browser's
| settings offered it?
| taftster wrote:
| Yes please.
| Ragnarork wrote:
| 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.
| a3w wrote:
| The website asks me to enable mp4 video. It does not contain
| gifs. Oh the irony.
| Kye wrote:
| 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.
| apankrat wrote:
| 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. https://backup2.com/features
| superkuh wrote:
| 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.
| gherkinnn wrote:
| I like it. Makes complete sense.
|
| Sure, this and that could or should be improved. But only ever
| focussing on those things is depressing.
| ldng wrote:
| 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 ?
| msdrigg wrote:
| Exactly. And similarly with the charts and graphs, how about
| just the good old raw csv data
| wizzwizz4 wrote:
| 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.
| [deleted]
| oauea wrote:
| 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 ?
| ggregoire wrote:
| For your off-topic: Maybe they are French.
|
| https://en.wikipedia.org/wiki/Question_mark#Stylistic_varian.
| ..
| cyann wrote:
| 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...
| SamuelAdams wrote:
| 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...
| Benjoin wrote:
| 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!
| [deleted]
___________________________________________________________________
(page generated 2021-11-30 23:00 UTC)