> Design for design's sake.

This is one of the most senseless things I've read in a long, long time. I guess you think "design" means "decoration".

Lots of people do. I am sure people asking to learn about design on this site have been directed to dribble.

Actually design is a very ambiguous word for me as a developer. I use it to include application architecture, and user workflows amongst other things, while many other people seem to think its all about the shinny pictures on the front page.

The first mention I have ever seen of dribble on this site was from you, just now.

I have had the opposite experience and it seems to me that design articles posted here tend to be focused on user experience improvements, research based explorations into best practices, and calls to stop gimmicky mumbo jumbo like scrolljacking.

I hope this Picasso thing doesn't take off. If Van Gogh wasn't annoying enough we'll soon have this cubism abomination in every museum.

Beauty for beauty's sake. Art for art's sake. This is just tacky.

> This is just tacky.

According to you. I think it's beautiful.

I personally don't like the current implementation. But I think they are doing some good work on this repo.

Over the next year I expect it to mature quite a bit. Once I start using it on my current project, I will even contribute to the code base.

Thanks :)

What's the problem with animations? We have 8 cores with 3ghz+ and 16gb of ram to just render plain text?

I consider it as high distraction. Yeah, sure it looks great in demos and talks, but do we really want to have two seconds animation every time one switchs tab? Or would you like to have this kind of design in tool you use everyday, editor or IDE?

IIRC, in the design guidelines longer animations should be limited to context switches, where anything under two seconds is "acceptable speed" and anything under half a second is "fast".

There's no need to use the most extreme animations for minor actions in the interface, and the linked page is obviously a showcase, not a real application.

Showcase is no excuse. This was intented to extend bootstrap. The author clearly envisions people reusing these animations.

The author has stated right below that some animations can be improved. Make your suggestions.

The author is on HN and commenting in this thread. So I did make my suggestions: Make the animations shorter, more subtle.

Hello, thanks. I see lot of people would prefer what you're asking, and actually the Material Design specs are not followed very well by me regarding the animations. If you'd be so kind to open an issue on the GitHub page I'll be happy to assign a priority to it and work on it when I find some time.

Because it takes time and is distracting.

An interface should be snappy and get out of your way, not try to impress with pointless animations. That screams graphic designer trying and failing to do UX. Which is material in a nutshell really.

Material animations are not (entirely) pointless, they are designed to improve user's awareness of UI's behaviors - primarily by making transitions between related screens less "beam-me up, Scotty" Teleport-like.

Sure, it may be prone to abuse, but the base theory is sound. By tapping into the perceptual abilities of movement and shadows, some parts of the inner structure and layout of the interface (which are usually only known to the dialog's developer) are exposed to the user in an intuitive way.

What's some of the best UX design you've done? Can you tell me about affordances, and why the Materials design falls short on them? On desktop? On touch devices?

For us developers, a command line and vim (or emacs, not trying to start a war) can be the epitome of UX -- once we learn all those shortcuts.

But for users, there's a lot more that comes into play. Indicating to a user when something can be interacted with and - more importantly, many times - how it can be interacted with is very important. Usually such indications will also inform about what kind of result will happen from the interaction: will the form submit, will the page reload, will I see a list of additional options?

Just as important is indicating to the user that yes - you just interacted with something that can be interacted with. Depending on the action, this can be something as subtle as an underline - or as obvious as showing a loading indicator.

The Material animations aren't just eyecandy for the sake of eyecandy. While touch screens are getting better, there are still situations where a touch doesn't necessarily register as a touch. It's super important to indicate to the user that a touch has been registered. It's just as important that this happens immediately, instead of after - say - a round-trip request to a server somewhere.

If you've built and designed a user interface that has amazing affordances, a general perception of 'speediness' even if the server is being slow, and treats touch users as a first-class citizen ... I'd really like to see your work!

We do need to let users know a touch has been registered. In some cases all you need is a color change. Other time, a slight fade in or small animation. But having content areas fly in for almost a whole second is overkill. That's why this site is a poor example of the technique.

  having content areas fly in for almost a whole second is overkill

...except for those cases when it's not. Major context changes such as switching applications benefit from more explicit animations, that physically convey where everything goes or comes from; those can run from less than half a second to about two seconds for more showy "Welcome to product X" screens. If the old interface simply disappears, the user has no clue on how to restore it. That's why you get nifty "minimize" animations in all modern desktop environments that care about more than processor cycles.

In the Material design, animations are also intended to increase affordance by showing what areas are interactive, without requiring the extra chrome of everything having 3D borders.

I think you misunderstand. I'm not against animations. The minimize animation in today's operating system is a perfect example of how animation can simplify the user experience (although I do think the OSX shrinking animation is a tad dramatic). But keep in mind, those animations are still short compared to the examples here. Whats more, the linked example uses the fly in animations for interactions without major context changes. Switching from pages in a document is hardly the same as switching applications.

I think that a compromise can be found, just check out Lollipop to see a successful example.

There are some glitches when animating layouts. The "primary action button" (is that what the floating circle was called?) sometimes covers the scrollbar after resizing the window, and jumps around on mouse-over; and when the browser window is not maximized, after selecting an option in the left vertical menu, the floating panels jump around a lot vertically before stopping. I'm using latest Chrome on Windows 7.

That's up for debate. I have disabled the animation in L as they were too distracting.. Although I like Material Design overall.

I really really really Material design

I like that they make me think about things like depth to differentiate what's active , I like the little line in inputs ,it encourages users(me included) to fill the input,

the ripple effect is small and cheap animation and communicates to the user a click .as is with checkbox etc

the morphing transitions is their best idea , As a user I hate flickers , if you blink you miss them overlay are even worse unless you are alerting.

First of all, I like the design. But about the animations...

Web browser engines are not particularly good in animation. I was viewing this with (not quite latest) Firefox and the animations were really choppy (with my less than 3GHz PC). As in really annoying and made user interaction next to impossible. Other browsers may work better.

Secondly, animation (especially in browsers) is very power consuming if you target mobile devices. Of course, this isn't something a web designer would have to care about, because unlike for "native" apps, you can't tell which web site was consuming all the battery. (and battery consumption means bad reviews in app stores)

I work for a mobile device company and I can tell you, for every minute a major web designer spends adding animation on a popular web site, a systems engineer spends an hour trying to optimize the power consumption (with changes to WebKit/Blink, device drivers and the kernel).

Web browsing power consumption is a major benchmark how device manufacturers choose their parts vendors. One of the key benchmarks is picojoules required to render nytimes.com front page. (this is ridiculous but that's how the industry works)

Quite simply: your design would be a lot better if you'd remove most (if not all) of the animations. Especially the mouse click circle (which appears so late it's distracting) and the things that scroll from the bottom (which scroll so choppily that it's annoying). They don't add anything to the usability of this site, on the contrary they make it work slowly.

Otherwise I like the aesthetic of your design.

What percentage of machines do you think have those specs?

do you think that the listed specs in the comment are truly accurate regarding the types of machines needed to properly display Material design elements, or just the author's way of indicating the the current state of technology?

The thing is, it doesn't really matter. You can't program your interface for quad-core processors and 16GB of RAM because if 50% of the userbase is using 1GB on an ARM processor then you either have to design two interfaces or cater to the lowest denominator.

At the risk of being productive with my comment, please read Google's information on material design (http://www.google.com/design/spec/material-design/introducti...) and you'll understand that this isn't animation for animatio's sake or design for design's sake.