comment 1

DC项目总结(二)TV篇

我不是一个经常看电视的人,所以,也很少注意过遥控器,印象中对遥控器的感觉就是5个键:电源键,节目两个键,音量两个键。更别说智能电视了。所以,在设计的时候,很多设计都是从使用PC的经验上迁移过来的。结果,在最初的草稿中,旭博看了之后,方案直接被毙掉了。

“你做的那个太PC了,你是没看过电视吧,你等会儿,带你去看看电视。”

然后,就被带到了五楼的一个会议室里,那里放着一台三星的55寸智能电视。第一次见到这种设备,不由的觉得兴奋起来:好想用一下感受感受。

当时,有另外两个同事在测试三星的输入法,说是巨难用。看到他们艰难的使用遥控器进行输入时,我在想:这设计真够糟的,这么烂的东西三星还放出来卖?他们测试完之后,我就开始了试用。

有些问题是真要实际操作了才能发现问题的。空想是想不出来的。在看了电视之后,立马就感受到了TV的操作特点了:遥控器操作,以跑焦点为主。

那么,三星的电视为什么难用呢?因为遥控器的缘故。三星的遥控器主要分为4块区域:T9键盘区,四向方向键区,功能键区,四色键区。这些按键加起来超过50个按键,遥控器长度接近30cm。以完成一个汉字的输入为例:

1,   使用功能键调出并切换输入法;

2,   使用T9键盘进行拼音输入;

3,   使用方向键移动焦点;

4,   使用四色键对候选词翻页

5,   使用方向键移动焦点并确认。

6,   这期间不能有差错,否则重来。

有没有觉得非常恐怖?你完成一个输入,需要你的手指在跨度近30cm的四个按键区进行移动,并从那些密集的案件中寻找你要按的键,这个时候,你会有摔掉遥控器的冲动。是的,就操作而言,这样的使用方式是比较恐怖的。

这时,我知道了在TV上设计界面的关键点:

1,   明晰的焦点机制

2,   小范围内的按键操作

对于“小范围内的按键操作”,我们的期望是所有的操作,尽量使用方向键来完成。因为方向键的操作有以下几点优势:

1,   学习成本低;传统遥控器、手机、PC上都有类似的操作,几乎一看就懂。

2,   位置集中,操作方便;相比其他按键来说,方向键的操作,手指可以在一小块区域内完成,且不需要看键盘面板。

3,   可借鉴的竞品较多。例如google TV,apple TV ,手机,乃至windows都有很多可借鉴的地方。

之后,开始找一些资料,看了apple TV的设计,它的遥控器非常简单,4个方向+确定键+menu键+播放/暂停键,这很符合我们的预想。但是,在观看了相关视频后就发现了另个问题:操作效率低。因为是跑焦点的缘故,所以就把大量子啊传统遥控器中完成的操作放到了界面上,这样的后果是在大量媒体文件中寻找一个特定的文件,效率变得十分低。这是TV的一个共性问题,但是仍需要解决。

于是,在最初的设计中,TV的设计一直在围绕一个问题尝试各种解决方案:如何只通过方向键快速从大量文件中寻找某个特定文件。

在最初的一个方案中,我们提供了简单的分类和搜索,来实现这个目标。分类是那种视频网站、VOD上常见的分类方法:剧情片、爱情片、动作片、科幻片等等。但是这个方案很快就被否了,因为技术告诉我们:

1,   实现不了对远端设备的内容搜索

2,   无法按照视频内容的类型进行分类

我们才意识到,那些网站上的视频,都是有人工进行编辑过的,而我们的视频环境,多是从网上直接download下来的,按视频内容分类,顶多也就是你看过某个视频后把它放入一个你自己定义的文件夹里。而程序是不能判断出来视频的类型的,除非你告诉它。对于第一个问题,不能实现搜索,这就给我们带来了更大的挑战。

接下来,我们又开始想另一个方案。因为没有搜索,所以就很自然的想到了将视频进行分类,最简单的分来方法是:基于文件名对文件进行分类并排序。于是就做了一个字母导航,通过选定不同第字母来寻找视频。

但是,这个方法也存在一些问题:

1,   用户很少自己去命名视频文件的名称,多数从网上下载下来的视频,首字母多是一些特殊符号,于是大量视频可能被归到“#”下,分类的初衷就没有得到提现。

2,   如果某些字母下的视频数很少,就会出现一屏下只有一个视频文件,这样又太浪费屏幕空间

基于以上两点,我们认为,在TV上,对于一个没有编辑名称的大量视频,字母分类是没有意义的。

