我眼中掌阅的不足和解决方案20120614..doc

我眼中ireader的不足和解决方案 目录 1. 不足1：书城结合的不够紧密 1 1.1. 方案1：书架增加“可能想读的书”模块 1 1.2. 方案2：阅读过程中的书城推荐 3 1.3. 方案3：推送功能 4 2. 不足2：书城受移动网络影响大 4 2.1. 方案1：下载不完全也可以阅读 5 2.2. 方案2：多种版面可以切换 5 3. 不足3：书城消费方式单一 5 3.1. 方案1：图书打赏 5 3.2. 方案2：先看书，后支付 6 4. 不足4：工具性强社交功能弱 6 4.1. 方案1：摇一摇，摇出推荐图书和推荐的人 6 不足1：书城结合的不够紧密 掌阅客户端靠书城来获得收入，书城可以跟用户结合的更紧密些： 书城可以融入书架界面。 书城可以融入阅读过程。 书城可以融入手机桌面。 方案1：书架增加“可能想读的书”模块 大致界面参考如下： 图1：书架主界面 图2：可能想读的书 交互方式：点击图1里的“可能想读的书”跳转到图2，图2里显示系统推荐的图书。 相似创意：新浪微博“可能认识的人”功能。 客户端逻辑： 在图2中，用户首次看到的是客户端软件里面预置的图书，这些封面和图书相应的地址不需要联网获得。 用户后续进入或者点击“换一批”，则需要联网获取推荐的图书封面和相应地址。 当用户停留在图2界面时，后台会自动去获取下一批推荐的图书，同时当前页推荐的图书封面和对应地址能缓存在手机本地。 对于推荐的图书，用户点击到最后一批时，当用户再点击【换一批】，能从头开始循环推荐的图书。 客户端能记录用户书架里的图书清单，一个用户一个清单上传到服务器，清单中不断的加入用户书架后增的图书以及增加的具体时间。 服务器逻辑： 1、根据用户，给客户端下发推荐图书信息。 运营工作： 建立具体用户的推荐库 服务器可以比对各个用户图书清单的重合度，由运营人员确认延伸建立该用户的推荐库。 建立具体图书的关联图书库 运营人员可以根据图书的作者、名气级别、图书品类（比如一个用户看了这本书，他往往也会看另外的几本书，那么另外的那几本书，也可以成为这本书的关联图书），确定并录入各个图书的关联图书及彼此间优先级。 运营需要降低推荐页面跳出率，提升最终的一个命中推荐的计费arpu值。 确保每周有关联图书录入的图书数量，并跟踪关联命中情况。 确保每周建立推荐库的用户量。 方案2：阅读过程中的书城推荐 大致界面参考如下： 图3：阅读过程中的书城融入 交互方式：弹出框 客户端逻辑： 用户阅读完数章之后，点击下一页时，弹出。 用户阅读完整本书，首次点击下一页时，弹出。 用户阅读了一定的时间，比如45分钟之后时，弹出。 该场景出现停留4秒后，自动消失；用户也可以点击弹出框之外的部分，回到全屏阅读界面。 弹出框包括以下几个部分： 一句文字描述：可以是其他用户对当前阅读图书的经典评论/必威体育精装版评论、该图书的下一章的标题，用户分享以及系统公告等的随机。 推荐的图书：在用户阅读过程中，这些信息由客户端后台从服务器获取。 图书打赏。（该功能详见后文） 服务器端逻辑： 1、根据用户，给客户端下发推荐图书信息和弹出框中的文字描述。 方案3：推送功能 交互形式： 在线的推送功能：用户处在有网络状态下的，实时联网获取的推送功能。 离线的推送功能：用户处在没有网络或者网络状态不佳情况下的，使用本地离线的推送功能。（类似于缓存，推送也可以有本地缓存） 运营工作： 推送内容的制作。 推送频率和时间的确定。 提升由每次推送所带来的人均arpu和沉寂用户转活跃用户的转化率。 不足2：书城受移动网络影响大 移动信号不好时，无法联网，下载不成功，下载等待时间长，需要弱化移动网络的影响。 方案1：下载不完全也可以阅读 交互方式：下载时，通过后台下载，下载过程，用户无需知道（比如下载进度），用户把在线的图书加到书架中打开阅读时，体验尽量靠拢用户打开本地图书的体验。 相似创意：多媒体P2P下载时，可以边下边看。 客户端逻辑： 按图书内容顺序请求下载。 把各可阅读单元按序合成一本书。 在用户打开图书详情页面时，后台自动下载该图书的第一个可阅读单元。 能够自动加载和刷新后续下载完的图书内容。 即使用户没有启动客户端软件，在有WIFI环境下，也能够定时发起未下载完成图书的后台下载。 服务器端逻辑： 1、每次传送给客户端的都必须是一个可阅读单元的整数倍。 方案2：多种版面可以切换 书城页面分为无图版和有图版，无图版和有图版可以互相切换。 图书在进入详情页面的同时即开始下载（此时不加入到书架），也可以先进入图书的详情界面再下载（用户确认下载，再加入到书架）。 不足3：书城消费方式单一 对有一部分人来说，阅读是一种享受，但他还