Cross-platform design is once again a hot topic - especially if who’s talking is Google and when Material is the key word coupled with design. But is it really a viable option?
On the latest update of the Material Design guidelines there is a brand new section: Platforms. What’s in it? Just two subsections: Platform adaptation and Android. The latest subcategory it’s just a list of four links pointing to components and interactions designed specifically for Google’s mobile OS. Do you remember those guideline’s pages with the Android only label on top? Yes, it’s precisely those ones that are listed here. Keep this detail in mind, because it will be one of the keys to unlock the understanding of the whole story.
The most juicy subsection appears to be the first one: is Google finally taking an official position about using the Material Design system on non-Google-platforms, explaining why the unofficial answer - so far - has been yes it’s a good choice!
Now let’s be frank: by non-Google-platforms the guidelines are referring to iOS and the web world, the only categories analyzed by the Platform adaptation section - not a line on Tizen here.
The redesign started - for everyone
Many iOS users and designers of all field were kind of angry at Google immediately after was made clear that Material Design was really not baked to be confined to Lollipop and it’s heirs: Google begun to materialize its own iOS apps on the fall of 2014, just six months after presenting the new design system.
Maybe the redesign was so notable thanks to a strategic choice by Google’s part: the first iOS apps to enter into the Material Designed family were among the most popular on the entire Apple App Store: we are talking about giant like YouTube and Google Maps, 3rd and 7th respectively on Apple’s official Top Downloaded Free apps for iPhone Apps of 2014 chart; YouTube was even first on the same chart referred to iPad apps. We are talking about apps that are really universal, not just multiplatform: could you imagine a smartphone, a tablet, a PC or a smart TV - anything with a screen and an internet connection, basically - without YouTube? No way. Not possible.
The bagarre was simple: Google was shipping the visual language (sic!) designed for its mobile OS - Android - to iOS, like an attempt to conquer the competitor’s platform using bold colors, sheets of smart paper colored by magical ink and a good use of Gestalt principles.
Crafting a digital world
Every OS has it’s design language, it’s style, it’s unique flavor. But even before that - before the so called look and feel - every OS must create a world made of otherwise evanescentes bits, establishing a how things works in this particular digital reality - in other words, a set of rules. The problem here is simple: jumping into a digital world means to be able to handle a universe that’s totally different from the one we are used to - it’s a pool of pure potential.
What happens when the reality your are working in is so new and full of possibilities, where nothing recalls nothing else and no door handles are there to suggest how to use a new kind of door handle? Digital entities, their visual appearance, their behaviour, the ways to interact with them: it’s all pretended!
As humans, we still don’t have any standards for representing or manipulating digital entities (and what a digital entity is, anyway?); since a smartphone screen is just a 2D glass canvas where anything could appear and behave without being subject to any law of (newtonian) physics, we just don’t have any natural idea of how that thing could behave and, ultimately, how to interact with it to ask what the weather will be tomorrow. Again, no past experiences with door handles here to help us.
This is, then, the first and most important goal of an OS - especially of a mobile one, because it powers devices much more integrated in our daily life than any other OS: to be able to offer to the user a paradigm, a metaphor which will enable him to be immersed into a different reality without any massive cognitive load, frustration or inability to understand what’s going on between the glass on the front and the metal (or plastic) on the back of his phone.
My digital world is just like yours but still different
Once the OS has his set a rules to establish his digital world, it’s facing another need: it must differentiate itself from the competitors: besides what’s under the hood and what’s differentiate their devices in a technical way (something usually invisible to the medium end-user) the main part that must shine is the most visible part to that same end user that will be eventually the buyer: the general look & feel, the UI (intended in its broader sense, as the use of space, the shapes and kind of controllers, the use of color and much more; and here we are not even going technical, specifying the differences between UI design, Visual design Interaction design and all the other design specializations involved into the creation of this fundamental layer); this OS’s part is so important that even when the used paradigm is the same - or very similar - the OEMs try to create slightly different interactions that the user has using the device and the overall User Experience of the product.
The importance of this kind of differentiation does not depend just from the nature of the OS itself - let’s say, Android and iOS; the proof is in the pudding: have a look to what happened (and is actually kind of still happening now) to the Android platform itself, a single OS deployed on so many devices manufactured by different OEMs; each manufactured had the need to add its own flavor, style, look & feel to the same OS - otherwise, what would differentiate their devices from any other competitor’s ones? Certainly not the hardware. Even the interaction model was somewhat different from brand to brand, to . In the Android world, this phenomenon was referred to as fragmentation.
Material Design : developed to be universally applied
Besides the technicalities of the answers to the question: what is Material Design?, one of its traits was clearly emphasized from day one: MD was developed without having any Operating System, device or brand in mind; would you like me using a big tech word? Material Design it’s a platform, device and screen-size agnostic unified system that combines theory, resources, and tools for crafting digital experiences (see Material.io).
Its affordances and the signifiers, the paradigm of the universe confined between the layers of plastic and glass of your phone and the patterns developed are designed to be one of the possible standards to approach a whole set of digital experiences- while the visual components, the interaction methods will change for sure in accordance with the changing in technology, need and desires of the users. It’s not an Android solution or a Google solution: it’s something much, much bigger. In Making Material Design, Matias Duarte was crystal clear:
I don’t wanna be looking fours years down the road, 10 years down the road, and saying “well Material Design - all those ideas, those frameworks - they’re over.” The principles behind them, I think, should be timeless. Maybe we don’t have them right yet but I believe we'll get there.
[Matias Duarte on Making Material Design]
That's a biggie, really. But it’s there since day one, on the front page of the guidelines, as the main goal of the project! Ok, we didn’t see any screenshots depicting MD on iOS since December, but on the other hand Google integrated some common components, patterns and ideas from iOS that could actually be a benefit for such a gargantuan design system - bottom navigation, anyone? Anticipating in some ways that sooner or later the guidelines would be updated including other platforms.
This continuous improvement process actually fits perfectly into the MD living system concept - gargantuan, remember? - and one indicator of the one step at a time approach versus the bad guys who wants to conquer the competition is the fact that even the whole ecosystem of Google apps is not already benefit from Material Design - the releases are gradual exactly because the point is not to change a gray button with a more saturated one.
To constantly be re-evaluating itself and to constantly be thinking about what’s no longer relevant. What did we think was universal, but turn out to be a fad or simply the wrong emphasis?
[Matias Duarte on Making Material Design]
One design to catch’em all: a meh path so forth
So why the sudden surprise and the flowing rage from many parts?
As a starter, since today Google has shipped iOS apps using MD principles quite literally - and for an Apple products lover or for an iPhone user that actually cares about its device, even just this move is a good reason to complain. See, MD is still seen as a Google system, tied to Android and to the various Google apps and services: this is - in my opinion - the first problem to solve. If the sensation of MD being the Google way will not go literally puff, this point will never be solved. Even Wikipedia, on its article about human-interfaces guidelines, gives a link to the Android Design section of the official developer guide - but no mention of Material Design: obviously, in the article’s mind, Android Design and Material Design are just the same thing.
The consistency that Google is trying to achieve here is not between his products on different platforms - so that the user will not care about what device is using, as long as Google Music is looking and functioning the same way - but a consistency between the platforms themselves, at a higher level: branding, differentiation and personal preferences will be preserved; the MD building blocks are there to create a magical world where everyone can express its own personality - but the user will feel much more comfortable even when switching from Android to the Web and from his browser to a TV or an auto entertainment system, thanks to something we still missing today that MD is here to fill: a universal way to see how a digital device should interact with us. Back to the door handle mentioned before - we are missing exactly that kind of knowledge and craftsmanship.
This is why the why then Google stressed so much the pure Android concept argument falls: at the time a unified design system was not yet conceived, and the OEMs, the designers and developers had to be instructed about the topic; the usual process to create an Android or a web app at the time was just using iOS flavored components to design - and when an Android app was a porting of an original iOS app, the result was even more evident: tons of Android apps looked as iOS screenshots stiked on your Android phone, with poor performance and a general low UX experience.
Back to the cross-platform design,it should also be at least mentioned the fact that this kind of approach could really be a very good path to follow for a number of economical reason - easier development chains, less costs on reinventing platform-specific-patterns, more shared tools - just to write down a brief list. But this concepts - together with the fundamental principles of MD - are not communicated and shared as well as they should - or everyone would had understand them by now.
This two linked problems should be handled by Google with much more communication with the people in the design and mobile industries - at least; articles, guides, code repositories that doesn’t have a lifespan of a moth, app examples: we need to know where we are going to if we choose the Material way, we need to see the bigger picture: the small team that created MD in a small room is no longer conceivable and we cannot wait for updates to the guidelines falling from the sky every now and then. A good example is the step back of the MD guidelines for Wearables devices: after a while, without any explanation, the spec has been renamed Material Design for Android Wear - a clear admission that those guidelines are not universal anymore.
The new home for MD (Material.io) it’s a great starter point but we as designers, product managers, business owners, freelancers - and the list is much longer - need more from Google. No one except Material addicted like me watch YT videos of 2014 to get the idea of a universe constrained between the front and the back of a phone. The launch of MD components for web, Android and iOS is another example of this fog covering the project: what’s that example app given on GitHub? where is Material Design, just on the yellow shadowed Nav Bar?
Wait: MD is flexible enough to be adapted
As I mention at the beginning of this document Google updated the MD guidelines in December and there's a new section dedicated precisely to the Material Design ability to being adapted to better suit the hosting platform or device.
Why a universal system should have this capability, are you asking? Because of the strong conventions created as time passed. But lets the guidelines themselves answering to this question to better understand when and why we should adapt Material:
Design conventions can differ from platform to platform. These differences in convention can affect the user's ability to understand the UI or complete certain tasks. In these cases, it is recommended to adapt to platform-specific conventions. In areas where design differences are minimally disruptive, adapting to the platform is optional. [From Material Guidelines - Platforms]11
Please note that the bold is mine: it highlights some words that are the keys to understand the adaptation concept. First of all: the basics of MD will be always the same - Material as the metaphor, print-like aesthetic and meaningful motion. The problem - the only problem, actually - relies on some strong design conventions established by the hosting platform: when these conventions are too different from the ones adopted by MD, the user will have a problem about understanding the interaction model, the UI - or he will simply experience frustration. This is the case when Material Design should be adapted. We are talking about serious situation here, at a level where the user could even not be able to perform a task. As for the guidelines, this is the only relevant case that justifies an adaptation of MD - again, the user has to experience a delightful digital interaction with his device.
If the design convention is not so problematic, well - plain Material Design will be used: actually, in Google's own words, the adaptation would be optional. A small cognitive load for the user to hop a minimal design barrier is bearable and, after all, MD is based on best practices in both traditional and web design, informed by user experience research and cognitive science, so this risk should be keep at a minimum level.
The concept itself is not bad at all: remember? The main goal is to have a happy user being able to switch from platform to platform and from device to device without experiencing any kind of frustration - and today we are starting to live in a world already projected in this kind of situation.
The real problem is that something is very wrong about the latest MD guidelines update. Google is handling the topic too lightly, literally throwing out of the window years of time spent to establish and teach patterns that are a given on Android - and on MD, too.
On the section dedicated to the Toolbar component, subsection Iconography, we find that:
- On Android and the Web, “the back button contains a thin arrow with a stem”
- On iOS, “the back arrow is thicker, and without a stem”
Besides the fact that instead of being more thicker the iOS icon arrow seems to be actually wider (or more opened, higher, as you like), this simple affirmation is a slap on many designers and developer faces that tried to inform through the years the difference between the back and the up button on Android - something that still today is often misunderstood, probably because of a lack of proper content hierarchy design.
I mean, we had the Up VS Back conversation since, what? Ice Cream Sandwich? It’s not something shining added to the platform just to add a new component but a serious matter of navigation into one app, through different apps, about handling the apps navigation when differents entry points are triggered, managing the chronological views the user navigated through and much more. No less than three lessons are provided on the official Android Developer guide to learn how to implement a correct up/back navigation, and other five articles full of diagrams are there to learn how to design an effective navigation with a proper use of these two different buttons - and going further, one is a system button, the other one is under the app responsability.
Even Material Design has a subsection about Navigation dedicated to the topic. I am not going to bother you with the details - links are provided in the footnotes - but I must summarize the basic differences, citing the MD guidelines to add a bit of salt on the wound:
- The Up button returns users to the previous screen they viewed. It navigates upward in the app’s hierarchy until the app’s home screen is reached.
- The Back button navigates in reverse chronological order through the history of recently viewed screens. Whereas the Up button ensures the user remains in your app, the Back button may take the user back through recent screens outside of your app.
The Back button also:
- Dismisses floating windows (such as dialogs or popups)
- Dismisses contextual action bars, and removes the highlight from the selected items
- Hides the on-screen keyboard (IME)
Should we throw all this out then?
And even if the two controls were both back buttons the irony continues when we find out that iOS Human Interface Guidelines actually consider the possibility of changing the standard back button if a series of conditions are met:
“However, if you implement a custom back button, make sure it still looks like a back button, behaves intuitively, matches the rest of your interface, and is consistently implemented throughout your app.”
That seems a perfect description of a MD Up button, doesn’t it? Unfortunately, the MD arrow is not a back button. Please Google, delete this equation between the two components and provide a navigation solution for devices without system back buttons: changing the style is not an answer to the problem.
Again, this is a problem found in the Toolbar section. There again we discover that:
- On Android and the Web, “The action overflow menu icon (indicated by the “More…” symbol) contains three vertical dots.”
- On iOS, “The action overflow menu icon (indicated by the “More…” symbol) contains three horizontal dots.”
Now, these three dots doesn’t have the same meaning at all on the two platforms.
On Android, the App Bar (a special kind of Toolbar, the one you usually see on the top edge of the screen) has precise roles and functionalities - branding, navigation, search, actions and more, just to have a short list.
This bar is clearly splitted in two main sections: navigation on the left side (where you can find the up button or the hamburger menu, as an example) and app actions on the right side. When the actions that the user can accomplish on the screen he’s working on are too many to be displayed or not so important to being elevated as action icons, one option is to group these secondary actions under the overflow menu (now renamed menu icon because - guess what - you’ll find it across different components to reveal pop up menus containing contextual actions): exactly the three vertical dots on the stake here.
This is a fundamental paradigm since the appearance of the App Bar ancestor, the Action Bar on ICS and an important component to being able to getting rid of the physical option button, once required on Android devices.
No navigation link should be contained here on a mobile device - the only exceptions are the Help and Settings sections, and only in special cases (basically, when the app has no Navigation Drawer or enough space on the App Bar).
selection is the same - that’s the iOS pattern, using the same check mark for both cases.
Not adapting, in this case, would actually be an improvement: I mean, we are used to radio buttons as signifiers for single choices since we had GUIs. Bad choice, Google, even in writing and argumentation:
Native platform switches may be used as they have matching functionality and appearance as Material switches. Use switches instead of check boxes and check mark lists instead of radio buttons, as these are the graphics expected on iOS. [From Material Guidelines - Platforms]20
If the native switches match the appearance and functionality of the MD ones, why adapting? Plus, as the related image clearly demonstrates, switches are not to be used instead of checkboxes: as we just mentioned, both MD’s checkboxes and radio buttons are replaced, on iOS, with the same check mark icon.
Should we now expecting a replacement of all these controls in all Google’s iOS apps? If you don’t believe in this option - nah, Google is too lazy to do something like that! - read the following section to start fearing the unbearable.
The adaptation is already here - did you noticed it?
If you are a user of the iOS Google Calendar app you should have noticed that Google has already started to implement its own recommendations about adapting MD: when creating or editing an event, you can spot an iOS switch to set the event as an all-day one - in a horrible blue that doesn’t matches the color of the event; and when you open a created event, you’ll spot the out of place three dots icon, that opens a bottom sheet with an option to delete the event itself - like on Android - and a second one to close the sheet - what? Google, here’s another advice to better handle your cross-platform device system: fix this horribles replacements for iOS Action Sheets, please. They are too small and no cancel button is needed.
Conclusions: the problem is not cross-platform design
As anyone can notice, I’m not here to criticize the cross-platform design path. At the contrary, I firmly believe in it as a viable solution for these transactional years - where we are going from have many Uis and interaction models to devices iper-connected and without what we are used to call a UI.
In my opinion, the problem is the foggy approach that Google has taken on the topic: and to be clear, I am limiting myself to Google because - let’s admit it - there is no other player in this game. No one would have the interest or the technological power and a myriad of products and services that could benefit from what MD could really be one day. Yes, we have other giant in the mobile OS industry - Apple, that could have the financial power and a great grip on its followers. But why should Apple being interested in cross-platform design, when one of its pillar it’s always been to differentiate themself and their products in any possible way? And besides that, all the design power that Apple once holded is now a memory, and the same could be said about the advanced hardware that once it was able to ship without any competitor being able to match the same product experience level. The same power of the iOS powered devices - the complete integration of hardware and software - would not be an applicable model in a cross-platform design world. The iPhone would not be the iPhone anymore.
So, please Google: let much more of your power into the Material Design project; try to be more opened, to communicate more; the Web is practically your kingdom: use it more wisely and let the Material Design dream come really to life - a truly applicable cross-platform design system.
In the meanwhile, we designers could experiment more, write more about the topic, select the best tools and let our voice to be heard: Twitter, Medium, private blogs, Google Plus communities are great places to ignite sparks and inspire great things.
We could take action, starting by taking the latest Google Design survey: you can find it on Twitter or following this link: Google survey on cross-platform design.
Happy cross-platform design to everyone!
- Google. “Material Design - Platform Adaptation / Platforms” Material Design Guidelines, Google, Dec. 2016, material.io/guidelines/platforms/platform-adaptation.html
- Google. “Material”, Google, Dec. 2016, https://material.io/
- Google, “Making Material Design” 28 May 2015, www.youtube.com/watch?v=rrT6v5sOwJg.
Just a couple of articles to express the general feeling at the time: https://www.reddit.com/r/apple/comments/3pd5j3/is_anyone_else_getting_sick_of_google_trying_to/
 I beg your pardon for this neologism, but I really love it and it actually makes the idea of an app morphing from its foundation to its visual appearance: it’s a paradiìgm shift, not a visual make over.
 And, BTW: these were the apps that shipped out of the box since the first iPhone ever.
 One reason being that - given a more or less set of common hardware capabilities - conceivably, explorables and truly usable metaphors to create digital worlds confined in a rectangular piece of metal and glass and looks & feels to “dress” them are limited in number by nature; one example comes from desktop machines environment, where the counter/table/folder metaphor won a big segment of the whole computing market and if we just count the consumer pie, we could easily say that that slice is practically the whole pie. Sure, the flavor of a Windows machine is different from an OSX one - but the used paradigm is exactly the same.
 Note the difference from device and product here: the UX goes behind the mere device and begun much more before the user is physically handling the device.
 But again, fragmentation was (is) actually living on a deeper level: besides the look and feel, some OEMs went further, adding functionalities, not official supported hardware and APIs that worked only on a particular brand or even on a certain sert of devices (yes Samsung, I’m looking at you right now). And I’m not even touching the update platform problem here!
 Hint: nope, it’s not just a visual language.
 This isn’t exactly true - more in a while!
 Please remember: we are not all designers hee - I mean, not every user is so sensible to certain kind of changings.
 Literally: the smart Paper surfaces and the magical Ink that populates the universe inside the devices.
 See footnote 11
 From iOS Human Interface Guidelines on Navigation Bars: https://www.google.com/url?q=https://developer.apple.com/ios/human-interface-guidelines/ui-bars/navigation-bars