与JDReact的第一次亲密接触 ——加油卡项目总结

JDReact 平台是在 Facebook ReactNative 开源框架基础上,进行了深度二次开发和功能扩展。不仅打通了 Android/iOS/Web 三端平台,而且对京东移动端基础业务能力进行了 SDK 级别的封装,提供了统一、易于开发的 API 。基于以上种种优势,加油卡壳牌业务决定使用 JDReact 技术进行开发。 由于这是我们团队首次使用 JDReact ,在开发过程中遇到了很多问题:不熟悉 JDReact 提供的 API 、如何调用后台数据接口?怎样切换测试、预发环境?开发完后怎样打包?如何上线?等等每个流程都不熟悉。因此,在完成项目之后,很想做一个总结,从前期准备到最终项目上线的整个流程做一个分享,希望能为初次使用 JDReact 的同事有所帮助!如有错误,还请多多指教! 1 前期准备 1.1 项目背景 加油卡壳牌业务是京东APP中的一个项目,可以从首页的「充值缴费」入口进去,如下视频演示: 1.2 项目环境配置 1.2.1 开发分支以及文件结构 初始项目中只包含一个 dev 分支,最后打包 APP 时会从该分支中抽取代码,所以我们新建了一个 trunk 分支,平时在该分支上进行开发,最后打包 APP 的时候再切换到 dev 分支,合并代码。 对于文件结构,如上图所示,其中 Navigation.js 设置页面路由信息,以及打开项目时进入的默认页面;pages 文件夹下存放项目的每个页面代码;images 存放项目开发中使用到的图片;components 文件夹下存放页面中用到的各个组件。 1.2.2 安装依赖环境 按照 JDReact 团队给出的安装依赖环境的步骤,当执行 npm start […]

“猜你喜欢”设计总结

