这是资讯架构学–网站应用，第三版的第八章：搜寻系统(Search Systems)，在上一章有可以帮你替网站建立最佳的导览系统。这一章要说明另一种寻找资讯的形式：搜寻。想到搜寻ㄚ琪很直觉得就是Google了，可是Sophia却是Yahoo，这当中还真有点差异，但是在工作达人上的搜寻又是怎样呢？其实很早以前是有另一种搜寻系统的，是Wordpress预设的，但后来ㄚ琪弃守了，今天让我再来看看，是否有新的搜寻技术，可以让我变更目前的搜寻方式，现在让我们读下去吧。
昨天再去Google的自订搜寻引擎发现有新版的功能，而这新版的功能看似好像可以符合ㄚ琪的需求，不过完了半天也是还没搞定，看起来满复杂的，特别是中文的部份很弱，所以很多是英文的说明，或许过些阵子可以改善，我们就拭目以待吧。
试了几天的新功能，感觉中文方面的功能好像不是很齐，所以就先继续使用元来的搜寻功能了。
网站需要搜寻功能吗?
替网站建构搜寻系统前，先想想下列的问题。
- 网站有足够的内容吗？
投资搜寻系统会不会转移更有用的导览系统的资源？
你有时间和技术替网站搜引擎做最佳化工作吗？
有更好的替代方案吗？
网站用户讨厌搜寻吗？
综合上述地问题，可以再度地帮助ㄚ琪思考是否真的需要搜寻功能，不可讳言地，ㄚ琪是觉得对于一个部落格而言，搜寻功能实属必要，当然导览系统的充分利用也是需要考虑到的，这个导览系统ㄚ琪以前倒是没有特别注意，不过我想从今天开始会好好注意的，另外值得一提的是搜寻引擎最佳化的工作我们是否做得来，当然，现在WordPress已经提供了很好的搜寻，另外像Google也有自订引擎，可是如果扪心自问，他们是否都做了最佳化，这就比较不清楚了，但是如果我们的技术跟时间不足的话，使用这些预设的功能，其实感觉起来还满好的说，不过这可能是自我感觉良好吧。更好的替代方案：网站索引是否合适也值得列入考虑。我的客户是否讨厌搜寻，我想就有待各位提供意见了。
如果已经有必要建构搜寻引擎，基本上ㄚ琪想应该会是需要的，否则就没有这一章内容存在的必要了，你说是不，现在要继续探讨何时建构：
- 有太多资讯要浏览而搜寻会有帮助时
搜寻可以协助成片断的网站
搜寻是学习工具
搜寻应该在那儿，因为用户希望在那儿
搜寻可以驯服动态性
当有这些条件成立时，我想就是建构搜寻系统的时候吧。 -
搜寻系统详解
- 这里有一个来自In Defense of Search的图解，大体而言者里头牵涉到的技术还不少，像是查询语言、查询辅助工具、中介资料、控制词汇、排名与丛集演算法、介面设计等等。这些是否全留给IT来处理，就看你啰。
搜寻不是一种IT玩意
这里头就节录文中有关资讯建筑师应该要做的事，‘理想上，资讯建筑师、IT专家、以及其他专长的人会找出他们各自的需求，讨论这些需求对彼此的冲击如何，最后在评估搜寻引擎程式时，再列出一组统一的需求。可惜的是，因为某些政治因素或者其他理由，这种结果不见得都会成真。这就是为什么资讯建筑师必须准备好大声疾呼（至少以对等的职责发声），要选择和实作最适合用户的搜寻引擎，而不是选择那个只能在某人最爱的作业平台上跑的搜寻引擎，或者选择那个以某人最爱得程式语言写成的搜寻引擎。’
选择要搜寻什么
决定搜寻区域(search zone)
‘搜寻区域就是网站中的子网站，其内容的索引工作和网站其余的内容是分开来做的。当用户搜寻某一搜寻区域时，他已经由网站的互动介面，表明他只对特定资讯感兴趣。理想上，网站中的搜寻区域是对应到用户的特定需求，可以得到更好的取出效益。把和用户需求无关的内容剔除掉，用户应该可以取出更少更相关的结果。
…
所以，要小心：很多用户在开始搜寻时会忽略搜寻区域，而是倾向隅输入简单搜寻字串以搜寻整个网站的索引。所以，用户可能不会碰触你细心做出来的搜寻区域，直到他们经由“进阶搜寻”介面做第二轮搜寻之时。’这是非常自然的，但是又觉得有点累赘，那么是否有一种藉由使用者的搜寻经验直接来决定搜寻区域呢，这样不是可以减少两次或多次的搜寻吗？有IT正在做这一块吗？
导览 vs. 目的地
‘大部分网站至少有这两种网页：导览网页和目的地网页。目的地网页就是存放你想要的实际资讯：比赛分数、书评、软体文件等等。导览网页可能含有主页、搜寻页、以及帮助你浏览网站的网页。网站的导览网页最重要的目的，就是让你到达目的地网页。’
如果就工作达人来说，会分成分页跟内容，分页应该可以类比成导览网页，也就是说如果搜寻时也把分页当成结果列出看起来就有点乱了，但是实际上分页的目的又好像跟导览有些微的不同，毕竟还是看格主的使用方法，如果要界定清楚的话，那么工作达人的分页，可能就有再重新定义的必要了。另外ㄚ琪也发现，在Google的自订引擎的使用上，如果搜寻的资讯是分页有的话，确实会被列为结果显示，当然这跟这里所有诉求的目的可能就有点不同了，但是毕竟分页跟导览网页不同，所以这就见仁见智了。
替特定观众做索引
‘如果你已经决定采用以群众为导向的组织体系为架构，则根据群众做切割建立搜寻区域，也是很合理的。’在工作达人里头，ㄚ琪其实并没有掌握到很好的群众，所以要做这个索引，无形中就变得有点困难，让我们再加油吧。
以主题做索引
Ameriprise Financial采用松散的主题式搜寻区域。新版的搜寻系统还是保有类似这样的功能，而且看起来更有人性。
替新进内容做索引
这个功能到现在还是一直保有，看起来是很有用的功能。
选择要替什么内容元件做索引
‘对网站的某些局部内容提供取得管道通常是很有用的，同样地，让用户可以搜寻文件中特定的元件也有其价值。’这就跟ㄚ琪在前面导览 vs. 目的地那里提到的困扰一样。
以Salon.com网站为例，其搜寻系统可以让用户善用网站的结构，以下列内容元件支援搜寻：
- 文章主体
标题
URL
网站名称
连结
影像连结
影像的替代文字(alt text)
说明
关键字
远端锚点连结文字(anchor text)
像这样的功能，用户是否清楚并知道如何善用？确实有点矛盾，我想如果一般人如果没有读到这里，我想要思考这些功能的使用及差异，还真有点困难，至少对ㄚ琪来说是如此。
另外，内容元件不是只有增进搜寻精确度而已，还可以让搜寻结果的格式更有意义。
搜寻演算法
这里推荐你看这本Ricardo Baeza-Yates 跟Berthier Ribeiro-Neto写的 Modern Information Retrieval (Addison-Wesley)这本书啰。
样式比对演算法
‘大部分撷取演算法采用样式比对(pattern matching)的方法，也就是说，它们会比对用户的查询字串与网站文件全文的索引，以寻找符合的文字字串。’
检索和精准
这里头有公式：
检索 = #取出的相关文件 / #在集合中的所有文件
精准 = #取出的相关文件 / #在集合中的相关文件
另一个观念就是这两者是负相关，所以说鱼与熊掌不可兼得。
其他做法
‘当你有“好”文件在手上时，有些演算法会把该文件转换成相当于一个查询（这种做法就称为文件相似化(document similarity)。’
‘另一种做法是展示那些已经使用相类似的中介资料做过索引的结果。’不过书中所举例WebMD，现在已经没有提供See More Content like this。据我所知以前Google也会有这样类似的查询结果，不过这一阵子看来也没有了。
另外‘像是协同过滤法(collaborative filtering)以及引用搜寻法(citation searching)是更进步的作法。’像是CiteSeer会自动以多种方式寻找文件：
- Cited by
Active bibliography (related documents) - Similar documents based on text
Related documents from co-citation
查询辅助工具
‘查询辅助工具(Query builder)就是可以增加传寻效能的工具。’常见例子如下：
- 拼字检查工具
语音工具
词干搜寻工具
自然语言处理工具
控制词汇和汇编词汇
基本上这些辅助工具看起来只对英文语系的使用有帮助吧，中文语系的看起来可能没有帮助。
展示结果
要显示哪些内容元件？
‘最简单的原则就是，对那些已经知道自己要找什么的用户而言，资讯就少显示一点；但是，对那些不确定自己要找什么的用户而言，资讯就多显示一点。’
新的Salon网站看起来只有一个原则了，就是搜寻结果配有摘要，另外不提供摘要的选项，就不知怎么玩出来了。
要显示多少文件？
‘要显示多少文件，多数是由两个因子决定。如果你的引擎的组态是要替每一笔取出的文件显示很多资讯，可以考虑显示小一点的结果集，反之亦然。此外，用户的荧幕解析度、连线速率、以及浏览器的设定都会影响能够有效显示的结果数量。单纯化是最安全的，只显示一小群结果，但是，提供很多设定值，让用户可以根据其需求选取。’
另外有一个重要建议，就是一定要让使用者知道文件总数。
列出结果
‘列出结果的方法，常见的有两种：排序和等级。’基本上现在的Google这两方面都处理的很好，只不过排序上好像只限部份的网页的查询，像是部落格之类的比较多。
按字母排序
这排序法，砍起来就只对英文的abc有用了，中文看起来没啥大用。
按年表排序
像是工作达人就是以修改的时间来做排序的，为什么要这样做，只不过是因为ㄚ琪还一直在改部落格，这样子的排序方便我做修改。
按相关性分等级
这个演算法通常是按下列项目之一或其中几项决定的：
- 取出的文件中含有多少个查询字串中的术语？
这些术语在文件中出现的频率多高？ - 这些术语出现的位置有多近？
术语出现在何处？
查询术语出现所在文件的受欢迎度
依照受欢迎程度分等级
这是Google的PageRank，ㄚ琪不再赘述。
以用户或专家的平比分等级
‘愈来愈多的情况下，用户愿意评比资讯的价值。用户评比可以作为结果排序的基础。’像是Digg的情况。
以订单付费分等级
‘由于看板广告行销不再是最可行的经济模式，订单付费(pay-for-placement，PFP)变成Web搜寻中愈来愈常见的东西。’像Yahoo! Search Marketing就是这样，这到是很新鲜的结果显示，有空再多研究。
群组结果
‘另一种替代和分等级的做法看来是有希望的：依照某个共同的方面把结果群组起来。微软和加州大学柏克莱分校的研究人员所做的绝佳作法研究出，当结果按类别和等级群组时，可以改善效能。可以参考Dumais, S.T., Cutrell, E. 跟 Chen, H.的 “Optimizing search by showing results in context.” Proceedings of CHI ’01, Human Factors in Computing Systems (April 2001).
汇出结果
印出、寄送、或储存结果
考序列印文件和寄送文件的功能加进工作达人，这可能算新的创举，我可以想想看。搜寻了一下发现有Print Friendly and PDF Button这个外挂可以用。
选择结果的一部分
储存搜寻
‘在某些情况下，你想保留的是搜寻本身，而不是结果。对于你想按时追踪的动态领域而言，储存搜寻特别有用。你可以手动定时执行一个储存下来的搜寻，或者予以排程，使得查询定期自动重新执行。’
‘当结果变得比较“可携”时，就可以使用RSS或Atom做同步发表。’像Google Alerts的使用，这也是ㄚ琪常使用的服务之一。
设计搜寻介面
考虑的因素：
- 搜寻的专业能力和动机的程度
资讯需求类型
被搜寻的资讯种类
被搜寻的资讯数量
搜寻盒
进阶搜寻：说不
支援修改功能
在结果页中重复搜寻
说明结果来自何处
说明用户做了什么
整合搜寻与浏览
用户被绊住时
这个单位倒是ㄚ琪很想看的，用户被绊住时通常有两类，一是搜寻结果是0，Orz，另一种则是结果太多，这时该怎么办？
第二个问题较好解决，很多搜寻引擎都已经可以有效改善。
但是第一个问题可就大了，书中的建议是使用“无尽头”策略解决这种问题。可做的选择如下：
- 修改搜寻。
提供搜寻技巧或其他改进搜寻的建议。
浏览的工具。
如果搜寻和浏览无法运作，就与人接触。
上哪儿学更多？
接下来又要看更多的书了：
- Modern Information Retrieval 由Ricardo Baeza-Yates 跟 Berthier Ribeiro-Neto 合着(Addison-Wesley)。
- Concepts of Information Retrieval
由 Miranda Lee Pao (Libraries Unlimited)所著，已经绝版。
- On Search, the Series 由Tim Bray所著(http://www.tbray.org/ongoing/When/200x/2003/07/30/OnSearchTOC)。
学习搜寻工具的网站：http://www.searchtools.com/
以及http://searchenginewatch.com/
这一章看了好久才看完，当然提到了一些观念希望可以对工作达人有用。