【读书笔记】信息架构:超越Web设计-第一章

目录

​编辑

第一章-信息架构想解决的问题(The Problems That Information Architecture Addresses.)

嗨ITunes(Hello, iTunes)

The Problems Information Architecture Addresses 信息架构想解决的问题

信息爆炸

更多接触信息的渠道

Enter Information Architecture 

走进信息架构(Enter Information Architecture)

信息构成的地方(place made of information)

跨渠道一致性(coherence Across channels)

系统思考(Systems Thinking)

 总结recap


笔者注:这是一本全英文的书,很多知乎大佬都推荐要读这本书。但是笔者英语很差,所以很多精力会放在和“”正确的翻译“”作斗争上,一定程度上牺牲了笔记的可读性和完整程度。但是我会尽可能保证全面的记录。如果你也找不到中文版,可以试试关注这个专栏!

第一章-信息架构想解决的问题(The Problems That Information Architecture Addresses.)

引言

本章会介绍这些要点:

  • ·信息是怎么从容器中分离出来的
  • ·信息过载(overload)和环境扩散(contextual上下文的 proliferation 繁殖扩散)的挑战
  • ·IA如何解决挑战

唱片是音乐的载体(container),marla拥有一张唱片,她需要在自己的唱片架中找到这张唱片,然后放在唱片机播放。

marla的儿子mario拥有一些cd,cd中的歌曲是数字存储的,他可以在cd机上选择循环播放这些音乐。但是cd仍然是以实体存储在他家的。在Mario买了个imac,并使用imac录制(rip)后,他可以使用任何排列方式在电脑存储中保存音乐,也可以重新刻录CD分享给他的朋友。mario不再需要管理一沓cd了。

嗨ITunes(Hello, iTunes)

iTunes是一个很复杂的软件,它支持智能播放音乐列表、听播客、听广播、看电视等很多功能。后来发行了iPod之后,iTunes也支持管理iPod中的歌曲。这些功能这些功能中的每一个都引入了新的内容分类。iTunes仍然有一个搜索框,但搜索结果包括不同(且不兼容)的媒体类型。比如《眼花缭乱》的搜索结果是指这部电影电影原声音乐,齐柏林飞艇乐队的歌曲,或其众多歌曲中的一首封面?

后来Mario买了iPhone,但是iTunes中的这些功能在iPhone中分别对应不同的app。后来,苹果推出了一项名为iTunes Match的服务,允许Mario将他的音乐收藏上传到苹果的“云端”;现在,他还必须记住哪些歌曲实际上在他的云上

mario无法理解,但是他知道自己管理这些东西这么复杂,一定是哪里出了问题。

The Problems Information Architecture Addresses 信息架构想解决的问题

Mario遇到了这两个问题:

  • 他用来管理音乐的软件,实际上已经成了一个管理数十亿信息的平台,每种信息(音乐、视频、广播、电子书)都有不同的规则(比如某电影购买后24小时内可观看)和使用方式(看视频、听广播、音频转码录制)
  • 同一个信息的载体有着不同的交互方式,并不局限于电脑访问,比如某个视频在手机上也能看、carplay也可以听音乐。但并没有让Mario感受到它们是一个一致、连贯的交互模型。
信息爆炸

数字化促进了信息的增多,也促进了很多信息管理工具(比如搜索引擎)的诞生。

*谷歌的使命是:组织世界上的信息,使其普遍可获取和有用。

更多接触信息的渠道

Mario遇到的问题2,是新时代的问题:电子产品的不断小型化,加上无线通信技术的广泛采用,导致了小型、廉价的互联网连接设备的激增,这些设备正在改变我们与信息以及彼此之间的互动方式

正如我们前面提到的,曾经有一段时间,信息存在于与传递该信息的工件(artifacts)紧密耦合的关系中。

想想早期的书籍:在印刷术发明之前,手抄是唯一可用的复制技术,这是一个极其繁琐的过程。复制既不容易也不便宜,因此像书籍这样的信息工件的个体实例( information artifacts)甚至更有价值。由于这些早期书籍的稀有和昂贵,阅读它们是在特定的时间和地点(例如,白天的修道院图书馆)为特定阶层的人(例如,学者,僧侣,贵族等)保留的一项活动。

