京东火车票项目思考总结

京东火车票项目是一个不断迭代优化的项目。一想到要参与一个 GMV 很大的项目,内心抑制不住的兴奋。随着业务和需求的深入,兴奋感渐渐转变为压力。因为一直忙于完成业务需求,也就没有认真总结和反思存在的问题。借着写博客的机会,对项目进行简单的回顾和总结。 一开始接触项目是对当时存在的一些 bug 进行集中处理优化,对原有组件进行版本更新。然后到车次列表页进行前后端分离的尝试,还有对退改签业务的更新和重构。还有后来的学生票、儿童票丰富了火车票的业务场景。在这个过程中,遇到了形形色色的问题。有的问题很快解决了,有的就会耗费较多的时间精力。我遇到的问题有的是个例的,小概率的,有的可能是很多人都会犯的错误。我希望将一些自己认为有用的东西写出来。 学生票的特殊业务及其带来的问题 1、学生乘车时间为每年的6月1日到9月30日及每年的12月1日到第二年3月31日,可提前30天购买学生票,不能购买学生票的时候,学生票勾选不能点击。 看上去很简单的业务,做起来的时候发现还是不那么简单。因为它并不是简单的数字的比较。首先,要找出学生票可点击的区间范围,具体时间节点及范围如下: 1月1日到3月31日 6月1日到9月30日 12月1日到12月31日 然后,重点来了,出发日期日历范围的控制。正常推算,这个范围就是从当天到30天后结束嘛,但是细想一下,这30天的区间跨度可能会包含了某个时间节点,就是说有可能30天后,学生票不在可购买的范围内。那么,日历的可勾选范围就并不是简单的从当天到30天后,就出现以下如图所示的几种特殊情况。 思路理清晰了,转换为如下代码即可。

2、购买学生票填单页面需要输入学校和优惠区间城市,页面引入了学校和优惠区间城市的相应数据文件,但是学校和城市数据 JS 太大,导致页面第一次加载完成时间超级长,甚至加载到最后,直接失败,整个页面功能基本不能用。 解决方案: 因文件过大而导致的页面加载失败,最直接的解决方案就是缩小文件。 优化第一步:改变数据格式,删除冗余字段名,减小文件大小。具体修改如下图,改完后文件大小缩小了大概300多KB。 本以为这样就万事大吉了, BUT 问题来了,文件还有400多KB,网速稍稍不好的时候,刚进入页面时依旧会加载失败,导致页面功能无法使用。 优化第二步:按需加载。具体方式是,鼠标移动到需要该数据的区域时再请求数据。 这么做表面上看上去是解决问题了,初次进入页面超级快。BUT问题又来了,当鼠标移动到要操作的区域的时候,数据还没加载完了,用户就要操作了,来不及啊! 优化第三步:延时加载。具体操作办法是等待页面其他资源全部加载完毕,再加载学校的数据文件,这样利用用户在做不需要此数据的操作时,加载学校数据文件。如此,来不及加载数据的问题得到缓解,不浪费任何时间加载数据,同时也不影响用户的其他操作。 按照以上三不优化做完后,页面加载过慢问题有了很大的改善。 车次列表页前后端分离重构 起初是后端将数据直接输出到页面,可是有一个很奇葩的问题。就是在IE9下 table 代码段不能有换行,否则页面就会错乱掉。解决方法简单粗暴,后端将页面的换行回车都去掉。这样看似解决了问题,但引发了新的问题。就是 HTML 文件是一大坨难以名状的怪物,维护起来简直想去死。于是提出了前后端分离的实现思路。 后端只输出数据,渲染页面由前端处理。我使用的是 art-template 来进行数据渲染。 当时普通车次列表页和改签车次列表页同时开发。我对接了两个不同的开发同学,他们对业务有不同的理解,于是给出不同的数据结构。可是两个列表页只是业务场景不同, View 层的展示大同小异。最简单的解决方法就是开发同学统一数据结构,那我就只需要维护一套模板来渲染数据了。要不我维护两套渲染模板,这样带来的问题就是之后的维护成本会很高。就在前两种都不满足的情况下,想出了如下图新的解决方案。 数据处理函数,对不同的入口数据进行处理,输出需要的目标数据,我称之为是一种中间件模式。经过这层处理之后,对于后期开发同学数据结构需要变化的情况,只需要对数据处理函数进行修改,确保始终维护一份渲染模板代码。这样代码的稳健性和可维护性就提高了很多。 列表页会有很多个数据接口,有的是基本不会变动的,有的是需要开发人员更新的。将公用并且基本不会变动的接口放在公共接口对象里(前端控制)。可配置接口及可能变化的接口放在页面里,后台开发同学只需要将 HTML 本地开发的文件注释掉就可以了。 在使用 art-template 时出现一个问题,如何循环一个数字长度来显示大量重复控件。需要实现的效果图如下: 对应的数据结构如下图 需要实现的是根据 star 的不同数字展示不同的效果,10、20、30、40、50展示不同数目的星号,25、35、45展示对应的文字信息。

