[B·G – 13] Bangumi 番组计划的条目详情页初构与反思

这里就不给Bangumi(后简称Bgm)作介绍了。之前有想给Bgm做个概念App,实际并不轻松,再加上本来的工作累也就不敢再占用自己稀薄的业余时间了。所以现在重新开始Blog时打算从小处着手。

虽然App里的一页最多也没多少内容,但为了对比最初想法与落地之间的历程,我决定把这些本不用出现的那些文字也记录下来。同时我也深知自己单人能力有限,所以一并附上反思,毕竟我更期望团队合作的力量。

前言

出发点:现有的App的未完善导致redesign职业病犯了;恰好Bgm的条目页信息和层级足够复杂,值得一试。当然了,很大的原因还是自己会经常使用。虽然2018年2月官方API刚出来,但是之前就有一大串App坑了,详见,感谢他们的付出。

接触程度:虽然2012年就注册了但是使用没有现在这么重度。日志功能以及一些wiki相关功能是没怎么碰过但了解一些。一些非常琐细的功能(例如Dollars)也是没有体验过。用过onAir客户端。

需求点:如果是整个App的话,基本还是以条目为中心构建UGC分发的老一套架构而已,因为标签系统也只是从标记操作中关联条目而已。然后像是小组和天窗联盟等版块独立出来。尽可能满足网页用户的需求下,在App上以较好(?)的视觉呈现。自己较为喜好的优先级大致为 书影音等标记 > 日志 > 其他。

这次只是条目详情页的话,主要目标是梳理PC端的信息,在竖屏形式下简化罗列信息。以更偏向单页应用的使用场景去重新构建一套各个信息板块之间更为平行的交互方式。

观察与解构

这次就拿 JOJO的奇妙冒险 黄金之风 这个动画条目来做例子吧。其实动画、书籍、音乐、游戏等条目模板之间会有所区别,但基本大同小异,可以分为:

  • 原标题
  • 封面(多比例)
  • 以中文名开头的条目详情(staff)信息(导航- 制作人员)
  • 条目内进度(导航- 章节)
  • 条目简介
  • 大家将 XXX 标注为(TAG)
  • 收藏盒(标记交互与分数展示)
  • 角色介绍(导航- 角色)
  • 关联条目
  • 条目评论(实际上会归为用户日志)(导航- 评论)
  • 讨论版(导航- 讨论版)
  • 吐槽箱(导航- 吐槽)
  • 推荐本条目的目录
  • 谁看过这部动画(标题文案不太准,其实意思是最近标记的log)

以上部分版块可在拥有独立url的导航栏中打开查看全部信息,表明了其优先级相对较高的一点。整理之后,便可以开始思考几个原型Points了。

  • 网页里的收藏盒是包含了标记和评分,这里肯定要把评分分离出来单独放置以更加突出视觉比重;
  • 对于分离后的标记按钮自己私心是挺喜欢FAB样式的(但实际设计中FAB并不适合);
  • Bgm没有提供存储条目图片/视频的功能,所以封面图作为第一非文字信息视觉来源,而且尺寸不限,所以想留出一定空间放置顶部,增强访问印象;
  • 条目简介的话肯定会自带一个折叠(更多/收起),然后与TAG联动展示(说实话我不太喜欢用户驱动TAG,看过Bgm网站内部也有人吐槽这个功能,于是打算后面暂时取消这个TAG关联)。
  • Bgm的评分会与吐槽箱相关联,而评论(日志)本身没有评分,讨论版也是,都是条目的相关内容。三者相同点一是带有时间因素,二是都会对第一次浏览条目产生影响,这里打算对齐合并为动态。这个改动比较大,也是后期想出来的,所以会做一下对比。
  • 说道各个版块的平行性,也无需做到极限。本质上还是有优先级之分。我在之前的一篇文章中也提到了,我比较偏好把更多的自由交给用户,所以也会采用那个自定义排序。
  • 整体的话像是角色介绍、评论、讨论版、目录相关等版块,给出 > 更多入口;
  • 动态的展示幅度最大,但也并不是全加载,一般只加载最近的几(十几)条就好了,然后再给出更多入口。这样顺序基本依照网页排布,也不会太陌生,大概。

另外,Bgm目前的网页结构已经超过五年时间没有大动干戈了,所以这里还需要总结一些必不可少的点(特色/老用户习惯等)以渗透到新的设计当中:

  • 分数与排名(重点)
  • Staff 信息(包括原作、监督等)
  • 章节评论
  • 评论数标识(+xxx)
  • 吐槽版(大量评价信息)
  • 条目/人物之间的关联和跳转
  • ……

视觉决策

