【译】设计还原的九个原则

发布于 2018年01月13日 作者 Rilara 分类 设计

最近,我正在为我们的一个客户主导一个培训课程——如何最佳地使用HTML和CSS来还原设计。 我们有一部分时间用作讨论诸如OOCSS、SMACSS和模块化等等所谓“样式驱动开发”的设计过程。 接近最后一天的结尾,有人问:“但是我们怎么知道我们做得对不对呢?”

 

起初我很困惑。我刚刚已经花费了几个小时告诉他们做什么才是“正确的事情”,但回头思考这个问题之后,我意识到这个问题根植于一个更深层次的需求来引导和评估一套主观选择,而那一套主观选择往往是由不同的人在不同的时间制定的。“统一的命名规则”和“灵活的样式规则”看起来似乎就是最优的方案了,但是这些看似是最佳的实施方案是根植于一个并不确切的思路。例如,像“通过与其他类合并以最小化类的数量”这样的具体的建议,要是在没有广泛了解模块化思想的前提下是没有用的。

 

我意识到为了真正了解我们的工作是不是做好了,我们需要一个更高层次的原则,让我们能够以此作为实现设计的测量棒。我们需要一些从特定语言中删除的东西(比如CSS)或者是一种有主见的书写方式。这个很像设计的通用原则或者是尼尔森的可用性启发式原则,我们需要一些能够指导我们去还原设计的东西,而不是仅仅告诉我们如何做到这一点。为了弥合这个缺陷,我编制了九个设计实现原则。

 

这不是一个清单,相反,这是一套旨在保护潜在可能性的广泛指南。它可以指导参与实施的人员,或者是作为一个评估现有项目的工具。因此不论你是在审核代码,审核CSS,还是在面试团队候选人,这些原则都应该提供一种超越专业范畴、并能够作用于设计实现的指导体系。

 

1.结构化

文档需要符合语义和逻辑结构,甚至不带修饰。

 

2.高效性

用最少的代价去还原设计。

 

3.标准化

有能够被存储和自由使用的公共规则。

 

4.抽象化

基本元素从一个特定的内容中抽离出来,并形成一个核心的框架。

 

5.模块化

通用元素有逻辑的被拆分成可重复使用的部分。

 

6.可配置

通过参数控制去获得定制化的基本元素。

 

7.可扩展性

代码的可扩展性强,并能够在未来得到进一步优化。

 

8.归档

所有内容都能够供其他人使用与扩展。

 

9.准确性

最终输出要还原设计预期。

 

为了更追踪每一个原则是如何适用于一个项目,我们将使用我的一个设计案例作为本文的基础。这是一个特别的着陆页,它促成一家现有电子商务网站上每天的交易。虽然这个着陆页会继承现有网站上的一些样式,但要注意到这重要的是,页面上的大多数元素都是新的,我们的目标是要使用这9大原则,让这个静态的图像转换成HTML页面和CSS样式。


 1515827642图1.png

这种产品的卡片式布局对于我们的商务网站来说是新的。

 

 

 

1.结构化

文档需要符合语义和逻辑结构,甚至不带修饰。

 

这个原则意思是,在即便没有CSS样式的情况下,HTML文档也是有意义的。这意味着我们需要使用有正确排序的标题和无序列表,还有有含义的容器,例如<header>和<article>。我们不应该跳过使用诸如ARIA标签,alt属性还有其他我们可能需要的东西。

 

这个不论使用与否似乎都不是个什么大问题,但是一个看上去一样的元素是用了一个锚点标签还是一个按钮却十分重要,因为它们表达不同的含义并提供不同的交互动作。语义标签对搜索引擎和辅助技术是有意义的,它使得我们能够更轻松让我们在其他设备上进行重新调整。这会让我们的项目更具前瞻性。

 

创建一个结构良好的文档意味着需要学习编写语义化HTML代码,熟悉W3C标准,甚至熟悉其他专家的最佳实践理论,并花时间让你的代码更加通顺。最简单的测试方法就是去掉样式在浏览器中查看HTML页面:

