网易新闻“讲讲”分享功能的设计与复盘

2003年,网易新闻“跟帖”功能上线,如今日均跟贴数量超过400万。

2018年8月,网易新闻“讲讲”功能上线。

架构&目录:

出于保密需要,文中涉及到的详细数据、细节将会被略去。

什么是讲讲?

“讲讲”是网易新闻2018年8月份上线的基于UGC内容创作与分享的核心功能。至此,网易新闻共有三个核心功能:新闻内容浏览、新闻内容跟帖、讲讲。作为新增功能的讲讲业务范围很广,涉及到原有的基础功能:新闻正文、跟帖、视频、feed流,以及一些全新功能:讲讲发布、讲讲评论(不同于跟帖)、分享卡片等。是网易新闻在算法时代的突围之路。


为什么要做讲讲?

网易讲讲项目的需求与动机,可以从内因与外因两部分概括:

内因

网易新闻在用户印象中最显著的标签是“跟帖区”,而网易从16年前就上线了“跟帖”功能,可以说网易新闻相较于其他新闻平台一直都有着较强的社区化氛围。虽然如今达到了每日生产400万条内容的规模,然而除此以外,网易新闻严重缺乏用户对于内容以及其他用户之间的互动行为。

16年来,网易新闻的跟帖功能依然维持着较低限度的交互

跟帖本身是一种成本很低的轻度交互,因此用户的使用门槛很低,但也有着产生的内容复用率低下的问题——一条优质的跟帖,也许仅是评论区中的一抹亮色而已。即时有再多的“顶”与“回复”,这条内容仍然是被局限在新闻正文后方的评论区中,无法做到更广泛的传播,更遑论二次内容生产。这也就间接导致另外一个结果:网易新闻中轻量内容(资讯)的生产往往只能依靠专业新闻媒体(OGC)与网易号用户(PGC),普通用户(UGC)无法参与其中。

因此讲讲这样的社交化feed功能的诞生,是为了解放普通用户对资讯内容的生产力,同时也会优化用户们使用产品时的互动体验。同时让用户成为表达的主体,形成用户的个人画像,加上个人身份和群体的标签,可以为社区和社交行为打下基础。在产品架构上也保证了对于动态内容容器的支持与拓展性。

外因

2012年今日头条诞生以来,越来越多的新闻资讯类app开始转型算法推荐,在此冲击下,网易新闻单纯的“跟帖社区”功能越来越难以满足用户需求。算法推荐的优势是依据用户浏览行为形成用户画像,并根据其内容偏好推送内容。实现这样的推荐算法需要海量的数据与内容,通常的做法降低PGC门槛或者直接推行UGC内容,带来的显著缺点是内容质量容易下降且不可控。

因此,网易新闻既需要采取变化,学习同类产品以换取用户粘度、留存,但同时又需要维持对内容质量的把控、引导,保持区别于竞品的网易新闻的原有内容优势。因此我们根据原有的社区化运营优势,倡导用户们对新闻内容发声,并分享、传播高质量的用户内容。


预期

网易新闻的愿景,是做一个传播新闻资讯,分享用户观点的社区化平台。作为“社区化设计”的核心功能的讲讲,担负着养成用户感知、推动用户从浏览到分发的转换、沉淀平台内容、增强输出与回流的职责。因此,从设计到复核都将以各场景、各行为的转化率作为主要参考数据。具体数值隐去。


设计

框架

首先,定义“讲讲”功能的核心使用流程是:浏览 → 创作 → 发布 → 浏览/分享。

作为一个成熟产品的新功能,交互行为产生的第一步是让用户对此新功能产生感知,因此“讲讲”的交互设计先从“对于现有场景、页面的改动”开始。主要包括:

  • 首屏tab与导航、
  • 个人主页、
  • “我的”页面、

1.首先是首屏,主要包括顶部tab栏目、底部场景导航。

顶部tab中的“微资讯”入口删去,替换为“讲讲”,点选后可见讲讲内容的信息流内容。

作为“讲讲”功能的主要入口,底部的“讲讲”入口会在用户首次打开新(功能上线)版本的app后,显示一个提醒气泡用于增强用户对此新功能的感知,规则细节见下图。

 

2.个人主页(以网易号为例)

个人主页的改动思路主要是强化“讲讲发布者”的身份辨识,具体做法是:显示特定身份认证信息(与哈姆雷特功能联动,后述),订阅与关注合并(强化用户个人载体),主页默认显示发布的讲讲内容。

3.“我的”页面(以普通用户为例)

主要改动思路是增加“我的讲讲”入口,合并关注与订阅。

 

而讲讲功能交互设计的新增部分主要包括:

  • 核心内容
    • feed卡片
    • 详情页
  • 话题运营
    • “哈姆雷特”
    • 普通主题
  • 发布流程
  • 搜索流程

1.feed卡片与详情页

feed流页面的主要改动是在原有的新闻、视频基础上,新增“讲讲”类别卡片。