边界容错(undefined、try catch) 一开始约定好,拿到服务器返回的数据,返回了个 […]

大促分会场-模块化设计方法总结

写在前面 在电商的世界,似乎一切时间都可以和购物挂钩,5.20、6.18、11.11、12.12、年货…..;有购物节就要有各种各样的会场进行促销展示;面对越来越细分化的类目会场,作为设计师需要把多达几十个会场一一设计出吗? NO!如何提高设计及后续工作的效率,似乎在工业产品的标准化零件中找到了答案——标准化模块设计 如果将会场比作工业产品,模块即是零件,动线即是图纸;使用不同的模块与动线,即可组成满足不同需求的会场 如何进行会场模块与动线设计?接下来将从模块设计原则、其它设计要求、会场动线设计三个部分进行讲解 一.模块设计原则 从往年多次负责大促分会场的设计实践中,总结出一些模块化设计原则:可变性、可拓展性、丰富性、创新性;其中可变性与可拓展性属于结构化原则,创新性和丰富性属于内容性原则;接下来将逐一介绍遵循这些原则的原因以及如何遵循 part1.可变性原则 模块化设计并不意味着所有会场一成不变,需求总是多种多样的,如何在模块设计下满足需求的多样性,是遵循可变性原则的重要原因。 案例1.不同会场因其自身的需求,所要求放置的类目入口数量不可能完全相同,而在类目入口模块的设计中,如何满足数量的可变性呢?需要我们把握屏幕尺寸、模块最小可接受尺寸、浏览动线、尺寸的规律和融合,然后设计基础组件,需求方可根据不同的基础组件搭建不同数量的的类目入口如下图示:          案例2.单品模块的设计,不同类目要求展示的信息侧重点不同,拿一排一个单品展示样式为例:我们会模块化商品展示尺寸,固定信息可变区域,设计可变信息的基础组件     在可变区域内,考虑信息的布局、尺寸、字号、间距等,在方寸间千变万化,如图示: part2.可拓展性原则 方盘货策略、用户浏览记录、实时库存等都会影响会场各模块的内容展示数量,如何满足因数量变化而形成的会场差异,是模块化设计中考虑可拓展性原则的重要原因 案例1.‘加车商品降价提醒’模块:此模块自动拉取用户加车商品降价记录,因此用户不同看到的内容数量不同,此时的模块设计需要考虑0、1、2、3…数量的变化,同时需要考虑页面布局、模块占用高度等,如下图示:(此时,不使用一排多个竖排版的布局样式,是因为当只有1/2个商品时,布局有缺陷,对数量的兼容性较差)   案例2.优惠券模块:同样是需要考虑数量变化带来的样式不同,如下图示:       案例3.常用的品牌+单品的模块设计,因考虑平铺单品模块较高,采用单品横行滑动的设计,既能拓展单品展示数量,又能较好的控制模块高度,如下图示: Tips:有些模块的设计要同时考虑不同原则的设计要求,就如类目入口的设计需要遵循可变性原则的同时也要遵循可拓展性来满足数量的变化 part3.丰富性原则 需求总是多种多样的,以品牌模块为例,不同的类目有不同的展示需求;我们不能强迫所有会场使用同样的模板,这违背了类目个性;此时需要我们收集类目需求,判断需求的合理性,然后进行样式设计     part4.创新性原则 模块设计并不是延续以往一成不变的,好的模块需要继承,但更需要创新来应对需求的变化;创新并不是天马行空毫无根据的,需要我们在充分了解需求的前提下同时考虑尺寸、间距、大小等天然限制,更需要我们平时素材的积累来寻找灵感     二.其它设计要求 在实际的会场模块设计中,除了要遵循上述四条设计原则,还有一些更细致的设计要求需要我们综合考量 1.挖掘运营实际需求 2.屏幕的天然限制(尺寸、字号、间距、大小等) 3.技术的可实施性 4.用户体验感受 5.视觉氛围呈现 三.会场动线设计 已经讲了很多关于会场标准模块化设计的一些原则和注意事项,此时我们会根据设计输出一份包含各种各样的模块组件库交付给需求方;我们的设计工作完结了吗?当然不是!正如刚开始所提到的:将会场比作工业产品,模块即是零件,动线即是图纸;若没有一份图纸的指引,需求方搭建出的会场页面可能是千奇百怪的,这无疑增加了我们后续评审的工作,同时需求方也可能因为错误的搭建而做无用功;此时我们不仅要输出模块组件,还要给到动线设计示例。 作为设计师如何给出合理的动线设计示例?对于这个问题比较难回答,更多的源于日常工作的经验积累,这里有三条积累途径分享给大家: 1.来自日常各类目促销卖场的设计、评审总结(熟知各类目特性、日常卖场结构与沉淀) 2.来自往年大促设计的经验沉淀(各类目上线后的实际情况、数据分析、效果对比;总结精华,剔除糟粕) 3.来自对竞品的学习(多看、多截屏,分析总结竞品动线优缺点) 最后输出动线示例图,如下图:(一般会给出常用的几条示例)   写在最后 动线设计示例更多是作为参照物存在的,类目还需根据实际需求看待,动线搭建应以简洁高效、清晰明了为核心设计点;更要在各类目搭建完会场后进行逐一的交互评审检查。