· 没有了CSS样式后页面是否可用?

· 页面是否仍有清晰的层级结构?

· 原始的HTML文件是否能传达意义?

 

确保文档是结构化的最佳做法之一就是从HTML着手。在考虑视觉样式之前,先考虑纯HTML的页面如何划分层级,还有它的每个部分的含义。避免全盘使用div并考虑使用一个合适的标签。只有这个基础的步骤能够让你能够长久以往地建立起一个合适的结构。


<section>

  <header>

    <h2>Daily Deals</h2>

    <strong>Sort</strong> <span class="caret"></span>

    <ul>

      <li><a href="#">by ending time</a></li>

      <li><a href="#">by price</a></li>

      <li><a href="#">by popularity</a></li>

    </ul>

    <hr />

  </header>

 

  <ul>

    <li aria-labelledby="prod7364536">

      <a href="#">

        <img src="prod7364536.jpgalt="12 Night Therapy Euro Box Top Spring" />

        <small>Ends in 9:42:57</small>

        <h3 id="prod7364536">12" Night Therapy Euro Box Top Spring</h3>

        <strong>$199.99</strong>

        <small>List $299</small>

        <span class="callout">10 Left</span>

      </a>

    </li>

  </ul>

</section>

从HTML开始,并思考每个元素的含义如何让文档更加结构化。从上面可以看到我创建的所有标签没有一个使用了div标签。

  

 

2.高效性

用最少的代价去还原设计。

我们必须仔细考虑我们的代码以确保代码的简洁性,不包含不必要的标签与样式。通常我检查代码时,会发现代码中使用很多特定框架下的类名去实现多个div嵌套,而这种做法通常仅仅是为了使一个块级元素实现右对齐。通常过度使用HTML是因为不了解CSS,或者是底层框架的原因。


1515828831图2.png

这是一个常见的过度依赖框架的例子,这些框架会生成臃肿的HTML和CSS。想想一个标签需要做什么,而不是框架可以做什么去实现设计预期。

 

除了标签和CSS以外,我们还需要其他外部资源,例如icon、网页字体和图片。从自定义图标到嵌入到外部SVG的base64图像,有很多很好的关于实现这些资源实现最优化的方法和意见。每个项目都不一样,但是如果你在一个按钮上使用一张有500像素的png图片作为一个图标的话,这个明显就是降低效能的做法了。


1515828750图3.png


文件的大小不总是最重要的。在CSS中使用base64相对于使用一个外部资源的方法,例如图片或者icon font,对于编写高效代码更加重要。

 

在评估项目效率的时候,有两个问题需要问的:

  • 我可以用更少的代码完成相同的事情吗?

  • 如何优化资源能够让代价最小化?

实施的最优化也与下面的标准化和模块化的原则相重叠的。因为提高效率的一种方法就是设定标准,并重复使用。为一个普通的盒子阴影创建一个mixin是高效的做法,它同时也创建了一个模块化的标准。

 

3.标准化

有能够被存储和自由使用的公共规则。

创建网站或者App的标准通常是关于建立一些规范,例如每个标题的大小,常见的栅格宽度,还有每个按钮的样式。在简单的CSS中,你必须利用外部的样式指南来维护这些规范,并且记住如何正确使用。但是最好使用诸如LESS和Sass之类的预处理器,你就可以将它们存储在变量和混合中。这里的主要挑战是如何平衡标准化设计与“像素完美”。

因此,当我拿到一份是栅格间距是22像素的设计稿(而不是我们其他地方已在使用的15像素),我会认为这个精度是不正确的,而继续使用原来标准的15像素。进一步说,所有元素的间距值都会使用这个标准的倍数。额外的间距将会是$gutter-width * 2(等于30像素),而不是一个硬编码写死的值。这样的话,整个App就会有统一的感觉。


.product-cards {

  li {

    display: inline-block;

    padding@gutter-width/4;

    color@text-color;

    text-decoration: none;

    background-color@color-white;

    .border;

    margin-bottom@gutter-width/2;

    margin-right@gutter-width/2;

  }

}