详情页(以视频详情页为例)

图片为早期交互说明,“推荐”即现“讲讲”

2.哈姆雷特与主题运营☆☆☆

哈姆雷特是此次讲讲项目中的重点功能,基于“主题/话题运营”设计的内容分发机制。

这个需求产生于一个现象——网易新闻跟帖区内,虽然存在大量优质内容,但由于跟帖基数太大,因此难以进行快速的筛选浏览;其次优质跟帖内容往往独立存在,缺少对应联系用以整理合并;同时,这些优质内容传播难度大,难以跨越对应新闻内容页面本身进行分发传播。为了解决这个问题,我们在规划产品初期将功能定义为“通过运营热点话题,整合平台优质用户与内容统一分发”——是一种类似于内容合集的容器概念。在预设目标中,会实现用户集中在一个或几个话题下进行讨论、发布自己的观点内容,并以话题/主题为维度进行分发。

但是在最早期的灰度测试中(甚至可以叫原型测试,因为产品形态较为简单且测试用户数量较小),我们发现依然会有低质量内容充斥平台的问题。主要原因是:1.部分用户只追求较为浅层的参与感,因此随意灌水发布评论;2.大量用户仅仅因为新鲜感与好奇心,想尝试体验一下新功能而已;3.话题社区下没有形成足够的讨论氛围,部分认真发布内容的用户并不会/不能关注到其他用户的发布内容。

我们从两个思路提出了问题的解决方法:

  1. 从产品、运营的角度,快速消除低质量内容的分发是提高用户的参与门槛——邀请大V、专业人士、优质用户(高分高赞等指标)参与话题讨论,其他用户仅有内容浏览与评论的权限,或发布评论的内容不在广场进行曝光。于此诞生了“100大V”企划,即邀请100位/大量大V入驻平台,参与话题的运营与讨论,并优先曝光他们发布的内容。
  2. 从交互与机制的角度,我提出了给用户“打标签”的方案。即用户可以为自己添加自定义tag,如“95后”、“执业医师”、“资深特斯拉车主”…同时系统也可以对用户进行tag配置,包括专业人士的认证信息,以及针对特定运营的话题下不同的立场作为tag分配给用户。话题运营时优先邀请对应社会属性tag的用户,或是对立立场tag用户(类似辩论的正反双方)并以tag作为内容展示分发的维度。

可以预见,用户在进入自己感兴趣的话题页面下,可以快速浏览到与自己立场相同,有一致观点的发言人,并进行点赞、转发甚至站外分享;同时也会看到与自己看法对立的用户群体,或者是好奇的人群类别(如专业人士等),并产生交互行为的发生。在后来的实际测试中,这个解决方案也以较低的设计成本带来了较高的场景使用率(<发布内容量+pv>/dau)。

最终产品形态如上图所示,从早期单纯作为合辑而存在的形式转变成为了一个观点碰撞的新闻事件讨论平台。而基于其“根据用户tag(属性)分发、浏览”的特征,正好契合“一千个读者眼中就有一千个哈姆雷特”,正是强调了其观点、立场的多样性、丰富性。

3.发布流程 & 4.搜索流程

发布流程如图所示,与目前线上版本差异较大,设计细节略去。

 


评估与总结

在后续的A/B测试、灰度测试中,基于“气泡引导”、“feed流内卡片”带来用户的较强感知,并且“浏览-发布”的转化率得到了较大提升。尤其是内容复用率,部分用户发布的优质讲讲在运营话题下得到了大量的复用并二次生产了很多优质内容,形成了较为良好的内容生产、传播回路。尽管在回流页环节发生过一些意料外的失误,但整体上产品数据与用户体验反馈都达到了我们的预期目标,总体来说此次项目的产品设计部分较为成功有效,并为后续设计工作提供了不少经验。

未完待续…

设计虚拟现实前,如何丈量真实世界?

之前在工作中遇到一个需求,是要将一些直播拍摄的场地以三维模型的形式复原至VR环境中去,于是花了一段时间研究了下三维激光扫描与摄影测量等方法。本文就是以VR设计师的视角对于这些技术的理解与整理介绍,可以结合到一些具体的案例场景给出推荐建议。

首先,做虚拟现实设计的前提是把现实世界把握好。现实世界在我们心目中是怎样的存在往往同时取决于外部世界的客观存在与个人主观认知的影响。但落到通俗的感知层面,就是“这个世界看起来怎样?”的问题。(听、触、闻等其他感知在现阶段可供设计的余裕不大,本文暂不涉及)

在传统3D游戏的美术设计中,玩家最终可见的视觉呈现效果一般是以原画/设定为基准,再由模型师进行模型的搭建、塑造(以及之后的渲染计算)。然而在同样需要3D虚拟场景设计的VR产品团队中,也许就不会需要有特定的原画师了——因为目前的VR产品设计一般更倾向于还原真实世界,而非充满艺术风格的虚拟世界。(在一些游戏中也会有类似情况)这种情况下,“逆向建模”成了最佳选择。


