Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Go nuts with CSS3 hover effects

tympanus.net

Post reply on HN
Print view View original

11–20 of 70 posts

Re: Go nuts with CSS3 hover effects

#11

Post by Xixi »

grovulent wrote: post #4
iaskwhy wrote: post #2

When the iPhone was released I thought it would be the end of hover. I know that's what I think about when I see something like a menu which only works on hover.

Always surprises me that developers let platform makers dictate what they can use and what they can't. If developers chose to use stuff on the basis of what they as developers think should be used - and if that meant iphone users couldn't use them - guess who would ultimately win that battle? Not Apple. IE would have died years ago if developers had adopted that culture en masse.

The hover is not an iPhone vs developer problem, it's a touchscreen problem. Hover feels very natural with a mouse, but there's no logical equivalent on a touchscreen.

"on hover" is a side effect of pointing at things with a mouse. With a touch screen you touch things directly with your finger, you don't hover. So you have to design your website/app with that in mind: users will touch whatever they want to interact with. That's neither a mouse "on hover", nor a mouse "click".

Of course you can forgo people who use touchscreen, or even mouse and go keyboard only... it's a choice.

Re: Go nuts with CSS3 hover effects

#13

Post by _frog »

lell wrote: post #10

Why is everyone shitting on this in the comments? It's a demo: you can't complain that it's hindering usability or enjoyment of the pictures when there is no context in which you might use it or enjoy the pictures. When I saw this I thought it might be nice for the website of a magazine like vogue or something: some sites are about decoration and style, usability can be at the back of the priorities. Just because it…

> Some sites are about decoration and style, usability can be at the back of the priorities.

I'm pretty sure this is exactly the problem people had with flash-heavy sites in the first place.

Re: Go nuts with CSS3 hover effects

#14

Post by dexen »

Xixi wrote: post #11
grovulent wrote: post #4

Earlier quoted context omitted.

Always surprises me that developers let platform makers dictate what they can use and what they can't. If developers chose to use stuff on the basis of what they as developers think should be used - and if that meant iphone users couldn't use them - guess who would ultimately win that battle? Not Apple. IE would have died years ago if developers had adopted that culture en masse.

The hover is not an iPhone vs developer problem, it's a touchscreen problem. Hover feels very natural with a mouse, but there's no logical equivalent on a touchscreen. "on hover" is a side effect of pointing at things with a mouse. With a touch screen you touch things directly with your finger, you don't hover. So you have to design your website/app with that in mind: users will touch whatever they want to interact w…

> ...but there's no logical equivalent [to hover] on a touchscreen.

There isn't now, but there well could be.

Suppose for a moment that you get a good old cursor on iPhone and it follows your fingertip as you move it around the screen. It wouldn't even have to be user-visible. To click, you press a bit stronger, or you raise & lower your finger (`tap' if you will). The hover's back.

There's nothing inherent in touch-based technology that prevents hovers from working. Such behavior has been available way on (decent) touchpads for well over a decade now, modulo user-level configuration.

Re: Go nuts with CSS3 hover effects

#15

Post by iaskwhy »

jeffehobbs wrote: post #8
iaskwhy wrote: post #6

Earlier quoted context omitted.

That would be right if this was about platforms but it's not, it's about interaction. If you can't hover then why depend on it? Also, it's easy to add a touch event to do the same as the hover event, it's up to developers to do it. I was just thinking about the dependency of hover which need to go.

Exactly right. The thing I don't like about hover is that at core, it's a leap of faith -- you're asking your user to mouse around blindly (like Myst, anyone remember that frustration?) until the page rewards their fumbling with some sort of UI treat. It's a symptom of inefficient and poor design. (Having said that, these are lovely animations.)

Events like hover (or swipe, or trying to scroll out of the box) are really good for the experience side of design. It's that leap of faith that works that sometimes creates such a special connection between the user and the interface. If one ignores usability to favor experience then it's inefficient and poor design but I believe sometimes there's a good compromise between both.