数字媒体让信息不再具有特定的时间地点约束,变得非物质化(dematerialization of information),也不再专为特定阶层的人服务。

可穿戴化的设备获取我们的身体数据,并且相应的对服务做出改变(the Nest thermostat server)。越来越多的机构不得不考虑用户将如何在这些和许多其他完全不同的环境(context 上下文)中访问他们的信息。他们显然希望这些体验是一致和连贯的,而不管信息是在哪里以及如何被访问的。

Enter Information Architecture 
走进信息架构(Enter Information Architecture)

虽然大多数软件应用程序都是为了解决非常具体的问题而设计的,但随着时间的推移,这些成功的应用程序往往会超出问题集的范围,包含越来越多的功能。

比如:ITunes从简单的管理音乐的软件,变成了具有这么多功能的程序系统。

鉴于我们前面提到的信息和设备种类的激增,这是许多组织已经在努力解决的问题。我们需要的是一种系统的、全面的、整体的方法,以一种易于发现和理解的方式构建信息,而不考虑用户访问信息的上下文、渠道或媒介。

换句话说,需要有人走出产品开发的战壕,从抽象的角度看更广阔的图景,理解它们是如何结合在一起的,这样信息才能更容易找到和理解。

信息构成的地方(place made of information)

正如我们之前所说的,使用数字产品和服务的体验正在扩展到包括不同地点和时间的多种设备。重要的是要认识到,我们通过使用语言与这些产品和服务进行交互:标签、菜单、描述、视觉元素、内容,以及它们之间的关系,创造了一个区分这些体验并促进理解(或不!)的环境。举个例子,手机上的食谱应用程序使用的语言必然与汽车保险公司网站上使用的语言不同。这些语言上的差异有助于将主题定义为不同的“地方”,人们可以访问这些“地方”(place)来完成某些特定的任务:它们为所传达的信息创建了一个框架,使我们能够相对于我们已经知道的概念来理解它。

信息架构师安德鲁•温斯顿在他的著作《理解语境》(Understanding Context)中认为:

我们理解这些经历就像理解物理场所一样:通过挑选特定的词汇和图像来定义在环境中什么可以做,什么不可以做——无论是英国乡村田园般的开阔田野,还是网络搜索引擎

数字体验是由信息构成的新型(非常真实的)场所;设计上的挑战在于如何让它们在多个环境中保持一致。正如Andrew所说,“信息架构是一门非常适合应对这些挑战的学科。几十年来,它一直以这样或那样的方式与他们合作。

跨渠道一致性(coherence Across channels)

信息架构如何实现这种一致性?

信息架构要求设计师定义语义结构(internal consistency),这些语义结构可以根据不同渠道的需求以多种方式实例化(external consistency)。

在桌面网页上运行良好的导航结构,在5英寸的触摸屏上呈现时,其功能应该有所不同,但两者的用户体验应该是一致的。

换句话说,当一个组织通过多渠道为其用户提供服务时,用户在这些渠道上的体验应该是一致和熟悉的。例如,使用银行移动应用程序的用户在使用银行网站或调用银行基于电话的服务时,应该体验到一致的语义结构。虽然每个通道的功能和限制是不同的,但每个通道中使用的语义结构应该是熟悉和一致的。为了实现这一点,它们必须从实际实现中抽象出来。

系统思考Systems Thinking

当其他设计学科专注于特定工件的设计时,信息架构关注的是定义单个工件artifacts(应用程序、网站、语音接口等)将在其中工作的语义系统semantic systems。

信息体系结构的重点不仅仅是高层次的抽象模型 : 可查找和可理解的产品和服务的设计也需要创建许多低级工件,比如网站导航结构

有效的信息环境在结构一致性(高级不变性)(high-level invariance)灵活性(低级灵活性)(low-level flexibility)之间取得平衡,因此设计良好的信息架构会同时考虑这两者。