逆向建模,顾名思义就是“反过来建模”。传统的建模思路是:概念→建模→模型;而逆向建模可以概括为:实体→扫描(建模)→模型。

两种方法的最终产物都是三维模型,区别则是前者依据模型师/3D美术的想法进行创作、发挥;后者依据现实世界的实体进行扫描、还原。因此,逆向建模可以理解为“3D拍照”——普通拍照是将现实世界的信息输出成一个二维图像,3D拍照即是输出成一个三维模型。三维扫描与二维拍摄的最大区别之处在于三维扫描需要采集空间深度信息。也就是说,测量现实世界的“三围”数据(也就是获取空间深度信息)是三维扫描/逆向建模的关键。

常见的测量手段有TOF、结构光、双目视觉/摄影测量等。(如下图)


ToF:

ToF全称是Time of Flight。简单地概括它的工作原理就是:在传感器记录光线的同时,还会记录光线的“飞行时间”(Time of Flight)以计算物体到传感器的距离(即空间深度信息)。微软Kinect 2代使用的就是这种技术。

相较于结构光及其他几种技术,ToF在测量空间深度信息时受动态变化的光照强度影响较小(因为其数据来源是光线飞行时间而非光线本身),所以更适合进行动态、即时的测量,这也是kinect 2代改用此项技术的原因之一。(其实最重要的原因是kinect1代使用的结构光技术的来源公司被苹果收购了,这后面会提到:P)但ToF的缺点也很明显,在十几米距离外几乎无效(也就无法利用无人机高空飞行进行大范围的自然环境扫描了),而且分辨率也较低,注定难以真实再现现实世界了。

因此ToF更多的应用于即时、动态的人物动作捕捉等领域,对于玩家/用户的体验更加友好;然而对于VR设计而言,生产力则显得不够。


结构光:

顾名思义,结构光就是将特殊形式的光线(如条纹、点状光)投射至物体表面,通过捕捉光线形变量,来计算物体表面结构。(如下图所示)

原理如上图所示,即通过计算机编程产生正弦条纹,将该正弦条纹通过投影设备投影至被测物,利用相机拍摄条纹受物体调制的弯曲程度,解调该弯曲条纹得到相位,再将相位转化为全场的高度。

相较于“玩家友好”的ToF,结构光显然更适合用在精确、大批量的VR场景环境设计中。结构光扫描可以做到整个场景一次性扫描、录入并得到模型。其精度取决于扫描仪性能与扫描对象的距离。(理论上有效扫描的极限距离有数千米),并且扫描所得的点云数据能够存储不同时期同一空间位置的信息。

其实结构光只是一种扫描技术的原理,是一个很广泛的类别。具体的每种技术方案都各有区别(iPhone X前置的3D摄像头用的也是结构光的一种,该技术源自以色列PrimeSense,也就是为Kinect1代提供技术的那家公司),具体到产品形态就更加种类繁多(从小型手持式设备到大型三维坐标/扫描仪)。这些技术、设备在过去更多的被应用在了GIS、RS等地理、工程测绘领域,所以虽然听起来陌生,但已经是相当成熟的技术了,最近也开始被应用在了VR选房等O2O领域中。(如Matterport服务,下图)


双目视觉测距/摄影测量:

双目视觉测距是利用多视角捕捉到的图像信息进行视察计算来测量距离,摄影测量(photogrammetry)也就是应用这一基本原理的一项技术:通过对测量对象多个不同角度的拍摄,分析多张照片关键点,获取照片关键点在三维空间中的坐标,所以将照片输入至程序即可进行计算模拟出对象的3D结构了。

相较于ToF和结构光,摄影测量不需要特定的扫描硬件,数据输入端只需要若干照片(少则十几张,多则几百张),输出3D模型的质量好坏取决于作为输入源的照片的质量高低(清晰度、光线好坏、拍摄对象的特征点多少等因素)与数量多少,理论上输出模型质量的唯一瓶颈是计算机运算性能。在精度不足的情况下,通常采用zbrush等方法添加模型/纹理的细节。优势在于将每个独立物件建立完整的三维模型,因此可以保证输出场景模型后可以供用户/玩具自由移动位置、视角。。工作流程为:拍照——导入图片至项目——对齐——反复调整——输出结果。

摄影测量法的缺点在于需要的照片必须是外部环绕向同一中心拍摄的(即不能在空间内部向外进行三维重建);由于受可见光影响较大,在测量视觉特征较少的对象(如大面积纯色的平面物体)会有一定误差,同时对拍摄对象的材质也有限制,比如不可以是高反光(镜面)或高透明度(玻璃)。尽管有这些诸多的条件限制,但并不妨碍摄影测量技术在游戏设计中的大量应用。

