最近忙著畢業設計,需要文獻翻譯。本想隨便那之前翻譯的交個差,但總覺不夠嚴謹。我的畢業設計主要是幫老師的研究所做個網站,本來已經有網站了,但老師和我都覺得老版本的網站很是陳舊。於是毛遂自薦。
網站需要重構,自然信息架構部分也是重要的一環,雖然之前也看了不少,比如《下廚房的搜索OR分類之思》即是思索的痕跡,但還是系統地翻譯了Five Simple Steps團隊著作的《A Practical Guide to Information Architecture》其中一個章節:《IA Patterns》。 (對於這本書,網上有PDF文檔流傳,由於個人潔癖,就不貼出來,需要的可以留言。另,需要本章節PDF的亦可留言索要。)
——Start——
這一章都是關於信息架構的模式——主要是針對不同類型網站的信息架構所需的一些通用方法。希望能夠拋磚引玉,當你構建自己網站的信息架構時,能夠從這些模式著手開始。當然,前提是你的網站得符合這些模式中的一類,或者是他們的結合。
模式是什麼
一種模式即是對於一類頻繁遇到的設計問題的通用解決方法。
模式的思想來源於建築[1]。正如你所想像的,建築物有許多普遍的問題等待解決——食品準備區和食品服務區間的關係,人們如何進入一幢建築,以及房間的內飾怎樣與屋外和諧相處等等。
模式在軟件開發領域也非常普遍(一些問題屢次出現),提供一些軟件設計的解決方案給開發者們。交互設計也同樣如此,一些可複用的解決方案浮出水面,通用的需求譬如有登錄表單和分頁設計。
模式中很關鍵的一點是這些想法都是來自真實世界的需求。你不必坐下來冥思苦想,為一個全新的領域創建一套模式。以下我們討論的模式都是“勞動人民”智慧的結晶。
信息架構模式
信息架構與人們需要使用信息的很多領域都有關。下面我將闡述每個模式的特點,使用場景,並提供相關案例。
首先我將討論四種簡單模式(層級、數據庫、超文本和線性)以及三種的結合。
簡單模式
層級
在層級的概念中,類目之間關係是父子關係或者廣義與狹義——即抽取為更廣義的群組或者是分解為更具體的群組。
層級結構可以描述為扁平式和錐形式:
- 扁平的層級結構特點是:頂層有很多類目,但層級數較少;
- 錐形的層級結構特點是:頂層類目較少,但層級數很多;
一個層級結構也可以描述為嚴格型(strict)和多元層級型(polyhierarchy):
- 嚴格型層級中,一個類目只能處於一個位置;
- 在多元型層級中,一個類目能夠置於多個位置;
現實世界裡,嚴格型層級結構是必須的——畢竟一個實體一次處於不同地方是不可能的。然而,在數字世界裡,我們很容易就能讓一個東西置於很多地方,且很好的解決了現實裡類別混亂的局面。我們能夠將東西放在期望看到的多個位置,並且允許類別邊界的重疊。
層級結構是組織信息所使用的最簡單和常規的方法,適用於內容範圍很廣。尤其適用於小型站點,僅僅需要一些簡單的層級——頂層(首頁),一些二級頁面和底層的詳細頁面。
同樣,層級結構對大型站點也適用。尤其是那些內容型的網站(內容雜亂多樣)。即使你的信息複雜度各異,層級結構也有作用。例如,你首先可以展現綜述信息,然後允許用戶根據需要細分出更多詳細信息。
3次點擊的“魔咒”
很多年來,一直有個“傳說”:每個具體內容從首頁進入時都應該少於三次點擊。
對於很多網站來說,這簡直是天方夜譚。按它這麼操作,很多網站每個層級的類目將會多的讓人無從選擇。
相反,更重要的應該是讓用戶在每個層級都能輕鬆決策,並告知其處於正確的路徑。如果用戶覺得自己的操作是正確的,那麼他們會按照自己的意圖進行瀏覽學習。
圖片16-3:CHISIG(Computer-Human Interaction Special Interest Group)是一個小型的組織且信息量也很少。 簡單的層級結構就很有效。
圖片16-4.白宮官方網站有許多內容,但仍然採用了基礎的層級結構。 (whitehouse.gov)
數據庫
這裡討論的數據庫並不是一種技術對象——各種信息的數字化存儲,而是一種概念模式。
它們的相同點都是具有特定規劃的結構或模型,所有的信息都必須來適配於這些結構。所以你不能強加一些不適合此模型的東西。
數據庫模式針對的是具有一致性結構的內容。有些內容可能與其他的沒有直接關係——它們確實不具備層級內容裡所需的父子關係——但是它們都由相同的內容塊組成,擁有相同的結構。
例如,etsy網站,這兩個類目沒有任何共同點:
圖片16-7. Sleepy time (來自esty.com)
圖片16-8.Headbands (來自esty.com )
但是它們具有相同的內容塊來構成列表:
- 標題
- 描述
- 標籤
- 材質
- 位置
- 付款方式
- 創建日期
- 照片
- 類別
- 顏色
即etsy上的每個產品都是相同的結構。
數據庫模式應用場景要么是較小的信息集,要么是很大的數據集。
數據庫結構最大的優點是一次性儲存數據,然後可以使用不同的數據塊和方式來展示信息。例如,在etsy裡,你可以通過類別、顏色、位置甚至是最近更新(很小的層級)來尋找內容。這給了用戶很多途徑來發掘他們自己感興趣的信息。
數據庫結構適用於音樂、產品目錄、書籍、文章、博文等等具有一致性結構的內容。它為用戶提供了很多進入內容的入口。例如,flickr(flickr.com)中,你能夠通過攝影者、相冊集、小組、最受歡迎和標籤來發掘照片。
元數據
元數據通常被定義為“關於數據的數據”或“關於信息的信息”。這種定義雖然不是很有幫助,但是很準確。元數據就是所有的與內容塊相關以及描述內容塊的信息。
有三種不同類型的元數據:
- 固有數據(Intrinsic):對象實際是什麼
- 管理型(Administrative):它是如何使用
- 描述型(Descriptive):類目的描述
比如UX Australia博客,元數據可能包括:
- 類型:博客發表的文章(固有數據)
- 作者(管理型)
- 發表時間(管理型)
- URL(管理型)
- 狀態:已發表(管理型)
- 標題(描述型)
- 分類(描述型)
- 標籤(描述型)
這些元數據主要用於兩件事情:
- 生成特定的內容列表(例如,展示'Announcements'類別下的所有內容)
- 選擇頁面中需要展示的內容(例如,包括標題、作者、描述、分類)。
當然,項目最困難的部分莫過於決定收集哪類內容和他們的內容是什麼(或者你將使用哪些分類)。
超鏈接
超鏈接模式是信息架構中很有趣的部分,因為它似乎是一種反結構(anti-structure)模式。內容塊僅僅根據相互關係來進行連接。與層級或數據庫不同的是,不存在主結構——內容僅僅通過鏈接進行連接。
超鏈接結構最佳案例是維基(wiki)。維基沒有預先規劃的結構——內容僅是通過內嵌的鏈接產生聯繫。
維基百科(Wikipedia)就是最好的註解。維基百科的內容並沒有主架構,也沒有很健壯的數據庫結構。 (沒錯,他是儲存在數據庫中,且有一些基礎的數據塊,例如表頭、描述等。但是它不是上面所述的“數據庫結構”。)每個頁面都是獨立的,通過相關鏈接與其他頁面進行連接。
如果內容已經創建了一段時間,但你仍然不確定構建的東西,那麼超鏈接結構特別有用。在這種情況下,預先確定詳細架構甚至是為網站確定基本模式都是不可能的。許多文檔項目都是這樣起步的——人們首先寫出獨立的文檔頁面,然後忙著通過鏈接來創建文檔關係。
許多網站開始時都是超鏈接結構,當內容確立後,才進行重構。
超鏈接結構的主要問題在於:該模式的成功很大程度上取決於人們在內容塊間創建的聯繫。對於層級結構,你能很清楚地看到下一級;對於數據庫模式,你能展示一種特殊類別的所有內容;但對於超鏈接結構,它本身並沒有能力自動展現關聯內容。如果作者沒有創建鏈接,用戶就根本有辦法發現信息。
線性
線性模式,顧名思義,按照直線規則一個跟隨著另一個。
線性模式並不常見——通常使用該模式是為了用戶能夠按照他們所理解的方式跳轉內容。
如果你遇到一種情境:當用戶轉移到另外一件事前,必須先理解一件事情,那麼很適合使用線性模式——通常例如,教學資料。如果用戶實際並不需要按特定規則閱讀的話,就不要使用線性模式了,否則用戶會有一種挫敗感。
[譯者註]
蘋果官方的“Start Developing iOS Apps Today”文檔中就是利用了線性模式,顯然iOS開發的學習是個循序漸進的線性過程。
混合模式
現在讓我們看看如何結合這三種簡單的模式來創建更複雜的信息架構。他們之間會有重疊,所以不要糾結於你的網站到底屬於哪一類模式。
“簡單等級+簡單數據庫”模式
一種很常見的模式就是簡單的層級結構與多個數據庫式內容的結合。
這種模式適用性很廣。你可以針對基礎內容創建網站的層級結構部分,然後利用強大的數據庫模式將具體信息與某部分集成。當然,也可以是其他任意組合。
案例分析:UX Australia
圖片16-17. 會議網站——一些內容頁面安排在了一個小的層級結構中。
圖片16-18. 展示部分使用了數據庫結構——這個索引頁面說明了標題、演講者、簡短概述、AZ順序排列。每個鏈接都指向一個詳細內容的展示頁面。 (www.uxaustralia.com.au/conference-2009/program/presentations)
這種模式的主要挑戰之一是決定哪部分轉化為結構性內容,哪部分留下作為層級結構內容。可有如下考慮:
- 你想在網站的另一部分再次使用某類內容?如果你沒有二次使用的需求,那麼就不必擔心過度組織的問題——完全是小題大作。
- 數據庫結構能幫助你管理大量信息集。如果你一年內有很多新聞故事素材,你能夠將之視為層級式內容進行管理。如果一天內有上百條,你可能得利用數據庫結構來進行自動展示了。
目錄
第二種常用的莫過於目錄模式。
這種結構事實上是數據庫模式,但是這里特別提及,是因為它很常用,尤其是電子商務領域。底層是內容,由此向上的三個層級取決於網站規模和內容類型。
Jared Spool曾寫了一篇文章深入分析了該模式[2],並描述了主頁和內容頁包含的三種不同類型:
- 陳列頁(Gallery pages):提供內容頁的直接入口;
- 分類頁(Department pages):提供陳列頁入口;
- 商店頁(Store pages):提供分類頁入口;
應需而變。毋庸置疑,大型的產品目錄可能會用到這三種。
Jared強調說,陳列頁是信息架構設計中最困難的環節,因為用戶會根據這個頁面的效果來決定是否點擊瀏覽詳細頁面。
中心輻射型(星型)
中心輻射模式歸根結底也屬於層級模式的一種。然而,這裡想單獨闡述是因為人們使用的時候還是與層級模式有些許不同。
在層級結構中,人們傾向於從頂層(首頁)開始,一級一級向下瀏覽內容,經常是徘徊於層級結構下的某個分支。而中心輻射型結構中,人們會從一個層級進入到另一個具體信息,然後返回出發點(中心點)然後在進入到其他詳細頁面,如此往復。例如,對於LinkedIn,個人頁面就是一個中心點——它是你經常流連徘徊的地方。
子站(Subsites)
我參與過很多大型網站——政務網站、大學教育網站等等。我用的最多的一個模式,自稱為“子站點”(曾有一段時間,人們稱之為“門戶(portals)”,但後來就銷聲匿跡了)。
很顯然,整個網站都是有一系列子站構成,並通過首頁或多個頂層頁面連接起來。子站可以應用任何模式,也不必局限於同一種。
在一些應用場景中,子站點都是使用統一的導航和頁面佈局,潛移默化地表達一種觀點:這些子站點是品牌網站的一部分。當然,有些實踐方案的導航和頁面佈局往往會考慮內容和用戶的感受而略有不同,但是仍然會通過一些細節處理來展示其整體效果。
該模式特別適用於大型組織結構——往往擁有許多職能部門或者很多子品牌——但有需要以一個整體的效果呈現。此外,內容分析後,如果你不能找到一種單一的模式解決各部分的信息架構,那麼你就應該考慮“子站模式”,而不是強迫套用某種模式。
正如你所想到的,大學網站是個很好的案例——大學作為一個整體代表了一個組織和品牌,但內容多樣,每個學院和組織機構都有特定的交流溝通需求(包括對象、政策等)。政府機構也是一樣。例如,ABC(Australian Broadcasting Corporation,澳大利亞廣播公司)旗下擁有很多電視台、廣播站、新聞以及其他網絡服務。
圖片16-28. 對於ABC,首頁承載了許多子站點的入口。
集中入口點(Focused entry points)
很多大型站點,不可能以一種單一的方式組織內容就能滿足所有的用戶——所謂眾口難調。
面對這種情況,我通常使用“集中入口點”模式。首先我都會根據內容和核心用戶確定一個適用於該站點的信息架構模式(層級結構居多)。
然後,假設一些用戶不會通過主信息結構來尋找信息,我會有意提供一些入口點來幫助他們發掘有用的信息。這些入口點不必覆蓋所有站點內容——專注核心信息即可。
我曾說過一些分類組合很難使用——特別是用戶組合和任務組合。我發現入口點很好地解決了該問題。例如,你先運用基礎的層級結構組織網站內容,然後為不同的用戶或任務提供合理入口。
案例——澳大利亞的水
澳大利亞政府的“水”主題網站包含了很多政府政策和相關大綱。當然,政策和大綱並不總是這麼明顯——一些人可能很了解(如相關政府人員和媒體工作者),但是很多人都很無措。兩類人都需要找到自己關心的信息。
這個網站是個運用“集中入口點”模式的典型案例。主信息架構是簡單的層級結構,圍繞政策和大綱進行組織:
圖片16-34. Water policies and programs,作為類別分組顯示出來了。
話題式入口,比如脫鹽(desalination)、雨水貯蓄池(rainwater tanks)和節水(saving water),提供一些用戶感興趣的話題入口:
圖片16-35. 話題入口頁面——鏈接貫穿整個網站
標籤(Tagged)
標籤模式無論在基礎的數據庫模式或者是超鏈接模式中都有所運用。網站中的每個類目都利用關鍵詞作為標籤——而它們同時也是內容的入口。
標籤可能是內容原作者添加的,也可能是其他具有權限的讀者(例如同一團隊成員)。
這種模式適用於大量不同內容的作品集,特別是內容讀者都具有很不同的觀點和想法。
當用戶感覺無從下手時,標籤能夠幫助用戶探索和發現相關的信息。例如,Flickr列出了所有的標籤,你可以根據一個特定的標籤找出所有相關照片——攝影師和訪問者都有權添加標籤。
適用內容 | 適用內容 | 挑戰和話題 | |
---|---|---|---|
層級 | 擁有各類內容的小心站點 | 習慣先閱讀概述信息,然後詳細內容 | 平衡內容的廣度和深度 |
數據庫 | 內容具有一致性 | 想通過更多方式進入內容 | 所有內容需要適應於結構,且不要收集超出需求的元數據 |
超鏈接 | 培育階段的內容 | 追隨相關材料的鏈接 | 作者需要了解鏈接的內容;
當內容完成後,可能需要重構; |
線性 | 順序性內容 | 用戶想按照特定順序理解某些內容 | 只有當用戶必須按順序閱讀時才使用 |
簡單層級+數據庫 | 綜合性內容加上具有一致性結構的內容類型 | 區分出哪些內容需要結構化,哪些不需要 | |
目錄 | 大量結構性內容集 | 尋找特定類別,然後順藤摸瓜查看具體產品 | |
中心輻射 | 分級內容 | 用戶每次想回到中心頁面,然後在查看新的內容 | |
子站 | 大型企業和政務站點,需要許多獨立的內容版塊 | 考慮子站是否需要統一的導航、頁面佈局和品牌 | |
集中入口 | 任意均可,但通常層級 | 用戶想隨心瀏覽,且沒有最好的方法 | |
標籤 | 大量內容集 | 根據自身的定義發掘信息;
輕鬆找到相關信息; |
誰有權限進行標籤操作 |
[1] 最著名模式方面的建築著作是Christopher Alexander的《The Timeless Way of Building》(1979)。
[2] 目錄模式更多信息可以參見Jared Spool的文章:The 8 Types of Navigation Pages和Galleries: The Hardest Working Page on Your Site。另外,也可以參考Jared和Robert Hoekman Jr合著的《網站設計結構——有效的交互設計框架和模式》(Web Anatomy: Interaction Design Frameworks that Work)。
特別注意:本站所有轉載文章言論不代表本站觀點,本站所提供的攝影照片,插畫,設計作品,如需使用,請與原作者聯繫,文章轉自alibuybuy