comments 2

DC项目总结(三)phone篇

接手phone的设计是国庆来了之后的事情了,这时的phone已经开始处于维护阶段了。基本的设计方向已经确定下来:为了便于开发,访问媒体时,调用本地媒体库。所以,phone端的设计思路是:选设备à选媒体à媒体库,然后再对媒体库进行修改。

有些问题是设计的时候根本想不到的,比如架构问题,使用本地媒体库这样的架构,最初也是接受开发的建议,当然,事实证明,后面的许多问题都出在这样的架构上。

由于使用了本地媒体库, DC就涉及到了另外4个应用:图片库,视频库,音乐库,文件库;同时就DC本身而言,还包含了设备发现、服务、同步、云端等相关apk,这样加起来,一个DC事实上涉及到了将近10个apk,由于其复杂性,在后来的测试中暴露出了越来越多的问题,这些问题有些是DC的,有些是媒体库的。

涉及到媒体库的问题,推动其改动就会有相当大的困难,因为这是另外一帮人在做的东西,这里的沟通成本就十分大,经常会遇到有几个月前的bug还没解,而这些bug就是其他媒体库的bug。

这是在最初设计时没有想到的,也算是一个教训:一个应用尽量少涉及其他应用,这对于开发和维护是有意义的。

相当长的一段时间内都是在做一些维护工作,这些维护,主要是一些一致性的问题。四类媒体在最初设计时并没有想到之后要因为DC而做统一,但当DC调用这四类媒体时,其统一性的问题就暴露出来了。比如,提示信息的统一,按钮位置的统一,标题的统一等等。有些问题还很棘手,比如,由于只有图片库是没有状态栏的,所以,一些需要放到状态来的操作对于图片库就不合适。除了调整一致性的问题,phone端还补充了一些定义规则,主要有两块:

1,   设备排序问题;

2,   上传数据的提示机制。

对于排序,主要有以下几个排序依据:

1,   在线状态;2,屏幕大小;3,是否登录联想账号;4,是否授权;5,是否为相同账号

于是,根据这五个依据,就有了以下规则:

1), 在线状态: 在线 > 离线

2), 设备类型: TV > PC > pad > phone

3), 授权状态: 已授权 > 未授权

4), 账号状态: 本账号 > 非本账号(包含无账号)

5), 设备名称: 字母 > 中文 > 数字 > 符号

排序是一个经常遇到的问题。我们有时会纠结使用哪些方式来组织信息,tab, list, 缩略图等等,都是组织信息的方式,但再每一种方式中,排序是不可避免的,排序是为了让信息更容易被人浏览,我们可以根据信息的特点来提炼出不同的优先级,这些特点可以理解成信息的元数据,对信息的排序,实质上是对这些信息的元数据整理,根据不同的元数据进行排序,起效果是不一样的,比如之前的TV的例子,很大程度上就是对媒体信息的排序。

接下来说另外一个问题,关于数据上传的提示。这是一个稍微有点复杂的问题,因为它有很多种情况。那具体有多少种呢?将近20种吧。哈,也可能没这么多,因为我真没细数,其实我是想说,这是一个复杂的问题。DC的数据上传,采用的是首次完全备份、之后差异备份的上传策略,考虑到网络环境、上传状态,上传的条件有以下4种:

1), 上传操作有2中情况:勾选上传,未勾选上传;

2), 上传的状态有3个状态:上传开始,正在上传,上传结束;

3), 上传的网络环境有3中状态:无网络环境,有wifi有,有3G网络;

4), 上传结果有2种:上传失败,上传成功。

这4种条件会在整个上传过程中频繁交叉出现,比如,勾选上传后上传一部分数据然后取消上传;勾选上传后关掉wifi;勾选上传后关掉wifi再使用3G等等诸多复杂的情况。但是,我们可以认为,那些复杂的情况是由多个小情况构成的,于是有以下6种情况需要有相应的提示:

1),未勾选,从未上传过数据,提示尚未上传;

2),勾选后没有可用网络(检测wifi和3G的连接情况),提示没网络;

3),勾选后,本地网络正常,提示正在上传;

4),勾选后,本地网络正常,上传成功,提示上传成功并显示时间;

5), 勾选后,本地网络正常,上传失败,提示上传失败;

6),未勾选,上传过数据,提示上次上传时间。

看似复杂的情况,稍加整理,一切便会明了,因为,对于每一个影响结果的条件,它的情况是不多的,对于一个复杂的情况,影响它结果的条件也是不多的。把他们全列出来,排列组合,找出共同问题,提炼出来,就是最后的结果。

虽然一直在做维护,但是,还是有机会做一些新东西的,比如程序引导。这一块内容只之前没有做的,所以才在后面进行补充。

在做引导提示之前,我们分析了目前其他应用的引导提示,主要有以下特点:

1,   风格上,多以“局部界面+手绘描述”为主,也有纯界面展示的。

2,   出现时机,多数为第一次启动程序时出现,且不能复现。

3,   展现方式,多以全屏展示

4,   页面数量,一般是3-7页

5,   操作方式上,多以滑动操作为主

6,   展示的内容,多是亮点介绍,新功能介绍以及常用操作介绍

在了解其他应用的时候,我们发现,引导多出现在程序启动时。另外,还有一种引导,它应该算是提示,一般在第一次进入相关页面时才出现,多为一些亮点操作。也就是说,“引导”和“提示”解决的是两种不同的问题,即:

对于新发布的软件来说,引导解决的是,软件是什么,软件能干什么;

对于升级的软件来说,引导解决的是,软件有什么新功能,有什么新变动;

而提示解决的问题是:对于简单的功能来说,提示的是不常见的操作或者说是软件亮点;对于复杂功能来说,或许是一个完整的使用帮助。

那么,DC的引导提示应包含哪些内容呢?我们觉得需要有包含以下内容:

1,   整体性介绍DC的功能

2,   部署家庭环境的提示

3,   亮点手势操作提示

4,   特色功能介绍及提示,如播放到,切换设备等

具体来说,对于1,2,4,是需要出现引导中的,即第一次运行软件时出现;对于3,4,是属于提示部分的,需要出现在相关页面中。

Phone端的设计真是越做越有意思,或许是因为触屏本身就太过好玩,所以才觉得有趣。第一版的DC如今已经发布,虽然它还有太多问题没有得到解决,但就其功能来说,已经都很好的实现了。现在正在做第二版的DC,最近这些日子,一直在想着概念的方案,整体的思路是,自己做简单的媒体库,将DC从本地解耦出来,同时,将DC的特色功能进行强化,采用安卓4.0的架构将层级做浅,相信下一版的DC会更好用!

 

2 Comments

  1. Phone端的设计真是越做越有意思,或许是因为触屏本身就太过好玩,所以才觉得有趣。第一版的DC如今已经发布,虽然它还有太多问题没有得到解决,但就其功能来说,已经都很好的实现了。现在正在做第二版的DC,最近这些日子,一直在想着概念的方案,整体的思路是,自己做简单的媒体库,将DC从本地解耦出来,同时,将DC的特色功能进行强化,采用安卓4.0的架构将层级做浅,相信下一版的DC会更好用!

Leave a Reply

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