游戏行业内最著名的摄影测量软件可能要属俄罗斯的Agisoft Photoscan了。在摄影测量、逆向建模这些环节应用photoscan的著名案例比比皆是:《星球大战:前线》(延伸阅读:用3D扫描创造出《星球大战:前线》的世界)、《生化危机7》、《合金装备5》、《神秘海域4》、《伊森卡特的消失》……可见此技术之成熟,除此之外还有RealitvCapture(代表案例有攻壳机动队真人电影)等其他的产品也都用过成功商业案例。

上图是生化危机7的三维扫描拍摄现场,同时架设了大量相机,就是为了同时记录下对象物体各个角度的信息数据,这样可以极大地提高photoscan计算生成的三维模型的质量。

有这种“土豪”的办法,自然也有很“经济实惠”的做法——下图是星球大战:前线的三维扫描拍摄现场。

可以看到,拍摄对象是一个身着军服的假人模特,为了获取它各个角度的信息,肯定是像前面生化危机7那样的海量相机完成得简单粗暴,但这个现场显然没有那么多相机,于是就在模特假人的下方安置了一个转盘——这样可以保证相机停在相同的位置规律的拍摄、记录对象的多角度信息。(题外话:我个人印象中,应该是EA这种美帝大厂更加大手笔一些,没想到扫描设备的规模竟然不如日系的卡表,也是有点出乎意料: P)


除开上述提及的,其实逆向建模还有其他一些大同小异的方法,但核心都是“还原这个世界本来的样子”。本文所写的,也都只是停留在一个初涉VR领域的交互设计师的理解,如果继续深入,还是需要有些计算机视觉等专业知识的积累。既然还是初涉VR,那么就暂且止步吧~

设计迭代版本那么多?怎么管理?

在交互设计师的日常工作中,一定会经常遇到产品迭代带来的设计版本管理问题。无论是产品从1.0进化到1.1、1.2甚至2.0、3.0,抑或是为了上线某功能而进行了三四次交互评审分别对应的设计方案,这些情况下交互设计师往往都需要同时查看、管理多个设计文件。在交互评审或是技术评审时,每当被团队的其他成员问到做出这般设计决策的原因时,在一堆画板,或sketch文件中来回切换实在不是一种优秀的工作方式。

