Li Yishan [ write words ]

公司周年庆视频

上个月初接到同事邀请,参加了公司周年庆视频的摄制工作,从筹备、拍摄到剪辑完成约 2 周时间。这也是我第一次有专门花时间去思考脚本和剪辑和视频作品。途中因为受 Youtube 上众多 vlog 作者的「蛊惑」,用 slog3 摄制的素材但没有可靠的调色能力来统一色调,导致最后成片的许多片段的颜色并未能够很好地还原或统一。但毕竟是观看人数最多的一支视频作品(约1000人会场),下一支还不知会是什么时候呢。

相关数据

  • 设备:索尼α6300
  • 镜头:16-50
  • 剪辑:Final Cut Pro X

观看地址 http://www.bilibili.com/video/av11684318/

一份来自 2016 年的推荐清单

去年写了篇《一份来自 2015 年的推荐清单》,今年继续做个记录。

总体来看,今年因为个人生活和工作等方面的原因,图书电影音乐这几类文化活动的记录,相比以往几年都显得更少了。与之相反的是在工作中遇到和解决的问题也在逐渐积累,由此获得的经验倒是在分辨网络中一篇篇似是而非的文章上起到不少作用。另外年前往家里添置了一台娱乐终端PS4,品玩到游戏这个第九艺术的多款巅峰之作,动人之处所带来的情感冲击不怯于一场电影带来的相似体验。

同样,今年也在豆瓣上维护了一个2016同名豆列,可以移步浏览或相互关注:豆列2016

影视

星际迷航:超越星辰,09年新版的三部星际迷航,这一部最打动我,开场描述星舰上的日常生活及长期航行所带来的困惑,立意高出其它科幻作品一大截,将尚未到来的生活与现实生活描绘成同样具有的孤独、无趣和与自己相安共处的样子,找准了现代人所共有的普通性焦虑,故事的末尾也为接下来的作品再次出发奠定了基础。

毒枭,欲罢不能,印象深刻,从此开始追 Netflix。

我不是潘金莲,圆形画幅迷人,影片不同阶段的画幅更迭与剧情配合得很巧妙。故事则基本按原著小说走向,为方便叙事做了些关键点题要素的删改,倒也可以理解。但原著里那种更令人无法言说的荒诞也无法避免地减弱了一些。

图书

今年没怎么看完一整本书,在看着的推荐 Ken Follet 的《巨人的陨落》。另外还有买来收藏一直没拆的中文完全版《海伯利安》,快十年前那套只出了前两本就没声的科幻巨作终告完结。

音乐

《周杰伦的床边故事》,周杰伦,今年听过最久的一张专辑,也不过两周多一些。这张比上一张丰富,也精彩得多。当年有新砖就一定年度前三,我认为这个局面在接下来的五年还不会有什么改变。

Light the Sky,Grace VanderWaal,单曲,Google Year in Review 2016 的背景歌曲,歌词出奇地好,小姑娘的歌唱表现又将歌词所蕴含的寓意提升了一些高度,12岁的年纪,未来可期。

踏血寻梅原声,丁可,踏血寻梅还没看过,但给电影制作原声的丁可真心推荐一下。可能很多人不喜欢丁可在原声里使用的人声,但是没有这样的声音,曲子所营造出的氛围至少减去三分一。

游戏

泰坦陨落2,增加了单人剧情的泰坦陨落2,好于今年推出的包括使命召唤13,战地1在内的其它同类型射击游戏。单人关卡的设计令人赞叹,每一章节都有引导得恰到好处的游戏机制教学和实战过程。可惜卖得不好。

看门狗2,3A五星大作,现代语境下的日常英雄故事。很多人认为看门狗2的剧情平淡如水,多半是因为他们多半没有意识到网络时代中的权力获取与个人自由之间的博弈正是如此悄无声息。

文明6,在每年惯例性地吐槽甘地的间歇中,著名的“再来一回合”游戏今年迎来了第6作,游戏机制相比前作有较大变动,但能让人不由自主的一回合一回合玩下去的特性,还依旧点缀着这款游戏。

应用

LICEcap,Windows/MacOS 双平台GIF录屏软件,今年陆续地给公司多位伙伴推荐这款应用,收获大量好评,界面近似于无,但功能足够好用,明年继续推荐给可能会用得上的小伙伴们。

豆瓣,今年是用豆瓣的第十一年,希望接下来也能一直用下去 :)

Google Calendar,今年开始使用谷歌日历纪录每日纪录,收获非常大,从前半年做周报到后半年方便自己撰写阅读总结,以及今年在移动端新加入的循环项目等,帮助我养成了一些好习惯。

服务

