Am I the only one who doesn't get this Material Design everywhere thing? Maybe it's why I'm not a designer, but do we really want all our UI experiences everywhere to look exactly the same (with perhaps color variance only)? I mean I'm all for having design principles, like the timeless principles of typography, which have near-infinite variance, but with a powerful yet subtle underlying set of guidelines which make it beautiful and legible. Material Design seems to me like Google branding forced all over the place. Boring.
UX designer here. It's way overhyped. The concepts behind it are great (using good motion design, giving proper feedback, showing clear affordances for actions, and lots of other good stuff), but that does not mean that everything has to look like Google's material template to work.
For everyone: take the UX cues from Material, sure, but please make it your own. The clone army is getting very, very old.
I'm working on a desktop application at the moment, and taking great detail into making a good UI/UX. This is something I've never really paid much attention to in the past - and the Google's spec is one of the few comprehensive guidelines on UI/UX. I'm following it, and using for inspiration, but taking liberties as to not make something that looks solely Google-y or Lollypop-ish.
The sad truth is in particular in the free software space there are only a few gems of truly inspiring consumer software, the rest are mindless rip-offs with terrible UI. Especially the chrome and rendering techniques used on a modern linux desktop compared to both Windows / Mac OS X are hacks. Compare for example the graphical foundation libraries of Mac OS X with the X11 + compositing wm + gtk / qt stack. So for example Yosemite style translucency might be implementable, but not in the presumably nice way OS X is able to do it, because OpenGL is not integrated as tightly in the graphics stack in Linux.
At least Kwin primarily runs in OpenGL mode, rather than GLX mode, so it never uses X for compositing and always does its graphical effects (which include translucency, blur, wobble windows, desktop cube, etc) as OpenGL only effects with no X library dependencies.
Its transition to Wayland is depreciating any latent X dependencies in its internal rendering code as well.
The interesting bit is that in addition to scene graph engine, "QML" is actually two slightly different but overlapping things.
First - QML is a set of javascript bindings to manipulate the native Qt widgets. In this regard it's a bit like Delphi mixed with Smalltalk. You can build and rewrite the UI scenes, using javascript as just the glue language. The more logic is built into the native widgets, the less javascript code will be required for actual UI implementation. (QML requires QtScript, which builds on top of V8. So for random javascript code execution, it's reasonably fast.)
Second - QML is a declarative scene description language, not entirely unlike CSS. You can embed javascript code to handle dynamic UI updates, which is pretty neat for simple interfaces, and quite nice for prototyping. For anything which requires high frequency and reliable low latency, native widgets are still the way to go. Yes, you can write your own custom widgets; Qt 5.x provides proper development headers so extending the framework is easier than in 4.x days.
Technically the scene graph and QML parts are separate. There is quite a bit of history in how the implementations lived and diverged: from a single "declarative" engine to first integrating a scene graph backend, to eventually splitting the QML implementation(s) into their own higher level modules.
Disclosure: I had the privilege of working for very propeller-head style Nokia projects where we had direct exposure and visibility to how Qt evolved from its 4.7/4.8 form to the current, modular 5.x rewrite.
Right, but at least as far as I know, currently a window manager trying to do compositing in Linux has to fight with X11 to achieve that, because it was not really designed to support that use case. Which is why Wayland is getting traction I guess.
OpenGL originated from the X world, for better or for worse, so I doubt there's much fighting going on. Any modern OpenGL is pretty separate from it however.
You're not. And "make all the apps look the same except for some color" is a misinterpretation, but it's how a lot of the early practitioners seem to be interpreting it.
The idea, as I understand it, is material is a base metaphor that's basically flat goo paper. It can be arranged, layered, and has some intrinsic animation behavior.
But the designer should think of material in the same way print designers think of text columns, or pullquotes, or the page. These are all things someone invented. They're useful, but they're not compelling. You still need to do something else on top of it.
The biggest problem I see with the flat goo paper is it's being treated like its intrinsically playful. But that's not appropriate for all UI's. Some apps should be stark and clean. Some should be dark. To me, if you're going to create a base UI language, it needs to be flexible enough to adapt to less playful brands. The next question is whether that's a problem with "material design" or just a matter of nobody has made a stark app with material as a metaphor yet. And if that's not possible then it's just a passing fad.
(Can you define "goo paper"? I searched for that term and did not find anything useful: almost all of the hits were "false positives", with "goo" and "paper" as part of different phrases separated by punctuation. I ask, because you seem to have a really short intuitive summary of the design concept, and I'd like to understand it, but you seem to be using a term that no one else has ever used.)
I'm a designer, big MD fan, and I'm dying to see some decent design in OS desktop land. But I don't get it either.
Design is all about understanding a problem/context and creating a solution to match it. MD is a great answer to a completely different problem than this project is solving.