目前现有的设计工具软件对于迭代或版本管理必能没有一个针对性的解决方案,往往都集中在“文件传递”和团队协作编辑上。CHI2018会议上,UW HCDE与Adobe Research联合发表了一篇专注于设计迭代工具的论文(Charrette: Supporting In-Person Discussions around Iterations in User Interface Design, https://dl.acm.org/citation.cfm?id=3174109)

 

目前设计工具主要提供两种设计迭代的方式。

  • 一种是提供明确的,包含视觉、可浏览的编辑序列的设计历史(记录)。这些工具被设计用于记录编辑操作的历史,而不是管理特定的、编排好的设计迭代集合和备选方案及其配套反馈。
  • 另一种方法是版本控制。类似Git的标准工具的主要目标是帮助用户明确地跟踪正在进行的工作版本或迭代。然而,大多数此类版本控制工具专注于如何合并编辑(通常是来自多个协作者)或回复到以前版本之类的任务。(尽管此类工作的确较为常见)

一个更典型的问题是,设计师试图管理一个结构松散的零碎设计集合(如设计文件中的各个画板),这些画板经过多次迭代发展而成。这些迭代经常包含许多并行演进的替代方案。为了方便他们的设计工作和评审会议,设计师经常需要从设计历史的不同角度来查看和参考给定设计的几个迭代或备选方案。这类型的操作在多数需要用户维护整个版本的可视管理工具中非常繁琐。


上述内容就是对论文原文的摘录+介绍了,原作者针对这个问题,提出了一个叫做“Charrette” 的系统,它用于跨产品、工具地向设计师提供迭代版本管理的解决方案。我搜了一下知乎,目前还没有介绍过相关内容,大家感兴趣可以去Adobe的blog查阅了解一下,“Charrette” 系统的具体信息以及论文中实验内容也不在此赘述,想了解的建议去阅读一下原文。

作为一个有过几段“从0到1到不断迭代”经历的见习交互法师,我对于论文中描述的“Charrette” 系统并不看好,主要原因是其仍然停留在“插件化”的解决方法。无论这个系统的最终形态如何(软件or插件),它解决迭代管理问题的思路依然是基于现有产品的基调,增加“快照”(snapshots)并链接至已保存的诸多迭代版本历史记录中。

在我看来这就还是以典型的工程师思维解决问题:

  1. ——发现了迭代管理不便这个问题
  2. ——思考怎样提升迭代管理效率
  3. ——直接添加迭代版本管理功能
  4. ——无法在现有工具中实现/其他原因
  5. ——将迭代版本管理功能削弱成迭代快照管理
  6. ——done!

那怎样才是解决设计迭代管理问题的合理思路呢?我尝试给出一个:

  1. ——发现了迭代管理不便这个问题
  2. ——分析问题出现原因
  3. ——发现根本原因是“互联网产品迭代设计”的普遍化
  4. ——归纳直接原因是现有设计工具原生不支持迭代设计
  5. ——重构设计工具

其实我也是因为读了这篇论文才意识到这个问题——现有的各类设计工具没有原生支持迭代设计解决方案的。无论是Photoshop或是AI、Sketch,其进行作品创作/设计的核心逻辑里是没有时间概念的,有的只是空间概念(多图层、多页面,“蓝湖”等工具的空间概念在于多协作者)。

这里就需要强调一下“迭代设计”与“传统设计”的差异了。PS一张海报、AI画一个icon、Sketch做一个原型甚至是C4D渲染一个动效,都是传统意义上的做一个作品,工作流程会伴随着作品完成而结束。

而迭代设计是没有工作结束的状态的——同样,迭代设计的产品也不会有设计完成的状态的。一款迭代设计的app,用户体验到的设计不是最终的设计,而只是“上线版本”而已;当前进行的工作也只是当前态而已,会因为产品经理提出新的需求而继续发展迭代。因此,一款迭代产品的设计不应该是时间停滞的,每个时期的历史版本与备选方案都是整套迭代设计的组成部分。因此,迭代设计的工具软件最需要的功能应该是时间轴。

不,应该是时间树。

前面已经提到,迭代设计不是单线程渐进式的工作,在各个历史节点上可能存在着多个迭代的版本,而这些版本也都可以继续延伸出去以影响后续版本的设计。因此不但要在设计工具中引入“时间”概念,而且还不能是单一线性的时间轴,应该是多轴线组成的类似树形图的形式。因此我暂时将其称为“时间树”。

可以假想,存在这么一款设计工具软件,它从一个最基础的prototype开始,不断向后发散,定义出多个迭代版本并且能进而发展为多支“迭代线”,每当需要历史版本进行审查、反馈时可以拖动时间轴浏览这个树形图上的所有版本。这将极大程度上地提升了设计师进行迭代设计的效率与整体性。当然,也会给设计工具的定义带来新的难题,如:需要增加方向的定义以区分“时间”属性和“空间”属性甚至是“操作体验”属性。因此对于“时间树”的设想,还需要进一步的深入与细化。

至少可以肯定的是,目前现有的各类设计工具对于迭代设计的支持都很有限,也许是“时间树”,也许另一种形式的“snapshot”,因为无论如何我们都亟需一种更高效的迭代设计管理方案。

[译] 用3D扫描创造出《星球大战:前线》的世界

写在前面:最近因为工作原因开始接触到自动化三维重建技术,发现photoscan在游戏产业内应用不少但鲜有针对具体游戏项目案例的科普文,于是翻译了本文并放出。原作者为NICK LIEVENDAG,3D Scan Expert社区创始人, 阅读原文点击这里。(原文中有不少视频与网页链接此处不便放出,希望读者们去原站点浏览支持。)

 

文/NICK LIEVENDAG,译/Milton Wong

几个月前,我写了一篇帖子,是关于“3D 扫描是如何被用来为《哥谭市》(电视剧)制作视觉特效”的——因为我喜欢3D 扫描,同时又是蝙蝠侠系列的忠实粉丝。然而,还有另外一个故事甚至更加吸引我:星球大战。所以我在等有机会的时候,可以写一个关于3D 扫描技术和遥远的星系相结合的文章。

然后,就在上周,我发现了一个由瑞典游戏开发商DICE(代表游戏:《战地》系列、《镜之边缘》,和最新一代的《星球大战:前线》)撰写的文档。

将这款 “次世代”游戏(对应平台为PS4和XBOX ONE)与其前代作品形成鲜明对比的一点,是《前线》中惊人的视觉效果——尤其是对于星球大战粉丝们而言充满辨识度的那片广阔开放的世界。通过对行星霍斯、塔图因、恩多和萨卢斯非常真实的画面表现,这个游戏是让你自己互动、沉浸于星战宇宙中的最好方式。就像《连线》杂志(Wired)评价的那样:“玩《星球大战:前线》,就像是在看电影一样。”

在我继续介绍之前,让我们通过一张游戏内的截图来看看这意味着什么:(即本文题图)

可以说,上图看起来更像是恩多丛林,而非绝地武士归来。(原文这句话我也不是很理解。。)但开发者是如何让它看起来如此真实的?来自DICE的Keneth Brown 和 Andrew Hamilton 在今年游戏开发者大会(GDC)上带来的一小时长的报告“《星球大战: 前线》和摄影测量艺术”给出了这个问题的答案。

因为报告文档是为开发者准备的,所以它看起来技术性很强,并且涉及到各种编程细节。因此我决定着重介绍一些单纯的摄影测量内容,这样你就可以从中学到一些,并能应用到你那些富有创造性的3D扫描项目。

首先给那些不了解这门技术的读者简单介绍一下:摄影测量(或照片扫描,photogrammetry)是一个现实可行的图像信息捕捉技术,使用常规(2D) 照片和机器算法来生成带有贴图的3D模型。这与使用专用的3D扫描仪(详见《哥谭市》的帖子)相反,在入门级,你可以免费试用移动端的摄影测量APP。在专业层面上,有一些解决方案如Autodesk
ReCap(Reality Capture,我之前评测过) 和 Agisoft PhotoScan(我很快就会评测)。DICE的艺术家们主要使用后者,但也尝试过新的软件方案,如RealtyCapture。

报告中提出的第一个重要的问题是,基于摄影测量技术的3D扫描被用来结合 “传统的” 3D建模技术,以创造所有的资源素材和(游戏)世界。下面你可以看到一些角色道具的3D扫描(来自卢卡斯影业的档案):

这些道具被添加到传统3D角色模型:

但其实摄影测量主要是被用于创造环境素材资源。为此,开发小组去了之前提到的四个星球(萨卢斯星是一个特例,因为它不存在于原版电影中。在这个与《星球大战:前线》艺术总监Dough Chiang的采访中,你可以阅读这个星球的地点位置是如何被选中)的原型拍摄地点。(他们还拍摄了那段旅途的记录短片)

开发小组的工具组件非常简单: 只是佳能6D相机与24毫米镜头,一个三脚架和彩色图表而已。他们主要使用自然光以尽可能地避免投影。在某些情况下,比如冰冻洞穴内,他们也使用了照明设备。

他们细致规划了行程,并预先进行了素材细分,以便弄清楚哪些素材需要一次性完成捕获。由于(野外)摄影测量的工作可能会让你很容易迷路,以及拍摄过量或是不足的照片,因此大量的前期努力使得拍摄工作卓有成效。为了使这项技术能够有效地发挥作用,最最重要的事情是交叠(指记录一个对象的数据需要通过多个不同角度的拍摄相组合——译者注)。这意味着有很多张照片会存在着相同的视觉特征(看起来很像)。在这个项目中开发小组发现,拍摄照片时,从更远的距离来同时覆盖到拍摄对象更多的部分,会更加容易成功。他们还强调了“从所有可能的角度进行拍摄,以避免后期制作过程中过于耗时的润饰”的重要性。

下面的照片是一个例子——恩多星球所需捕获素材的细分:

为了将那些在不同地点拍摄的大量照片转换成可用的游戏素材,团队将经历与以传统方式制作游戏素材相似的阶段,但他们却花费了少得多的时间。在下面,你可以看到使用传统方法为过去的游戏(战地4) 相较于《星球大战:前线》制作素材耗时的管状对比图。

耗时主要的区别在于“高模” 阶段。我猜这一般包括在zbrush或类似软件中做数码精绘的时间。而使用了摄影测量的话,这一阶段主要工作是修饰——这个改变会让团队中的一些设计师因为感觉对创造性的缺失而抓狂。

创建可用的贴图纹理也会花费更少的时间,但仍然是工作流程中最耗时的阶段之一。其中一部分是去除阴影。这非常重要,因为游戏的环境是由游戏引擎即时演算的,所以游戏中的阴影可能在任何地方显示。

第一个去除阴影的技巧是用16位处理并简易地使用在Adobe Photoshop中的RAW相机通道内的特定功能,以去除尽可能多的阴影。然后他们使用了我个人认为非常聪明的技巧: 从3D 数据生成法线贴图,使用Photoshop 的黑白滤镜为法线朝向的不同方向创建遮罩。然后调整这些差异,以创建一个几乎没有阴影的结果。我决定做一个GIF小动画示意:

 

在我结束这个帖子以防止它花掉你们比看完整的技术文稿更多的时间之前,我想展示游戏内一个很cool的(双关语)摄影测量的应用。这可不是一个岩石或树桩,DICE团队利用从当地五金店淘来的东西做了一个AT-AT (你知道的,那些帝国步行机) 的脚,用以制作一个白色(雪地)粉末上的足迹。这是当时被3D捕获的,用来创建一个在游戏中生成足迹的置换贴图。

最后但同样重要的是,开发团队为游戏四大行星创造的摄影测量素材:

我原以为上面这些素材应该只是(游戏所用素材的)一部分,但是报告结尾的问答环节时,团队证实了这的确就是游戏所需的全部摄影测量素材。当然,它们被置入到一个更大的背景环境中去。开发团队的确也运用了激光探测仪扫描一些地方以用作基础地形的建模。此外,他们拍摄了非常非常多的照片用作传统的贴图。例如,树木只在可以转化为具有确定高度的平铺贴图的底部使用了摄影测量。并且一些植被是具有基础几何alpha通道的贴图——同样能够奏效。

为了合并所有的素材,DICE为每个行星创建了非常好看的“Level Construction套件”。显然,最初的想法是让用户易于使用,但最终它只用于内部开发。真可惜,因为就像你可以在下面这个视频(略)看到的一样,它合并摄影测量素材与其余的地形真的非常棒。

把最好的留到最后,这里有一个很好的《星球大战:前线》中各种场景的蒙太奇。伴随着John Williams的星球大战原声音乐,我建议把视频调至1080p 全高清,全屏,并将你的扬声器开到11——但希望是在你将本文分享给好友以及你SNS关注者之后。

占位符文本的可用性研究

如果你经常做PPT,想必对占位符应该会比较熟悉,那么占位符文本又是啥?看看本文题图,知乎(或是其他平台)登录界面中的表单填写框内,那两行灰色的文字就是占位符文本。有没有注意到,不同网站或app的登陆界面上的占位符文本,不但具体文字内容不同,功能类别甚至是背后的交互逻辑都是不一样的。所以占位符文本应该是以怎样的形态存在于UI中呢?目前百度谷歌能找到的相关论文或是规范书很少,之前在我Medium上看到一篇论述此主题的文章,有些小亮点但还存在诸多谬误,所以写下这篇文章供大家参考、交流。

 

所谓占位符(Placeholder),是界面设计中常用到的一种元素,它可以包含具体的功能或是信息的组织结构。用户面对空白的电子表单等界面时,往往会产生不能理解交互方式的“认知摩擦”。占位符的主要作用就是在此类用户界面中占据一定的空间面积,既能调节或控制界面给用户的视觉传达效果,同时又可以实现对用户进行默认的提示、说明或引导等功能。

在用户填写表单的界面中,占位符常常以文本的形式呈现,作为对表单填写栏或选项的补充说明,因此被也称为占位符文本。在不同场景下,占位符文本有着不一样的设计目的与职能,暂且可以从设计目的出发,概括为两大类——

使用占位符文本常见的目的有两大类别:视觉优化、功能优化。

  • 视觉优化角度的具体功能有:

第一 “统一视觉效果”功能——基于占位符文本的表现形式为文本这一特性而实现,可以使界面上的图形元素减少,使文本元素与线框成为界面的主要形式。

第二 “缩短表单(或界面)长度”功能——因为占位符文本可以内置于表单填写框区域内,无需额外添加“标签”(label)元素,可以减少表单填写框区域外的标签文档,从而达到缩短长度的效果。

第三 “精简表单(或界面)结构”功能(与第二点类似)——常见的表单组成元素除了标签外,还有示例文本(为用户填写的数据提供格式上的范例参考)、指令文本(提示用户执行相应操作)等页面元素,但它们往往会以不同层级展现:如“弹出窗口”(Dialog)、“弹出气泡”(Toast)等。使用占位符文本可以降低对这类不同层级、结构的元素的使用频率,界面层级浅的结构访问路径短,一定程度上可以帮助用户对完整路径进行观察学习。

综合上述三点,大致可以概括为对表单界面的视觉元素进行整合,使之视觉传达效果趋于整体化、简洁化。

  • 功能优化角度有四大具体功能:
(这类功能的占位符文本是最常见的,知乎也是如此)

第一 “充当标签(或辅助标签)文本”——在表单填写框区域内的占位符文本充当标签或辅助标签,以说明用户在此处填写的数据类型、名称。

(支付宝的注册界面中,“请输入你的手机号码”这段文本就是一个对用户的指令)

第二 “充当指令文本” ——占位符文本在表单填写框区域内对用户执行的操作给出指令或引导,同时让用户对数据填写的对应区域有了较为快速明确的定位。

第三 “充当帮助文本” 指应用占位符文本在表单填写框区域内就用户填写的数据内容、格式等问题提供帮助与参考,便于让相关表单填写经验不足的用户理解对于数据填写的具体要求。同样是上图支付宝的注册界面,“校验码是6位数字”则是一个帮助文本而非指令文本。

(传统程序中常见的预置占位符文本,“example@example.com”是当前填写字段的范例)

第四 “充当示例文本” 第三点功能的具体化、特殊化案例。在用户无法掌握输入数据的格式时,一个实例文本可以直观地展现格式范例,并让用户在输入框区域内实现对照范例输入。

 

综合上述四点,占位符文本的应用旨在给用户执行数据输入的操作提供更加易用、顺畅的使用流程,简化交互关系,改善体验。因此,占位符文本的设计有必要考虑到产品本身的功能性质,作为一个工具性元素加入产品的整体体验设计。

占位符文本直接作用于表单。表单填写框区域内的占位符文本直接影响到用户填写表单所需数据的流程,这种影响并不直观,但可以体现在用户对于表单信息获取的效率并带来的页面停留时间(Time on Page)以及用户填写数据错误率的变化。缺失或难以理解的功能性占位符文本会导致用户执行填写操作的效率低下,长时间停留于表单界面,甚至会造成诸如“反复修改已填数据”、“填写过程多次中断”等结果。此类现象发生率较高但容易被开发者、设计者忽视,从而破坏整个产品的交互体验。

用户体验设计中,有很重要三点:需求是否被满足、满足需求的效率如何、需求之外的情感。表单填写是一个纯粹的功能性、工具性步骤,是服务于用户达到目标的前期准备工作。没有人(或极少数人)会以填写表单本身为乐趣,将此作为自己使用产品的需求与动力。因此设计者要尽可能地简化这个步骤,用尽可能高效、简洁的方式引导用户去执行预设好的操作(即填写表单)才是优化表单界面用户体验的方法,也就是所谓“最好的工具是用户察觉不到的工具”。

既要做足设计,又要让用户意识不到,这是个充满挑战却又有意思的事情。

占位符文本本质上毕竟只是占位符的一种,起到的根本作用是占据空间位置,直接作用是提供信息。这信息包含诸多种类,例如:位置信息(将不同功能区域进行定位)、数据类型信息(说明该区域内数据的类型)、指令信息(提示或命令用户执行相应操作)等。为了保证信息能够用户有效获取,占位符文本必须要具有足够的视觉刺激,过于浅的占位符文本颜色会导致在屏幕上难以辨认。但是由于表单填写框区域内本应该为空白,因此占位符文本的存在本身就对用户具有一定的视觉刺激与导向,所以需要对其视觉上的刺激程度做好控制。如果使占位符文本的文本颜色设定为黑色(或正文文本的相应颜色),则会与正文内容产生视觉冲突,导致用户将占位符文本错误理解为预设文本,进而影响其对与数据填写区域的理解,降低此阶段交互流程的效率。

前文也提到了,占位符文本具有多重功能,可以表达多种的数据类型,因此表单填写框区域内的占位符文本应该保证功能类型的统一,否则会导致表单界面的信息传递逻辑混乱。例如:“登录邮箱地址”数据填写框区域内的占位符文本设定为“例:xxxx@example.com ”(充当示例文本),“登录密码”数据填写框区域内的占位符文本设定为“请输入密码”(充当指令文本)。这个例子中,两处相关联的表单输入框内置两种不同类别的占位符文本,在面向用户的信息传递环节没有遵循统一的标准规范。这种情况下会导致用户对于表单指令的理解产生偏差,如难以理解“例:xxxx@example.com”此项占位符文本对用户的指令与要求。

此外占位符本身具有“可覆盖”这一特性,即:用户在表单填写框区域内进行数据填写操作时,表单默认会以用户当前填写的数据覆盖原本的占位符文本。这也造成了占位符文本给用户的指令、帮助具有时间局限性——一旦开始输入文本就消失了。因为指令信息一般较短且容易理解,所以受到“时间局限性”的影响较小,但帮助文本(包括示例文本)通常长度较长,内容类别较多,导致在用户填写表格时点击文本框后会使得帮助文本消失,因此对于帮助文本的记忆难度较大。对用户来说,浏览信息要比记忆更容易,理想的设计是用户不用查阅说明书就能清楚该产品的功能并进行正确操作。基于前文所述的“占位符文本具有‘时间局限性’”的特点,在用户输入一个较为陌生的数据类型时,往往会输入了一部分而因为对相关要求、规则的记忆模糊而导致输入操作中断甚至取消,重新回到占位符文本未被用户数据覆盖的情境,再次阅读帮助说明。诸如此类的问题还有很多,但设计师和用户往往都不会太重视,因此至今为止还没有关于占位符文本的交互设计规范存在。

我暂且归纳出的占位符文本的设计应遵循的三项基本原则:易用性、统一性和阶段性。

  • 1)易用性原则,即加强引导作用,降低使用难度。优秀的工具是用户察觉不到的工具,占位符文本的职能是降低用户使用界面的负担而非增加用户额外的关注点。因此,要求设计师在占位符文本的设计过程中了解用户的语言、文化、思维模式,以提高占位符的可理解性。实现“置界面于用户的控制之下”、“减少用户的记忆负担”、“保持界面的一致性”。
  • 2)统一性原则,也可以理解为秩序性。占位符文本的类别、定义、布局甚至是形式上的不统一,都是对界面设计背后的交互逻辑的破坏。既会混淆产品界面信息的传递,进而影响用户执行交互操作的流程;又会破坏用户使用产品时的主观体验感受。
  • 3)阶段性原则。占位符文本不是静止不变的界面设计元素,在用户进行阅读、输入等不同行为的同时,与产品的交互关系也不断随之发生着变化。因此占位符文本在人机交互的过程中也是依各阶段发生变化的。对应用户的不同行为、操作,占位符文本应该表现以不同形式,执行以不同功能,不因位置布局而定义功能,而应该因交互的不同阶段、不同目的来进行具体的功能定义。

【如果你坚持能看到这里我也是很感动了,有什么想法、问题或批评、指正欢迎提出~】