.product-status {

  font-size@font-size-small;

  color@grey-darker;

  font-weight@font-weight-bold;

  margin-bottom@gutter-width/4;

}

因为我们是使用从LESS变量和mixins派生出来的标准化值,我们的CSS是没有任何自己的数值的。所有都是从中心变量得来。

检查是否标准化,查看CSS中有没有硬编码的内容:像素、十六进制的颜色值,ems或者大量的具体数值。

  • 这些部分应该使用现有的标准值还是变量?

  • 一个模块是否因为可以得益于一个新变量而被重复使用?也许你已经注意到了你是第二次使用一个部分不透明的背景,并且每次都是需要相同的透明度。

  • 该部分是否可以根据现有的变量计算得出?这个对于颜色的变化很有用。例如说使用一个标准的颜色,然后通过计算得出比这个颜色深10%的颜色,而不是对这个更深的颜色进行硬编码。

通常情况下我会尽可能使用标准值,并在例外情况下创建新数值。如果你发现你对一个元素的调整在这里是5像素,在那是却是1像素那么你的标准有可能会被破坏。

根据我的经验,大多数预处理的CSS应该使用集中的变量和mixins,而且你在组件中几乎看不到数字、像素或者色值。有时候是添加一些像素值来调整单个组件的位置是恰当的,但这些情况应该很少见,这时你应该再次检查你的规范有没有被破坏。

 

 

4.抽象化

基本元素从一个特定的内容中抽离出来,并形成一个核心的框架。

我最初称这一原则为“框架化”,因为除了创建一个你正在进行的项目以外,你还应该致力于一种可以在原始环境以外使用的设计系统。这个原则是用来确定那些在整个项目或者将来的项目中需要用到的数量更多的公共元素。这个跟排版、表单输入,还有不同的导航设计方式一样应用广泛。以这种方式思考一下:如果你的CSS将作为一个开源的框架,如Bootstrap或Foundation,你将如何分离设计的元素呢?你将如何写他们的样式呢,即便你已经在使用Bootstrap?不同之处在于你的项目有Bootstrap所没有提供的基本元素,这些将会在你将来的项目设计中使用到。

 

1515829190图4.png

虽然这些设计元素目前并没有在我们的电子商务网页上出现,但这大多数是有用的,并抽象出来提供到整个框架当中。

 

这里的关键是以更通用的术语来思考每一个元素,而不仅仅在你的项目所在的特定情境中。当你在查看特定元素时,将它拆分开来,不管你现在正准备用的具体实现方法,为每一部分赋予全局的样式。最常见的元素是版式(标题样式、行高、大小和字体)表单元素和按钮。但是其他元素也应该被“框架化”,如标注的标签或者其他价格标签格式,它们可能已经使用在我们“每日交易”的设计中,并且有可能用到其他地方。

当你在检查你的项目的抽象化情况时,请问:

  • 如果我知道这个将会在其他需求的情形中重复使用时,我会如何构建这个元素?

  • 我如何将其拆分才能使它在整个中都有用?

思考如何用更通用的方式去实现每个元素是关键。这些元素应该储存在完全分离和独立的类当中,或者是最终能编译为CSS的独立的LESS或者Sass里面。

这个原则在网页组件或者模块化App架构中更容易实践,因为这些独立的部件可能已经以这样的方式分离了。但是它对我们的思想有更深远的影响。我们应该常常思考如何从具体的工作中抽象出来,以便我们去创造更加灵活的东西。

 

5.模块化

通用元素有逻辑的被拆分成可重复使用的部分。

 

与抽象化原则相重叠,使我们的设计模块化是创建一个便于维护的具设计系统的重要组成部分。这两者之间有着细微的差别,这在原则上非常重要。细微之处在于,即便全局基础元素需要从整体中抽取出来,但是全局中的单独元素也需要做到能够重复使用,并保持独立的样式。一个模块可能对于我们的程序来说可能是独立的,并且不需要应用到整个框架中,但是他们仍需要做到可重复使用,以便我们无需每次用到他们都要重复代码。

