Material design 2 vs 3 - an assessment apparatus
Intro
In the 7 years since Google released it’s Material Design palette, the state of User Interface (UI) design has developed significantly. In 2021 Material 3 was announced to connect with the new state of play. Coincidentally, this has aligned with the released of Jetpack compose, a modern UI Toolkit for the Android community. The duality of these changes has left teams with an Multiple Migration problem, how to incorporate these 2 changes into their Applications over the next few years.
Material story
Material Design was developed by Google, as a visual language that could bridge the divide between developers and designers. Released in 2014, it provided developers with a set of out-of-box design principals which they could crudely design Apps which looked half decent, whilst avoiding the Magenta and Cyan colours which plague dev-UI practices. It is also gave a designers a box with which they could play in, containing the foundations of the platforms look and feel, but with a dash of flair and customization that appeals to their thinking tenor.
In 2021, at Google I/O, a new concept was announced, Material You or Material 3 (M3). It emphasised audacious animations, larger buttons, distinct elevation panes and custom UI themes based on the users wallpaper. This is was not an overhaul of the Material design system it was a modernisation, a refresh and an update for the direction UI design had taken in the 7 years since Material was released.
Alongside the UI design changes, Jetpack Compose (Compose) was released in July 2021, as modern UI Kit for building native Android applications. XML was replaced with a functional reactive framework written entirely in Kotlin, allowing Developers to think in the same language throughout out their Application space. Now, in 2023, Compose has been adopted as the industry standard and most tech companies have begun their migration from XML to Compose.
Multiple Migrations
Coupling the release of Compose with the Google’s updated Material framework has left Android developers with a tough decision and easy decision with respect to the Multiple Migrations in their application space.
XML -> Compose
A purely technological transformation, replacing each screen with a different underlying technology set. As if moving from a internal combustion engine to electrical engine in your motor vehicle, whilst the steering wheel and break pedals act much the same, but with a drastically different engine noise.
M2 -> M3
A conscious transformation of how the user interacts with the application. The underlying technology set might be the same (XML), however we are looking at completely different steering wheel, with throttle-esq mechanism to manage velocity variations.
Assessment Apparatus
Facing down this Multiple Migration situation at my work, we had to make tough decisions on how to manage this problem same. Not only were there Technical/Design considerations of the Application Structure. Now a human factor came into play, there was a conflicting perspectives between Developer/Design space and again a the omnipresent spectrum of developer perspectives.
Developers
- Dev’s wanted compose, the migration had begun, 5 % of the code base was migrated to compose and the in house UI Toolkit was being migrated component by component. This was happening!
- M2/M3 was different, many Developers could not see a significant enough difference in the look of M3 to warrant the extra work. Some were concerned with the freshness of the M3 library, there were @ExpiermentalM3Api annotations littered throughout the M3 code, and many of the API’s had already been deprecated in the libs short lifetime. This signified risks of managing a changing API.
Designers
- Designers were confused at the state of play. Was M2 something that would be around for a long time? Would M3 come along at some point and make their designs defunct? How would they plan out their Design components for the App refresh over the next year? Would the refresh be done again in a year when the M3 migration was Green-Lighted?
- A slight concern was voiced, that of having different screens having a different look and feel during the migration. However, as you might notice in the screen shots above, the differences are not significant enough to stop the M3 migration.
- With respect to Compose, Designers could care less what Developers used for their UI Toolkit, as long as the delightful designs were expressed on screen ❤
Options
In short, compose was happening, would M3 happen at the same time? Trade off’s needed to be evaluated. Here were the two options…
- Migrate to Compose now and do M3 later. Less risk from a developer perspective, we could use stable API’s in the future and the learnings from the Compose migration to handle the M3 migration with greater competitance. However, this is would incur more tech-debt, more knowledge-debt and increase designer frustration.
- Do both migrations at once. Compose was fresh and migrating now would cost significantly less in the future. However this would require more learning upfront from bother Developers and Design, and more risk with unstable API’s.
From a empirical perspective, here is the equation that needed to balanced
M2TD + M2KD < M3IC + M3R
- M2TD = Tech debt incurred from remaining on M2
- KD = Knowledge debt incurred by remaining on M2
- M3IC = Cost of migrating to M3 immediately
- M3R = Risk from Migrating to M3 with unstable API’s
Was the cost of Moving to M3 less than the cost of staying on M2?
Each company/situation will apply different weights to these values and come out with a completely different answer. Each weighting is very subjective leaning to a very difficult decision if one of the parameters did not dominant the equation in your specific perspective.
Our results was that the cost of Tech-Debt/Knowledge-Debt incurred would be significantly higher than the upfront cost of moving to M3 immediately, so we decided to Rip The Band-Aid off and embrace M3 immediately.
Evaluation epilogue
In evaluating the M3, Designers wanted to see the complete palette of widgets on offer in the Library and how the set color schemes would affect their Look-and-Feel.
A technique we used was to Mash every single component from the M3 library onto a single, showcasing the whole library to both Developers and Design. Developers could see the breadth of the experimental API’s and designers could go shopping, taking what widgets they liked and leaving the rest out of their Design ToolKit.
Here is a link to the component Mash if you would like to use it in your evaluation of the M3 compose Library.
Conclusion
Many Android tech teams are facing into the problem of managing the Multiple Migrations from XML->Compose and M2->M3 at the moment. There are many factors at play Technical, Design and Human. All of these need to be balanced whilst making the decision on what to migrate and when. Hopefully I helped making this decision easier for teams facing into this complex scenario.