Google’s annual I/O conference has always been a field day for developers, but I/O 2014 brought what was perhaps one of the most groundbreaking revelations in the history of mobile design.
As Matias Duarte, Google’s VP of Design took to the stage, the screens behind him rippled and revealed the beauty that was Google’s foray into a unified cross-platform visual language, titled Material Design.
The initial days after I/O were a frenzy of developers, designers and users alike attempting to get their fill of paper and ink, modifying their designs, their code, and even their homescreens to reflect the new paradigm that Google had introduced. But as time passed and apps supposedly completed their transition to Material design, it became painfully apparent that numerous parts of the guidelines were being lost in translation.
Floating Action Button
Definitely the most iconic component of the Material Design visual language, the Floating Action Button pattern rapidly gained popularity among both users as well as developers, driven primarily by its easy accessibility and its archetypal nature. Alas, developers went on to misrepresent the FAB’s importance, blatantly ignoring its symbolic representation of a primary action, going on to associate Material Design with the FAB and wrongly using it for secondary and other less important actions. Marissa Mayer, under her “3 Rules of App Design” topic in her book, explains the essence of the FAB rightfully, stating that ” every product should be designed for the way it will be used 98% of the time.”
Functionality > Aesthetics
Up until a white ago, the metric for good design was solely based upon how good an app looked, as opposed to current trends measuring design in how good it feels — the past few years having buoyed the significance of user experience and established its position as a superset of user interface design. However, a host of developers fail to realize the implications of prioritizing UI over UX, and thus go ahead and implement patterns like placing the navigation drawer below the toolbar solely for the hamburger to arrow animation, throwing the hierarchy and app’s experience into disarray. Designers everywhere are gradually gaining ground in the battle for change, and while the transition is a slow one, it’s a steady one, and each passing day sees another step in the direction of a high quality application ecosystem.
Launch Screens
Ahead of a recent update to the Material Design spec, Google strongly advocated against the use of splash screens when launching an app. However, as the design language matured and took into consideration the hardware and network constraints that some users face, the design team expanded the guidelines to allow the usage of splash screens – or launch screens – with a set of acceptable use cases. Despite the spec entreating developers only to use it when constraints prevent the immediate presentation of content, a large number of developers employ launch screens for the sole purpose of branding, a decision that proves solely detrimental to the overarching user experience, forcing users to unnecessarily wait before being able to access the app’s content.
Grid and Keylines
Riveting the focus of app designers on structural and balance, Material Design introduced the concept of an 8dp baseline grid and certain keylines, which combine to give Material apps a certain underlying structure and balance. One such case is the aligning of list item labels at the 72dp keyline, which line up with the toolbar title, forming an associative visual relationship between the two. Unfortunately, many developers dismiss the importance of the baseline grid and the keylines, unbalancing the app’s layouts and unknowingly abandoning the structural integrity of the user interface.
Navigation Drawer
Though they were shunned in their early days by design pundits citing its lack of visibility, the navigation drawer and hamburger button patterns have experienced rapid increases in adoption rates in recent years. With widespread platforms like iOS and Android pushing hard for it, users slowly but steadily got acquainted with the pattern, but as is the case with everything that crosses a certain limit of popularity, developers and designers began misusing the navigation drawer. Depending on the hierarchical structure, navigation can take on various forms, and the Material spec has a section dedicated to deciding what form of navigation is appropriate for your app.
Navigation Bar
Even as Material Design was making its ingress in the designer communities, a number of APIs were being prepared for the API 21 release, among which was the navigation and status bar APIs. While status bar coloring was deemed appropriate, designers everywhere have taken a rigid stance against the tinting of the navigation bar as well, given that it disturbs the visual balance of the screen and “boxes-in” the app, suffocating the design and the app’s content.
Design is a delicate subject. Wrongly used, even the most sound logic can be extremely detrimental to the end-user experience.
What parts of Material Design do you think are often misrepresented? Sound off in the comments section below!
0 comments:
Post a Comment