Go nuts with CSS3 hover effects
tympanus.net
tympanus.net
I'm pretty sure this is exactly the problem people had with flash-heavy sites in the first place.
No, it's a tech demo with artsy pictures. This is very obvious.
The site is also very bad as a computer game and a travel catalogue.
There are many app experiences beyond simple navigation that ask for and respond to actions/events - many would benefit greatly by expressive animation. I agree the effects shown are more distracting than useful, but this isn't a CSS template for folks to copypaste. It's inspiration to experiment and discover the subtle, sophisticated, delightful details that make your app feel alive and exciting without going so far that it becomes a whirling and twirling abomination.
Use some design judgement. Don't sniff at the tech demo for being a tech demo.
The perennial example is iOS: Almost all of the animation is there to guide the user through what's happening when the state changes. Left/right transitions make view hierarchies intuitive to follow. Expand/contract animations spatially establish the home screen as the very top level. It's subtle at times, but the animation in iOS is almost never decorative; it's only "fun" because it builds and reinforces the user's mental model of what they're navigating, making them feel in control.
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, so I can spend less of my life watching text fade in.
The Chrome Web Store uses this to excess, with sliding panes flying everywhere. It looks great, but it's really painful to use.
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.
They add two distinct advantages: 1) Ease of accessing additional information. Instead of having a click based event a rollout is 100x easier to accomplish and can reduce clutter on a page. This is accomplished by being clear with labels, such as a "More Info" or "Rollover for details". It is surprising to find out out how many users won't click.
2) Whimsy. The emotional impact these have is wonderful, and to discount it is to ignore the delight of this new medium.
As for the touchscreen issue, these would be handled in a click state. This is how hover menus are handled in iOS for example.
This is exactly the problem.
Haven't used it, hopefully it will be useful when Flash is gone.
Apart from that I liked the effects as a proof-of-concept.
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.
"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.
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.
Or not.
On touch touchscreen it feels natural to just touch the part of the screen you want to interact with. I hate the word, but it's intuitive. It doesn't feel like something you need to learn and become familiar with. My daughter understood how to use my iPad when she was less that one year old. She just touched the screen and something happened, she was happy. Even my mother-in-law understand how to use a touchscreen.
Neither my daughter nor my mother-in-law can use a mouse: it requires too much dexterity. I've seen people hovering a mouse in front of the screen hoping that something will happen. It's less intuitive, but it's familiar to all of us on hackernews.
What I'm trying to say is that there is something intrinsically natural and easy with a touchscreen: touch - interact. We won't go back from that.
I might be proven wrong, and tomorrow everybody will do on hover with its phone/tablet with the process you describe, or the one described by grovulent, or another one. But my guess is that it will remain mostly unused, except for a few "power users".
Twenty years ago, I'm sure people would have been skeptical if you told them that someday, they would be able to wirelessly interact with a mass network of information via a touch-responsive, glassy device that fits in the palm of their hand.
Now where would be today if we'd listened to THOSE skeptics...
If we think about the future of touch and gesture interfaces, I absolutely think we'll see a hover state be implemented, but it won't be connected to a mouse cursor. That's moving backwards.
There will likely come a point where a touch or gesture interface will be able to tell if your hand or finger is quite literally -hovering- over a touch-enabled element, and will be able to give you context.
It's seems completely intuitive. If you're hovering over an element, you're likely hesitating, so give more context. Preview the next screen, provide info in a tooltip. Why wouldn't you take advantage of this?
A Synaptics touchpad can do that, no problem. Used for, at very least, the `palm detect' functionality. Catches a single finger at a few milimeters' distance, configurable to the boot.
But I believe pushing that is a prime example of backwardnes -- a metaphor taken literally overriding ergonomics concerns. It taxes your muscles more to hover your hand in air with no support, than to slide it on screen. Perhaps that doesn't concern a person nearing top physical fitness, but that's a limited segment of market. Also, keeping fingers away precludes tactile feedback of reaching edge of active area, or some sort of active tactile feedback: http://www.macrumors.com/2009/12/24/apples-research-on-tacti...
The fingertip is the new cursor ;-)
If developers choose en masse various interface methods that a particular platform doesn't support - that platform loses.. end of story.
Nor is there anything inherently impossible about hover + touchscreen. Double tap to prevent scrolling (and at least on my nexus S I'd prefer that to zooming which 3/4 times doesn't actually zoom at all). Move finger across screen - stop over element without additional tap. That's hover baby!
Not sure why folks voting me down. What I'm saying is not only right - it's sensible... and it's also preferable. Developers should be deciding UI reality.
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.
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.
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.)
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.
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.
> drop support for IE due to a lack of BUTTON support
Use our screenshot service to embed self updating 75 pixel thumbnails on your site for free!
A fade is a very simple animation to communicate what's happening, but the details of duration and exponential vs linear transition can make a simple fade seem frantic, soothing, or even invisible. When you say "fade into the background", I assume you mean a linear animation that takes about 1 second. It's pretty awesome that the world has a very specific fade that serves as a "word" in our shared design language.
Interactions are filled with interstitials and microstates, but a fade isn't really appropriate for all of them. While we try to figure them out, some folks will make animations that remind us of geocities - but others are going to express actions with animations that seem so natural we can't help but describe the action as the animation. Just as you did.
And then our shared design language will have a new word.
Animation is not the reason flash was [used] bad[ly].