Aaaand the first three buttons are hidden until you hover over them. How visual designers keep making mistakes like this in the age of mobile browsing is beyond me.
EDIT: As has been pointed out to me below, they have their use-cases. I still wouldn't put them as the first shown option though - they're not exactly the sensible default fall-back.
Also, the menu doesn't work on my Firefox Aurora browser.
Google's design guidelines advise using flat buttons "for contexts such as toolbars and dialogs to avoid gratuitous layering". Seems to me there may be cases where they are useful.
Fair enough. I still think putting them first is sending the wrong signal though: using a flat UI should be a deliberate, carefully evaluated choice (like the example you gave). Not the default.
this is a nice start of a cool and handy tool. As someone who recently got into React, browserify and uses less by default, I really apreciate people making libraries like this and will probably try using this at some point. Yes, as others seem to note aswell, it needs some work finetuning and improving (are buttons in the dialog supposed to have no borders?). But I think it's a very nice initiative, thank you.
The comments thus far are disappointing. People go to the trouble of making a pithy comment on hackernews, but surely since many of us here are developers we understand the frustration of bad bug reports. Is it so hard to bottle up your negative comments and spend another two minutes doing something constructive - like heading over to github and adding an issue with your system specs?
These comments are as constructive as it gets - test your shit before submitting it for a public review or clearly state that it wasn't tested outside that one Mac it was written on. I would rather not see HN turn into a sloppy developers support group, though it is already part way there.
Well, I think it should be at least marked as a work-in-progress. Because right now it looks like it's a production-ready framework, and yet people are reporting that it doesn't work on major platforms.
Heading over to github would help the project, it is true.
But HN isn't only a place where people come for help. It's also a place where people come to share. And when low-quality (or not-yet-production-ready) work is shared, it's important that we let each other know that. Especially when the site seems to imply it's "ready", as this one does.
I visited the site on my Windows Phone 8.1, and the page is rendered incorrectly. There's white text on white background, different text sections overlapping eachother, columns being one word wide and lot of more things. According to other comments here, it is unusable on iphone and broken on android as well. According to issues in their tracker, it does not work on Windows 8/Firefox and Ubuntu/Firefox.
It also renders incorrectly on Chrone om Windows 8 (on my laptop, at least).
If you're creating a new CSS framework, publish it and fail to mention that it's work in progress and it only works on a limited set of platforms (like what), you have wasted my time.
I really hope developers doesn't expect to only get constructive feedback when doing something like that.
It's not "negative comments" to point out to other people what works and what doesn't.
Complain as much as you want about how I don't push fixes, but as long as I'm not paid those complaints are better kept to yourself.
(I realize you are not one of the developers for this project. I only want to illustrate how negativity goes both ways. I'm a bit tired of "contribute or shut up". There's a big gray area inbetween.)
It's kind of strange how there's a whole generation of young developers who are supposedly «hurt» by perfectly valid criticism of objectively flawed or bad work.
This wasn't always the case. Before the whole «social justice» movement infected the software development industry and hobby, it was expected that bad work would get publicly criticized. This was a good thing, because it fostered improvement, and high quality work. But now that apparently all takes a back seat to making sure nobody has «hurt feelings».
It needn't be bad, even. Pointing out a bug in the comment field is somehow "negativity", while working through the bug tracker of github is "constructive".
In this case one could say thank you for the input and register the issue oneself, if the project was dear to ones heart.
I wonder if it is a product of young developers being told to build a public github profile, that they are increasingly careful about?
Having to use GitHub to report bugs is itself a very serious bug.
It should always be possible to submit bug reports and comments anonymously, or as a "guest".
Making it difficult for users to report bugs is stupid, and harmful. While some people do already use GitHub, there are more of us who don't.
It's bad enough that I had to create an account here to post this comment. I refuse to go through the more extensive GitHub signup just to report a bug affecting software I don't really care about.
That image has nothing to do with material design and cards have nothing to do with tiles. It's very far-fetched to even suggest that Material design and Metro UI are even remotely similar.
There are not similar, but there are similarities. The way the controls are designed, the flat style, the whole content-first approach, and giving the content space to breath.
http://material-ui.com/#/components/dropdown-menu really? how can this be good usability. it's text and an arrow far, far away. this could be anything and does not in any way imply any kind of select action. if this is really implemented after the material design spec of google, than oh man, google really has an issue.
That's an arrow? I just see a Unicode failure-box :(
That's one of the problems with the trend of icons-as-fonts, when they fail there's no reversion mode for users to understand what the glyph is supposed to be.
planefinder.net is a canonical example, without the correct font none of their on-screen controls make any sense.
The dropdown also caught my attention it seems like it's a bit of a distance from the traditional dropdown in a sense that I think some users will have some trouble with actually realizing that it's a dropdown.
Another complaint is the checkbox, there's no way to tell once something is checked off whether it's a picture or a form.
I think you're ignoring the context in which this element will be displayed. It makes sense visually inside a form or options panel, among its related counterparts. There is no reasonable situation that would result in this element being lost in such a sea of whitespace, as portrayed in the example.
If you look at the menu with "All", "Family", "Friends", "Coworkers", initially it shows "All" and the arrow is immediately to the right of the text. I expect that if you select "Coworkers" then the arrow moves.
The problem is that many people will use those copycats as the basis for their own app designs. Not everyone is willing to really understand the reasoning behind the design spec down to such minute details as an arrow placement if he can be hip and trendy with something that superficially looks like the same design.
If a design is so easily misunderstood with such (comparably) large consequences for the user, that's a flaw in the original spec IMO.
I don't believe it's easily misunderstood; I think people just don't know how or why to create a quality implementation based on an original. The spec is actually remarkable in the level of depth it goes to teach you not only about the design guidelines themselves, but also the reasoning and psychology behind it. Really, it's probably the best full on UX specification ever produced (and I'm not saying that lightly).
It just shows that it's very difficult to get this stuff right. There's still going to be a bell curve, with most implementations and copies ending up in the mediocre middle, but overall, the guidelines might bring the quality of the overall market up. That's all we can hope.
I was recently looking into libraries to use Material Design with React.js.
I found the material-ui project to be implemented less well than this one: http://sanderspies.github.io/react-material/ (though I have my reservations about the approach taken here, too -- and it's less complete).
react-material is mostly an experiment to use react-style (CSS written in JS). Unfortunately I do not have enough free time to give react-material the right attention, so I wouldn't recommend using it for now.
I like these small frameworks. Bootstrap is almost a little too big for my taste. You end up having custom builds which are hard to maintain and update. New frameworks like semantic-ui make the mistake and are even bigger and more interwoven with js code. Fluff that! I really don't need 5 variations of every component!
And drop your icon library into a seperate project! So i can choose between font-awesome, boostrap-gylphs or this MUI-Icon set. FA-like is the way to do it.
I really like it. It's very different from what we have. I guess it makes sense (it is google after all). One complain I have is that it's so cosmetic, feminine almost, but I guess that's the color scheme.
While I like the project and effort put into this, I think, if you considering using this project, you should also look at google's own polymer project. Its based on the industry standard web-components. https://www.polymer-project.org/
React is using "virtual dom" which is kind of a hack to support web-components kind-of technology. Since the technology is currently here, i would recommend using it, and not using React.
However a consideration is also browser support. I'm not sure if polymer is production ready.
Can't vote this comment down (not enough karma?), but I would.
React is great library, it is not very constructive to call it a hack just because webcomponents are there.
I'm not saying React is a hack. I'm saying that all libraries that try to provide true "web components" that hide their implementation details for the user, are only achievable trough a "shadow dom" implementation in the browser.
Thats just a fact, based on how browser work. With the shadow-dom, customer elements, and templating you can achieve true componenets, like in uix toolkits such as Android, iOS and Java Swing.
Is this correct? React doesn't use the virtual DOM to create HTML-like elements, it uses JSX for that, and JSX is optional. As far as I know the virtual DOM is used to avoid updating the "real" DOM in the browser when you don't have to.
React does use a virtual DOM, namely so that it can efficiently track changes to the DOM. That's different than the shadow DOM that web components use, though, where they have their own sandboxed DOM that's completely isolated from the parent DOM.
Indeed. That's what i try to say. I think the knowledge regarding the shadow-dom and true standards-based web-components is not widely spread yet among devvers.
Your first sentence is pretty much just a shorter version of what I said in my comment! The shadow DOM and React's virtual DOM are completely unconnected.
A few things looked slick but not particularly usable, but I found the flare animation on-click got old (and a bit slow) after a while. Might be worth toning that down a bit?
I've never been a fan of material design and surely hope it doesn't become a standard. Design guidelines from a company that is widely known not to care about design? No thanks. Even Google Inbox shows how engineering-driven everything is at Google - the navigation is completely unorthodox (going back = drag down), like someone above decided "this is the way we do everything from now on" and nobody had the balls to question 'em. I'd never accept Microsoft's design guidelines or Google's. If you truly care about design, you'd stick to Apple's or develop your own, which frankly isn't too hard in CSS anyway, and it means you aren't tied to a particular OS feel or a big-corp policy.
I had a talk with myself at the weekend about making a concerted effort to cut out the snark when I comment on the web.... And I'm about to fall at the first hurdle.
Being "on trend" isn't good UI design. But I can see how we got here. Through OS X and iOS, Apple's UI ethos became the gold standard in UI design. It was so well designed that it was easy to imitate and by simply adopting the core elements of Apples UI language, stuff became intuitive and usable without the designer needing to understand "why" something looked the way it looked.
And then came a new trend, the current trend, that appears to me to be rooted in nothing more substantial than a desire to replace the old with something new at all costs. And when the likes of Apple and Google fall for the same trap, it's nigh on impossible for fundamental UI design knowledge to make itself heard above the noise of a million designers advocating the new and pointing to Apple for credibility.
You can see that I don't like Material. I also don't like iOs's new UI language. It doesn't work. Ive seen no evidence that it's any more useable and I struggle everyday to make sense of software and tools that have adopted these new trends so anecdotally, I have to say to myself that we're going the wrong way.
I feel like the same as OP. Change for the sake of change without any real benefits. But with plenty of draw-backs. For example the new Gmail App on Android now uses an almost unreadable font in the overview. It is "designy" but not good for usability - and I still have 100% eye sight.
In general I feel like surrounded by the Microsoft paper clip. There is constantly something animating, popping up or popping with strong colors into your eyes.
Try to find in all the talk about material design the underlying reasons for usability. There aren't any. To me it feels like the emperor's new cloths.
I was about to buy a Nexus 6 but the new Gmail app is a no go for me and I will avoid it as long as possible.
I mean this in the most respectful way possible, but, your concrete flaws are that you believe it's just designed for the sake of change, it animates too much, and that a font is too small in one place?
For what it's worth, the underlying usability really is very well explained and pretty sound in the material (no pun intended) from Google on MD. Eg: http://www.google.com/design/ in the top 2 items.
I don't know if he was talking about flatter designs, but (IMO) they might fail because the elements are less affordant. We know that affordances are important so, again IMO, the removal of graphical cues that afford action should be approached with care (and empirically validated).
That's one of the success marks of MD I think; it retracts a bit from total flatness and says, ok, even though this is on a screen and will appear flat, how can we give subtle cues that it's actually a thing (material) and you can do stuff with it?
And they decided to do it with shadow, animation, and contrast.
Maybe there are better ways as well, but the end goal is sound.
> I'd love to hear specifics about where you think these designs fail?
I actually like the 'flat' look, but one thing I hate is the drop-down menu in Chrome for Android. Here's what I'm talking about: http://goo.gl/41iRZk
When the menu is displayed it takes about half a second to display. Every menu item is...slowly...faded...in...one...after..the...other. Give me Windows 3.1 where you click and the menu displays instantly!!
Couldn't agree more. And I've started to think that one of the reasons open JS grid and tree controls are so lackluster is that there is too much effort being spent on animations in general. The 'flip and fade in' display options are never useful, but being able to work effectively with high-dimensional, hierarchial data would be. Sencha is closest, but I still have to do a lot of low-level customization to work with dynamically defined columns.
I'd love if my iOS 8 worked buttery smooth. No animations. Just click -> open. I hate even a small delay. Every delay is time wasted. I wonder how much time I've cumulatively wasted on UI animations in my life.
And while they are at it, put the dang refresh button back in the url bar. I have never used the speech input button to enter a url into the field. One tap becomes two taps to do something as common as refreshing the page.
I know it is very difficult for professional users to understand this, but from a design perspective this is actually very well done. These animations are really helpful for people who aren't spending their whole day in front of a computer and rely on cues to help their orientation.
I've done usability tests where these "issues" came up, whenever a dropdown or any other form of interaction suddenly popped up and the user had to spend valuable time to re-focus to find out what exactly happened and if this was indeed the right control. Additionally animations are also very useful for transition purposes. Guiding the user from one screen to another can be quite stressful when it's done in an instant and the user has to understand what's happened. This is why Apple's guidelines to transition the screens in a horizontal motion were so damn good, because they allowed users to spatially recognize their "position" in the UI. And I'm glad that the MD guidelines now also state that transitions have to be spatially correct and a screen transition isn't just a window jumping out from the center of the screen. [0]
Of course these animations are only temporary and can only help you so much, but they're very good for consumers when they are noticed. And that's all they really are: helpers, not the sole messenger of the meaning of the UI.
But of course I understand the plight of delayed interactions. UI lag that is caused by hardware aside, they're really annoying. But I see that more of a problem of customization. The OS should allow to switch off any animation.
"Unfortunately, there’s so little ornamentation that there are no cues left to tell you when something is tappable. What’s a button, what’s a label, what’s a heading? You won’t know till you try tapping."
Awkwardly, the "design design" is past that -- the guidelines say to use shadows to create buttons. But the deployed design is using the older design design that didn't realize that.
The example he uses is a bit contrived, since everything but the toolbar title is tappable. Does it need raised and colored affordances to signify such? Would this be more or less confusing than what was shipped?
And this gem: "In Android of old, you could swipe down from the top of the screen to open a panel of quick settings buttons (brightness, Airplane mode, and so on)." Which tells me the reviewer either has a poor memory or has confused Android with Samsung (which is an honest mistake to make).
That quick panel is indeed in stock android. On tablets, swiping down on the right side of the notification bar opens the quick settings. On phones, swiping left from the notification pulldown switches to the quick settings.
Additionally, IIRC swiping down on the right side for the quick settings is default in a number of ROMs.
I see no snark on display. I also see no arguments or reasons on display to support your position.
That is to say:
1) I can see that you don't like Material but _why_ do you not like it? Because it's new is not a reason because it can be both new _and_ adhere to tried and tested design principles, put forward new ideas for consideration, and be aesthetically pleasing
Flat UI has fewer affordances (or "signifiers" as Donald Norman now refers to the concept.) For examples of issues caused by this see http://uxcritique.tumblr.com
This is the second time in the thread that I've been asked this, so here's my non answer.
I feel that there's plenty of literature out there that details the faults and flaws in all the new UI languages from different vendors, and unless I write my magnum opus on UI design, I'm only going to be able to offer broad strokes commentary that would be child's play to pick apart on the surface and just drag us all into a meandering argument.
And I feel I factored this into my original comment. For example, I specifically avoided the word 'flat'. There's nothing inherently wrong with something being 'flat', and there are plenty of scenarios where one could quite easily argue in favour of a flat design over a 'lickable' drop-shadowy visual feast. So to mention it in passing wouldn't be worthwhile.
But 'flat' is only one adjective you can use to describe the current UI trend. Many have been referred to in this thread. Animation, depth, ui-as-content and so on. The topic is greater than the sum of it's parts. I also feel that there are also no absolute right or wrongs and I didn't want to kick off one of those sorts of debates stroke arguments. I suppose I'm not scrutinising the implementations but rather questioning the motives.
In addition, my comment was as much about 'how we got here' rather than the problems with 'where we're at', which I believe totally undermines the current state of UI design. For that, I don't think there is much out there to support my view other than the history we've lived through, and we can each interpret that as we see fit. So that part you can take or leave. I offer it as an opinion. I believe the opinion will hold up to scrutiny, but at this moment in time, it's anecdotal.
The primary principle at least from the point of Apple is to turn the actual content into the UI by allowing for a different kind of visual depth.
What you see right now is first steps towards a UI that will use animation to create a sense of depth and perspective rather than using static visual design to imitate the world around us.
So think about Googles Material Design and Apples iOS design paradigm as a return to content using time (animation) as the skeumorphic replacement.
Whether this is the right or wrong direction is hard to say for now given the trends away from UX and interaction design we will see over the next 10 years.
Relying on animation to provide depth and perspective may not be a great idea. Subtle static cues remain a constant reminder on the display even if you aren't focused entirely on the application. Animation is much more heavy handed and isn't always there. If the user misses the transition animation, how do they know how to interact with the resulting static page? Animation also has the potential to slow down users as they become accustomed enough to the interface to know which elements they want to interact with before the animation completes.
You have to take a longer perspective on this think about where information is going, think about vectors rather than bitmap, think about non-interaction rather than interaction, think about the complexity of the apps of the future and you will realize that animation might not be such a bad idea. With skeumorphic design you only have the illusion of access to the elements with a flatter design you can programmatically access them and change them which will open up for interesting new visualization opportunities.
With regards to be being heavy handed both apple and google are well aware of that which explains their support for this new way of approach GUI design.
Such as... shadows? which help in feeling depth statically, which is what Material Design is about. What I feel is that MD is young and has rough edges but rests on solid principles.
> Animation also has the potential to slow down users as they become accustomed enough to the interface to know which elements they want to interact with before the animation completes.
Interestingly consistent animation time can have a bonus effect, as a "slow" loading element and a "fast" loading element are paced, creating a temporal rhythm in interface action for those accustomed to the UI, instead of a randomised, off-beat staccato. You don't just know "where" this button will land, you also know "when" and you can get there without visually polling and parsing the screen for availability.
This is all a game of balancing opposites. I totally loathe brutal reflows and interface pop-in (to the point I disabled Chrome's new tab page[0]) because it just triggers an interrupt->parse->interact cycle whether or not I know where to go.
> Animation also has the potential to slow down users as they become accustomed enough to the interface to know which elements they want to interact with before the animation completes.
Happens to me so often. When turning off all animations in Windows, the system feels so much more responsive and doesn't hold me back in well-trained workflows.
With Android 4, the default state is really bad. Fortunately, you can turn off most animations in the dev settings, but still, it feels like the OS wasn't optimized for low latency (especially when switching apps). I hope that Android 5 will still allow for animations to be turned off. I can't say that I'm very eager to try Android 5.
Worst thing is, even with the reasonably powerful Nexus 4 (and I hear the same is true even about the Nexus 9), under a little bit of load, animations tend to become even more sluggish; inaccurate animations let the user make mistakes. I have noticed that it is nearly impossible for me to quickly check something using the Nexus 4 while waiting at the lights, especially if it involves switching apps (go from navigation to messaging etc. and back), the phone just isn't responsive enough. This isn't entirely the fault of animations, but it's one more symptom of a lack of focus on low latency.
This is a well known design flaw in Windows. Apple on the other hand goes to great length to keep the illusion alive. They would rather de-priortize non-visual tasks if it means providing more power to finish ex. some animation.
Animation is a science in it's own and even small unobtrusive cues can mean a world of difference.
I totally agree, to me it looks like the main goal of Google's UI design is for "being different from others",but not for improving the UX from the user's perspective!
The current trend is rooted in the fact that computer displays approach the visual fidelity of paper prints by now (> 300dpi). Consequently a more print like design language is adopted, which often features a small selection of colours and simple geometric shapes.
The large variety in print design demonstrates that this is not an unreasonable restriction. In my eyes the translucency of windows in Yosemite is a much nicer choice than "brushed aluminium" or "black with fake highlights", it does not pretend to be something it is not. Eventually I would prefer if the "Desktop" metaphor, including "Folders", was given up and replaced with something different. The faster the design language becomes more abstract to facilitate that change, the better. We are stuck with an overall UI design initially conceived in the 70s, alternative versions of personal computing like the Lisp Machine died unfortunately.
Unlike print, computer user interfaces are interactive. When you adopt a print-like design language you remove cues that indicate how to interact with the interface.
With flat design, sometimes it's really hard to know what you are suppose to click on. I enjoy its simplicity, but it does have some usability problems that come with it.
I think we went way overboard with it and the pendulum swung to far to the side of flat design. Hopefully we start moving away from super trendy flat design, much like we moved away from those crazy web 2.0 design styles.
I would say Consideration. I am a designer, and I work with lots of designers. Design is harder than it looks and even brilliant designers don't get it right 100% of the time, but I can see a clear difference between the types of designers whose work "looks right" and designers who have approached a brief with the aim of figuring out what "works right".
It's easier to be the former than the latter both in terms of skill and the politics of the client relationship, and that's why there are so many "designers" and so few designers.
Yes. A real designer isn't just a UI artist. Art is one skill among others. A real designer should also understand: UX, human behaviour and interaction, logic, visual language (architecture, shape, color, animation) and other skills...
Most designers don't get it right because they don't have these skills, they are only artists. And because of that they don't understand why a particular design is better than another or even what their own design expresses.
To do a real design, it asks you to do a ton of research and going back and forth between art and UX. Doing brain storming to implement old and new logic elements in a fashion way.
It's like the iOS 6 it was a big step forward because it was a design: simple, expressive, and functional. The guys who created it understood all of that. Then again, Apple followed the fashion trend more than the logic and did the iOS 7 design criticized even before it was out. The problem, among its specific fashion, was that the design was so flat it was destroying UI information. Plus visual problems: sometimes the color seems to mean something but you find one red button that isn't one, sometimes the shape, sometimes the animation...
In Material design, you are still intended to make use of proper cues for useable components. Interactive components are supposed to exist as another logical layer on top of static content. This is the change from Holo, do not use flat things so often for interactive widgets.
Computer displays on average don't. Phone displays largely do, but there are millions of computers sold every quarter that aren't anywhere close to retina displays. Also, there are hundreds of millions of existing devices with non-retina screens.
Probably not wise to abandon those because of the new shiny thing.
My opinion on Apple's use is mixed. In cases like the OS X lock screen, the use is great. It signifies an inability to continue until the device is unlocked while hinting at the content underneath.
Other uses are gratuitous and often the blurring and blending of colors creates weird sensations where what is underneath a window seems more important. I can see something is there, but can't make out the details, make me anxious that I'm missing something happening in the window.
Your comment had zero content and no value for anyone other than you.
I'm happy you're excited about your launch, but, unless you're linking a technical, or at least informative, blog post or similar that describes ways you're solving the problem the person you replied talked about, Hacker News isn't the right place to brag.
Fair enough. The user mentioned that no one seems to be rethinking the file system so I just wanted to say that we were, but obviously we don't have the materials ready to link to pre-launch.
Your post contains no useful information, and thus contributes nothing to the discussion. Ergo, downvotes. The only way to work out what you're talking about is to go through your comments (which I did) and synthesise based on founder bios and a job posting. Even then there is little to no concrete information about empiric.al that I could find in the few minutes I spared for this.
Here's a post that might have worked better, and maybe even could have got you some marketing/interest. I didn't downvote you the first time, but I would be far less likely to downvote this:
---
I agree completely. File management is still an unsolved problem and existing solutions are not optimal by any stretch of the imagination. It's really only getting worse as more and more user data moves to various independent and unconnected online services. Even if you manage your local files in a satisfactory manner you can't use the same system everywhere.
I'm actually actually working on a product that should help alleviate that problem. It does $ACTUAL_DETAILS and works by $IMPLEMENTATION. Our site is barebones for now (empiric.al if you want to read more about founders or sign up for information), but we're really excited about what we've built so far and aim to launch next month. Hit me up on $EMAIL if you'd like to discuss it!
Well the fundamental flaw is that the view presented to the user is rooted in the representation the filesystem implementor chose, the user should effortlessly be able to switch between different views and add additional ones, Apples' "All My Files" together with the ability to filter and save those filters is brilliant and very much in the right direction, although it should support some form of join operation.
One idea would be, that in addition it should be possible to execute computations on the current view of the filesystem and the possible computational primitives are selected by the "type" of the files (essentially find a way to lift a typed version of the unix shell with pipes to the GUI level).
Another idea would be to emphasise versioning and time based information more. For example with the current storage capability it makes little sense for the default save operation when working on a document to be "destructively replace the old one". Obviously as a programming one is aware of that and uses version control systems, but so far I had multiple occasions when working on a collaborative project not involving code, where the versioning was done by appending suffixes to folder names.
I find the Apple OSX finder's half hearted attempts to hide the file system a pain in the arse.
What does work quite well for me is the default approach of Gmail where your emails are in basically one folder with a good and fast search facility (and tagging)
>The current trend is rooted in the fact that computer displays approach the visual fidelity of paper prints by now (> 300dpi)
My impression (I'm not expert) is that the trend is rooted in the opposite - the crappy displays of cheap phones. The old fancy graphics of say Windows 7 could not render quickly or at all on cheap phones so with the advent of responsive design companies used flat design so the same graphics could be used on all devices including cheap phones.
I get the technical issue but I still find it a bit ugly.
I don't like everything in Material Design, but there are undeniably a lot of really really good ideas in there. So borrow the patterns that work, and ignore the rest.
Consistency / familiarity is a very important part of developing UIs/UXs that are intuitive.
What you have with material design is a very well documented approach to promoting this. The wrong direction? As a developer I lack the expertise/talent to have an opinion one way or the other on the direction presented by material design. But if the designer community is unhappy with the approach, then they should probably get together to create competing principles that can be adopted by the rest of the dev/design community.
You are still free to design you applications however you see fit, but you risk missing out on users quickly feeling comfortable in your applications.
>Consistency / familiarity is a very important part of developing UIs/UXs that are intuitive.
This. My understanding is that Google's adoption of Material Design is in large part intended to make apps more intuitive so they'll be used more frequently and by more people. I've found out when testing Recent (http://recent.io/) that average, non-tech users would prefer something intuitive that uses standard UI toolkit features -- even if they're not that exciting -- over highly designed custom interfaces.
The interesting question to me is to what extent iOS apps beyond Google's own will adopt material design...
I fully agree. I also don't find the new "flat" designs an improvement at all, and that applies both to Google's new designs and to Apple's work.
What's wrong with them, you ask? Well, in brief:
* very little indication as to what I can interact with,
* you have to know the interface before you can use it, discoverability is abysmal,
* touch-interface-specific: lots of actions require swipes, which you have to learn in advance and remember,
* actual tappable areas became smaller (an example: "<" instead of a "Back" button).
They are hard to use for me, and even harder for my Mom.
I think this case is similar to what often happens in architecture: form over function. You get beautiful buildings that are dysfunctional. Architects hold conferences and assign awards for the beauty (light, form, straight lines, whatever), while people crowd in passageways and make their way to work next to the garbage dump, because that way is more convenient than the main entrance.
I really hope the pendulum will soon swing in the other direction and we will go back to more "meaty", discoverable interfaces with more visual hints as to how to use them.
Bug report: If I follow the "Demo" link from the homepage, the first demo ("Buttons") works but clicking on any of the others (via the left hand menu) e.g. "Dialog" doesn't do anything. No obvious errors in the console.
I'm using FF 33.0.3 on Win7.
Edit: looks promising though - just get them bugs ironed out! :)
I like the animations, inputs are really what I need today for my UI designs.
Checkboxes have different styles in Chrome and Safari. Safari checkboxes look a bit weird as in unchecked mode a rotated green tick is displayed inside a checkbox, and in checked mode one of the tick's lines extends horisontally.
In Chrome the checkbox looks really nice though.
Is there a way that I can use this as a drop-in replacement to Bootstrap or on top of Bootstrap? If not, what would be the easiest way to re-skin a project that currently Bootstrap to use this?
Then I could have Facebook/Google/Twitter design and coding chops baked in :)
This is my first introduction to Material Design. I am confused about an aspect of it.
Here[0], we see two separate cards next to each other, with the same dimension, but at a different elevation. As a result, one casts a larger shadow.
Here[1], they specify that "Shadows are never approximated using material". Wouldn't that require that one of those two cards with the same dimension appear to be larger, since it is closer to the eye?
Doesn't seem to embody the principles of Material Design other than the flat design and use of colors. For example for the dialog[0] when you click it it just appears out of nowhere instead of sliding in or expanding out from the button. Material Design isn't only about everything being flat but there being good animations to make transitions clear.
I wonder what Google's design team thinks of all these creations masquerading as "Material Design."
It highlights the fact that it actually takes a lot of work to do all of these details and get the UI right, and if you miss one or two, it really doesn't hold up. Something we should all take to heart. Not many design frameworks have such complete and irreducible properties. The Material design guidelines and (good) implementations so far are really very impressive.
Thanks to everyone for checking out our little project. It is very much a work in progress. We released it because we are excited about it and knew that the open source community will only help to make it better. Let's make something awesome together!
Does React have something like web component's <content/> ? It's really unfortunately that the LeftNav component takes an array of objects to turn into links instead of allowing you to define arbitrary html as <content/>
Can anyone explain to me why having the dropdowns and other items in JavaScript is better than the DOM? Seems like we fixed this approach on the web 10 years ago.
This is the best implementation of Material in html/css i've seen. It's a little buggy, but nothing a few tickets won't fix. I'm constantly impressed with how fast you guys work.
I have to say I REALLY like what you did with the inputs. That action is really cool. I thought the spec said that buttons with just text and no background or borders were discouraged as they looked too unactionable?
Why can't I use esc to dismiss the dialog? Why do arrows in menus also scroll the page? Is this because this is not pure CSS? Would this be a problem for accessibility?
Nicely done. Material design looks great on Android. I'm not sure if I'm sold on material design for desktop use. I started building a material design look and feel for a new web app we're building and besides the fact that it lacked all the subtle animations no one really was digging the vibrant colors, flat buttons, and drop shadows. We ditched it for a more conservative theme and so far we've had no complaints.
Any Inbox users here? What do you think of the full desktop web app for Inbox? Personally while I love the mobile material design version, there's just something off about the desktop version.
Inbox user chiming in: I actually like the desktop interface, and it's nice to not have to change mental context when using Inbox on mobile vs the desktop (probably the best, if more subtle, benefit to the Material overhaul of Google's services). My biggest gripe is the more restrictive keyboard shortcuts compared to Gmail, which basically necessitates using a mouse for some operations. But I imagine that will be remedied over time.
I tried Inbox in Chrome on OS X Yosemite on rMBP 13'' last year's model and it stutters and freezes when scrolling, and takes a minute to load all dependencies. I tried in Safari too, but it does not work with Safari yet, and in Chrome it's a disaster.
I worked through the demo and actually kind-of liked it, until I got to the checkbox page.
How is that checkbox design better than the commonly used empty square for unchecked, and square containing an X or a V for checked? I can't even tell if the boxes are checked or not!
I would seriously advise taking a look at the usability of these checkboxes.
reply