例如,如果你从前一个示例中为一个“每日交易”的着陆页创建一个产品卡片列表的时候,没有专门为这个列表创编写专独立的HTML片段和CSS样式(使用类似于 daily-deal-product的类名),而是创建一个更通用的 product-card的类,这个类包含了所有你可以在这个“每日交易”页面以外重复使用的抽象类。这个可能会导致组件会有三个不同的途径进行获取:

  • 基础CSS样式

这个是底层的框架,包括字体、栅格、颜色和其他内容的默认值

  • CSS组件

这个是从整体设计构件中抽取出来的部分,但能够在全局中重复使用。

  • 父级组件

这些是包含了样式和个性化元素的“每日交易”模块(和它的任何子模块)。对很多人而言,这个可能是一个真正的JavaScript Web组件,但是他可能仅仅是一个能够呈现整个设计的父级HTML。

 

1515829226图5.png

让你实施模块化的结果呈现出类似于这样的一个结构,其中每个组件可能都有一些间距或者是定位的样式,但是大部分的CSS都是继承于框架。 

 

当然,这也许考虑的太长远了,所以你必须懂得如何判断。但最重要的是,你所创建的每一个东西都尽可能可以复用,否则日后的维护将会相当麻烦。

 


6.可配置

基本元素的自定义可通过可选参数提供。

 

构建设计系统的一个很重要环节是考虑项目现在或者将来可能需要的选项。只是按照规定执行设计是不够的。我们还必须考虑到哪些内容是可选的,通过不同的配置打开或者关闭。

例如,我们设计中的标记只展示了三个颜色的变化,并且全部指向左边。我们不会创建三个单独的类,而是创建一个默认的类,同时添加额外的类作为可参数。除此之外,我想有人可能会希望将箭头指向不同的方向。事实上,使用默认的品牌颜色来标注这些标记也是有用的,尽管设计并没有特别要求。我们会转么写CSS样式来说明这一点,包括向左和向右选项。


1515860435图6.png

我们默认标记上使用的是我们默认的品牌色,而我们希望在着陆页上使用的是特殊的样式。我们还会创建一些可选项,如不同的颜色和向右的箭头。

 

当你在思考一个特定的设计元素时,想想它有可能的选项。要理解这一点重要的是要知道这个原色可能被复用的其他场景。

l   哪些部分可以是可以进行配置的、或者通过外部变量来选用和启用的?

l   元素的颜色和位置改变是否有价值?

l   是否有必要提供小、中、大不同尺寸?

使用诸如BEM、OOCSS或者SMACSS等方法去组织你的CSS,并且预定命名规则可以帮助你去决定这些是否有需要。按照这样去做事构建可配置的系统的重要组成部分。

 

7.可扩展性

代码容易进行扩展,并能够在将来进行优化。

本着与“可配置”原则相同的精神,我们的实现也必须考虑将来的变化。虽然创建可选参数是有效的,我们也无法预测我们的项目将来需要的一切。因此重要的是考虑我们的代码将如何影响到未来,并且有意识地组织好代码以便于以后的优化。

构建可扩展的CSS通常要求我们使用LESS和Sass更加高级的特性来编写mixins和功能。因为除了颜色以外,我们所有调用的标记都是相同的,我们可以给为每一个标签生成的CSS创建一个单独的LESS mixin,而不需要为每个变量重复代码。该代码旨在扩展,并且只需要简单更新一个地方就可以。


@angle: 170;

 

.callout {

  &.qty-left {

    .callout-generator(@color-deals, @color-white, @angle);

  }

  &.qty-sold {

    .callout-generator(@color-white, @color-deals, @angle, 2px solid @color-deals);

  }

  &.qty-out {

    .callout-generator(@color-greydarken(@color-grey, 10%), @angle);

  }

}

为了使标注可扩展,我们将创建一个LESS mixin “.callout-generator”用于定义诸如背景色、字体颜色、角度和边框。


1515860467图7.png

