在android平台上开发音乐播放器-设计..docVIP

在 android 平台上开发音乐播放器 设计实录 文章来自 腾讯 CDC 在 android 平台上开发音乐播放器是一个全新的挑战。这次通过 android QQ music 项目实战，总结出一些方法和经 验，希望能够对移动平台的设计尤其是多媒体这块提供一些有价值的参考和帮助。 一、引入产品定义描述（Application Definition Statement） 相信大多数设计师都有过这样的经历：在产品设计过程中，设计师和产品经理不断 pk，各抒己见，甚至闹得脸红 耳赤、拍桌翻脸，最后项目总结时又因达不到“理想目标“双方深深自责，纷纷表示”缺少交流“。彼此不断 pk，交流 绝对足够，只是我们缺少有效沟通的工具。如果能在早期建立共识，口水仗爆发的频率就会越少，真正花在产品上 的时间也就越多。这一次，我们决定更早地切入，在最开始的产品规划层面，引入“产品定义描述”（关于 ap-plication definition statement，请参考《iPhone Human Interface Guidelines》）。 注意： ADS 的定义也是一个迭代的过程，外部环境的变化、后续过程产生的问题，都可能对原 ADS 产生影响，需 要重新评估、修正，甚至否定再来，但无论如何，必须确保整个团队对 ADS 有一个共同的认识。 二、细分场景，从场景推导需求，从需求推导设计 从源头的战略层面上建立了统一的认知，我们接下来开展的工作就有根据了。既然核心是解决“移动场景听歌“的问 题，我们必须首先弄清楚什么是”移动场景“？移动环境和 PC 环境差异甚大，碎片时间的使用更为突出。用户一天 是怎么活动的呢？每次拿起手机听音乐都是什么时间？上班的公车上、走路、晚上睡觉前？在这些点上用户都会做 些什么？简单的脑暴可以罗列各个可能的使用场景，但还比较粗糙。场景的构想需要建立在高度的认知上，这时候 用研的切入显得相当关键，用户特征、喜好、使用习惯…对用户越了解，场景就越能贴近真实、越能发现更多的细 节。这些都为后续的设计决策提供了有力的依据。  客观构建的场景有很多有意思的发现,比如用户在播放本地歌曲时，挑选第一首歌往往比较犹豫，但对后续播放的 歌曲却不太在意。从场景仔细分析和推敲，很容易就可以明确产品的需求，对应上述的发现，推导如下需求：为用 户提供“马上听歌”按钮引导用户直接听歌。需求的推导因为有用研的切入，避免了太多的个人情感因素。 三、敏捷原型设计，适应与借鉴并行 用研的输出以及前面的 ADS 定义为功能筛选和设计取舍提供了强有力的决策依据。在需求框架大致决定的时候， 我们接下来就进行方案设计了。正所谓“一图胜千言”，原型有时候会比面面俱到的文档更直观。不同的阶段，我们 会进行不同精度的原型设计：  在原型迭代的过程中，需要注意 android 平台的 UI 尴尬。与其他平台（iPhone、symbian、windows mobile）不同， an-droid 更加开放，不同的厂商不同的 ROM 版本界面规范并不统一。如果简单地将其他平台的设计规范移植过来， 产品体验可能会和整个系统“格格不入”。借鉴了 android 平台的一些优秀 app（比如 twitter 和 new york times）的 设计策略，我们决定“适应与借鉴并行“：在大的基础体验上，保证与系统体验一致，尊重平台使用习惯；在细节体 验上，尽量克服系统的操作困难，保证局部体验的流畅。 四、视觉方案 在整个设计过程中，我们尝试了多套风格方案，比如“梦幻光影”、“清爽夏日”、“木质桌面”“蓝色海洋”等等， 由于 beta1 开发时间有限，最后选择了偏深绿色主色调的“梦幻光影”作为默认皮肤，这里奉上其他未曾谋面的方案，供 参考。 4.1 主要界面模块划分 视觉方案的第一步是对界面各模块和控件进行作出符合审美原理和需要的的合理划分和尺寸设定，这里重点会落在 正在播放界面和歌曲列表界面两块，虽然两个界面功能和承载的信息都不相同，但是在造作上两个界面跳转和切换 是紧密关联的，在各模块划分和空间比例上两个需要统筹安排，一方面考虑上下同样尺寸的“标题行”和底部“控制行 / tab 行”一方面要考虑歌曲列表界面的列表选择合适的行高和行数。在保证每一行歌曲信息能够有足够的空间显示 的同时，还得保证一屏里面的歌曲行数是整数行。  从上图区域划分和比例可以看出，播放器界面，封面/歌手图片的中心点在整个界面的高度是 296，相对于整个界 面的高 4