旧瓶新酒–谈谈京东机票的新生

时光荏苒岁月如梭,青春一点点地从指缝中流走,蓦然回首,才惊觉进入机票(jipiao.jd.com)这个大家庭已经有一年了。从最初的战战兢兢,怀疑自己是否有能力接下这重任,到如今能坦然面对各种需求。诚然,进步是显而易见的(让我嘚瑟一会儿…)。 列表页查询速度优化 接手机票的第一个需求就是列表页查询速度优化,当时是中间临时接手的,所以并没有参与优化方案的制定,只是做了实施这一步,当然,很佩服方案制定人员,因为这不仅为机票速度的提升提供了很好的解决方案,也给我带来了不小的挑战。 下面来说说这厉害的方案。 方案的确定 先说说机票的背景,京东机票的数据是由很多个商家提供,但是商家之间返回数据的速度参差不齐,快的2s,慢的十多秒也是有的。因此,开发同事需要等所有商家的数据返回以后再进行比价等逻辑,筛选出前台展示的数据,再进行渲染。相信大家明白了,这会导致响应时间会非常慢,用户会长时间地处于等待中,结果就是,耗尽了耐心,拂袖而去。 (大家可以通过下图感受一下,不要怀疑自己的眼睛,请耐心等待。。。)   当下的第一要务就是要提高响应速度,让等待属于过去式。经过后端开发的评估,响应时间无法真的缩短,因为商家的返回速度是不可控的,因此,这个重担落到了前端,既然不能真的缩短时间,那我们就假装缩短了吧。是的,假装。 用户对于响应时间的评判无非是什么时候能看到页面上有内容展示,那么我们就尽快地展示出内容就行啦! 方案的实现 方案就是这样的:前端分多次请求后端数据,后端在得到第一次请求以后就去获取商家数据,然后尽快地返回已获得的数据给前端,前端将拿到的数据立即展示出来。这样迭代多次,在无碍于用户操作的同时,逐步地完成了全部数据的展示。 下面是这个过程的流程图: 主干形成,我们又描绘了一些枝叶,为此增加了可爱的loading动画,小飞机飞过,在各种操作的时候都加上了缓动效果等等,让用户操作起来自然流畅一气呵成。 在此过程中,作为首次接手交互场景较复杂,涉及众多业务逻辑的单页面应用,其中付出了不少汗水和努力,收获颇丰。 迭代 接下来的一年里,又进行了多次需求迭代,体验也越来越好,不过在迭代过程中也遇到了一些问题: 首先,在新增需求的时候会涉及到前后端双方上线,但是这两方上线之间肯定有时间差,因此需要做好兼容处理,既要保证先上线的一方不影响线上环境,还要做到另一方上线后新的功能得以实现。相信作为前端开发,这个问题大家都会遇到。 其次,机票作为一个大型的项目,虽然单从列表页来看只有一个页面,但是后台会划分为很多个项目需求对其进行开发。这会造成一个问题:多个需求同时并行,在前端这边修改的是同一个文件,那么这对做好各需求之间的隔离和兼容就有很高的要求,我也总结了以下几个方法: 新增的模块,CSS中使用新的命名来区分,JS中对其操作要首先判断此模块是否存在 修改现有模块,如果对一个模块的细节做了很多调整,那么在这个模块的最外层加上区分的选择器,样式和JS都写在这个作为区分的选择器上 如果有些改动无法用上面两种方法解决,那么就需要上线一版新的文件,由开发修改引用路径,这种方式是简单的,但是不到万不得已还是不要用,因为这会引起其他问题(同时进行的几个项目,有些需要修改路径,有些不需要,在后端开发合并代码的时候也会有迷惑) 还有一点就是要注意,一些特殊的逻辑可能会引起后续修改时不断地改动或新增,因此一定要注意这些细节不能错过 首页性能优化 首页的优化始于团队内部对于首屏时间的优化安排。 由于历史原因,机票业务并未采用前后端分离方式开发,因此页面的交互JS都是由后台开发编写,相比于前端,后端更注重的是功能的实现,因此,会对性能有些影响。 来看看优化前的一些数据: 全部资源有81个请求,共2446.52kb,本地测速是1.82秒。 因为未做任何懒加载,所以首屏时间和全部资源加载时间基本一致,1.82秒作为公司的网络测速,普通用户体验到的可能远远不及这个。 资源占比图 由上面的图可以看出,图片和JS占比将近99%,因此优化主要从这两部分入手: 优化方式: JS部分 将旧版的组件全部替换 重构JS代码,去除冗余部分 延迟加载搜索框逻辑(将搜索框逻辑抽出为单独的文件,在用户鼠标滑过搜索框区域的时候再加载并初始化) CSS部分 去除旧版文件及冗余代码 优化合并压缩CSS文件,搜索组件CSS用户触发后加载 图片部分 合并零散的icon为一张图标 协助运营优化广告图片大小 优化后的结果: 全部资源有53个请求,共1731.98kb (总加载时间取决于用户的操作,在此没有参考意义)。 首屏数据: 通过优化后的首屏时间可以看出,效果还是比较显著的。 重构(首页及填单页) 由于首页并未做彻底的改版,因此优化JS主要是对已有代码进行了重构和整理。填单页对优惠券部分的JS进行了重构优化,因此也总结了一些重构的步骤: 作为用户熟悉页面各个地方的功能和效果 通过阅读现有代码来了解整体的业务逻辑和设计,尤其注意在页面上直观看不到的一些功能 梳理功能与逻辑,确保自己理解透彻,必要时可以画出UML示意图 分解并重组代码,在这过程中要注意每做一步改动,在页面上进行一次测试,保证每次改动不会影响原有逻辑 重构是一门很深的学问,能用到很多方法追求极致,我这里做的比较浅,只是初步的尝试了一下重构的方法。但对后续填单页的部分重构也起到了基础作用。 版本升级 […]

