1、课程作业,计算机科学系 2012年秋季本科课程,课程作业,电子记事本、日记等信息工具的设计与实现(练习6.1 ) 调查实际世界中相对应的工具,并借此为隐喻 用户用它们做什么? 它们的外部表示形式、结构、内容是什么? 它们有哪些功能(如用笔记录、随机翻页)? 用户如何使用这些功能? 分析物理及现有电子工具存在的问题 功能问题:如物理工具无法对信息进行处理 可用性问题:如电子工具在结构和使用上与隐喻区别太大 考虑并提出改进设计方案 至少需要达到的功能目标和可用性目标,课程作业,如至少应当实现和现有电子工具相同的功能(若有必要) 如在外部表示和使用上尽量逼近物理隐喻 进行概念设计 手工或借助界面编辑
2、器绘制故事串联图板 描述用户使用情节或用例 描述关键的信息对象及其相应的外部(界面)表示 相对于用户进行评估 进行原型设计 手工程序设计(Java,C+)或借助界面建造器建立界面及其动态表示 进行有限功能模拟,实现简单,但关键的用例和对象 相对于用户进行评估,课程作业,利用该原型对用户的任务进行分析 导出系统的需求模型,如用例模型 导出系统的领域模型,如对象模型 导出系统的界面模型,如界面的表示和行为描述 进入产品开发的迭代阶段,一个共享日程表的设计实例,使用情节描述用户的任务 情节是一种非形式的叙事性描述(又称用户故事) 以叙述的方式描述人们的具体行为、活动或任务 帮助理解使用上下文,提取与
3、用户需要和需求相关的信息 使用用户语言的描述使用户可以参与开发过程 由用户描述他们的故事通常是建立需求的第一步 帮助设计者解释用户的目标和任务,而非集中于技术分析 以下情节说明了一个用户使用系统的方法,一个共享日程表的设计实例,使用用例描述系统需求 作为需求描述工具,用例强调描述用户和系统的交互 集中于描述待开发系统的用法,不包括非技术的活动 关注于描述新系统的功能需求,表示了一定层次上的抽象 用例的描述 可以使用事件流(或动作序列)来指定用例的行为 主事件流用于描述“正常的执行序列” 替换流用于描述“异常的执行序列”,一个共享日程表的设计实例,例如:共享日程表中有关自动填写会议安排的用例 正
4、常事件流用户动作 系统响应 1 选择“安排会议”选项2 提示输入参与者姓名3 用户输入姓名清单4 系统检查清单是否有效5 提示输入会议限制6 输入会议限制7 搜索日历,查找满足限制的时间8 显示一组可能的时间9 选择一个时间10 把选定的时间写入日历11 用电子邮件给所有参与者发通知,一个共享日程表的设计实例,异常事件流用户动作 系统响应5 如果参与者清单无效5.1 提示错误信息5.2 返回步骤 28 如果没有找到合适的时间8.1 作出相应提示8.2 返回步骤 5,一个共享日程表的设计实例,使用基本用例 情节和用例均不适合于建模用户和新系统之间的交互 情节强调描述现实并缺乏结构,妨碍了探索新任
5、务和交互 用例假定了交互技术和方式,隐含了某种形式的交互设计 对交互设计而言,它们适合于事后分析和评估 基本用例在一个抽象层次上指定用户和系统的交互 描述用户想要做什么,以及系统应如何响应 避免了导致不成熟设计的相关技术假定 迫使设计者根据情节来概念化用户的任务和交互 抽象模型也允许设计者考虑不同的交互设计方案,一个共享日程表的设计实例,在建模时,对用户的动作序列进行抽象,导出其意图 例如:“用户输入姓名清单”的目的是要“确定参与者” “用户输入姓名清单”指定了一种特殊的交互方式 而“确定参与者”给予设计者更多的设计选择,例如 可以根据员工角色(而非名字)来确定参与者,或 从系统存储的员工档案
6、中选择,或 直接输入人名 其关键在于没有指定具体的交互方式 一旦交互设计完成,则可利用具体用例来指定系统功能 可以看出,UCD需要首先考虑用户做什么,其次也必须考虑系统做什么,一个共享日程表的设计实例,基本用例是一个结构化描述,包括三个部分 用例名:概括用户目的或意图的描述 用户意图:导致动作的决策,即想要完成的阶段性工作 系统响应:假定系统完成的工作或责任 例如:共享日程表中有关自动填写会议安排的基本用例 会议安排 用户意图 系统响应 安排会议要求确定参与者及会议限制 确定参与者及限制建议可能的会议时间 选择会议时间预约会议,一个共享日程表的设计实例,概念设计 选择何种交互方式 交互方式指用
7、户与系统交互时如何触发系统的动作 基于活动的模式:指令、会话、操作与导航、探索与浏览 基于对象的模式 如何选择取决于用户的活动,即如何使用产品来完成任务 显然,这样的信息来自于建立需求的过程(如用例描述) 例如:游戏需要操作和导航型的交互方式,而绘图则需要指令或会话型来提供交互支持,一个共享日程表的设计实例,也需要为交互的不同部分采用不同的模式 例如共享日历应用中 对找出某天日程安排的任务,宜于采用指令型方式 对为多人安排会议,则需要提供会话型支持 对于规划任务,则采用浏览型较为合适 基于对象的交互模式提供了信息和操作表示的视角 通常是有关物理(或虚拟)对象及关系的屏幕模拟 选择何种对象作为建
8、模的基础与相应的界面隐喻相关 例如:模拟便携式日程表,或张贴的大型计划表,一个共享日程表的设计实例,选择合适的界面隐喻 界面隐喻结合用户熟悉的知识和新知识帮助用户理解产品 选择界面隐喻的三个步骤 理解系统的功能性 也可按照所识别的功能需求,开发部分概念模型并测试 识别系统的哪些方面会给用户带来问题 界面隐喻只是虚拟表示和所模拟的对象之间的部分映射 只有理解了用户在哪些方面可能遇到困难,才能选择隐喻对其提供支持 另一方法是识别哪些任务或子任务会造成问题,哪些是复杂或关键的任务 发现用户所熟悉的对象并建立相应的界面隐喻,一个共享日程表的设计实例,最后需要对建立的隐喻进行评估,应回答以下问题 界面隐
9、喻是否具有结构?隐喻应结构化且为用户所熟悉 隐喻与问题的相关程度?隐喻应与所需解决的问题相匹配 隐喻是否易于表示?隐喻应当容易用多媒体手段来表现 隐喻是否容易被理解? 隐喻是否具有可扩充性? 例如:对于共享日历系统 明显可选用的界面隐喻是纸质的个人日程表 可以使用电子文档的能力(如超链接和搜索)扩充其功能,一个共享日程表的设计实例,考虑这个隐喻时,需回答上述的问题 结构问题:基于物理日程表,但不支持共享信息 十分个人化的日程表 即使供多人共用,仍为内部使用,外部不能访问 相关度问题:有多少纸质日历的属性可应用于电子日程表 后者无法翻页,但可实现跳转至另一页 后者是否允许携带取决于所选择的交互范
10、型 后者具有共享的属性,而前者通常不是 表示问题:该隐喻容易表示 理解问题:该隐喻易于用户理解 扩充问题:该隐喻可以扩充,一个共享日程表的设计实例,选择交互范型 交互范型即技术在交互设计中的成功应用,包括 采用WIMP界面的桌面范型、无处不在计算、普适计算、可穿戴计算、实物界面、混合现实等 环境需求是选择交互范型的一个重要因素 例如:在不同的环境中使用共享日历,可以选择 无处不在计算:采用大屏幕显示器,任何人可与之交互 普适计算:PDA等便携设备,可访问服务器的共享信息 可穿戴计算:各种随身物件,随时访问或通知某些信息,一个共享日程表的设计实例,建立原型评估设计思想 原型应能让用户体验到产品将
11、如何支持他们的任务 因此,开发原型需要考虑更为具体的细节 在评估时,原型用于收集来自于用户的反馈,也用来说明某种决策在技术上的可行性 在不同的开发迭代阶段,需要使用不同类型的原型 低保真原型(如纸模、卡片等)通常适应于早期概念设计 高保真原型(如可执行软件)则适用于设计后期 如果目标是让用户接收产品,则需要开发高保真原型,一个共享日程表的设计实例,例如:共享日历系统的卡片式原型 旨在测试会议安排的任务流和信息需求是否合理 第一张卡片:系统询问用户信息,以查找合适的会议时间,一个共享日程表的设计实例,第二张卡片:系统在所示的区域内显示结果,一个共享日程表的设计实例,第三张卡片:用户在选择后的三个可能选项,一个共享日程表的设计实例,根据原型进行物理设计,