DRD交互文档规范.pptVIP

大智慧交互设计小组—DRD交互文档构成与规范 制定人 : 陶亮 协助: 高乃波 制定日期: 2012.10.10 目录 一.文档的目标 一：DRD文档的目标 梳理整站的逻辑结构页面跳转以及交互状态说明 二: 输出形式 格式：以word 文档的方式输出 三: 阅读对象 前段开发人员 四: 文档的组成 1.目录 1.目录 3.网站结构拓扑图（产品的配合） 4.复杂交互行为逻辑设计图及说明 5.公共模块的梳理及其说明 （重要） 6.对交互稿中不明显的交互动作或隐藏的设置项作说明 7.单个页面或主要的交互模块描述 8.测试部门检测 五.相关小组对二期项目交互的建议 * * * 二.输出形式 三.阅读对象 四.文档组成 五.相关小组对二期项目交互的建议 确保整站的交互体验的一致性和统一性。 对整站公用模块的组成分析和整理 形式：文字配合图片清晰说明交互于逻辑行为 程序开发人员 视觉设计人员 测试人员 2.文档版本信息 3.网站结构拓扑图 4.复杂交互行为的逻辑设计图及说明 5.公共模块的梳理及其说明 7.部分单个主要页面或模块的交互行为说明 6.对交互稿中不明显的交互动作或隐藏的设置项作说明 8.测试人员可行性检测 2.文档版本信息 包含版本号，更新时间 ，更新内容，以及更新人。 需有清晰目录页方便各需求方的查阅。 版本号 更新人 更新时间 更新内容 更新原因 V1.0 陶亮 12.11.2 初步提案 V1.1 陶亮 12.12.31 5页共用模块 产品方向和需求调整 整站结构的拓扑图 部分主要页面的拓扑图 工作圈个人微博首页 个人信息 粉丝数 关注数 微博数 用户名 部门 用户图片 我的粉丝列表页 我的关注列表页 我的微博数 例: ..... ..... 主要针对逻辑较强的页面以图表化得方式来给与注解与说明 角色：1.申请人 2.被申请群群主 行为：1.申请人通过搜索或公司群列表入口页发起申请加入群 2.群主出现消息提示 结果：1.群主同意 2.申请人返回消息提醒，公司所有群中显示该群 1.群主拒绝 2.申请人返回消息提醒 群主 公司群列表 搜索 申请加入 申请人 同意消息提示 消息提示 拒绝消息提示 例：申请加入群逻辑图 导航 页脚 文本框 公用按钮 微博回复框 转发框 等其他可能会公用到模块 例： 微博首页 我要转发 发送私信 2者前端样式具有 公用性 后期可能会多次应用 ， 注意扩张。 我要转发多出回复给谁的复选 以及选择群下了菜单 （下拉内容 为自己创建或加入的群）。 权限：回复框选中原微博出现我的回复内容， 下拉框默认状态“ 选择群” 转发后 只要互关注所有人可见 下拉框选择后 则只在选中的群中人可见 状态：下拉框选中后状态为将默认“请选择”替换为您所选中群的名称 如图： 注：本例主要用于说明模块公用关系案例，与发布中的无关。 例：微博发布框隐藏动作 微博发布框默认状态下外观 微博发布框输入状态下外观 隐藏的交互行为 微博框在输入状态的情况下 行为一：表情文件夹 和谁分享出现 行为二：发布按钮改为可用状态 发布按钮成灰色为不可用状态 链接的指向 链接的打开方式（本窗口或新窗口） 那些地方是否需要做链接 是否带 ait title 信息 极限状态所表现的方式 操作时产生的信息的提示等 激活标签与未激活的不同状态 网页弹出浮动层的说明 js 效果的注解说明（如滚动 点击按钮的div的展开和隐藏等） 列表信息显示数量 复杂不同场景的状态其实说明（必要的话配合场景图） 权限限制、数据限制、字段限制、一般错误提示 所有的交互细节都会以图片注解的形式出现 ，DRD 文档目的是辅助图片注解加强表达交互。 根据不同的交互行为思考参考方向 测试部门DRD所描叙的交互行为和逻辑设计等从测试的角度来给予检测 并其提出修改建议。 前端小组： 1.在不影响需求和用户体验的情况下，减少js特效（复杂js）特效使用。 过多或不恰当的使用对用户体验十分 不好。复杂的特效增加整个前端开发周期. 2.做好公用模块的梳理，便与模块化地开发 3.交互流程尽量跑通 ，不能缺少页面。 程序小组： 1. 交互行为和逻辑需要理清 （以为转发 与 @输入框弹出为例） 2. 在程序之前前端设计交互 要深刻理解需求把html页面流程跑通 * * *