‘猜你喜欢’当然它还有很多词汇可以形容,比如:为您推荐、为您精选…;经常在移动端购物的剁手一族们肯定都不会陌生;它似乎无孔不入般的存在于我们浏览的各种页面中作为长尾内容进行向用户补充推荐。我们在浏览时可能并不会细想其背后的逻辑是什么?这样设计的原因是什么?但仔细观察就会发现,虽然它们都有共同的名字‘猜你喜欢’,但在不同的运用场景下,其设计与推荐逻辑存在很大的差异化。 本文将从设计师的角度出发,全面而细致的介绍‘猜你喜欢’内容设计的思考与总结。首先,先来介绍一下什么是长尾 一、什么是长尾: 长尾(The Long Tail)这一概念是由Chris Anderson在2004年十月的“长尾” 一文中最早提出,用来描述诸如亚马逊和Netflix之类网站的商业和经济模式。 长尾理论是网络时代兴起的一种新理论,当商品的销售成本急剧降低时,几乎任何以前看似需求极低的产品,只要有卖,都会有人买。这些需求和销量不高的产品所占据的共同市场份额,可以和主流产品的市场份额相比,甚至更大 二、设计‘猜你喜欢’的原因: 简单了解长尾的含义后,可以清晰的知道移动电商在页面中要加入长尾设计(猜你喜欢)的原因:利用互联网移动端页面无限长的框架进行更多货品的曝光来留住剩余未跳转流量进行商品售卖来实现价值最大化 三、‘猜你喜欢’常见的内容形式: 猜你喜欢的推荐逻辑多以用户历史浏览记录或已购买记录进行推荐,而单品推荐更加贴近触达用户;因此,单品是经常运用到的展示形式,后续讲到的关于如何设计猜你喜欢也是以单品为例。同时,随着推荐逻辑的逐渐完善,为了丰富产品内容以及满足用户多维度需求,逐渐增加了关键词、促销活动、品牌、资讯等内容形式,通常以穿插的形式展示在单品列表中 四、如何设计‘猜你喜欢’: ‘猜你喜欢’涉及的后台技术为BI推荐(实现模型),即将现有的用户数据进行有效整合,快速准确的提供决策依据,帮助产品做出明智的内容呈现,这里将不在多做介绍延展;主要从界面设计(表现模型)、及用户分析(心理模型)这两方面出发进行分析。 在移动端购物APP界面中,运用猜你喜欢的场景大致有如下页面:首页、搜索结果页、商品详情页、购物车页、个人中心页、购买成功页、订单详情页、物流详情页、大促页面等场景。接下来,将分场景介绍在不同页面下如何设计‘猜你喜欢’。 4.1首页: 是最重要的运用场景,如京东、淘宝、严选等的首页都是以猜你喜欢作为长尾展示。用户在浏览首页时,多以无目的闲逛为主,当用户未在重点活动或栏目入口处点击跳走,此时进入长尾内容区‘猜你喜欢’,如何留住用户的脚步是其重点;因此首页‘猜你喜欢’的推荐逻辑多以用户历史浏览记录来向用户推荐,以此来激发用户的潜在遗忘需求。 随着首页猜你喜欢运用场景的完善,后续可以单品推荐为主,增加关键词、品牌、促销活动、内容资讯、店铺等内容的穿插,既能丰富内容推荐维度,又能满足不同维度偏好的用户在闲逛时激发其潜在需求 在设计首页猜你喜欢单品样式时,也从最初由图片、标题、价格三种元素组成的基础样式,逐渐演变新增了功能按钮:看相似/不喜欢/加车、推荐理由、标签、标识等的展示。对于这方面的具体设计将在后面详细讲到 4.2搜索结果页: 搜索是用户在移动端购物使用的重要场景,此时用户目的明确,但不排除所输入词汇系统不可整体识别而出现缺省页的情况;或者,筛选出的结果太少等情况的发生。为避免这两种情况的发生,往往会通过猜你喜欢的形式,识别用户所输词汇的部分字段进行推荐,或者历史浏览记录向用户进行推荐。 4.3商品详情页: 用户在浏览商详页时,此时目的较为明确:对此商品有较高兴趣或需求;在此场景下,若用户未能进行直接购买的行为,如何让用户在此场景需求下继续逛下去是其重点;因此商详页‘猜你喜欢’的推荐逻辑多以相似商品或排行榜形式来向用户推荐,以此来补充用户对比较、筛选场景的需求。 商品详情页包含商品基础信息介绍(图片/价格/促销/店家等)、评价、图文详情等,页面篇幅较长;此时,很难像首页一样把猜你喜欢作为长尾进行展示处理。原因有两点:1.在海量商品面前,用户更多是通过基础信息项来锁定商品,在多数情况下很难浏览到页面靠下的位置,若还作为长尾展示,很难进行模块的曝光;2.此场景下的猜你喜欢满足了用户对此类商品比较筛选的需求,在初期商品筛选中,与图文详情相比对用户意义更大。 因此,对商详页猜你喜欢的设计,往往会固定模块高度放在商品基础信息(图片/价格/促销/店家等)之后,图文详情之前进行展示。常用形式为:一排三个展示两排,可滑动拓展的形式解决因限制模块高度而造成的商品曝光数量受限的问题。这里的单品样式较为简单,多以图片、标题、价格三种元素组合而成。 4.4购物车页: 购物车页属于功能型页面,用户多数是查看已加车商品或选择商品进行支付,是进行支付环节的前一步,以目的性浏览为主;如何提升下单率是其重点;因此购物车‘猜你喜欢’的推荐逻辑多以加车记录来向用户推荐,以此来满足用户对比筛选的需求。表现形式如:购物车有XXX的人还在对比;购买XXX商品的人还买了。 4.4个人中心页: 与购物车页一样属于功能型页面,是用户相关信息整合页,以目的性浏览为主。此页面‘猜你喜欢’的作用是以补充内容,长尾展示为用户曝光商品为主,推荐逻辑多以用户历史浏览记录来向用户推荐。 4.6售后环节:购买完成页、订单详情页、物流详情页 售后环节的购买成功页/订单详情页/物流详情页与个人中心页面一样,是用户相关信息整合页,以目的性浏览为主。其猜你喜欢的作用是:补充内容,长尾展示为用户曝光商品;推荐逻辑可以此订单商品的连带商品向用户推荐,挖掘其潜在需求。 4.7大促页面:主会场、分会场等 大促页面是猜你喜欢运用的另一重要场景;因大促页面内容较多,页面篇幅也较长,猜你喜欢主要作为补充内容进行长尾展示;推荐逻辑多以用户历史浏览记录+会场属性来向用户推荐。因本身大促页面设计及促销信息繁杂,此时猜你喜欢的样式设计趋向简单更容易释放用户的浏览压力,因此样式多以图片、标题、价格、看相似等基础元素组合而成,以一排两个或三个的形式进行展示。 五、‘猜你喜欢’组件化设计: 在众多场景中都有猜你喜欢的涉及,为了提高设计、开发的工作效率,以及用户体验的一致性,规范猜你喜欢单品样式,进行组件化设计是一个很好的方法。目前猜你喜欢的单品模块可以归纳为七个组件,分别为: 1.商品图片:占据最大位置的组件,也是用户关注的首要元素 2.商品标题:有一行两行标题的区别,但猜你喜欢通常使用两行标题来展示更多的信息 3.商品价格:核心组件,有单价格和双价格展示之分 4.标签:分为大促标签、腰带标签、日常促销标签三种样式,一个单品可同时出现这三种标签,因此信息传递的层次性是设计的关注重点 5.标识:如自营、全球购、沃尔玛、京东精选等表明商品从属的标识,一般只展示一种标识 6.操作功能区:如看相似、加车功能按钮等 7.业务拓展区:如推荐理由的文案描述,同时支持链接填写 当一个单品同时出现上述七个组件时,如何使信息传递具有层次性,是设计重点;同时也要考虑不同单品展示不同组件对页面框架造成的影响:如图片、商品标题、商品价格组成基础单品架构,而其余组件的设计应该在不改变单品基础架构的前提下进行设计,这样才能使样式更具有普适性。 六、思考:猜你喜欢是否能够作为独立的产品进行展示? 讲到此刻,相信大家都有个疑问:猜你喜欢是否能够作为独立的页面场景进行展示呢?天猫APP2017年6月发布新版,可以清楚的看到首页框架发生了极大的改变:除保留一排icon、banner、两个品牌入口外,其余内容以猜你喜欢单品的形式进行承载,频道/活动入口穿插至单品中;可以看出此次改版以简化框架,重猜你喜欢的形式进行展示为主。但在不久的10月发布了与6月相比变化较大的首页改版:前两屏不仅增加了有关天猫直营的天猫超市/生鲜、进口、魅力惠等频道入口,还增加了品牌维度的入口曝光,最大的改动是猜你喜欢变成了切类目TAB的形式展示,默认TAB为精选(原猜你喜欢的内容) 我们无法拿到6月改版后的数据变化,但可以大胆猜测10月改版的原因:1.6月轻入口重猜你喜欢的形式,无法使重点栏目得到充分的流量曝光;2.由于各电商平台的数据壁垒,无法精确推测用户行为,使猜你喜欢的内容推荐无法精准的集中用户     笔者认为:就目前的市场环境与技术发展,猜你喜欢并不适合作为独立的页面场景进行展示 写在最后的话: 以上都是关于猜你喜欢的个人设计思考与总结,希望能帮到看完全文的你;可能会有一些缺点和不足,欢迎一起讨论,互相学习,共同进步。