举例:你在设计时,是想要建设一个教堂还是车库?iTunes的作者们在想明白自己在做什么之前,已经给要盖的车库安上了穹顶和彩色玻璃。

 总结recap
  • 从历史上看,信息已经呈现出一种去物质化的趋势,从与它的容器有一对一的关系到完全脱离它的容器(就像我们的数字信息一样)。这对我们这个时代有两个重要的影响:信息比以往任何时候都更丰富,我们与信息互动的方式也比以往任何时候都多。
  • 信息架构(IA)的重点是使信息易于查找和理解。正因为如此,它非常适合解决这些问题。
  • 它要求设计师从两个重要的角度来思考问题:我们的产品和服务被认为是由信息组成的地方,它们作为生态系统的功能,可以被设计成最大的效率。
  • 也就是说,信息架构并不仅仅在抽象层面上运行:为了使其有效,它需要在不同的层面上进行定义。

 “Defining the damned thing”—“定义该死的东西”——或DTDT,因为它在Twitter和邮件列表上经常被缩短——是IA社区持续争论的一个来源,让一些人感到高兴,也让另一些人感到烦恼。当你以标签为生时,关于概念界限的争论是一种职业危害。

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
作者:(美)Louis Rosenfeld(路易斯·罗森菲尔德),Peter Morville(彼得.莫尔维莱),Jorge Arango(豪尔赫·阿朗戈) 译者:樊旺斌 出版社:电子工业出版社 ISBN:9787121287800 √ 领域畅销经典重装再现,北极熊书长期被信息架构师、设计师及网站开发者奉为圣经 √ 新版内容全面更新,关注焦点彻底突破网站,面向更热门更前沿的电子产品与设备 √ 深度剖析IA 要素,包括组织、标签、导航、搜索与元数据 √ 概念→过程→方法→策略→实现,全面更新 信息架构(IA)比以往任何时候都更具挑战性(和必要性)。由于如今可得到的信息供过于求,因此你想要分享的任何内容都应该是容易查找、浏览和理解的,同时提供的体验在多种交互渠道都应该是熟悉且一致的,从Web到智能手机、智能手表,等等。 为了引导你通过这个广阔的生态系统,本书为数字设计提供了经得起时间考验的基本概念、方法和技术。用户体验设计师、产品经理、开发人员和数字设计中涉及的所有人,都要学习如何创建帮助人们与你的信息进行交互的语义结构。 本书包括: 信息架构概述,以及为创建有效的数字产品和服务而解决的问题 深入探讨了信息架构组件,包括组织、标签、导航、搜索和元数据 让你从研究进入策略、设计信息架构实现的流程和方法 内容简介 《信息架构超越Web设计(第4版)(全彩)》 的前三个版本都是信息架构领域的开山著作。其中描述了信息组织的普遍和永恒原则,这一原则也适用于不断增长的移动世界。在第4版中,作者运用大量最新的插图和例子为这些原则提供了当前实践中的情境,验证了那些与技术和供应商无关的工具,以及那些经受住时间考验的技术。 第1部分 信息架构简介 1 第1章 信息架构要解决的问题 3 你好,iTunes 5 信息架构要解决的问题 8 信息过载 9 访问信息的更多方式 10 加入信息架构 12 由信息构成的场所 13 渠道之间的一致性 13 系统化思维 15 本章回顾 16 第2章 信息架构的定义 19 定义 19 看不到不代表不存在 21 走向优秀的信息架构 26 情景 28 内容 29 用户 30 本章回顾 31 第3章 为查找而设计 33 “太过于简单的”信息模型 34 信息需求 35 信息搜寻行为 38 了解信息需求和信息搜寻行为 41 本章回顾 42 第4章 为理解而设计 43 场所感 43 (现实世界)场所的结构 44 由信息组成的场所 45 组织原则 47 结构和秩序 48 类型系统 50 模块化和可扩展性 54 世界上最快乐的场所 56 本章回顾 61 第2部分 信息架构的基本原理 63 第5章 信息架构详解 65 信息架构可视化 65 自顶向下的信息架构 68 自底向上的信息架构 70 不可见的信息架构 73 信息架构组件 74 浏览帮手 75 搜索帮手 76 内容和任务 77 “不可见的”组件 78 本章回顾 78 第6章 组织系统 79 组织信息的挑战 80 模糊性 81 异质性 81 不同观点的差异性 82 公司内部的政治文化 83 组织信息环境 83 组织方案 84 精确的组织方案 84 组织结构 93 层级结构:一种自顶向下的方法 94 数据库模式:一种自底向上的方法 98 社会化分类 102 创建凝聚性组织系统 103 本章回顾 104 第7章 标签系统 105 为什么要关心标签命名 106 各种各样的标签 111 作为情景式链接的标签 111 作为标题的标签 114 导航系统内的标签 116 标签作为索引词 118 标签的设计 121 通用原则 121 标签系统的来源 124 创建新的标签系统 129 优化和调整 137 本章回顾 137 第8章 导航系统 139 导航系统的种类 140 灰色区域很重要 141 浏览器导航功能 142 场所营造 142 提高灵活性 144 嵌入式导航系统 145 全局导航系统 145 局部导航系统 148 情景式导航 150 嵌入式导航的实现 152 辅助导航系统 154 站点地图 155 索引 156 指南 159 搜索 162 高级导航方法 162 个性化和自定义 163 可视化 164 社会化导航 165 本章回顾 168 第9章 搜索系统 169 你的产品需要搜索吗 169 搜索引擎详解 173 选择要索引什么 174 确定搜索区域 174 选择要建立索引的内容组件 179 搜索算法 182 模式匹配算法 182 其他方法 183 查询生成器 185 显示结果 186 要显示哪些内容组件 187 要显示多少文档 190 列出结果 192 将结果分组 199 对结果采取行动 200 设计搜索界面 201 搜索框 203 自动完成和自动建议 206 高级搜索 207 支持修改 208 当用户被卡住时 212 到哪里学习更多 213 本章回顾 214 第10章 叙词表、受控词表和元数据 215 元数据 216 受控词表 216 同义词环 217 规范文档 220 分类方案 223 叙词表 225 技术术语 226 叙词表实例 228 叙词表类型 233 经典叙词表 234 索引叙词表 234 搜索叙词表 234 叙词表标准 235 语义关系 237 等价 237 层级 238 关联 239 首选术语 240 术语形式 240 术语选择 240 术语定义 241 术语特异性 241 多元层级结构 242 分面分类法 243 本章回顾 248 第3部分 完成信息架构 249 第11章 研究 251 研究框架 252 情景 253 获得支持 254 背景研究 254 初步演示报告 255 研究会议 255 利益相关者访谈 257 技术评估 258 内容 258 启发式评估 259 内容分析 260 内容映射 262 标杆法 263 用户 265 使用分析 266 搜索日志分析 267 参与者定义和招募 270 客户支持数据 270 调查 270 情景调查 270 焦点小组 271 用户研究会议 272 访谈 272 卡片分类法 273 用户测试 277 研究的保卫战 278 克服研究阻力 279 本章回顾 280 第12章 策略 283 什么是信息架构策略? 284 遭到抨击的策略 285 从研究到策略 287 策略的开发 287 思考 288 表述 288 沟通 289 测试 289 工作产品和可交付成果 291 隐喻探索 291 场景 293 案例研究和故事 294 概念图表 295 站点地图和框架图 296 策略报告 296 示例策略报告 296 项目计划 306 演示 307 本章回顾 308 第13章 设计和文档 309 创建信息架构图的准则 310 视觉沟通 311 站点地图 313 高级架构站点地图 313 深入站点地图 315 保持站点地图的简单性 319 详细的站点地图 320 组织你的站点地图 322 线框图 324 线框图的类型 327 线框图准则 330 内容映射和清单 331 内容模型 337 它们为什么这么重要? 337 实例 338 有价值的过程 342 受控词表 342 设计协作 344 设计草图 344 整合:信息架构风格指南 347 “原因”所在 347 “方式”所在 348 本章回顾 349 结语 351 附录A 参考文献 355

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值