然后,开始思考想第三个方案。这时,我们开始注意到,对文件进行分类,其实是基于文件的元数据进行分类的,之前的字母导航方案就是根据文件名进行分类,文件名只是元数据中的一项。对于一个视频文件来说,它还有其它元数据:持续时间、宽高尺寸、创建时间、大小等。于是,我们就考虑到,使用其他元数据进行分类。

我们觉得,持续时间是可以利用的。因为,一般来说,不同类型的视频,其持续时间基本都在一个特定的时间段内,比如说,电影一般都是在1个半小时左右 或者超过1个半小时,  电视剧一般在40分钟左右,动画片剧集一般在20分钟左右,10分钟以内的基本都是一些小短片。这样,我们就找到了以下几个时间区间:

1,   大于60分钟;绝大多数的电影属于这个范围内;

2,   30-60分钟;绝大多数的电视剧属于这个范围内;

3,   15-30分钟;绝大多数的连续短片、动画片属于这个范围内;

4,   小于15分钟;绝大多数的小短片属于这个范围内。

这样,我们就分出了4个大类来。另外,就每类的视频个数而言,如果有视频、动画片这样的视频时,2,3将占有多数的视频量。那么,接下来,就可以考虑如何对这两类视频进行分类。

电视剧和动画片,这两类视频有以下共同特点:

1,   数量庞大。动画片多数动辄超过百集。

2,   文件名的相似度极高,关注的内容是“第几集”

3,   缩略图的意义不大,几乎都是一样的缩略图

于是想到了一种处理文件名的方法:忽略文件名中的数字和特殊字符,将剩下的字符串作为一个文件夹的名称,这个文件夹内的视频以list的形式显示,一屏可以显示多列list,对于长文件名,保留两头的字符,中间的字符以“…”代替。

但是,这个方案由于对技术的压力比较大,对机器的性能要求也比较高,最终,这个方案也放弃了。

之后,开始想到了下一个方案:加标签。现有的元数据不好用的时候,那就可以考虑让用户自己加标签。因为,对于每个人来讲,他对视频都有不同的口味,而且,他的关注量也是会在一定范围内的,所以,用户每看完一个没有加标签的视频,就让他对这个视频加一个标签,程序只需提供一些常用的标签共用户选择即可,常用的视频标签不超过30个,用户每添加一个标签,就会多出一个视频分类,这样,久而久之,那些视频就会由杂乱变为有序。所以,这样的方案也是可行的。

但是,这个方案给技术看过之后,很明确的得到回复,远端的视频不能进行写操作,换句话说,写入标签数据这样的操作是不能被实现的。这个方案又被pass了。

想这些方案,前前后后花了近2个月时间,一直以来都在为如何对文件分类而殚精竭虑,最后,所有想到的方案都被毙掉了,真是心有不甘。但是,就在一筹莫展的时候,我们开始进行了反思,因为我们发现,路走的并不是那么通,一定是哪里除了问题,于是就反问了自己一下:一直都在尝试分类,分类,真的非常有必要么?

我们又回过头来,重新看了看关于DC的主要场景:

1,   phone里的视频投到TV上进行播放

2,   通过pad访问周围的设备,将其他设备的视频在自己的pad上播放;

3, 通过phone来控制其他设备上的视频播放,如快进快退,播放暂停;

4, 通过phone访问PC,然后将PC上的视频播放到TV上;

5,   基本功能,在本机播放自己的视频。

对于1、3、4这三个主要的场景,我们发现,TV就是一个播放设备!谁会拿它从一万个视频中找到其中一个然后再播放呢?这种人应该属于那种脑袋被门夹过的吧。DC的使用必须有至少2台设备才能发挥其功能,多数情况下,我们是用小屏幕设备进行控制,用大屏幕设备进行播放,这样,决定看哪个视频多是在小屏幕设备上完成的,又由于小屏幕设备操作的便利性,在TV上对视频分类几乎是无用的。TV只需要一个简单的浏览即可,甚至,连浏览都不需要,只需要TV提供一个播放服务即可,当然,这个涉及到了需求的问题,就不是由我们来定了。

这样,在想了两个月的方案之后,一切似乎又回到了起点,TV上通过DC浏览视频是不需要分类的,只用满足基本的需求即可。同样,对于图片、音乐也不需要做过多的分类。

一切都如释重负!

就是这样一个过程,不断试错,不断改正,早期的方案版本中,来自GUI、UE、BU、技术的各种反馈,使自己学到了许多,比如一致性、可行性、清晰的逻辑、沟通等能力都得到了不同程度的提升。

如果说,一个项目刚开始的阶段是锻炼你设计能力的好时期,那么,维护阶段就是锻炼你沟通能力以及发现问题的好时期。发现问题的能力和解决问题的能力是同样重要的。

 

1 Comment so far

Leave a Reply

电子邮件地址不会被公开。 必填项已用*标注