《京保养》基于Vue+Vuex的单页面应用实践

接到《京保养》项目需求,了解到是移动端项目,运用于微信公众号及京东 APP 。通过与后端研发沟通,后端将提供所有的数据展示接口,这样最终商定使用前后端分离技术,而作为前端这边就非常适合选择基于 webpack + Vue 的单页面应用来实现。 前期组内也有基于单页面应用的项目总结,他们的总结的确让我在本项目中少走了很多弯路,但是不同的项目又遇到了不同的新问题,本文将会介绍我所遇到的新问题及解决方案。 感兴趣的同学可以通过以下两个入口先去体验下京保养应用,然后回来接着看文章: 微信公众号搜索“京东汽车用品” – 关注公众号 – 菜单栏“京保养”,见图1; 京东 APP – 我的 – 我的爱车 – 京保养,见图2。 图1 图2 如果你在 APP 中找不到“我的爱车”入口,你得先在京东 APP – 我的 – 设置 – 添加档案 – 我的爱车 – 绑定自己的爱车,然后才会有入口。 为什么要使用 Vuex 初拟技术选型,项目开始了,而开发过程中发现,项目中有不同的表单视图需要大量数据的共享。而仅使用单页面的路由来传参并不能满足需求,因为数据量过大,导致路由传参过于复杂。如此,项目中引进 Vuex 技术来实现数据共享。 拿项目中需要数据共享的地方举例 —— 绑定车辆模块。先来看下该模块的操作流程: 绑定车辆页面填写车牌号码; 填写车系,包含选择品牌、选择车系、选择年款; 回到了绑定车辆页面继续填写车辆绑定信息。 如果上字描述还不清楚,我也录了个小视频,点击查看交互流程: 可以看到这几个步骤中已经有多个视图的跳转了,但最终目的是将绑定车辆的信息填写完整。每一次跳转都需要将已经操作过的页面交互数据(比如:车牌号、车系信息、电话号码等)记录下来,最后回填到绑定车辆页面。这些数据如果没有一个可以由多个视图都能取得的地方存储,绑定车辆的信息永远也填写不完整,此时 Vuex 就可以派上了用场。 Vuex 的使用 Vuex 的具体使用,有几个核心概念: state —— 定义存储状态; getter —— 对数据进行过滤; mutation —— 更改 Vuex 的 […]

京东火车票项目思考总结

京东火车票项目是一个不断迭代优化的项目。一想到要参与一个 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.来自对竞品的学习(多看、多截屏,分析总结竞品动线优缺点) 最后输出动线示例图,如下图:(一般会给出常用的几条示例)   写在最后 动线设计示例更多是作为参照物存在的,类目还需根据实际需求看待,动线搭建应以简洁高效、清晰明了为核心设计点;更要在各类目搭建完会场后进行逐一的交互评审检查。

© 2017 JDC. All Rights Reserved.