谷歌的Material Design是一个设计系统,帮助团队在不同平台上建立高质量的数字体验。Material Design最好的部分之一是它为跨不同技术(web、React、Angular、iOS、Android等)使用的不同组件提供了指南、实现、标准和代码。对于跨不同应用程序使用不同技术的企业来说,这是一个很好的支持使用Material作为标准的例子。但是你应该依赖物质吗?
不同技术的差异
事实证明,Material为不同技术提供的组件的设计和实现是完全不同的。假设一个组织决定使用Material作为他们的设计系统,有两个项目使用两种不同的技术,一个是Angular,另一个是由CMS驱动的静态网站。材料有单独的一套组件的角和另一个单独的设置网络(展开左边的组件部分)。
材质中按钮组件的样式角是完全不同的吗网络实现。Angular版本有一个stroke Button的变体,而web版本有一个outline Button的变体。如果我们需要在Angular应用中使用outline按钮,就需要对它进行单独的样式设置。按下按钮的情况与此类似。它需要在web应用程序中单独的样式。同样,文本框输入也有不同的样式和交互网络和角版本。它们中的任何一个都需要额外的样式来匹配。现在应该用哪一个作为标准呢?
除了组件设计上的变化,还有一些组件只出现在Angular版本中,而在web版本中根本没有实现。假设Angular和web项目都需要自动完成功能。Material为该组件提供了一个内置的、易于使用的实现角的版本。这在网络版本中不存在。你需要编写自定义JavaScript和自定义样式,以确保web的实现与Angular的匹配。对于日期选择器组件也是如此。Angular有一个内置的日期选择器组件,而web却没有。同样,这必须是自定义实现。同样适用于手风琴/扩展面板,步进形式,工具提示等。它们都需要一个定制的实现,以确保与Material的设计指导方针相匹配。
跨不同技术实现组件的这种差异肯定会让从事不同项目的开发人员和设计人员感到困惑。此外,如果Material的Angular组件得到了升级,自定义组件也需要手动升级。这增加了不必要的开发人员维护和测试不受特定变体Material (Angular、web或React)支持的组件的开销。
人们开始想知道为什么谷歌的Material背后的大脑没有花很多心思来以同质的方式创建跨不同技术的组件的设计和实现指南。跨不同技术的组件实现的缺失或更改在使用它们的团队中造成了很大的混乱和开发开销。如果要将Material的设计系统作为一个跨组织不同技术的标准,对其设计系统及其组件进行全面细致的审查是绝对必要的。