[转]从宜家的家具设计讲模块化
这是我刚进公司偶然遇到的一篇好文章,可以说趣味性跟思考性并重,每次看都有新的感悟,可以为你的工作和生活提供到很好指引的一篇文章,基本在我心里可以封为神作了!趣味中得到启发,隆重推介这作品,希望能引起交流和互助。
-- 来源 腾讯WSD
很久之前就知道 宜家 ,以前在广州的时候也去过一次,给我的印象就是:大、贵、巧。地方很大,东西很贵,设计很巧。现在住的地方离宜家不远,这个月找时间去逛了下,地方还是那么大,东西还是那么贵,设计还是那么的巧。虽然没有买什么东西,不过也还是有所收获的,通过宜家的家具设计方法,我们可以聊聊模块化。
去过宜家的同学应该都有注意到,宜家的家具基本都是组合的,可拆装。模块化的特点也是这样,可以组合,相对独立,在需要的时候可以很方便的加上。那怎么写可以基本实现这种方式呢?给个简单的例子:
模块化Demo
模块化结构的例子。
对应的CSS可以这么写:
.mode-a{...}
.mode-a h3{...}
.mode-a p{...}
其中“mode-a”就是这个模块的名称,表示这是名为“a”的模块,现在这个模块可以被放到你所需要的地方。既然是做模块,就不会只有一个,我们再加一个“mode-b”:
模块化Demo
模块化的特点:
- 相对独立
- 可移植性高
对应的CSS可以这么写:
.mode-b{...}
.mode-b h3{...}
.mode-b div{...}
.mode-b h4{...}
.mode-b ul li{...}
实际应用中大多需要加一些classname来减少类定义的复杂度,这个例子比较简单,但足以说明模块化的特点。上面两个模块可同时被使用到一个或多个页面中。
在宜家的卖场中,也许你也注意到了,基本是以设计师来划分商品区的,特别是那些小件的商品。模块化后的代码也可以被分配给不同的人进行编写,提高效率。当然要实现这种方式,我们也需要做些工作,如模块的命名规范、模块中哪些地方是需要留接口的等等。如上面的例子中可以约定的就有:命名以“mode”开头,模块标题使用h3标签。这样不管是哪个人写出来的模块都可兼容项目中的页面。
看到这你可能会发现,既然上面已经约定了模块固定的结构,每个模块的样式定义中所写的这一部分不就是冗余的吗?是的。如果已经形成相关的约定,这部分的样式定义可以被提出来放到项目的公共定义中,减少代码的冗余。如上面的例子可以变成:
/* =S global */
h3{
/* 第一种写法 */
...
}
.mode-a h3,
.mode-b h3{
/* 第二种写法 */
...
}
/* =E global */
/* =S mode-a */
.mode-a{...}
.mode-a p{...}
/* =E mode-a */
/* =S mode-b */
.mode-b{...}
.mode-b div{...}
.mode-b h4{...}
.mode-b ul li{...}
/* ==E mode-b */
不知你有没注意到宜家那些小件的商品,往往可以组合到不同的其它商品上面。这也带出了模块化的另一个话题:模块中的模块。即在模块中可以存在其它的模块,也很好理解,就像我们做网站的时候,整个页面的结构就像是一个大的模块,而上面所讲的例子就是模块中的模块了,只不过我们把这个定义缩小一层。上面例子中对h3的定义,就可以看成是一个模块,它在“mode-a”、“mode-b”两个模块中都出现,并且结构表现相对固定。
OK,这只是对一个标签的定义,如果不只一个标签呢?我们重新改下例子:
模块化Demo
模块化结构的例子。
模块化的特点:
- 相对独立
- 可移植性高
模块化Demo
这个是“模块中的模块”的例子。
模块中的模块:
模块“mode-a”就是一个模块中的模块。
/* =S mode-a */
.mode-a{...}
.mode-a h3{...}
.mode-a p{...}
/* =E mode-a */
/* =S mode-b */
.mode-b{...}
.mode-b h4{...}
.mode-b .cont{...}
.mode-b .cont ul li{...}
/* =E mode-b */
/* =S mode-c */
.mode-c{...}
.mode-c h4{...}
.mode-c .cont{...}
.mode-c .cont p{...}
/* =E mode-c */
从上面可以看到,“mode-a”是一个独立的模块,当它作为“mode-b”和“mode-c”的一部分时,就成了模块中的模块了。抛下砖,希望能引出更多相关的讨论。
用户登录
还没有账号?
立即注册