fir.im 前端工程师出品 — 重新定义前端

前端撸界面,后端撸数据。这两年前端开发者在迅速增长,前端逐渐向着多终端方向发展。11 月 7 日,SegmentFault Developer Day 北京前端专场吸引了 200 多位开发者到场参加, fir.im 的前端工程师有幸参与了此次分享,同时百度EFE、去哪儿、奇虎360 的前端大牛们也携干货来到现场做了技术交流。

fir.im 首席前端工程师郭建在 D-day 分享议题为《重新定义前端》。当界面设计到足够精美后,前端工程师作为产品经理、设计及后端的桥梁,如何更好地完成团队之间的协作,并通过不同的途径培养对产品、设计及后端的感知。此外,郭老师还分享了一些关于 fir.im 的前端实践。

下面是演讲实录:

fir.im

郭建:大家好我是郭建,我今天讲的主题是重新定义前端。我们在谈论前端的时候,我们大多数是在讨论技术。虽然我们项目的开发越来越大。然后我们又得寻找各种各样的框架和工具开发效率。大家看到现在很多新的技术和框架,可能很难做选择。但是还能找到很多好用的支援和工具,但是今天技术不是我分享的重点。

fir.im

我觉得前端真正的困扰是在团队协作这一块的问题。比如说我们公司的团队协作。前端在等设计师设计稿,产品经理在改需求,后端的同事也正在等。因为前后端需求是一个趋势嘛,所以就可能多了一个流程,这链条过程中就发现接口的资源不对。然后团队中肯定会有测试人员。经历上面的那些问题,就会导致前端背黑锅的,设计师就会说你的效果跟设计图不一样。然后跟产品经理也达不到一致,产品经理会认为你这功能需要这么长的时间。然后左下角大家觉得谁会说,后端。

fir.im

fir.im

我想可能大多数公司都会遇到这样的问题,而且不一定只有前端,可能移动端的同事都会碰到。这时候我去问我们的设计师,说他想象中的前端是什么样?他说我希望前端能把设计稿完整还原出来就行。产品经理的要求非常简单,只要说能跟产品经理沟通就行。我觉得现场如果有产品经理的话,可能也有这同感吧。这个还是后端的同事。 大家看一下这页的标题我在说他们到底想要怎么样。

fir.im

这个就是我今天的主题了。

fir.im

fir.im

从这一张图里面我们能看出来前端在整个产品开发的流程当中,它是一个中心,一方面它需要兼顾产品经理,因为产品经理可能从用户、老板等那里收到需求,我们可能要根据PM的原形稿来做很多原形。另一方面还有设计师,前端工程是和设计师是联系非常紧密的。另一个就是后端工程师了。看这张就说明前端在团队协作里面是非常重要的。但是现在的这种工作模式可能没有非常好的发挥出前端的价值来,这个是下一张图。跟上一张图的区别大家可以看出来。

fir.im

我所的箭头换了一个方向,这个是什么意思呢?

在跟产品经理进行沟通的时候,我觉得前端应该来主导原形设计。有一个事实是:牛逼的产品经理毕竟是少数,不是每一个产品经理都能把原形做的非常细致。有一个非常简单但是特别重要的东西就是异常流,就是在一个产品运行的过程中有很多不是正常流程运行的。它有很多异常流。但是图形里面都没有体现出来,最终导致我在开发时需要重新沟通和重新设计。

大家都知道工程师是最擅长协议,可能没有人比工程师了解哪些地方需要处理异常流。而且经验丰富的前端工程师,听到需求的时候他可能非常快在脑建立一个页面结构和交互样式。所以我觉得如果由前端工程师来主导原形图的话会有很多好处,另一点就是前端跟后端的变化,如果前端工程师了解需求并且画出原形图的话,那其实在画出原形图的时候,他就已经有一个大致的接口。我这演讲时间比较短,如果有任何问题大家随时沟通。

这种模式前端被动的主动模式不是哪一个环节受限制。而且前端开发与设计紧密联系, 可能会导致很多的问题。但是如果前端来主导原形设计的话,它可能直接影响到相关后期的 维护。我觉得很多前端开发经验的同事可能都会有这个同感。如果能完全理解这种方式的话, 这个就是我今天另一个概念,就是前端驱动开发,这可能是比较大的话题。

fir.im

我给大家举一个例子吧。这个是今年 8 月份的一次改版。

fir.im

首先介绍一下 fir.im 它提供了很多附加功能,这是我们今年改版的。大家看一下这是 fir.im 的应用后台管理页面,这个地方就是导航条了。 这个黄色按纽是上传应用的按纽。蓝色是应用列表的按纽,还有一些 step 功能都会摆放在这里。这个版本大家可以看一下,大家对这版本有什么意见吗?可能它美观但是不太实用,哪里不实用呢?我总结了以下几点。就是首先这是一个应用的详情页面,而且在这版本里面 是没有独立的应用列表页面,这是一个非常严重的问题。因为没有页面的话,用户在整 个网站操作流程就是一个断裂的过程,体验完全不流畅。