结果是可扩展的CSS可以产生一些新的参数

 



.review-flag {

    .callout-generator(@color-brand, @color-white, 75);

}

将来,当一个新的需求需要类似的设计模式时,生成一个新的样式是很容易的。


1515860494图8.png

结果是可扩展的CSS可以产生一些新的参数


要创建可扩展的设计系统,需要学会预测项目中常见的更改,并运用这种预测确保你编写的代码已经可以适应这些变化。常见的解决方法是使用变量和mixins方法,以及在将它存储在数组中,并遍历它们。你可以问问自己:

l   这些元素哪些部分是可能改变的?

l   你如何编写代码以便将来能够很容易进行修改?

 

8.归档

所有的内容都是为了供他人使用以及扩展的。

 

文档设计的价值通常会被低估,它通常会是项目最不受重视的环节。但是创建工作记录不仅仅能够帮助其他人明白你为什么这么做,实际上这还能够让所有相关人员都加入到这个设计系统当中,而你也不需要每一次都要重新造轮子。你的文档应该能给团队中每一个人参考,从开发者到管理者。

记录工作的最好方法是创建一个实时的样式指南,它是直接从代码注释中生成的。我们使用一种称为“以风格导向的开发文档”CSS,它会自己生成指南。但是,即使你的项目没有实时样式指南,在HTML中手动创建一个,或者是一个打印的PDF也是可以的。要记住的原则是我们所做的一切都要记录下来。将你的设计过程记录下来,编写说明文档以帮助其他人了解你的设计是如何实现的,以及他们知道需要做什么去进行重新设计。这些信息可能包括一个元素背后的设计思路,diamante示例或者是元素实例。*我如何告诉别人如何使用我的代码呢?如果我成为了一个新的团队成员,我会如何解说来确保他们其他人知道如何使用它?我可以展示组件的哪个变量来展示它能够使用的所有方法?*


1515860514图9.png

一个风格指南很棒,但是直接从CSS中生成的实时指南更加巧妙。

 

9.准确性

最后的输出要符合预期。

 

最后,我们不能忘记的是我们创造的产品必须是和原始设计同样优秀。没有人会想要一个没有符合视觉吸引力预期的设计系统。重要的是要强调一点,结果只会是设计的“适当表达“,而并不会是”像素完美“。我不喜欢”像素完美“这个词,因为这暗示为了实现像素模型一样的效果时必须忘记任何浏览器的约束,以及无视标准化(更别说每个浏览器渲染CSS时都会有细微差别)。使得准确性变得复杂的原因是,响应式应用程序的静态设计很少考虑到每个可能的设备大小。关键是需要一定程度的灵活性。你必须决定你项目需要用到多少适当的表达形式,但是要确保符合你所要服务的人群。在我们的项目中,我将会审查与客户的像素完美的主要偏差,以确保我们达成共识。”设计显示了一个带有边框的默认蓝色按钮样式,但是与我们的标准按钮颜色稍有不同,并且没有边框,所以我们选择了它(我们的标准样式)。“设定期望是很重要的一步。


1515860551图10.png

在实际数据和标准化CSS实施中,最终实现效果与原始模型略有不同。此外,在实施过程中,一些需求也发生了变化。尽管如此,结果还是准确的。

 

思维体系

这九个原则的目标是为HTML和CSS还原设计提供指南。这不是一套规则或说明性建议,而是一种关于你工作中如何在优秀的设计和优秀的代码中取得平衡的思考方式。应用这些原则的时候要给自己一定的灵活性非常重要。你不可能每次都做到尽善尽美。它们是理想状态。工作中总会有其他的干扰、原则和优先级妨碍我们把工作做好。尽管如此,这些原则永远是我们追求的目标。通过这些原则不断检查自己,并且在从设计图到最终在所展现的媒介上过程中积极的追求完美。我希望它们会帮助你创造出更好的产品,并建立起可持续多年的设计体系。


 

原文地址:https://www.smashingmagazine.com/2017/08/nine-principles-design-implementation/


评论(0)

暂无评论