墨刀,继去年之后再次推荐墨刀,这一年的墨刀进步很快,同时满足了易用性和速度两方面的交互原型在线服务,国内没有其它差不多的选择了,而墨刀也开始向海外市场拓展。规划中的原型市场和 Sketch 结合令人非常期待。

Treehouse,一个线上编程教学社区,Treehouse 的教学视频制作非常精良,讲师讲课的节奏也把握得很好,课程与练习的比重调配得令人获得成就感的同时,也有信心继续学习下去。一个不算问题的问题是订阅费用略贵。

Coursera,去年底到今年在 Coursera 上几乎完成了交互设计的专项课程,从用户访谈到需求分析,从故事板绘制到使用R语言筛选分析数据,每门课程都体会到了学习的乐趣。由于时间紧张未完成的两门课程计划在17年中旬前拿下。

Kindle Unlimited,KU刚上线时正好促销,立即就开了一年,订阅式无限期阅读的套餐让许多有点儿兴趣但又不会想买,也不会想跑老远图书馆借入的书籍得以被翻阅了一阵。有的确实不值一看,有的倒随即入了纸本,从这个角度看KU还是挺有帮助的。

2016就要过去了,我已准备好了去迎接2017。

Readfeed 这款年度应用应该是有设计不足的地方

Google Play 月初时推送了由编辑评选的年度应用,出于对没见过的新应用的好奇心,接连下载了好些个看似都非常有趣的应用,其中一款叫做 Readfeed 的书架类 App 顺手就标记了几本读过和正在读的书。

没错,这款应用和 豆瓣App 里的读书板块有些类似,同样包括图书搜索(可以通过扫描ISBN检索图书),标记想读,在读和读过的书籍,可以关注其它用户的阅读动态,也可以在书籍条目下添加讨论、提问,或是留下评论。

整个 App 的使用流程都没什么大的差错,除了用户实在是有些少这种不能算是缺点的不足,毕竟做为一个偏向于标记和信息查询用途的 App,能在基础功能上做到最好就挺好了。

但恰好是在个人页面上的“在读”和“读过”标签下,我看到的一个可以算是当前版本下 Readfeed 最大的一个缺陷 —— 进度条。

标记为“在读”的书籍阅读进度都是0%,而标记为“已读”的书籍阅读进度都是100%。

中间的99%去哪里了?

从应用FAQ看,Readfeed 的开发者还在争取能够在应用里直觉阅读书籍,但现阶段还是“still working on it”的进度。于是可以进一步地设想出,在开发者为这款应用进行的远景规划中,是能够和 Kindle 一样提供书籍阅读进度指示的,但现在没做好,所以只在两个终端状态列表中展示0%和100%这样非此即彼的进度条。

可功能还没跟上,阅读进度条这样算是和现有应用脱节甚远的功能点,还是应该规划进后期版本,而不是直接发布并留下或许不止我一个的满头雾水的用户吧。

写到这里时看了下豆瓣App,会发现豆瓣读书、音乐和电影这三大功能做得真是非常好。也希望 Readfeed 能够持续迭代,变成开发者所希望它变成的样子。

与现实保持一致的功能设计

前两周有朋友请教了个问题,一款允许商家入驻的外卖型应用,商家设置可配送区域的功能应该如何优化。提供了若干思路之后自告奋勇地表示要将这个问题写一写,没注意一不小心就过去了一个多月。今天抽空说一下。

需求的出发点是现在外卖应用很常见的“送货范围”功能:商家设定可配送范围后,由用户选购商品时的定位,确认店铺是否能够为其提供服务。如今定位都属于 App 的基础功能,判断买家的位置不算难点,需求的重点也就变成了如何帮助商家准确地设定送货范围。

三种不同情形

通常来说,商家确认配送范围的类型有以上图示的几种类型。一是理想状态下通过设定半径来确认可配送的范围。第二种单向与第三种的随机设定,则是考虑到了现实限制的设定方式,因为如下图般规划一圈圈的城市实在数量不多。

亚利桑那州某城郊区域 by Christoph Gielen

事实上,现在商家设置送货范围的功能已经有非常成熟的解决方案,如美团商家后台,可以实现以街道为分割线,精确地对各街道交割出的区域设置送货范围,以符合现实生活习惯。早前类似的实现方式在一些地产交易应用上见到过,但区域边界辨识得相对更模糊一些。

不过这次遇到的情况,恰好是只能通过设定半径的方式来确认多级配送范围。

由于多级配送范围的设置,对于不同的距离还将匹配阶梯式定价。因此所导致的问题是,如何在技术受限的情况下设计合适的交互,去帮助商家进行配置,而仍然能够符合商家已经形成的心智模型。

初版方案的设计是在一个页面上,放置开放性的三个范围输入框,商家需要顺序填入逐渐增加的半径,来确认配送范围。这个方案需要考虑的几个地方,一是如何向商家明确填入的半径范围需要依次递增,二是向商家明确递增的顺序是上下左右中的哪一种排列。

