This looks like great work, but I must be wired wrong, but I hate material UI usability on the desktop. I found myself to be much more productive with more traditional approaches. I don't mean component look/design which I don't really care, as long as I can identify a button, but more the trend to organize things, well "differently". For example, the play store developer dashboard is a nightmare to use, it takes me forever to find functions X or Y. I don't know, "in the old day" I could find where function X would be located very quickly, now I have to search the UI in all places and expand everything until I can find it. Also actions available only when hovering something with the mouse are sometimes hard to discover, especially for keyboard users like me who "tabs" through all controls in a page.
Material Design is fundamentally broken. It's based on the idea that things should look like animated physical materials, but UIs shouldn't look like real motion, because there are many people out there with visual motion accessibility issues.
Animation should be kept to an absolute minimum unless you're making a game.
>UIs shouldn't look like real motion, because there are many people out there with visual motion accessibility issues.
Could you expand on that point? I'm struggling to think of a user group whose experience would be fundamentally broken by the use of motion in Material. Could you give an example? I use Material extensively and would like to think that I have a good understanding of accessible design, but I'm always looking to improve.
The simplest example I have is text input field with placeholder "transforming" into the label when the field has focus. This simple animation and often color change of the text can be disturbing, especially when the appearance of the keyboard (on mobile) pull the field to the top and hide the label. On desktop, the label can become too small to read when above the text field. This is not really a problem for me, but I've seen people complaining about it.
If I think about complaint I would have, take the dialog spec[1], both "ACCEPT" and "CANCEL" "button" have same color and size, this is terrible design. I am going to do a destructive action, I need more distinction on what I am going to do. It should read "cancel" in a normal button and "reset settings" in a red button.
Looking at that page, I realize another MAJOR annoyance[2], what is "123 main street..." description? special "location" event attribute? Removing label from filled field is so bad for usability, for ALL users.
I could go on forever with what is wrong on every material design page.
> If I think about complaint I would have, take the dialog spec[1], both "ACCEPT" and "CANCEL" "button" have same color and size, this is terrible design. I am going to do a destructive action, I need more distinction on what I am going to do. It should read "cancel" in a normal button and "reset settings" in a red button.
It is up to the designer to scope out the magnitude of destruction the action will cause and select the right color/hue, and even set md-raised on the default action in a workflow.
I switched from material design (react-toolbox) to semantic ui around a year or two ago for similar reasons.
Material design looks great by default but it infects the rest of your app really quickly since any custom components you build have to match it in visual style or it'll look really out of place. This was pretty hard for a small project without a designer.
Semantic basically looks like bootstrap without being bootstrap and is much easier to work with.
The main dislike I had of using Material Design was trying to make it not look like just another Material App.
With bootstrap the basic buttons are fairly simple, so distinctive theming was easy, but with all the shadow and shimmer effects of the Material Design components its a lot of work if you want to change their structure to give it some of your own app's personality.
I tried both at the beginning of 2016, and neither of them seemed very usable at that stage. Both look much better now, and I can't wait to give them a shot.
Also noting that the semantic UI docs still give a horrible mobile experience (iOS 11).
Semantic UI React is amazing. I've used it to build a number of applications. My favorite thing is the interoperability between its various components.
I looked a bit at this while it was still in beta, and it seemed to be one of the more comprehensive UI libraries for React, and also one of the more active projects. It also isn't restricted to desktop use like some of the other UI libraries.
I'm curious about the choice for styling components, there seems to be a lot of different approaches and no clear winner.
When development of v1 started, JSS was the only solution that (with some tweaking) met all the needs of component library (as opposed to say, an application), as well as being one of the most performant.
The thread that this comment[1] is in is where it all starts, but the repo and presentation linked from that comment should give the answers. At least as a snapshot at that point in time).
Awesome news, I have been following the beta for the last year, upgrading versions every couple of weeks. The TypeScript definitions were perfect to catch changes especially in property names. Will get my site upgraded ASAP. Can't wait to see where you take this next.
Congratulations and thank you! This is a fantastic library, my team has been using the beta versions successfully in both desktop and mobile projects. The overall quality of and amount of components in this library has resulted in a major productivity and user experience boost for us.
Congrats! I've played with this on various projects for year now.
The only thing I keep getting frustrated with is styling with Typescript. I don't like the withStyles HoC but the alternatives still feel difficult to use.
I would love to just use a decorator but I believe there's a TypeScript feature still missing in order to support it correctly. I'm curious if the recently announced TS 2.9 changes will help.
A big thanks to the developers for this library. I've been using this with kotlin and react. Thanks for also including comprehensive typescript definitions. Great slibrary for spinning up web apps.
I've been using the pre-1.0 version for over a year, and recently switched to using the beta of the 1.0, and just want to say thanks — this is far and away the best UI kit I've come in contact with. It's well-designed, comprehensive, customizable, well-documented, and fun to work with. Great work!
Yup, big improvement over pre 1.0 as well. The old data table stuff in particular was pretty painful to use but that’s all been taken care of now. The only thing I’ve used that’s of similar quality to Material UI at this point is Vuetify, which still has a few rough edges
As someone who contributed to a very small part of this I know how hard the core maintainers worked and how patient they were, at least with my very long lived PR.
Thank you for staying the course and believing! What an EPIC effort!!!
Google announced their version of Material React (Alpha) at IO. "Material Components for React (MDC React)"
Curious to see how it plays out with Material-UI. They should support Material-UI.
Congrats guys! It's been a pleasure using the pre 1.0 releases -- looking forward to trying 1.0 out.
In addition to the overall polish, one of my favorite aspects of this library is the authors' focus on controlling bundle size.
Because of this library I learned that ES6 default imports may not be cheap.
VSCode users: consider checking out Import Cost extension [1] to keep an eye on this.
Unless I'm misunderstanding something, wouldn't Tree-Shaking remove the unnecessary code paths from each import? Assuming you're using Webpack 3+ that is.
Tree-Shaking (in Webpack 3+) is still somewhat conservative at the module level unless the dependent library also declares "sideEffects": "false" in package.json.
Granting the validity of many aesthetic criticisms of over the top skeuomorphism, it will be a good day for users when the fashion-chasing flat ui era is over.
Material is slowly moving more in the "flat 2.0" direction that the article points out as fixing flat UI's usability problems. It's not fully there yet, but you can see aspects of it in say Google's floating add buttons in Calendar, Inbox, YouTube's search box, etc.
It is worth meditating on the fact that such a terrible idea was and is able to dominate the visual design community for so long without any significant push back. It has caused real pain for end users, and people who objected were shouted down or ignored.
All the more outrageous in an industry that likes to wear the mantle of empiricism.
That's absolutely the plan now that v1 has landed, along with Material Design v2 components and themes.
Material-UI has been designed with customisability in mind, so you can get the functionality of the components without necessarily having to look like Material Design.
Great work, guys! Still bummed that you dropped Flow support, but I understand your reasoning. Definitely the most pleasurable UI toolkit to work with, and contributing is a blast.
I have been programming with Material UI, every day, for the past year and have nothing but very positive comments to make about it. The team is excellent, the code is extremely reliable, and the
I get that 'cssinjs' is now new and trendy but how can people legitimately pretend that the act of transcribing your css changes to their js format is anything but developer/designer hostile?
i can't be alone in mocking something up, then switching to browser to fine tune the css, then taking that back in to codebase.
Somebody in work also had the idea of storing every components styling in JSON, then getting the browser to render that as styling...so now you need to understand a JSON->CSS engine just to troubleshoot most styling issues?
When will it end. Do we need to rip out the DOM, HTML, JS & CSS and start over because we're creating more elaborate Rude Goldberg machines every couple of months.
