Yo!Search Systems

這是資訊架構學–網站應用,第三版的第八章:(),在上一章有可以幫你替網站建立最佳的導覽系統。這一章要說明另一種尋找資訊的形式:搜尋。想到搜尋ㄚ琪很直覺得就是Google了,可是Sophia卻是Yahoo,這當中還真有點差異,但是在工作達人上的搜尋又是怎樣呢?其實很早以前是有另一種搜尋系統的,是Wordpress預設的,但後來ㄚ琪棄守了,今天讓我再來看看,是否有新的搜尋技術,可以讓我變更目前的搜尋方式,現在讓我們讀下去吧。

昨天再去Google的自訂搜尋引擎發現有新版的功能,而這新版的功能看似好像可以符合ㄚ琪的需求,不過完了半天也是還沒搞定,看起來滿複雜的,特別是中文的部份很弱,所以很多是英文的說明,或許過些陣子可以改善,我們就拭目以待吧。

試了幾天的新功能,感覺中文方面的功能好像不是很齊,所以就先繼續使用元來的搜尋功能了。

網站需要搜尋功能嗎?

替網站建構搜尋系統前,先想想下列的問題。

  • 網站有足夠的內容嗎?
    投資搜尋系統會不會轉移更有用的導覽系統的資源?
    你有時間和技術替網站搜引擎做最佳化工作嗎?
    有更好的替代方案嗎?
    網站用戶討厭搜尋嗎?
    綜合上述地問題,可以再度地幫助ㄚ琪思考是否真的需要搜尋功能,不可諱言地,ㄚ琪是覺得對於一個部落格而言,搜尋功能實屬必要,當然導覽系統的充分利用也是需要考慮到的,這個導覽系統ㄚ琪以前倒是沒有特別注意,不過我想從今天開始會好好注意的,另外值得一提的是搜尋引擎最佳化的工作我們是否做得來,當然,現在WordPress已經提供了很好的搜尋,另外像Google也有自訂引擎,可是如果捫心自問,他們是否都做了最佳化,這就比較不清楚了,但是如果我們的技術跟時間不足的話,使用這些預設的功能,其實感覺起來還滿好的說,不過這可能是自我感覺良好吧。更好的替代方案:網站索引是否合適也值得列入考慮。我的客戶是否討厭搜尋,我想就有待各位提供意見了。

如果已經有必要建構搜尋引擎,基本上ㄚ琪想應該會是需要的,否則就沒有這一章內容存在的必要了,你說是不,現在要繼續探討何時建構:

  • 有太多資訊要瀏覽而搜尋會有幫助時
    搜尋可以協助成片斷的網站
    搜尋是學習工具
    搜尋應該在那兒,因為用戶希望在那兒
    搜尋可以馴服動態性
    當有這些條件成立時,我想就是建構搜尋系統的時候吧。
  • 搜尋系統詳解

  • 這裡有一個來自In Defense of Search的圖解,大體而言者裡頭牽涉到的技術還不少,像是查詢語言、查詢輔助工具、中介資料、控制詞彙、排名與叢集演算法、介面設計等等。這些是否全留給IT來處理,就看你囉。

搜尋不是一種IT玩意

這裡頭就節錄文中有關資訊建築師應該要做的事,『理想上,資訊建築師、IT專家、以及其他專長的人會找出他們各自的需求,討論這些需求對彼此的衝擊如何,最後在評估搜尋引擎程式時,再列出一組統一的需求。可惜的是,因為某些政治因素或者其他理由,這種結果不見得都會成真。這就是為什麼資訊建築師必須準備好大聲疾呼(至少以對等的職責發聲),要選擇和實作最適合用戶的搜尋引擎,而不是選擇那個只能在某人最愛的作業平台上跑的搜尋引擎,或者選擇那個以某人最愛得程式語言寫成的搜尋引擎。』

選擇要搜尋什麼

決定搜尋區域( zone)

『搜尋區域就是網站中的子網站,其內容的索引工作和網站其餘的內容是分開來做的。當用戶搜尋某一搜尋區域時,他已經由網站的互動介面,表明他只對特定資訊感興趣。理想上,網站中的搜尋區域是對應到用戶的特定需求,可以得到更好的取出效益。把和用戶需求無關的內容剔除掉,用戶應該可以取出更少更相關的結果。