It's also important to note that discoverability is really different than it used to be due to touchscreens and that plays a major role in usability.

Re: Go nuts with CSS3 hover effects

#16

Post by einhverfr »

peng wrote: post #7

Touchscreen issues notwithstanding, hover effects like this are awful for usability. The hover overlay completely obscures the original image, making it impossible to read the snippet and enjoy the image at the same time. The animation effect is more garish than anything, but this is a probably a personal quibble. It takes 200 ms for the hover effects to finish loading. I'd rather have the hover transition instantly,…

There are times when I find hover effects really helpful from a usability perspective. For example, with the right parameters, you can make text preview panes expand to view the entire text panel, and if white space is well used, the hovering doesn't get in the way too much.

This said, and while I realize this is a demo to show what can be done with CSS3, and while it is impressive, it gives me a headache. I wonder how long before we see Pokemon-style photosensitivity-induced seizures from CSS3 in the hands of clueless web devs.

Re: Go nuts with CSS3 hover effects

#17

Post by einhverfr »

Xixi wrote: post #11
grovulent wrote: post #4

Earlier quoted context omitted.

Always surprises me that developers let platform makers dictate what they can use and what they can't. If developers chose to use stuff on the basis of what they as developers think should be used - and if that meant iphone users couldn't use them - guess who would ultimately win that battle? Not Apple. IE would have died years ago if developers had adopted that culture en masse.

The hover is not an iPhone vs developer problem, it's a touchscreen problem. Hover feels very natural with a mouse, but there's no logical equivalent on a touchscreen. "on hover" is a side effect of pointing at things with a mouse. With a touch screen you touch things directly with your finger, you don't hover. So you have to design your website/app with that in mind: users will touch whatever they want to interact w…

"The hover is not an iPhone vs developer problem, it's a touchscreen problem. Hover feels very natural with a mouse, but there's no logical equivalent on a touchscreen."

Build your interface around the inputs. One nice thing about using CSS in this manner is one could (along with some discrete use of JS) build equivalent interfaces which are useful on touchscreens.

Re: Go nuts with CSS3 hover effects

#18

Post by einhverfr »

grovulent wrote: post #4
iaskwhy wrote: post #2

When the iPhone was released I thought it would be the end of hover. I know that's what I think about when I see something like a menu which only works on hover.

Always surprises me that developers let platform makers dictate what they can use and what they can't. If developers chose to use stuff on the basis of what they as developers think should be used - and if that meant iphone users couldn't use them - guess who would ultimately win that battle? Not Apple. IE would have died years ago if developers had adopted that culture en masse.

I'd actually agree with you. On LedgerSMB we made the decision to drop support for IE due to a lack of BUTTON support. Then IE7 came out which was still too broken and we didn't support IE. Then IE8 came out and supported buttons so we could support them again.

The tradeoff was simple: marginally greater market share at the time vs the fact that if we supported IE we would not be able to use BUTTONs to separate labels and inputs for i18n purposes. Really, there was no case to be made for IE support at that point.

So developers hsould consider the tradeoffs carefully.

Re: Go nuts with CSS3 hover effects

#20

Post by rimantas »

einhverfr wrote: post #18
grovulent wrote: post #4

Earlier quoted context omitted.

Always surprises me that developers let platform makers dictate what they can use and what they can't. If developers chose to use stuff on the basis of what they as developers think should be used - and if that meant iphone users couldn't use them - guess who would ultimately win that battle? Not Apple. IE would have died years ago if developers had adopted that culture en masse.

I'd actually agree with you. On LedgerSMB we made the decision to drop support for IE due to a lack of BUTTON support. Then IE7 came out which was still too broken and we didn't support IE. Then IE8 came out and supported buttons so we could support them again. The tradeoff was simple: marginally greater market share at the time vs the fact that if we supported IE we would not be able to use BUTTONs to separate label…

  > drop support for IE due to a lack of BUTTON support
We must be thinking about different BUTTON there. IIRC IE supports button since version 4.
Post reply on HN