人机交互课程作业.ppt

课程作业 计算机科学系 2012年秋季本科课程 课程作业 电子记事本、日记等信息工具的设计与实现（练习6.1 ） 调查实际世界中相对应的工具，并借此为隐喻 用户用它们做什么？ 它们的外部表示形式、结构、内容是什么？ 它们有哪些功能（如用笔记录、随机翻页）？ 用户如何使用这些功能？ 分析物理及现有电子工具存在的问题 功能问题：如物理工具无法对信息进行处理 可用性问题：如电子工具在结构和使用上与隐喻区别太大 考虑并提出改进设计方案 至少需要达到的功能目标和可用性目标 课程作业 如至少应当实现和现有电子工具相同的功能（若有必要） 如在外部表示和使用上尽量逼近物理隐喻 进行概念设计 手工或借助界面编辑器绘制故事串联图板 描述用户使用情节或用例 描述关键的信息对象及其相应的外部（界面）表示 相对于用户进行评估 进行原型设计 手工程序设计（Java，C++）或借助界面建造器建立界面及其动态表示 进行有限功能模拟，实现简单，但关键的用例和对象 相对于用户进行评估 课程作业 利用该原型对用户的任务进行分析 导出系统的需求模型，如用例模型 导出系统的领域模型，如对象模型 导出系统的界面模型，如界面的表示和行为描述 进入产品开发的迭代阶段 一个共享日程表的设计实例 使用情节描述用户的任务 情节是一种非形式的叙事性描述（又称用户故事） 以叙述的方式描述人们的具体行为、活动或任务 帮助理解使用上下文，提取与用户需要和需求相关的信息 使用用户语言的描述使用户可以参与开发过程 由用户描述他们的故事通常是建立需求的第一步 帮助设计者解释用户的目标和任务，而非集中于技术分析 以下情节说明了一个用户使用系统的方法 一个共享日程表的设计实例 使用用例描述系统需求 作为需求描述工具，用例强调描述用户和系统的交互 集中于描述待开发系统的用法，不包括非技术的活动 关注于描述新系统的功能需求，表示了一定层次上的抽象 用例的描述 可以使用事件流（或动作序列）来指定用例的行为 主事件流用于描述“正常的执行序列” 替换流用于描述“异常的执行序列” 一个共享日程表的设计实例 例如：共享日程表中有关自动填写会议安排的用例 正常事件流 用户动作 系统响应 1 选择“安排会议”选项 2 提示输入参与者姓名 3 用户输入姓名清单 4 系统检查清单是否有效 5 提示输入会议限制 6 输入会议限制 7 搜索日历，查找满足限制的时间 8 显示一组可能的时间 9 选择一个时间 10 把选定的时间写入日历 11 用电子邮件给所有参与者发通知 一个共享日程表的设计实例 一个共享日程表的设计实例 使用基本用例 情节和用例均不适合于建模用户和新系统之间的交互 情节强调描述现实并缺乏结构，妨碍了探索新任务和交互 用例假定了交互技术和方式，隐含了某种形式的交互设计 对交互设计而言，它们适合于事后分析和评估 基本用例在一个抽象层次上指定用户和系统的交互 描述用户想要做什么，以及系统应如何响应 避免了导致不成熟设计的相关技术假定 迫使设计者根据情节来概念化用户的任务和交互 抽象模型也允许设计者考虑不同的交互设计方案 一个共享日程表的设计实例 在建模时，对用户的动作序列进行抽象，导出其意图 例如：“用户输入姓名清单”的目的是要“确定参与者” “用户输入姓名清单”指定了一种特殊的交互方式 而“确定参与者”给予设计者更多的设计选择，例如 可以根据员工角色（而非名字）来确定参与者，或 从系统存储的员工档案中选择，或 直接输入人名 其关键在于没有指定具体的交互方式 一旦交互设计完成，则可利用具体用例来指定系统功能 可以看出，UCD需要首先考虑用户做什么，其次也必须考虑系统做什么 一个共享日程表的设计实例 基本用例是一个结构化描述，包括三个部分 用例名：概括用户目的或意图的描述 用户意图：导致动作的决策，即想要完成的阶段性工作 系统响应：假定系统完成的工作或责任 例如：共享日程表中有关自动填写会议安排的基本用例 会议安排 用户意图 系统响应 安排会议 要求确定参与者及会议限制 确定参与者及限制 建议可能的会议时间 选择会议时间 预约会议 一个共享日程表的设计实例 概念设计 选择何种交互方式 交互方式指用户与系统交互时如何触发系统的动作 基于活动的模式：指令、会话、操作与导航、探索与浏览 基于对象的模式 如何选择取决于用户的活动，即如何使用产品来完成任务 显然，这样的信息来自于建立需求的过程（如用例描述） 例如：游戏需要操作和导航型的交互方式，而绘图则需要指令或会话型来提供交互支持 一个共享日程表的设计实例 也需要为交互的不同部分采用不同的模式 例如共享日历应用中 对找出某天日程安排的任务