所以,要小心:很多用戶在開始搜尋時會忽略搜尋區域,而是傾向隅輸入簡單搜尋字串以搜尋整個網站的索引。所以,用戶可能不會碰觸你細心做出來的搜尋區域,直到他們經由「進階搜尋」介面做第二輪搜尋之時。』這是非常自然的,但是又覺得有點累贅,那麼是否有一種藉由使用者的搜尋經驗直接來決定搜尋區域呢,這樣不是可以減少兩次或多次的搜尋嗎?有IT正在做這一塊嗎?

導覽 vs. 目的地

『大部分網站至少有這兩種網頁:導覽網頁和目的地網頁。目的地網頁就是存放你想要的實際資訊:比賽分數、書評、軟體文件等等。導覽網頁可能含有主頁、搜尋頁、以及幫助你瀏覽網站的網頁。網站的導覽網頁最重要的目的,就是讓你到達目的地網頁。』

如果就工作達人來說,會分成分頁跟內容,分頁應該可以類比成導覽網頁,也就是說如果搜尋時也把分頁當成結果列出看起來就有點亂了,但是實際上分頁的目的又好像跟導覽有些微的不同,畢竟還是看格主的使用方法,如果要界定清楚的話,那麼工作達人的分頁,可能就有再重新定義的必要了。另外ㄚ琪也發現,在Google的自訂引擎的使用上,如果搜尋的資訊是分頁有的話,確實會被列為結果顯示,當然這跟這裡所有訴求的目的可能就有點不同了,但是畢竟分頁跟導覽網頁不同,所以這就見仁見智了。

替特定觀眾做索引

『如果你已經決定採用以群眾為導向的組織體系為架構,則根據群眾做切割建立搜尋區域,也是很合理的。』在工作達人裡頭,ㄚ琪其實並沒有掌握到很好的群眾,所以要做這個索引,無形中就變得有點困難,讓我們再加油吧。

以主題做索引

Ameriprise Financial採用鬆散的主題式搜尋區域。新版的搜尋系統還是保有類似這樣的功能,而且看起來更有人性。

2011-08-16_172514

替新進內容做索引

2011-08-17_143905

這個功能到現在還是一直保有,看起來是很有用的功能。

選擇要替什麼內容元件做索引

『對網站的某些局部內容提供取得管道通常是很有用的,同樣地,讓用戶可以搜尋文件中特定的元件也有其價值。』這就跟ㄚ琪在前面導覽 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也會有這樣類似的查詢結果,不過這一陣子看來也沒有了。

2011-08-22_171350

另外『像是協同過濾法(collaborative filtering)以及引用搜尋法(citation searching)是更進步的作法。』像是CiteSeer會自動以多種方式尋找文件:

  • Cited by
    Active bibliography (related documents)
  • Similar documents based on text
    Related documents from co-citation

查詢輔助工具

『查詢輔助工具(Query builder)就是可以增加傳尋效能的工具。』常見例子如下:

  • 拼字檢查工具
    語音工具
    詞幹搜尋工具
    自然語言處理工具
    控制詞彙和彙編詞彙

基本上這些輔助工具看起來只對英文語系的使用有幫助吧,中文語系的看起來可能沒有幫助。

展示結果

要顯示哪些內容元件?

『最簡單的原則就是,對那些已經知道自己要找什麼的用戶而言,資訊就少顯示一點;但是,對那些不確定自己要找什麼的用戶而言,資訊就多顯示一點。』

2011-08-25_152619

新的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,另一種則是結果太多,這時該怎麼辦?

第二個問題較好解決,很多搜尋引擎都已經可以有效改善。

但是第一個問題可就大了,書中的建議是使用「無盡頭」策略解決這種問題。可做的選擇如下:

  • 修改搜尋。
    提供搜尋技巧或其他改進搜尋的建議。
    瀏覽的工具。
    如果搜尋和瀏覽無法運作,就與人接觸。

上哪兒學更多?

接下來又要看更多的書了:

學習搜尋工具的網站:http://www.searchtools.com/

以及http://searchenginewatch.com/

這一章看了好久才看完,當然提到了一些觀念希望可以對工作達人有用。

馬上成為工作達人的Fans

About ㄚ琪

工作達人Fun Taiwan的創辦者及總編,可以在這裡更認識他。

發表迴響

你的電子郵件位址並不會被公開。 Required fields are marked *

*

這個網站採用 Akismet 服務減少垃圾留言。進一步瞭解 Akismet 如何處理網站訪客的留言資料

Scroll To Top