Quantum Paper is the overarching name for a new, unified design framework intended to make experiences consistent across all platforms. According to information available to us, it represents Google’s effort to both create (with Google apps) and encourage consistent, beautiful design that delights across all platforms. Quantum Paper is a hugely ambitious project, looking to unify and codify paradigms for visual, motion, and interaction design across all platforms, including web, Android, and iOS.
Google I/O is going to be very, very interesting.
It seems to be chrome exclusive, and thus I am very unlikely to ever try it.
Did you even read the article? Or even just the excerpt right at the top of this page? This isn’t Chrome exclusive, hell its not even web exclusive – its a design framework spanning web, desktop, and mobile (both web and native). Polymer (the web part of the equation) works on IE 10, Firefox, Chrome, and Safari. Its open source and built on top of open standards – its as far from “Chrome exclusive” as you can get.
Did you watch the video? He said that you needed chrome. People read the summary and think they know everything. I know it is a long video, but what did i expect.
The video is from last year… They only referenced it in the article to give background, and only the first 5 minutes or so of the clip they referenced was relevant (the very first bit about web components)…
Didn’t Facebook roll out a revamped iOS app with the same name, offering a more modern take on the experience of viewing one’s newsfeed?
I wonder if there’s going to be a trademark infringement issue, or if Facebook and Google are willing to work together around this shared project name.
Well did Facebook register the trademark?
Edited 2014-06-12 15:09 UTC
That’s a good question; it’s almost as if I was asking the very same thing…
Well to be fair you speculated, I asked if you had checked — which is in your power to do.
I very much doubt they trademark codenames or project names. I have never worked for a company who thought project names nor code names were worth protecting. But if they are they need to use the registered trademark symbol and state that it is a trademark of whomever on the first use.
So, let’s see, flat design ( which everyone is doing now including Microsoft, Apple and Google ), sort of systemized with some icons and colors and this is very interesting because?
Fair enough. The design aspect of this (from a look and feel point of view) is so far pretty bog standard and boring – its main selling point is being at attempt at a platform neutral design language that works across both native and web based applications on both mobile and desktop. That is the goal anyway – long way to go to get there.
However, the nuts and bolts underpinning it all are very interesting imo. Polymer (http://www.polymer-project.org/) is one of the most impressive things I have seen in the web development space in the last 10 years. It is extremely ambitious, a dynamic, declarative, and fully encapsulated way to define entirely new “tags” (components) that is built on emerging w3c standards with extensive polyfills to make it work on current browsers (even IE). At least until all the browsers catch up on the standards something like this is sorely needed to allow developers to start getting their hands dirty with it.
The web components standard (http://www.w3.org/TR/components-intro/) really looks to potentially be a new paradigm in web development – I could see this becoming the way to do things in the near future. I think this is going to be a Really Big Deal.
I’ll be honest… it looks like Dojo.
Sure it does. The widget interface Dojo uses (which is similar in some respects to Google’s old widget API) was looked upon as a model implementation during the web components standard process.
That isn’t the point though. If you take away the polyfills, the only thing Polymer really does is facilitate 2-way data binding – virtually everything else is native in browsers supporting the underlying standards. Dojo doesn’t currently use any of these emerging standards.
I wasn’t arguing that Polymer itself was going to take over the world – its just yet another framework. But once the browsers start to mature in their support for this stuff using web components as the fundamental approach to building functionality seems almost a given.
See this: http://comments.gmane.org/gmane.comp.web.dojo.devel/19261
The devs are at least considering the idea of rebuilding Dojo on top of the web components standard – even going as far as actually considering building it directly on top of Polymer.
Forgot to add… Alex Russell, one of the guys that originally wrote Dojo, now works for Google and is involved with both the W3C TAG, the web components steering committee, and Polymer development. Similarities are not surprising.
Edited 2014-06-12 06:39 UTC
So how does this compare to XUL or QML?
Afraid I don’t know anything about QML, but from the little I read it looks pretty darn cool. XUL is too. But neither is html and both require their own runtimes to function (by design)…
Web components don’t introduce a new markup language or a new runtime – the markup language is html and the runtime is the browser. There really isn’t much “new” stuff in web components – its almost completely facilitated by the addition of Shadow DOM and supporting the <template> tag…
All web components really are is isolated and namespaced document fragments (that is the part that Shadow DOM does) that can be “rendered” invisibly in an inert state until initialized (that is what the template tag does). Virtually everything else is just bog standard html/css/js.
Polymer, as a framework, is really just a set of standard web components to get you started with. On browsers supporting them natively, all it adds is some plumbing to support live data binding – its almost completely native. It does, however, offer extensive polyfills to make this stuff work on most current browsers that don’t support Shadow DOM/template tags.
I am really enamored by this approach as in effect the bulk of the rather large and complex runtime Polymer implements is designed to whither away with time… Once browsers catch up to the standard most of it will become unnecessary and all you will have left is a nice set of base components.
You actually don’t have to use any of Polymers components to get use out of it – you can just write your own. But it’s polyfills give you a way to deploy them while the browsers all catch up.
Pleeaase, give me rounded corners and bevels!
They make the feel so much more pleasant and natural.
F**k your flat design!
In your opinion. There are significant numbers of users who despise bevels and gradients. I find them an ugly crutch.
Crutch for what?
Their adherents often claim that they’re useful for differentiating functional elements from non-functional; e.g.: buttons.
I find that they’re not needed if the layout is thoughtfully done, and have a completely flat desktop theme via QtCurve which has made my belief that this is the case even more entrenched.
Colours and/or borders are generally enough, as is sensible placement of functional elements, like buttons in consistent places across interfaces.
Edited 2014-06-12 08:42 UTC
But that only really works for, basically, “OK” “Cancel” “No” “Next” “Back” etc, and the Microsoft Word toolbar when it was uncluttered.
When an application may benefit from a different layout due to workflow that becomes unavoidable.
Personally I find bevels/gradients helpful in multi-monitor (or large monitor) situations where you may be waiting for something to come up while looking at the other monitor. At the peripheral of vision, you only really have light and dark sensitivity. Bevels etc help with reactive interface usage.
I dunno, there’s a lot that can be put in toolbars and menus, and they don’t need that sort of thing.
That being said, I can’t actually think of any GUI application that isn’t toolbars and menus with a big, central content location (3d modelling, image editors, IDEs, email clients, transcoders, etc. etc.)
The only close things are data entry/form-like applications, which are basically all functional elements, with a few previews.
I’d find borders and animations sufficient for the use case you’re describing, but I guess my original point was that it’s a matter of opinion; there are people who find bevels/gradients useful, and there are people who find them to be ugly clutter.
I fully agree with gradients.
Sure, it is a matter of taste. But I would argue it also has in impact on usability.
This is just another javascript/css/html UI framework, from a company that isn’t all that good at javascript/css/html UI frameworks.
Also, it’s been open-source for years, so not really news… http://polymer-project.org
And have you tried the other javascript/css/html UI frameworks? They are crap.
Intel App Framewrok – which is supposed to be the most popular. Ugly syntax, slow development, very limited, no easy way to create new components, bug infested, very little communication from the developers, crappy tools, does not run in regular browsers. Awfull documentation – want to learn how to start a simple app? – their web site is mum on this (apparently you need the Intel XDK, I have no idea why they fail to mention this).
JQuery mobile – SLOW, never use this for mobile apps. Adds tons of garbage to the DOM and they still use code to make your button to look like a button, what’s wrong with CSS?.
Sencha-UI, it’s not that bad, but you program everything in JavaScript. No HTML! I like my UI semantic and separate from the code, thank you very much.
There was no fast, modular, easily extendable, elegant, well documented HTML5 UI framework. I ended up using topcoat.io, which is a CSS only framework, sill in development, not many components – far from perfect but it did the job.
Have you tried Twitter’s Bootstrap, or Bootstrap via Angular UI?
Yes, all. And yes, they’re all crap.
Is it the lipstick that’s crap, or the underlying pig the lipstick is trying to make dateable crap?
How much of the respective frameworks crappiness is due solely to design and engineering decisions vs the underlying model that they’re sugar coating poking through?
That was our conclusion as well. One problem is the frameworks suck, the other is the whole concept sucks. It’s almost impossible to write a fluid, responsive UI in HTML5. So we went back to native.
But a very commendable effort.
I can only support it.
“…encourage consistent, beautiful design that delights across all platforms.”
Such UX wankery. Does nobody work on actual usability anymore? As in the engineering practice that uses research from psychology, biology, anthropology etc. to create easy to use efficient interfaces for people to actually to DO something other than d**** around in facebook.
Considering Google’s track record with Android, I’ll be surprised if they manage to stick with their version of Metro longer than six months before coming up with a new place to put the menu button. Is been a hardware button on right and left side below the screen and a software button on the right and now left top corner of the screen.
HCI hasn’t been a real thing now for over a decade. I figure the few people who were working in HCI have gone off to help websites “increase their click-thru rates”.