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 wouldn't survive A/B testing on the landing page of the most recent groupon clone doesn't mean it's not useful, cool or fun.
Style, decoration and usability are not mutually exclusive. As with many disciplines they can co-exist beautifully. Frank Lloyd Wright's buildings wouldn't look much chop if he hadn't taken style into consideration.
Not to undermine the argument, but Wright does not prove the mutual inclusion of style and function. His buildings are notorious for structural problems.
Agreed, but effects like this are not style, they are a cheap veneer applied to otherwise poorly thought out designs. Fashionable kitsch integrated into otherwise unoriginal, uninspired designs.
It seems that many commenters are missing the value of a demo combining effects in new ways, presented in a new context.
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.
Animation is not at all mutually exclusive of good usability. Usable animation makes state transitions clear to users in ways instant transitions never could.
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 one thing I was thinking about while looking at these was how badly one needed to be the alert view "pop" from iOS. Such an aesthetically pleasing effect that gets the UX metaphor across extremely well.
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, 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.
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.
I agree with the seizure point. I think this is a bit too "nuts." I showed it to my friend who has frequent seizures and she agreed. I would not recommend CSS moving this quickly for general use.
Hover effects aren't awful for usability at all. It is about using this in the appropriate context.
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.
Thanks for these. I was able to enjoy them on their own merit without having to resort to fire and brimstone speculation that we're entering a new "skip intro" era.
Why is everyone comparing this to flash? Surely the problem with flash was one of accessibility and graceful degradation, rather than, say, having animated elements? There's nothing wrong with animations/transitions in the right context, right?
I've been visiting this site for a while, and this is the first time I got a awful stomach ache reading the comments. What is it that you want? Websites that look like they are written to work in lynx and IE4, in the pretentious name of usability?. In one breath the lament is that the older browsers are not offering features to eliminate flash, you see the it now and bitch. What a bunch of hypocrites. Just use curl to read your web pages or go back to gopher.
not only are they pure CSS (hence GPU accelerated and hence work lightning fast without any considerable lag) but they are also very (!) easy to write.. such things with js would have easily taken north of 200 lines (non minified with proper new lines where required) where as with css it would only take something like 10-20 lines max.
If enough people dislike this, I'm sure somebody will write a "NoTransitions" browser addon, or fork Firefox/Chrome and remove the CSS transitions functionality.
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.
> ...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.
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".
That's some very narrow thinking backed only by your anecdotal evidence.
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...
It's funny that we get this kind of response after that rant about the future of UI earlier this week
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?
> 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.
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...
I never said it was an iphone vs developer problem - I said it was a platform vs developer problem.
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.
"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.
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.
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.
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.
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.
You are both correct. IE always had a <button> element, however it only started working like other browsers on IE8. Before that it behaved like an <input>; you had to add "type=submit" to get it to actually submit the form.
The end of the Flash banner ad era is in sight. The sentiment is that this is simply replacing one evil with another but I think it will accelerate the migration from Flash so overall this is probably a good thing.
If you hate Animations, then have your browser disable CSS3 animations. Any website worth its salt will use Modernizr & jQuery to gracefully fall back.
Only for some people. For others, including myself, usability wins every time. Even for entertainment, I want the controls to fade into the background.
You said it yourself - you want the controls to _fade_ into the background.
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.
Crap. This will be the next flash, won't it? Should I start writing the CSS3Block extension for all major browsers now, or is the effort already underway?