开放性的输入框,商家大几率会尝试输入1-5-3、5-3-1这样的顺序,与理想状态下的范围递增(如1-3-5)有不小差距,如果贸然报错,必定会影响商家使用服务的情绪与积极性。稳妥一些的做法是,在确认输入位数和小数点位数的前提下,不判断输入的顺序,转而为商家输入的任意三个数值输出递增的排序供商家确认,以此规范并“教育”商家在后续设置时可以如何操作。

另一种可行的方案是拆分设定范围的步骤,每次仅输入一个数值,商家在这个过程中能够潜在地接受需要按顺序逐级递增范围的设定方式,同时在程序设置上也可以为后续的输入内容设定限制数值,避免出现顺序颠倒的情形。

通过对两种形式中辅助图形和 UI 提示文本的综合考虑,最后是确认了在初版方案的基础上再进行界面优化,通过指引和文本框输入限制来规范商家的输入行为。具体效果还得抽空实际用一下那款 App 才有所了解。

经过若干周的间断思考,我现在认为更符合商家心智模型的设定方式,可能会是以对话为基础,并封装可包装为“人工智能”的简化板机器学习系统。在这样的功能配置下,还能推出诸如“秘书助手”之类的定制服务,对于商家来说,相比有规有矩的格式化界面,对话式配置或许还多了一些能够被感知的温度。

隐藏在对话式UI下的设定

扯得有些远,希望自己在日常工作中所作的判断都可以在满足用户需求的基础上,尽可能地超出用户所想,而又不显突兀。

今天被自己项目的一句提示文案给绊倒

今早代理商群里突然对活动允许单个用户抢购次数提出疑问,印象中已有大半年没遇到类似反馈了,特别是此次疑问还直接@了我,希望我能对某个关键页面上的一个文本输入框旁边的提示文案做出详细说明。

先说下代理商和项目之间的关系,早前代理商是原部分销售伙伴单独成立公司承包项目销售权的,在上半年参与的几次代理商沟通会中,能了解到代理商希望运营及产品能够帮助其完成与公司约定的销售成绩,但因为种种原因部分反馈未能得到解决。年中周年庆后,代理商制度有逐渐被收拢至公司统一管理的趋势,这若干月下来收到的反馈也没有以往这么频繁。

今早被抛给我的这个问题,是关于商家希望限制买家抢购活动次数的一个设置项目,理想状态下,控制好买家抢购次数能够为商家带来最大化的收益(更多人购买),其次也能够规避第三方平台的监控风险(避免惩罚)。

今年因为三月份的一次市场整体变动,项目现行的商业模式,及同行业的其它大玩家,实际收到的限制是在不断增长中的,由此也多少影响商家在第三方平台的利益。

此次代理商应该是认为某张关键页面上的提示文案,与产品实际运行的规则不一致,而导致商家被第三方平台处理,以至于商家为了规避风险,降低了发布抢购活动的意愿。

对于代理商在群内的请求,我查看了需求管理系统上14年至今的相关调整,并结合线上的提示文案本身作出了解释。未料因此激起一波接一波的抱怨声 —— 我给出的产品解释,在实践中,与之前提到的理想状态恰好是相反的。

由于解释产品设置时的态度较坚定,导致区内疑惑、抱怨、责备和嘲讽的声音没有停息的意思。期间我反复确认了需求文档的描述,以及多次产品需求变更的日志,均无法做出令代理商满意的结果。

直到终于忙出手来,实际也是负责进行答疑的运营同事出来,确认了线上规则,同时我也从开发同事那确认了线上代码的实际运作逻辑,才算是终于解决了问题。

实际线上运作的规则与机制,与理想状态无异。但与代理商和商家一样,我对页面上一句提示文案的理解实际上是有偏差的。当时也同样有代理商反馈认为该提示并不能很好地说明实际规则,同时文末链接跳转至帮助中心的超链接,还居然是错的……

最后以自己为解释错误而道歉,然后确认调整方案来结束了这次沟通。给当天的工作增加了优先更改出错的超链接,同时让运营参考着修订帮助中心文案的工作,以尽可能地避免再次出现同样的情况。

事后重新翻看了需求文档,对自己做了些反省:

  1. 不完全熟悉运营规则,被质疑时临时查阅文档以至于出现理解错误。
  2. 在不了解真实情况下强势答疑,形成了自己不够专业的形象。
  3. 阅读文档有疏漏,实际规则在14年底即确认并执行至今。

在之后的工作会尽力杜绝类似事件发生。特别是在整体外部环境遇冷的情况下,各合作方的神经紧绷,也经不起这样的折腾。

国庆前让开发同事在内网搭建的资料库需要开始补充资料方便随时查阅了。