• 發行項

本文章是由機器翻譯。

展現可用性

可尋性的關鍵在於搜尋

Dr. Charlie Kreitzberg 和 Ambrose Little

在本專欄中我們指有關搜尋。搜尋會開啟在許多地方中。Web 站台內它們經常是瀏覽的使用者 ’s 第一個選擇。社交網路站台內它們可讓使用者找出相關的群組。在商務應用程式中，它們是工具，可尋找個別記錄以及建置報告。搜尋，與一個尺寸不適合所有。小心和創造力與您必須設計搜尋工具在應用程式中可以真的有一個影響使用者經驗。

最佳作法與模式


Ambrose Little

在過去說話搜尋是不的開發人員傾向於很多考慮一下，除非它們適用於 Google 事項之一。  在許多的 IT 應用程式中它 ’s 東西我們排序的 slap 的結尾。  Web 網站上通常是相同 — 我們假設我們可以利用搜尋應用裝置或搜尋設備，某些其他簡單關鍵字，並在某些情況下我們保留它向上完全於 Bing、 Google、 Yahoo 或另一個的搜尋引擎。

當我們自己實作搜尋時，有 ’s 通常二進位切換在 「 簡單 」 和 「 進階 」 之間我們心智與我們組成大部分或全部的索引鍵屬性的表單我們物件擲回的 「 進階 」 意義、 新增一些下拉式清單，讓人們前往城鎮。

我們可以和應該用搜尋更好做。無論我們不是我們的資訊架構，我們 nail 到搜尋的點的機會的特殊功能所需的程度是低，和它成長接近零越我們新增內容、 物件和資料到我們的解決方案。

搜尋需要時在思考您的方案供為最上層的考量。它應該是那裡連同安全性、 效能和其他需求的交叉剪下考量的一部分。  在實際上您可以更一般呼叫搜尋 「 findability，」，因為實際上是您需要認為不只是搜尋的角度還在尋找資訊的其他方法方面。

Donna Spencer 發現有四個使用者使用他們的搜尋資訊時的常見模式 (請參閱 boxesandarrows.com/view/four_modes_of_seeking_information_and_how_to_design_for_them )：

  1. 當他們知道什麼他們想要具有以說明它的文字，請尋找的東西。
  2. 探索如果它們有只有某些和的概念什麼他們想可能缺少文字來表達它。
  3. 當他們 don’t 知道他們的需要，請尋找相關項目。
  4. 尋找東西他們已經見過。

這些模式可能是啟動時的一般考慮 findability 的好地方。  (順帶到最 「 findability 」 已 coined Peter Morville 由他書籍 環境 Findability [O’Reilly 2005] 中。我認為它 ’s 很棒的詞彙交叉剪下考量和品質我們 ’re 這裡之後加總。of course，瞭解和專業領域參與這返回方式 — 到前一詞已 coined — 在資訊和程式庫科學)

其他研究人員有研究並寫入關於 「 資訊 foraging 」 (Peter Pirolli 和蔡卡，「 資訊 Foraging 中資訊存取環境，」 1995年) 和 「 berrypicking 」 (Marcia J.Bates，「 的瀏覽的設計和線上的搜尋介面的 Berrypicking 技術 」 1989年)。最近，某些 theorists 正在建置這些和其他建議更專注的 subdiscipline 「 探勘搜尋 」 的想法上 (Ryen 白色及 Resa 洛斯 「 探勘搜尋：超過該查詢回應典範，」 2009年)。