当交互与视觉都是一个人的时候,低保真交互似乎显得「有些多余」。在小团队「敏捷」开发过程中,上述信息架构与视觉的考虑几乎是平行的(指新产品),那么此时从低保真交互稿到高保真反倒没有直接高保真效率直接,但这也并不是100%的高保真,该单色/文案填充的地方还是会填充。

视觉决策也很直接,就是考虑自己要做出什么样式风格的App。这里面会充斥着许多形容词,比如简洁、干净、清新、顺滑等等,而这些 adj. 大都是属于结果一方,更具象的元素才是起步,比如白色、线条、阴影等。但这不代表没有意义,相反这对于后续设计过程来说意义非凡。

“…and what we cannot talk about we must pass over in silence.” 本文以详细的设计叙述为主但关于这点我暂时不想表达(一般实际工作中的话,关于这点最好的传达方法还是找一个类似范例)。所以这里直接从一些设计决策关键点开始:

  • 浮动的载体(卡片);可记忆滚动位置;
  • 尽量不用线条,采用更明显的空间间隔;
  • 尽量不使用厚重的高阴影突出元素;
  • 8pt已经踩了不少坑,这次以4pt为基础单位,虽然大多时候还是8pt原则;
  • 圆角,更多的空间;
  • 对于标题性质文字实行字距优化;
  • HSB (356, 51, 100) (#FF7C86) 作为辅助色;灰度系作为主题色;
  • 字号的对比
  • 响应式
  • ……

开 始 了

点此查看原图

首先要吐槽的便是苹果官方的sketch资源并没有适配XR和XS,所以像是状态栏各个图标的位置以及Home Indicator尺寸都不对,图中的部分是我根据实际截图添加上去的。

整体顺序是 头部信息 – 收藏状态 – 集数 – 简介与角色信息 – 评分 – 动态(NEW)- 关联条目 – 收藏目录 – 排序按钮。其中动态是一个新的模块,后面再详细展开讲讲。

头部

头部封面比例等高,并留下了一些拓展空间,以Bgm现状来说宽度比高度大太多的几乎没有,基本都是竖向矩形或者正方形(专辑)。下面是各种封面兼容度测试:

分数那里主要是字体比较难于寻找合适的。整个App氛围与德系字体有些不搭,自带的pingfang又毫无生气,futura类的高升部显得很不稳定牢靠,于是暂时选择一款不是那么矮大紧(Medium/Bold下的Counter不是太小)的 Gotham 作为临时决定,对比如下:

整个头部原本想做个转换动效,但实际这种转换并没什么用途,因为考虑了一下后放弃了下拉转换,而是把信息置顶,类似下方这种:

全图后面会有展示

绿色是代表当前收藏状态,这个后面也会详细说。原案动图也放出来吧,几分钟做的也没怎么细究:

收藏状态

收藏状态是这个页面里比较重要的一个,涉及到想看、看过、在看、搁置、抛弃五种状态。为了使用户一眼就可以看到自己标记过的状态,这里挑选了五种颜色和图标:

这里图标的灵感来自于播放器按钮,虽然有偏线性有偏填充,但一是这五种状态是不会同时存在的,二是如果在看和抛弃的图标再粗一点的话便会夺走右边文字的主导权,相反剩下三种则会因为差异性与图标相异。Bgm的收藏状态支持保存当前吐槽和评星,有些番剧条目的章节也有不同篇章,所以也会有下面这些特殊状态:

下方是未收藏状态和下拉状态的改变:

右边本应是底部的FAB改成了浮动类似的卡片的载体,没有滑动指示器(那个gray bar),交互动作只是TAP就可以了。左边的未收藏状态按钮我自己也不满意(五种颜色其实也不太满意),但是继续调下去只会浪费更多的时间。下方是收藏状态的编辑:

上方的文字会根据上面五种颜色替换,滑动评星,以及带有字数限制的吐槽。右边是键盘弹出后的样式,因为比较少见所以总觉的实现起来会比较麻烦。妥协后的样式大概就是面积变大(甚至全屏),这里也不再画出。为了防止与点击空白位置回收键盘的交互冲突,这里的弹框只有点击保存才会离开这个界面。这里面其实还应该塞进去一个取消操作这也是我的疏漏

在当前的收藏样式与交互形成之前,因为总体样式没有确定下来,所以诞生了一些其他奇怪的效果,我整理了一下大致如下图所示:

方案一诞生于没有载体缩小内容宽度时的稿件,本意是做成滑动,下方小字来解释当前观看章节以及总集数。但正如以往第一印象靠不住一样,这种结构很大程度上无法满足许多需求,例如明显地看到一共多少集,SP/OVA篇怎么安排等,不可置否的是这里面确实也包含了许多状态;方案二则是更偏于随想之作,原意是放置到底部的一个旋转罗盘式选择器,同样承受了方案一的种种缺点,并且会占用不小的底部空间;方案三稍微回归了下传统进度条,因为集数的数量与bar的长度有时会不合比例,所以采用了类似统计图中的省略效果,但结果来看完全是多余。后续方案比较接近现在的了,为满足上述需求做了些更改,抛弃白色背景也是为了更突出一些。方案四是现在网页样式的复刻版,是考虑不周的产物,现在留下来服务于「处于在看状态的条目」以及提供章节详情的入口(后面统一放出)。

章节进度

下方的一串数字仅作为进度展示使用。这里只清楚地展示两行半,意为「下方依然有内容需要点击查看」的意思。整体展示的行数是根据当前看到的集数决定的(虽然不能手动下滚)。单个章节总共存在三个状态:

对比原网站这里简化了几个更为复杂的状态(已播放抛弃、已播放想看),统一归到未看过状态里。遗憾的是点击载体也只是会进入到详细的章节列表这里,然后在单个章节的评论页里进行标记。显然这很复杂,需要跨过两个层级操作,这是本次失败的设计之一——虽然小众但是没有完全兼容这种需求,导致后续的思路紊乱。

如果有可能的话,我会再考察一下是否应该分开条目标记和章节标记。

简介与角色

个人先入为主的观念是番剧条目的简介和角色介绍属于同一性质的,所以这里放在了一起,展开后的载体也是同一页面。对于移动端来说,除了现在的横向布局外,其他布局基本空间效率低下(苦恼)。这里就不放图对比了,明显的一点是,图中角色区域的高度是放不下第三个角色的。

这个向下的箭头是新引入的标识,代表查看更多/More的意思。虽然比较隐晦但经过我对Bgmer的观察TA们应该会理解的。同时这会引出另一个问题,为什么上面两个载体没有使用这种标识呢?收藏状态是有个向下箭头作为隐喻,章节进度则是展示和入口功能,这点上和收藏状态无异,和其他载体与区别的便是展示信息的百分比了,以「进度」为关键词而言,配合上方算是展示完全了,也就无需标识占用更多空间了。

标签

上面说过这一版暂时不考虑标签,但在初版时还是考虑过的。因为这些标签的性质比较像主观评价出发的词语表达——也就是弹幕,所以之前考虑了这种样式:

说实话这种形式我还挺喜欢的,虽然里面需要考虑的东西也不少,比如TAG词数的多少与弹幕密度、循环、速度、关闭交互、详细入口、空状态等。既有特色,又可以良好地承接内容,再有机会的话我会更加认真考虑一下。

分数

分数这里把现有的柱形图精简了一下,数字都是和分数采用Gotham Medium。下方是大写的分数、票数和排名。没有把这块直接放在最上面是因为头部已经有分数和排名了,这里属于更为详细的完整展示。点进去的话进入的应该是下方「谁看这部动画」的后续页面,即现在的「wishes?/collections?/doings?/on_hold?/dropped?」页面。

这里还有一个问题是与有关于品牌方面的(虽然一直不温不火),原本条目评分左边会有一个小电视代表分数的五个阶段:

虽然已经把它们矢量化了,但是没找到什么合适的地方加进去,这在最初的时候相当苦恼(颜色、图形契合度啊什么的),于是直接放弃了,BAD。或许还应该有更符合Bgm形象的东西可以加进去的……

动态

动态这里属于改动比较大的一块,首先关于是把原本(网页左下角)不起眼的五组数据提了上来,并且数据是实时的(像twitter那样实时变化),这样可以更直接体现一部番剧在Bgm的欢迎程度。这里有两种常见场景:一是新番播出带来的数据变化冲击;二是针对旧番的数据补足,想一想你突然发现自己正在补的冷门番也有另外几个人标记在看是不是很欣慰,同时像是一些抛弃数据比较多的也可以勾起你想去看看具体评论的欲望……上下箭头则是类似「通知红点」一样的功能,只在一天第一次打开这个页面时存在。

下面的「谁看过这部动画」(文案会随着种类而变)按钮是详细到个体收藏状态的入口,同时在视觉上也有分隔开下方大量内容的作用。为了不引导用户去点击这个按钮而失去下方主要内容的注意力,不得已采用了灰色。

「全部、吐槽、评价、讨论」分别以时间为顺序排布着,这种timeline结构的做法并不是第一次思考得出的结论,这里放出之前的作为对比:

左边的三块要脑补成一竖排的情况,即吐槽、评价和讨论分开排布。使用自定义顺序时,谁在评分下方谁就会和评分「粘合」在一起,按照用户自己的喜好来方便地评估一个番剧。右边则是分别展开的页面,没什么好说的。

首先个人对于动态的看法是不确定的(虽然是自己想的),动态的好处是可以有效提高评价和讨论的曝光,但结构没有之前那么清晰。回想一下这种分开与结合的情况还是很常见的,微信的公众号就是一个例子(还是以前分开时候的舒服)。

另外动态这里我把代表评论数的「+ 数字」的标识变为常规的评论回复图标加上数字的形式,毕竟「+ 数字」还是有相当一定门槛的(可代表的含义太多了),之后如果加了👍赞数的数字,会更容易混淆在一起的。

关联与目录

这两处基本和原本网站没什么区别,自然也不是改动的重点,不细说了。

在最后面会有一个调整卡片顺序的按钮,就是上面提到的自定义各个载体的位置。

组件是和标记收藏那里一套的,所以右上角也会随机出现伪春菜。当时还有构想把伪春菜的随机台词搬过来,调试一番后便放弃,只能在消息提醒那里做文章了。

存在于原网站右下角

关于排序还有一点是,那张图过于原型化了。原本页面每个载体几乎是没有标题的,这里突然冒出来一些四字词语会有些不知所措。更好的方法可以是扩大对话框然后放上去一些辅助说明甚至对应的卡片预览图。

其他的二级页面

还有两张基本无变化就不发了

这几张二级页面图都没有返回键,取而代之的是放置在顶部的条目头部信息(缩减版),点击区域返回,功能一样,同时比较具体的展示出下方信息的所在条目。或者点击右上的「收起」符号也可以返回到条目主页。至于过渡动效,由于页面之间的差距性还是不小的,所以对内容的位移比较难控制,低成本的话只是载体的微动效就可以达到一定期待了。

下拉的时候会有所改变,一是头部那里占用空间太多了,而是载体之间都是浅阴影,叠加起来层次感不足。所以会变为正常顶部标题栏,上面也有提到:

绿色代表当前标记状态,可能的话希望中间的条目标题也可以滚动一下。

网页端的调试

网页端是在本文写下不久后为了对比「赶制」出来的,对品牌性的反思导致我很怀疑现在的设计是否能在这篇文章中用作例图,二来这种风格能否驾驭住多平台也亟待考验,所以:

原图

果然效果没那么好,但也没比预期的要太差。页面大抵都承接了现在的布局结构,然后就是配合移动端进行动态合并。去掉了原本的网页条目导航栏后,我在每个载体加上了小小的「详细 >>」以代表入口,但我认为这种传统的方式并不是我想要的。在最最开始的Bgm首页(网页端)重构时,还设想了类似Gmail左侧全局导航与类似MacOS的底部Dock。用崭新的交互来重塑一个Wiki向条目标记收藏网站「该有」的样子,这也是最初的愿景。

反思

  • 这是一次失败的redesign经历,或者说不完整。
  • 图标没有系统性的统一,只是拿feather的凑了一套(网页端导航栏那里还是稍微做了几个的)。
  • 精力原因只针对了iOS全面屏(414宽),宽度再窄一点的话不知道会多出什么坑。
  • 我有在怀疑是不是我的「独狼式」设计流程有什么问题,比如说越过了交互稿。事实上以现在的设计稿质量来说,再和谐了一些设计规范后和交互稿基本没什么时间成本上的差距。说白了便是,有按部就班地整理出一套交互稿的时间不如稍微多点经历视觉稿也一并出来了(当然多人合作时还是要避免这种)。
  • 接上一条,有时我也注意到我会比较专注于一个问题过渡深入而导致其他因素的忽略。之前在某国外设计社区看到过这个思考流程闭环,都是通过某个解决方案入手想了一圈后发现又转了回来,好像除了时间流逝其他什么都没发生一样……但我想我的程度应该比这个要重一些。
  • 大多设计规范其实我都列好了只不过没有发出来,因为之前工作已经实践一次8pt网格了,这次像chrome一样缩减成4pt后有了更多选择,算是比较欣慰的一点。
  • 「崭新的交互」这种话不是能随随便便就做到的,就像普通设计师做字一样,字的骨干其实还是先找优秀的字形先临摹下来,然后在此基础上进行扩张优化以及个性化。
  • 品牌的基因要融入到对应产品里,也是比较困难的一件事。我对去年的 Plus X帮助网易劳拉做的新品牌指导还有印象(地址),但实际App那边落地还是免不了一般电商产品的布局逻辑,两者第一印象给我的出入很大。
  • 因为是准备迎向未来全面屏交互,所以最开始考虑的是横向滑动大面积载体,利用独立的导航来驱动。大致:
  • 首先这样会加剧两侧空间的浪费(虽然现在也挺浪费的),然后是一些手势和原本系统之间的冲突。这里面并不是没有可能性,有机会的话更想在别的内容更简约的产品里试试。
  • BRAIN·G 本是想做一个轻量化的设计相关文章组,无奈现在又写了一堆。

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.

%d bloggers like this:
search previous next tag category expand menu location phone mail time cart zoom edit close