网站内容与功能设计(前端工程师可以脱离设计师直接接触甲方吗？|2016)

　　网站内容与功能设计(前端工程师可以脱离设计师直接接触甲方吗？|2016)

　　背景：在做 VALSE 2016 网站 时，没有设计师参与。在这种情况下，要制作网站，就得从功能的角度来考虑写网站，而在这个过程中，开始思考前端工程师工作的出发点是不是设计草案，并相应地查看它。前端工程师有可能直接从设计师那里写网站：从功能开始的网页构建。

　　优点是可以快速建站。前端工程师无需设计师直接联系甲方，根据功能需求直接编写代码形成功能模块组合，然后搭建网站。

　　缺点是缺乏装饰。虽然可以做一些装饰性的工作来弥补功能性，但是这样的设计缺乏整体性的考虑。这是速度和设计质量之间的较量。

　　有三个核心点：模块化（与响应性直接相关）、功能优先（原型线框？）、一致性（字体、徽标、前端自然模块（nav\footer））。

　　网站不需要设计吗？

　　大概是去年九月，我接了一个项目做 VALSE 会议网站。该项目的最后期限是“尽快完成”。在如此紧迫的情况下出现了一个问题：找不到设计师。迫不得已，只好硬着头皮，甲方的需求一明确，就开始写代码。具体做法是：需要10页？好的，那我就写一个 10-tab 的导航。需要会议新闻？那我就写个新闻吧。需要聚会地点？然后我将添加一个地图插件来指向会议地址。需要注册页面？然后写表格。像这样一块一块地写，终于形成了VALSE 2016的网站。同样的概念也产生了另一个会议网站：SIDAS 2016。

　　现在回想起来，我有几个问题：

　　我认为第一个问题是肯定的，设计绝对不是会议的必要部分网站。直到今天，还很难说设计了很多国际会议：ECCV 2016。

　　第二个问题，我觉得前端工程师工作的出发点不是设计稿，而是功能。拿到设计稿的时候，第一眼看到的就是图片美不美，但这还不够我写一个网站，需要快速阅读设计师想要表达的意思：“这块是导航栏，这块是横幅，这块是页脚”。并使用相应的语义标签：“nav, footer, article”。所以设计稿传达给我们的不仅仅是这个东西长什么样子，还有它是什么，也就是说，告诉我们这个东西的功能。说到这里，我好像在自相矛盾：我明明说我不认为设计稿是起点，但我之前所说的都是关于设计草案的。那么从设计师的角度来看，他们工作的出发点是什么？是甲方的需要，也是这个东西需要达到的。那么他们的工作是什么？就是把抽象的需求变成产品功能，用图片来描述产品功能，方便前端实现。对于一个前端工程师来说，如果你只知道设计很美，却无法理解设计师想要传达的具体功能，那你永远不会使用语义标签。因此，前端工程师的工程出发点是功能性。那么他们的工作是什么？就是把抽象的需求变成产品功能，用图片来描述产品功能，方便前端实现。对于一个前端工程师来说，如果你只知道设计很美，却无法理解设计师想要传达的具体功能，那你永远不会使用语义标签。因此，前端工程师的工程出发点是功能性。那么他们的工作是什么？就是把抽象的需求变成产品功能，用图片来描述产品功能，方便前端实现。对于一个前端工程师来说，如果你只知道设计很美，却无法理解设计师想要传达的具体功能，那你永远不会使用语义标签。因此，前端工程师的工程出发点是功能性。

　　再想一想，如果前端工程师一步步走设计师将需求转化为功能的过程，直接接触需求会怎样？稍微开动脑筋：你做的是一个看起来像线框的原型网站...（感觉这里有一个莫名其妙的玩笑）

　　回到我之前遇到的问题：如果没有设计师，只有前端工程师，怎么做一个还能看到的网站？

　　我认为是基于功能的网页构建：以模块化的方式，按照功能优先的原则，先写一个原型图网站，最后用一些一致的技术让用户认为这是一个<多个页面的@网站，而不是多个网站（另一个奇怪的笑话）。

　　通过这个描述我们会发现，基于功能的网页搭建的优势在于可以快速搭建网站，前端工程师无需设计师就可以直接联系甲方。缺点是缺乏装饰。虽然在实现功能后可以做一些保持一致性的装饰工作来弥补，但这样的设计缺乏整体考虑，是速度和设计质量的较量。

　　模块化的

　　根据甲方的需要，细分为功能后，每个功能实际上就是一个div标签（或其他语义标签）。

　　以会议网站为例，其实已经有一套固定的范式了。从会议到几页，每一页需要放什么，需求其实每年都一样，从需求到功能的过程一直是由前面的网站完成的。这时候前端要做的就是根据前面的功能模块进行粗精提炼，然后开始编码。

　　功能模块自然是 div。在响应式设计开始成为一种趋势之后，网页的设计变得同质化，它们看起来都类似于 Boxify。

　　为了便于响应，大多数响应式模板很少有左右布局，而且大多是从上到下的布局。这其实给前端工程师根据自己的需要编写网站带来了便利：可以直接添加新的模块，不需要考虑过于复杂的重排问题。Boxify 是一个非常典型的响应式网站，每个水平色块都假设一个功能。

　　对于前端工程师来说，接收需求的第一步是明确和细化需求。细化的需求对应一定的功能，最后根据这些功能从上到下写在一起。

　　功能第一

　　如果按照前面的步骤，很可能会很丑，因为没有设计，生成的页面会非常简单。就我而言，每次来到这种时候，我都觉得蛋疼，因为审美自然不允许自己写出这么难看的一页。但是为了快速实现需求，我们应该始终相信我们从头到尾都在做正确的事情。坦率地说，功能对我们来说是最重要的。不管我们多丑，都要坚持实现功能。

　　始终如一

　　从用户的角度来看，一致性是一项要求。

　　一个功能性的网站 是一个可用的网站，但这并不意味着用户想要使用它。除了开会网站再丑也得用的场合，在其他场合网站设计，美也是一个元素。

　　当一个网站的10页按照上述功能优先的原则完成后，结果就是一个难看的线框。然而，遵循一些非常简单的一致性很容易让用户相信“这 10 个页面合二为一网站”。同时，在保持一致性的过程中，网站也进行了一定程度的美化。

　　对于一个 网站 下的多个页面，它们自然是一致的：

　　其实只要满足这三点，网站的大部分元素都会根据这三点进行更新。更新后的 网站 离丑陋又近了一步。

　　以 SIDAS 2016 网站 为例。

　　除了这三点，还有很多细节可以美化和优化。例如，为了节省空间，将几个内容较少的模块组合起来；为长页面添加返回顶部按钮；悬停*敏*感*词*等

　　从功能的角度构建网页，将功能放在装饰之前，可能是急需项目的解决方案。采用这种施工方法，成功制作了VALSE和SIDAS两个案例。对于那些没有设计师帮助的前端工程师，以及想要尝试甩掉设计师去做项目的人，不妨试一试。

　　作者署名：王红阳

　　版权声明：免费复制 - 非商业 - 非衍生 - 保留署名 | 知识共享 BY-NC-ND 3.0