什麼似乎是常見的執行緒在這些 thinkers 之間是尋找資訊 (或您想要處理的物件) 的是不直接瀏覽] 或 [的操作直接了當的詢問-和-尋找方法。  它通常是模式，和不只如此的組合 — 人們傾向於使用 「 發展搜尋，」 的新識別、 有用的資訊時找到搜尋它們可用來進一步調整及增強的主題，以及其搜尋其知識。

什麼這建議幾乎是需要我們為建立者，以啟用這種尋找 — 思考搜尋索引鍵的啟用尋找它們需要尋找的人及其他方式探索與整合的一部份。

我們如何可以做呢？

如已所述確保 findability 其中一個交叉剪下考量您位址在您的解決方案中是索引鍵。有 ’s 很大說只要將它放在您檢查清單上和並確認您認為其相關資訊。  方案 ’s 也許需要 findability 是小於比在其他人 ； 也許它 ’s 最重要的品質。  您 won’t 知道是否 don’t 擔心它思考。

從實作觀點來看，您需要思考正式資訊結構，如我們述 �Strategies 為設計應用程式 Navigation� (msdn.microsoft.com/magazine/dd458810.aspx) 和再個別的檢視及螢幕 (請參閱 �The 螢幕 Design� Tao 在 msdn.microsoft.com/magazine/ee413547.aspx)。 搜尋，第一步是試著取得瞭解何種搜尋表示您的方案的內容中而您的方案 (比方說應用豐富型用戶端程式來處理貸款應用程式) 的內容可以幫助您認為有關何種搜尋是比 others.� 貸款應用程式與公用的行銷網頁 site�the 搜尋需要 Web 站台的對比更有幫助您 users.� 都可能非常 different.�

在第一種情況下方案內容是使貸款處理器在處理貸款應用程式有效。  該資訊是私用和在組織內緊密控制。在第二個方案內容是散發資訊，而教育有關產品或服務與一個檢視來推動銷售人員。這裡，資訊是公用，並適合盡可能廣泛 disseminated。

內部、 物件/交易導向的解決方案

通常使用貸款應用程式的人員需要尋找特定的貸款的應用程式、 其工作的應用程式群組、 相關的應用程式的一種情況中的型別，因此 forth. 就像這樣，應遵守這些人如何尋找今天這個資訊並給他們談論他們痛苦 points。 您可以要求建議，但請記住您不應該依賴它們的想法如何改善這些 processes�you 在唯一的地方來建立新的和較佳方式可讓他們能夠找到他們不可能有 dreamed of. 方式的資訊另一台不錯的方面的這種情況是，使用者的目標且業務通常 align�the 商業希望使用者使用更有效率且經常那麼做人民。

是否有像這樣的解決方案，您可以考慮使用資料表篩選條件模式 (請參閱 的 圖 1) 為工時與模式的一部份。  如果有意義的主要屬性可用您可以使用的字母順序排序，您也可以加入英數篩選連結。  作用中篩選也可能是很好的選項。  這些和其他相關的搜尋模式中找 Quince 在 quince.infragistics.com 。


圖 1 的 Excel 的資料表篩選條件範例

公用/資訊導向方案

公用的行銷 Web 網站，使用者 ’ 目標經常演變。其目標也可以是更廣泛，其內容可以變動等等。  很少是使用者 ’s 前來站台，並立即轉換成一個銷售的主要目標，但如果的 ’s 大小寫，使用者可能已瀏覽之前，可能知道完全什麼她想，並可能知道如何輕鬆地尋找。  像這樣的使用者已經有購買，而且想要從您購買。shouldn’t 忽略了這些人，但往往似乎當作結果的決策者太多 navel gazing 是假設的人物代表的行銷資訊的網站。

更常人前來類與模糊的概念，您是誰，而且您可以執行的網站。它們可能甚至不是購物 per 哪但只試著尋找相關項目做什麼的相關資訊。他們或許聽過您，而想要知道更多，或或許他們使用您的產品和將要顯示 [說明或想要 upgrade. Often 它們遇到到您透過某種搜尋，即使該搜尋不只是在您公司 name. Ive 甚至看到人鍵入 URL 到的點是公用網站的考慮如何公用搜尋引擎公開您人是 key probably 更因此比您自己的本機 search. 搜尋 engines.

但人們也想要能夠在本機搜尋，一旦在網站上必須是 (通常錯誤) 您的本機搜尋結果將會比它們可能從 Bing 或 Google 取得更好。  更進階的使用者可能知道搜尋語法的範圍設定那些引擎一個網站上的搜尋，或者或許他們必須要執行這項操作，工具列。  但您 shouldn’t 仰賴的而且，您可能會錯過的方式可以提高一般關鍵字搜尋，因為您可以在您自己的網域範圍某些機碼。

faceted 導覽

在公用的搜尋引擎上改善這種方法之間的鎮長是稱為 Faceted 瀏覽模式。儘管它的名稱這種模式是真的更多關於篩選搜尋結果 (也稱為是 Faceted 搜尋)，及近年來，它已經成為頂端的方式來處理搜尋，並特別是搜尋結果。正式的範例是 Amazon.com。的 圖 2 所示，側邊列，亞馬遜提供您能夠由各種 「 Facet 」 (也稱為屬性、 屬性、 類別，等等) 篩選結果。


圖 2 的 Amazon.com 的 Faceted 導覽

您在 的 圖 2 中看到 (此圖例中已一起 spliced — 通常這些資料行堆疊垂直左邊) 的類別、 品牌、 賣方、 價格、 Megapixels、 光學縮放、 顯示大小、 影像穩定性和 Viewfinder 類型 Facet。  在這些 Facet 是特定、 有意義的值或屬於 Facet 的值的範圍。  檢視可讓您清除出選取的一環使用任何選項上方的每個標題區段中。  它也顯示您如果依特定 Facet ’s 值篩選之後可預期結果中的項目數目。Facet 是不累積 — 亦即它們會影響 AND 布林運算子。

雖然圖中未顯示上亞馬遜, 階層連結被擴大時挑選一個可幫助加強哪一個使用者選取，顯示的順序 (記錄) 它已選取且可讓人們跳回按一下篩選的幾個步驟的 Facet。

這個模式的許多其他良好範例存在 (這就可以看到 Quince 上以及其他地方)。 不錯的比較最佳並不讓好作法，讀取 Greg Nudelman ’s 最近分析的 Office 軍火庫探討哪些他會比較亞馬遜 ( new.uxmatters.com/mt/archives/2009/09/best-practices-for-designing-faceted-search-filters.php )。 並進行目前的搜尋結果技巧，跨越主要網際網路插座的深入比較，檢查 「 搜尋結果設計：最佳作法與設計模式 」 由路易 Lazaris ( smashingmagazine.com/2009/09/28/search-results-design-best-practices-and-design-patterns/ ) 與搜尋結果模式中 Quince 一起。(有 ’s 搜尋標記，您可以在中使用 Quince 相關模式 ； 請參閱 quince.infragistics.com/#/Search$tag=Search )。

忘記關於進階搜尋

您可能會注意到，你-olde 「 進階的搜尋 」 有不被此處所討論。  ’s 因為在大多數情況下您應該嚴重考量消除完全在改由 Faceted 功能。  這 isn’t (無疑您思考主要的搜尋引擎上的 [進階搜尋] 功能) 的通用原則，但是除非知道您的使用者進階，而想這項功能可能 shouldn’t 執行它。您通常可以達成相同的目的，並取得更好的結果與 Faceted 功能。以下是原因：

  1. faceted 導覽 doesn’t 需要預付的決策，決定要使用哪一個 Facet。人可以引發一個擷取畫面，並調整結果。
  2. faceted 功能可以和應該要提供有意義的選項，以篩選出設定的結果的相關知識的使用。(，例如如果 $ 300–500 範圍不包含任何項目，有 ’s 加以顯示，或由它讓人篩選器中的沒有意義)。
  3. 因為的輕量的感覺特別是如果您使用立即更新為在作用中篩選 (請參閱 kayak.com) 人員覺得 freer 快速試 Facet 尋找他們想要的不同組合。

考慮限制結果集

限制結果集是個人設計喜好設定不硬和快速規則，但請考慮保持得像頂端 50 或 100 結果的結果集，特別是如果您有某種的排序和篩選就地。成長疲憊和想要篩選、 排序，或請嘗試不同的搜尋之前，人們 won’t 有效地更多掃描。藉由限制結果，您可以：

  1. 避免正式分頁、 從介面移除不必要的複雜性和儲存開發 UI 的那個部份的成本。
  2. 鼓勵使用的排序及篩選設施，這最後會讓人更有效率中使用搜尋設施且與他們取得超出它們更快樂。
  3. 改善整體效能。其中一個應用程式中常見的效能 killers 不管理搜尋結果也藉由嘗試抓取或載入太多結果。

’re 可能不定的這個最後的設計建議，但不妨試試 — 會感到驚訝。成本小於實作分頁，且分頁可新增稍後如果您想。  我會加入分頁，只有當可用性測試或問題的本質變得清除該讓它們更多的結果比不讓它們更好。

其他應考量的因素


Dr。Charles B.Kreitzberg

通常使用者挫折很多，就會發生周圍的搜尋。這反映出基礎一併搜尋的認知工作的複雜性是取得工作完成其重要性。如同所有設計您得到最佳的結果，當您了解並對齊使用者需要完成的工作和心理模型與能力分析。

使用者通常為他們想要查看的模型引用 Google ’s 搜尋方塊的簡易性。為什麼人們回應簡單的搜尋方塊的容易，但並非每個搜尋符合這個範例，它 ’s 理解。雖然它 ’s 不一定有可能建立更結構化的使用者介面不是有效的搜尋工具，謹慎設計的搜尋畫面真的可以簡化 UI。

最近，我是參與的 Web 應用程式在哪一種搜尋是重要的元件重新設計。它用在幾種方法：在首頁上 ； 一系列的特殊搜尋各有不同的商業用途 ； 以及報告工具快速的搜尋。這些年來，此應用程式已被更新並修訂，搜尋畫面數目 proliferated，每一個與其他稍有不同。

當我們仔細分析搜尋畫面我們發現就像所有基本上類似，我們可以建立併入它們全部的單一搜尋畫面。我們藉這可讓使用者從下拉式清單中選取搜尋和自訂依據選取範圍的搜尋參數。結果排除特殊的搜尋畫面，並取代成單一且更具直覺性搜尋工具。這是 UI 的與沒有遺失功能大幅簡化。

搜尋發生錯誤

搜尋設計經常發生錯誤有許多地方。以下是留意的三件事：

  1. 混淆 SEO 的搜尋。某些商業用戶端一詞 「 搜尋 」 表示搜尋引擎最佳化。SEO 是非常重要，但它並不使用性或使用者經驗。進行搜尋 UI 區別 SEO 是很重要的播放軌上保留您與商業用戶端的討論區。

  2. Pogosticking。思考 pogo 搖桿向上及向下跳某人。當使用者需要保留按一下搜尋結果以判斷哪一個是想要的項目上，您會得到類似的模式。  let’s 說出您尋找名稱為 Bob Smith 的客戶，並具有數個 Bobs 和幾個 Roberts 取得搜尋結果。您需要按一下結果清單向下，直到您找到您想要的客戶，這可以成為真正的可用性問題。您可能要閱讀的圖庫 (( uie.com/articles/galleries/ ) 的內容中 pogosticking Jared 多工緩衝 ’s 討論

    以下是您可以對進行 pogo 搖桿問題減到最少的兩個動作：

    將放置在搜尋結果中的使用者可以判斷項目關聯，而不需要造訪詳細資料頁足夠資訊。要非常小心有關您使用，因為這些都是使用者的重要提示的標題。比方說代替這種的 [結果] 項目：

    如果您可以提供一個更有意義的結果這類的請參閱：

    讓詳細資料可以使用 「 垂直導覽 」，如此使用者可以查看詳細資料、 關閉它們並放回在搜尋結果。目標是要避免讓使用者離開搜尋結果網頁，然後需要回瀏覽。(請參閱我們討論的瀏覽在三月 2009年問題的 msdn.microsoft.com/magazine/dd458810.aspx 在 MSDN Magazine )。

  3. 分頁。當您很多搜尋結果的分頁可以是針對 comprehensibility 和效能很重要。但當有很多頁面並沒有方法可以判斷哪一個具有項目使用者想分頁可以是使用者的夢魘。請試試這個 Amazon.com 上：尋找活頁簿上醫療練習由作者名為 「 Smith 」。當我已它嘗試過得到透過 11,000 拜訪人次與只顯示此前三個網頁。Jakob Nielsen 備忘稿 「 使用者幾乎永遠不會尋找第二頁的搜尋結果超過 」 ( useit.com/alertbox/20010513.html )。

    分頁可能很棘手的技術問題到地址，因為您經常 don’t 知道想要的項目所在或甚至幾個頁面是實際需要。但如果您可以提供線索到何處尋找有關使用者，您可以減少人力和挫折。

思考搜尋 UI 設計

用於建立完美搜尋設計沒有魔法但以下是一些您可以採用您自己的狀況的問題。請記住在單一應用程式可能有數種類型的搜尋，它通常是個不錯的主意，朝簡單、 完整 UI 可以支援各種類型的工作。這可能是極具挑戰性的工作。

  1. 資訊搜尋您預期的型別是高階了解的開頭。如 Ambrose 建議，像 Donna Spencer ’s 四種模式的資訊搜尋分類很有幫助。另一個分類是 Whitney Quesenbery、 Janis Morariu 和我所開發分類資訊搜尋的方法 ( wqusability.com/articles/search-usability.html )。它會定義五種類型的資訊搜尋：
    • 瀏覽 — 我想要探索什麼 ’s 可用，請參閱。
    • 尋找 — 我要找出特定的東西。
    • 查詢 — 我想要查看符合我準則的項目。
    • 結構化 — 我想要透過一系列的選擇來協助我縮小我焦點率領。
    • 指引 — 我要領導透過該資訊。
  2. 請考慮搜尋的網域。您處理與高度複雜的網域或簡單的一吗？您需要處理哪一種查詢？您需要處理同義字和暱稱嗎吗？是否日期或日期範圍的重要吗？是否記錄不同，或者不會需要使用者明確執行類似的記錄之間吗？
  3. 請考慮您的使用者的能力。希望就是被研究您的使用者而建立人物代表，因此，這應該是簡單的問題來回答。您想要知道：
    • 如何熟悉是它們與正在搜尋的網域。他們知道術語嗎吗？
    • 如何複雜是制定搜尋查詢的能力的使用者？
    • 是否以精簡一個結果能夠建立後續查詢使用者設定吗？(許多無法)。

明確定義搜尋任務內容。通常，搜尋工作會較大的工作序列中的第一個步驟。清除上為什麼搜尋使用者以及使用者會執行什麼動作以結果項目 (或項目集) 一旦找到存在。如果使用者有 repetitively 處理資料錄 (搜尋，找出記錄、 處理資料錄並再回到結果清單中選取另一筆記錄)，請確定流程是簡單且清楚。

決定將呈現結果清單的方式。您應該設計來提供簡易的視覺化掃描和識別項目的結果清單。若要避免發生太多的小頁面的混亂，(如果您使用的分頁)，將足夠的項目放在每一頁上。(我經常發現 50 開始的是一個很好的數字)。

還有什麼是要說？

搜尋是複雜的工作，另一個細心的設計可以讓使用性和使用者經驗的真正差異。時間和精力真正思考設計做可以付清。  以下是一些實用的考量可以請記住：

  • 搜尋，和更廣泛 findability，是大部分的解決方案的關鍵這些天，事先連同其他交叉剪下考量中考量。
  • 當接近搜尋時，請考慮您方案的內容和您的使用者的內容。您瞭解這些項目的通知如何在您的解決方案中支援搜尋。
  • 思考如何搜尋可以互補其他形式的資訊搜尋。
  • 如果您的方案 ’s 資訊公用，請仔細考慮有關如何最佳方式公開透過主要的搜尋引擎。
  • 新增至本機搜尋的值，透過公用引擎透過 Facet 您網域中的使用。
  • leverage 已知的模式和實務來協助賦予圖案至您的搜尋方案。 

看看大傢伙，範例，但永遠適應或排除它們提供的應用程式和您的使用者內容中有意義。

Dr。Charles Kreitzberg 是 Cognetics Corp.執行長(cognetics.com) 可提供可用性諮詢和使用者經驗設計服務。他的熱情就建立交戰和 delight 使用者同時支援產品 ’s 業務目標的直覺化介面。Charles 居住在中新增運動衫，他 moonlights 作為執行音樂家。

Ambrose Little 居住與他的妻子和中央新增運動衫的四個子系。他是被設計和開發 10 年以上的軟體是締結 INETA 演講者及 Microsoft MVP。最近，他的移位從技術設計人員的設計，現在是 Infragistics 使用者經驗設計工具。