Bye bye Material Design

Emin Durak

Published in

Hackmamba

8 min readJan 16, 2018

Considering Material Design for your next project? Please, think again.

Before you read…

If you think you’re too sensitive to read text written with critical thinking, please be mindful if you’re going to leave a comment. There were so many comments that are just products of strange, conditioned connection to this “tool”, which resulted with authors writing irrelevant text, with emotionally driven reaction. Remember no tool is perfect and critiquing them only helps them improve and the world become a better place. Besides, by the least, remember that this is an opinion article (unlike many others on the web) that you have all your right to disagree with.

What the design guidelines like Material Design (MDG hereafter) have tried to achieve was first to serve the interests of its creator; so to say Google which MDG were created for and by. Then, and consequently, it was to create a sort of web-literacy for the end-consumers of WWW. This web-literacy means basically creating habits of usage for people that consume basic every day information and go around in different platforms meanwhile, without continuously consuming and producing data.

The World Wide Web is a giant jungle. Everything is just a noise factor in an infinitesimal cosmos, just as is in the nature itself.

Let’s first deconstruct why Material Design is not a good fit for most applications, well at least for the rest of the 21st century.

Wrong Foundation

MDG was built not with so much in-depth design knowledge that spans over centuries (Gestalt, Vitrivius etc). It was built merely with a relation to material in the real world, hence the name… What they considered and tried to replicate was the real-life phenomena of material, mainly paper, for being the material of literacy (I guess).

This is a premature, shallow and arguably incorrect approach for designing for the web. Why? The main reason is that the perception of information does differ a lot from paper(s) to screen(s), and not only in between these two giant concepts; but also different contexts within each of these scopes.

First of all, by “paper” and “ink”; what do you refer to? Do you refer to newspaper, or magazine, or a novel, or an encyclopedia, or an illustration book, a children’s book, or a cartoon, or a poster, or a sign or what? All of these realms have their individually distinct design principles for their implementation that cannot even be interchanged in between. So how can you take it entirely and apply to an entirely different one?

And web, in itself, is a giant realm that is very distinct.

Shade Porn

MUI has this paper component that is everywhere. In no other solution I’ve seen, visual information is populated to stack things on top of each other as much. I mean you don’t cut pieces of a newspaper and stack those pieces on top of each other while reading on a sunday morning do you?

Check this from the Google Cloud Platform which uses MDG:

Try to make sense of the virtual 3D space created for no reason, but a confusion caused by items trying to attract users attention by simulating an illusionary distance to viewers eye…

I don’t know you, but I don’t want a web-page to appear like several people are trying to sell me different things at the same time in a bazaar.

A user has one attention at any given time, and that is best respected by any given medium that she temporarily interacts with.

Another example is this really interesting but weird one. Can you find the illusion at this image below?

The App Bar (at the top) appears over the main wrapper, but not the navigation; which appears as same height as the wrapper. So how’s that possible in the real world?

You can get stuck in this and never get anywhere, just as in MDG

The reason I wanted to share this particular information is that it’s actually beyond the coverage of this example. The usage of the paper component in MDG and hence MUI is ubiquitous and because of all the shades given, designers and developers will most likely have to confront such issues that they will have to resolve, if they choose to adopt MDG.

Human-Machine Interaction

MDG were made primarily (but not exclusively) for mobile (particularly for Android apps on Play Store). Mobile doesn’t only mean “smaller screens”. It also means interaction with finger vs mouse. Finger is way bigger than mouse, and it has different sensitivity and actions implemented to work on a device and its screen. In addition it means the operations that can be done in one screen on mobile are much more limited than they are on desktop due to size issues. There’s just so many details that MDG and MUI address in a good way, but these do not necessarily correspond to most applications’ needs and the context very well.

If you are developing an app primarily for Android or generally on mobile, and you don’t have much design resources; you can definitely benefit from adopting MDG. Nonetheless it is very encouraged to ensure that you don’t take everything as it’s granted, and that you customize it to fit your own needs. Nonetheless this may eventually take you more time than building your own guidelines inspired from all others…

