——读《web信息架构》

其实互联网设计阅读推荐是读此书后，受启发完成的。因为我觉得想清楚了关键点，在各自不同角度深入下去，虽然得到的东西差不多，但思路千差万别。

也许这就是交集越大，协作越顺畅的必然。在产品实践中，我发现超过80%的问题都与信息架构有关，最容易引起争论的也是。书中有一节专门讨论“什么不是信息架构？”搞清楚的目地不是更好的分离职能，而是为了在团队协作中更游刃有余。

有计算机背景的同学阅读此书可能相对容易，牵涉大量信息技术术语、以及思维模式。适合有实操经验的产品架构、内容从业者充电，相对大量方法我觉得最受益的恰恰是偏理论部分。当然，如何传达研究结果、保卫研究结果也给同行们提足了醒。

产品架构体系

曾经接受了个观点，互联网运营的架构体系有三套：业务架构、信息架构、技术架构。

以我的粗浅理解，尝试进一步解释。业务架构以赚钱为中心，信息架构以用户为中心，技术架构以稳定为中心。架构的目标，是要建立一个坚实的、经得起时间考验的体系。过度强调哪一方，都会不同程度的对整体造成影响。

在业务模式上大谈以用户为中心的唬头都是假话，时间问题而已。技术架构在软件工程学科中已发展很成熟，但在工程师主导开发的网站中容易出现不顾用户感受的“工程”模式，信息架构就是在这样的背景之下诞生的。

信息架构体系

信息架构是学术名词，互联网只是利用其基础原理来促进转换，阅过很多分析产品“信息架构”的探讨性日志，大都只单方面的从功能入手，我觉得这顶多触及到了功能结构层面。

我理解的web-based信息架构实践，最终应该是各类型方案和规划，以策略为主。比如在上周在书友会网络相册应用及策略分析中提到的“组织策略、管理策略、外链和存储策略、权限策略”都属于此，尽早搞定逻辑漏洞规避将要发生的问题，这是IA从业者的核心价值所在。

类似探讨div布局、css呈现、js行为也不适合叫“内容”架构，浏览架构还比较恰当，前端架构师的职责就是处理类似页面制作需求。在高标准压力下，架构理论的引入是必然。

真正的内容架构，我认为至少分organization, navigation, labeling三大步骤。前两点谈的多，labeling其实也好理解，比如我们会碰到类似场面，产品最高级别用户是叫站长，还是管理员？邮件系统最快的版本是叫极速，还是简约？

我的个人网站一直在做架构方面的新策略尝试，想解决个核心问题，如何让有价值的内容保持访问量？曾经在网站和博客的区别中提到“原创之后的内容细分不应该由Blog来完成。”这也是我常给朋友建议的原因“别使用www域名或目录搭建博客，这样会限制住整体格局。”

搜索引擎优化及展望

正巧前些天公司创新日听了《解密SEO-搜索引擎优化与网站成功战略》作者欧朝晖先生的讲座。国内某些大力吹捧SEO如何简单、没有技术含量的专著里，除通过小概率案列论证些显而易见的道理外。剩下几乎都是有关网站优化的内容，但又无法解释什么叫框架？什么叫结构？什么叫元数据？既不具备指导意义，也没有科学理论做依据。

其中缘由，去年在系列探讨中有详细阐述。在实践中我发现，信息架构有问题的产品根本无法进行SEO。其实在不同角度深入做事都是方法问题，但总有些小事都做不好的家伙喜欢谈大道理，喜欢阳春白雪的强调自己而忽略别人。

上次在阿里日本面试，与同事们聊天时我提到信息架构的流程引入问题，时隔一年已经更成熟。正如六月在把体验理论变成现实所提到的预期，相信随着这本《web信息架构》中文版的发行，信息架构将迎来理论执行上的第一个高峰。