然后还有刚才说的上传应用和应用列表的功能,没有文字提示只是一个图表。这对很多新用户来说很难接受,而且有可能根本找不到这功能。还有另一个 step,没有主次都摆在这个位置。而且这个 step 里面是有 7 个,他们都可以简化。当时我们改版完了后设计师就休假了。当时发现这些问题以后,我们也没有办法,我们只能工程师自己来重新设计了一个,这个是改版后的样子。

fir.im

这个大家可以理解它就是一个原形图。首先就是加了一个非常重要的应用列表页,增加了一些筛选功能、查询功能。还有在这个地方,这个地方就是每一个应用 kat,在这地方因为我是前端工程师,我跟我们的后端工程师就会有冲突,应用列表里面是没有这些信息,后端的功能相应就会增加。还有像这地方一个应用合并的功能,我们会增加一个标识,这个地方也需要偶尔增加下后端的工作量。还有用户头像那边下拉的改动,进入这个页面是详情页面,我们同时将应用信息拆分了一下。

fir.im

还有应用详情列表导航,这里可以很方便地返回应用列表页面,我觉得导航是非常重要的一部分,它能给用户传达很多信息。比如说网站结构还有当前所在的页面、各个页面的上下级关系等等。我认为设计良好的导航,能够让用户很容易在某个页面的时候找到他想去的地方。

至于这版本列表和应用信息拆分。我有一个理念是这样的,如果我在使用这产品就会有一个主要的操作对象,比如说百度网盘或者网盘内的 APP ,我操作的对象就是管理那些文件。我们当时做 fir 新版重新设计的过程中,我们在想,用户在使用我们这产品,他们主要操作对象是什么?最终我们认为是这版本列表。因为其他的功能像那些“应用信息功能”,还有“设置、消息”等都属于设置功能。所以我们把这版本信息拆分了出来,虽然不太美观,但是首先解决了不好用的问题。在这次优化工作以后,我们发现前端驱动开发的好处。我们还是在一直探索,当然会遇到很多问题。

fir.im

fir.im

首先就是跟设计师的冲突,程序员和设计师他们的思维模式是不一样。实际上这个不论是程序员还是设计师,每一个设计师设计的风格都不一样。比较幸运的是,我们在跟设计师长时间合作工作中,会有一些帮助工程师和设计师很好协作的技巧,但是这需要很多付出。这些我可以在后面讲。产生更多的是产品经理的冲突。跟产品经理的冲突,我觉得没有一个非常好的办法,但是不管是什么办法,多沟通、多交流是能够解决问题的。另一个就是跟后端的冲突,还有就是我自己遇到的一些问题。我在公司内部分享这理念的时候,有同事产生疑虑,前端本来工作很重,现在还要兼顾产品设计的工作。大家认真思考一下,为什么前端的工作量会非常重。我觉得有一部分原因就是团队协作低效导致,如果前端发挥自身的能力我觉得这个现状会大大的改善。

fir.im

前端驱动开发的好处有很多,我简单列几点:

第一点:降低沟通成本

可能在一开始 的时候我们收到需求,收到一些需求文档的时候,我们如果非常理解这些需求,我们非常快 做成原形,甚至做出一个上线的版本。

第二点:需求量产出的偏差

我们在后期可能需求变动的时候,整个过程是无痛的。

第三点:提升员工的成就感和归宿感

对于具体要怎么做呢? 我这边列了几点:

fir.im

第一点就是前端工程师首先要强大自身。因为自身实力是基础。这样才能在团队协作的时候不至于卡壳,而且非常快的实现功能。

另一点要学设计。程序员懂设计很重要,如果程序员懂一些设计的基本原则就能更好的跟设计师沟通理解设计师的设计心理。

还有,多思考产品吧。多看多思考同类型和不同类型的产品,去锻炼自己的产品思维,帮助自己更快的理解产品和老板的需求。

当然还需要后端的知识。学习后端知识可能会帮助你在后端交流的时候更流畅,而且能使一些前端,就是学习到一些新的概念,因为前端项目架构也是非常重要的。前面几位嘉宾也都讲到了。

最后会有一个必要的条 件,就是要有一个好的团队。因为如果管理者不信任你的工程师,而且工程师没有一些自由 的话,这个理念是根本实行不起来。

fir.im
fir.im

另外我再给大家分享一个另外文章的。这是青云前端工程师 PPT,我的主题跟她的非常相似。青云到现在为止一直没有设计师,他们所有的产品设计功能都是他们自己在做。大家有兴趣可以下载她的 PPT。

fir.im

就是说首先题目是与产品紧 密,前端与后端、设计是联系非常紧密,然后现在 WEB 产品越来越复杂,前端开发任务与 紧密的设计师沟通和合作。大公司工作职责划分是比较严格,但是这种划分非常严格就谋杀了工程师的创造力和想象力,而且工程师对自己的产品缺乏成就感。

fir.im


以上是 fir.im 首席前端工程师 SegmentFault Developer Day 北京前端专场的技术分享,如果对原PPT感兴趣,请点击这里。希望对你有用:)

fir.im

fir.im - Meng

尺度中蕴含本质