Overwhelming Feedback Indicators

I first have to admit that this has been a good way to indicate users about where they touch on a given touch-screen device, given the ambiguous nature of the finger-screen tangibility. It’s also been necessary; since users don’t right away get to know where they touch.

But, my God, this can easily be overwhelming:

Do you survive looking at this for more than 10s let alone use it for long?

Since MDG were developed for end-consumers on mobile devices (mostly for Android apps basically), the usage frequency was considered to be pretty low (per app). Thus they made a lot of the interactions visually quite resonant (like when you touch/click there’s a circle animation indicating where you click). This is because users who do not really know the dynamics of a mobile app could have an easy understanding of their interactions with immediate feedback. So even when they use different apps, there’s a coherence in the whole experience.

Nonetheless these interactions could easily be overwhelming for such users who use a data-intensive application after a short time of usage, distracting them from what they want to do. There’s a lot of differences that arise between the habits of people sitting on their couches using a certain app once in a while on a phone — vs. — people using a heavy, data-loaded desktop application consistently, as a requirement of, perhaps, their daily work that they get paid for.

So there’s so many differences to take into account for while designing for primarily desktop vs mobile and high vs low frequency of usage.

Poor number of Data-originated Components

What is a data-originated component? It’s a kind of component that is primarily designed and built for either: displaying, entering, or customizing a given data content itself, rather than focusing on the form it takes. For example Drawer is a non data-originated component, although it may include some. Whereas Table, or Form, or even Feed are good examples of data-originated components. You can see good examples of each of these components if you click the given links to also see the libraries they belong to.

Forms are perhaps the most used components of our age and hence are hard to design and build coherently. MUI library doesn’t even have a component that deals with it (It only has the basic input components) Example is taken from Ant.design as a good one

The Forgotten Anchor is not even mentioned

This section is added after article is published (25th Jan, 2018)

In MDG, there’s 4 (four) different sections dedicated to Buttons.

There’s, however, no information regarding one of the most fundamental elements in the history of HTML: anchor: <a />

I personally think this is very sad. Anchors make happen the links, that allow us to navigate through the WWW, without having to commit to anything. They are the foundation of the inter-operability of the web. You can click a link from some article to another and surf around the web reading, and this all thanks to the hyperlinks that enable it. Besides, anchors, or just “links” are often used to navigate within a web-application too. It is just a very fundamental aspect of the web.

Anchors, in contrast to buttons, are also great way to keep the literacy consistent; by preserving the typography of a paragraph while providing means to jump out of it without visual clutter.

Nonetheless Material Design doesn’t even mention it. This, to me, is an evidence that it was made primarily or even exclusively for apps, particularly Android.

Conclusion

Material Design Guidelines and the libraries that have been accordingly created have previously addressed a lot of the issues 21st century internet users needed ever since. First and foremost of them is just a “consistency” of overall experience. When we use 100s of different UIs, we as the users want to know what is a button, and what is a menu basically...

Even if a design guideline or just the design itself is “bad”, or “poor”, if it is sufficiently widespread; then it becomes consistent for users because users create their habits accordingly. I believe Material Design has achieved a good pattern of building a more engaging usage behavior turning people from Facebook news-feed spectators to nodes that actively make a decision and can click a button.

BUT, what I’m trying to promote is to engage users into experiencing web literacy better. We don’t need any more fancy buttons, or fancy transitions. We don’t need a sexier new library. What we need is to inform people better, and produce better and healthier guidelines that address fundamental human perception paradigms. We have no choice to inspire from Gestalt Principles, Vitrivius Principles, and any other one that has been made in history.

If you’re in need of others, please take a bit of time to research, and don’t be afraid to create one refined and synthesized by the help of others. Personally ant.design (created by Alibaba) has really impressed and inspired me to continue the research on this and elaborate further.

Here’s already a compilation of a mixture of both guidelines and libraries that you can use:

Thanks to Doruk Demircioğlu for pointing to this: https://adele.uxpin.com/