类目场馆建设设计方法-交互研究思路总结

Part 1:全流程交互设计–馆区建设 在馆区建设与版本迭代中,交互在其中扮演着重要的角色;一个全流程的馆区交互设计应该综合考虑:运营策略分析、竞品分析、数据分析、目标用户分析、平台特性分析等,下面将针对这五大模块做具体介绍 1.1 运营策略分析 需求方提出品类馆区新建或改版时,会输出他们未来对馆区的运营规划策略,作为类目运营侧的他们,是比我们对产品及目标用户更加熟悉的,而对运营策略的分析,能够让我们快速了解到产品及目标用户的特性,以及需求方对新建或改版馆区的需求,交互设计不仅仅要考虑用户及产品需求,更要考虑商业需求,只有在符合商业需求的前提下才能创造价值 分析方向:   案例讲解:   1.2 竞品分析 俗话说:知己知彼百战不殆,了解与分析竞争对手的产品,模拟用户流程,列出竞品或者自己产品的优势与不足,分析与挖掘用户的潜在与深度需求,对于自身馆区的建设有着重要作用 分析方向:(一般选择分析2~4个竞品) 案例讲解: 1.3 数据分析 对于数据的收集和研究,我们可以从中提取有用信息和形成结论,在馆区的建设或改版中帮助我们做出判断,以便采取适当的交互规划 分析方向:   案例讲解: 从上述数据中可以看出,品类宫格区(首屏展示)的UV占7成,说明手Q美妆目标用户大多数是目的性购买用户,新馆的设计应该重点考虑这部分用户群体 GMV有近9成来自于品类宫格和品牌区,虽然品牌的UV占比不高,但成交转化最好,侧面说明目标用户有较高的品牌偏好性,馆区中可重点展现和运营 单品的UV与GMV占比虽然不高,但UV价值较高,在馆区建设中可考虑根据美妆的特性,多纬度的展示单品 1.4 目标用户分析 在之前的设计环节,我们对需求方、竞争对手、数据表现做了充分分析,但在设计中还有个更重要的角色需要我们着重考虑,就是‘目标用户’;对目标用户的分析能够让我们认识和了解用户,帮助我们在产品的设计环节中做出综合的判断。(当没有相关的用研报告时,选择身边的同事或朋友做简单的访谈来了解目标用户的心理特征与购物偏好不失为一个好办法) 分析方向: 案例讲解: 网购美妆用户群体以女性(80%)用户为主,年龄主要分布在20-39岁的用户群,馆区运营上应更多的迎合这部分用户的偏好 护肤品与化妆品的购买模式都是以‘搜索+挑选’的模式为主,目的性购买较强     从图表中可以看出:用户最关注的痛点是‘品牌’,其次是安全、年龄等;可以看出,用户一旦找到适合自己的品牌后,很难会更换品牌,补充性的购物中,多数是根据品牌来选择购物,在美妆护肤的购物中,品牌偏好占据很大的比重 从调研分析可知:目标用户购买目的性强,多为缺少型购物;‘典型场景(补充、换季)、促销优惠、他人推荐’为有效的购买驱动力 因此,馆区的动线设计上应导购性强,满足目的性用户快速挑选;同时也要包含以季节、主题包装、推荐等纬度来激发用户浏览购买 1.5 平台与平台用户特性分析 每个平台都有其独特的平台特性与目标群体,这就像房子的地基一样,即使之前的分析调研做的再详实完善,如果没有地基的支持,房子终究会坍塌。因此我们要充分考虑平台特性与平台群体特征,在馆区搭建中综合运用,才能使得馆区更好的服务用户创造价值 分析方向: 涉及内部数据,此处将不再上案例。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。 小结: 到这里,一个全流程新建类目馆区的前期交互分析已经相当完善,或许有遗漏或偏差,但意在和大家分享讨论学习 Part 2:快速搭建交互设计–馆区建设 在类目场馆的建设中,根据各馆区实际的数据表现与经验总结,从中总结出馆区建设的共性,而这些共性往往是馆区的重要组成部分;在缺少数据与用研支持、排期紧张的情况下,可以根据经验总结,结合运营规划与竞品分析快速搭建出馆区交互 馆区交互模版:   Part 3:馆区中的细节交互策略 交互中一些细节上的小小改动就有可能带来意想不到的效果,我们应该勇于尝试,在交互细节中处处体现小心机 案例展示: 总结 在近半年的类目场馆交互设计中,了解很多、学习很多、进步很多,总结出的一些方法和建议也许有些比较片面,但对于自己而言都是一种工作和学习的沉淀,后续将会更多的在版本迭代中进行交互策略的探索和学习,不足之处,欢迎多多吐槽~   […]

智能生活从京东开始 – 智能云项目小结

京东智能云是“京东+”智能硬件计划旗下的落地产品,主要是为在京东销售的智能硬件提供统一的一站式应用。主要连接业务包括“智能家居”“健康生活”“汽车服务”“云空间”四大部分。项目完成后,在京东销售的智能产品均可使用这一个“超级APP”来管理操作。在接手需求时,项目组已经有一个与开发同时进行的“自主版本”,JDC的版本会作为二期版本,所以无论从工期到功能构想都还是有很大的空间的。

© 2017 JDC. All Rights Reserved.