工作達人(Job Da Ren)
服務是我架站的宗旨,全球華人及男女青年未來的工作方向

  • Home
  • About achi
    • My Disclosure Policy
  • Archives
    • Link Exchange
  • 隱私權政策
  • stock photos
  • Contact
  • Top Posts
  • Poll
  • wp-buzz
    • ㄚ琪的Live PR
  • Advertise
Job Da Ren > 文章導讀 > Information Architecture for the World Wide Web

Archive for the ‘Information Architecture for the World Wide Web’ Category

« Older Entries

 Powered by Max Banner Ads 

Yo! Strategy

2011-11-07,Last modified: 2011-11-07Please wait

 Powered by Max Banner Ads 

這是資訊架構學–網站應用,第三版的第十一章:策略(Strategy),好久沒有看了,重新進入似乎有些障礙。

什麼是資訊架構策略?

『資訊架構策略是一種髙階的概念性架構,可以讓你建構舆組織網站或企業網路,提供堅實的方向和必須的範圍,讓你有信心能夠進入設計和實作階段,同時也能簡化討論,在進入更花錢的設計階段前,協助眾人都站在相同基準之上。』這裡頭有提到高階的概念性架構,所以又是一種架構,那我們可以繼續再看看這個測略可以提供的事項:

  • 資訊架構管理
  • 技術整合
  • 強調由上往下或由下往上
  • 組織系統和標籤系統(由上往下)
  • 文件類型識別(由下往上)
  • 中介資料欄位定義
  • 導覽系統設計

策略受到質疑

這裡有一段話,可以讓你像樅樹那樣是個有責任的資訊建築師:『資訊建築師應該直接和商業策略小組以及內容方針小組工作,探索這三種重要領域之間的關係並予以釐清。就像是商業策略師和內容管理者應該放開心胸,接受資訊架構策略的發展可能會透露他們領域之內的缺失,或者在他們領域內引入新的機會,資訊建築師也必須記住(也要提醒其他人),資訊架構策略不是刻在石頭上。當互動設計師和程式設計師在專案後半部介入時,他們的工作也會透露出改進資訊架構的地方和機會。』這句話是理想,也是在人與人溝通上應該努力的地方,要成功就得人和啊。

從研究到策略

ㄚ琪在這一節中,嘗試萃取出重點來分享,雖然要從滿是文字的書中找出重點或許有點難,但是值得一試,看看是不是合你的口味,『好的資訊建築師甚至會在研究開始前,就開始構思架構和組織網站的可行策略。

…

無論時程和正式的專案計畫是否相符,這都是你從研究轉向策略的時刻了。重點從開放是的學習轉到設計與測試。雖然當你在各階段移動時,還是可以繼續使用研究方法,但是,你的焦點會放在利用有形之物(概念性藍圖和架構框架),清楚說明你的想法,在策略會議中和客戶、同事分享這些有形之物,然後,對用戶測試你的組織結構和標籤體系。』有頭有尾,讓大家可以重點學習一下。

開發策略

上圖是『策略開發流程的概觀,以及最後可以得到的結果。注意箭頭的指向。這是高度反覆而互動的流程。讓我們沿著路徑來看這四個步驟(TACT):思考(think)、說清楚(articulate)、溝通(communicate),和測試(test)。

思考

參考上圖的說明,思考的階段就是『把研究資料轉成創造性的概念』,I tried to get a fix on “Think”, but I just couldn’t understand it. 哈哈,就是目前ㄚ琪對思考的認知,難。

說清楚

『圖表、比喻、情節、場景、藍圖、架構框架』,這裡有一個忌諱的事,『大型團體會議是腦力激盪和分享彼此反應的場所,但是,不適合用來設計複雜系統。想想看,你能把flu說清楚嗎?我不能,我最初還是只能說成是感冒的一種,但是中文是說成流行性感冒;流感,但是如果你上wiki,你可以查到Influenza,有篇幅很大的說明,但是去看維基的流行性感冒,似乎可以明確地知道『流感和傷風都是由病毒引起的,兩者的前期病徵亦非常相似,而且傷風也被稱為感冒或普通感冒,故此不少人常將兩者混淆。』,可以清楚了,不過如何界定的清楚,你還得繼續看他們的差異,縱使你知道了差異,你還是不能掉以輕心自己去判斷你患的是流行性感冒還是普通感冒,這得由醫師說了算,所以一般不是專業的人來說,說清楚也不見得容易啊,有時有些人工作的專業知識不夠,在說話時就很容易露出破綻來。

溝通

『簡報、互動、腦力激盪』,這裡有個建議,ㄚ琪也覺得很好,不僅應用在此,也應用在生活中,而且ㄚ琪也卻曾發現不善於溝通者的問題就包含在這建議中,『很多經驗發現,愈早愈常表達你的想法是比較好的。我們大部分人都不喜歡把尚未成形的想法講出來–我們的自尊不讓我們冒這個險。減少這種危機感的方法之一就是強調這是「沒價值」的工作產品,目的是激起反應和刺激討論。這種明白的宣示,會讓每個人在表達、討論不同觀點時,覺得很輕鬆,因此,有希望可以得到共識。同心協力採用這種共同合作的方式,就會得到一個比較好的資訊架構策略,你的客戶和同事也更信任你。』這當中牽涉到自尊、危機感、信任等的人類本性的問題,如果可以像隨風飄拂的頭髮那樣或是柔情似水,這都可以克服溝通的問題。

測試

『封閉式卡片排序、原型』,這裡頭提到『最有價值的測試方法,就是各種卡片排序和任務效能分析』,詳細作法我就不抄了,但這裡提到一個察覺能力的增加,而這個資訊察覺能力(information scent)的觀念來自Xerox PARC發展出來的資訊搜索理論http://www2.parc.com/istl/groups/uir/publications/items/UIR-1995-07-Pirolli-CHI95-Foraging.pdf

還好可以Google到,不然課本提供的連結還不對說。

所以『無論預算夠不夠,…,不能有藉口不去測試你的想法。』唉,這倒是我常用的策略。

工作產品與輸出結果

隱喻探索

請直接參考George Lakoff跟Mark Johnson何著的Metaphors We Live by,可以瞭解隱喻的用法。

書中也舉例資訊高速公路的隱喻,引用自Mark Stefik (MIT Press)的Internet Dreams。

『有多種比喻用在網站的設計上。…

組織型隱喻

這是善用對某個系統的組織熟悉度,快速理解新系統的組織。

功能型隱喻

這是那些你能在傳統環境中執行的任務,以及那些你能在新環境執行的任務之間,建立連結關係。

視覺型隱喻

這是善用對某些圖形元素的熟悉度,諸如影像、圖示、以及顏色,建立對新元素之間的連結。

…

隱喻探索的流程可以讓創意流動。』這可能是如此,創意或許可以來自閒逛吧,但是如果刻意去閒逛,就不得而知了。

書中舉例Internet Public Librarym,據查現在已經沒有這一頁了,所以ㄚ琪在猜隱喻或許不好用吧,而且書中指出傳統圖書館的隱喻無法支援諸如多用戶物件導向環境multiuser object-oriented environment (“MOO“)的整合。因為如此,所以作者提出了隱喻的危險可以參考Alan Cooper的About Face: The Essentials of User Interface DesignThe Myth of Metaphor這一章。

場景

ㄚ琪覺得場景的使用很像是一種花招,不過ㄚ琪很同意這樣的說明,『場景是幫助人瞭解用戶如何在你設計的網站中,瀏覽和體驗的最佳工具,而且也能替你找出有關架構和導覽系統的新想法。』

書中提出註解http://www.usecases.org/,但是這會轉到http://alistair.cockburn.us/ㄚ琪沒有注意看英文內容,於是無法得知是否跟書中場景的討論有關?

場景樣本

就是範例了,有範例在社群上討論就可以很簡單,不過ㄚ琪不再重抄。

案例研究和情節

『要使得一個像資訊與架構這樣複雜而抽象的主題,能夠讓各種聽眾都能理解,並不是一件容易的事。』像ㄚ琪跟Sophia在程式設計領域就存在一種gap,而要填補這個gap,就如同這節說明的用案例,ㄚ琪曾在男青年協進會時討論有關url這個含意,我把它用地址來說明,並進一步把郵差也加進來,郵差怎樣找到你家,這個概念應該可以讓人聽懂,但是多數的情況下,並無法把這gap彌平,這是智慧的挑戰。

概念性圖表

就像天然氣是無色無味的,然而在送到最終用戶之前,還要用硫醇來給天然氣添加氣味,以助於泄漏檢測一樣,很多東西就是得用顏色、氣味、視覺來呈現,才能幫助人建構抽象概念的表達。而『圖表是另一種把抽象概念帶進現實生活的方法。』

這張資訊雲的圖很好看,就引用給各位看看。

藍圖和架構框架

『藍圖(顯示出網頁和其他內容元件之間的關係)和架構(顯示出網站上主要網頁的內容和連結的雛型,是建築師進行這場轉換所要選擇的工具。』Gee, what a great tool!

策略報告

看來策略報告可以說是成果的表現了,寫報告對於ㄚ琪來說不見得是件易事,但是書中這樣提『首先,在報告中引入高階視覺圖樣,你可以畫出一份非線性大藍圖,後面再接線性的文字說明。其次,要記住,策略報告不能也不該獨自存在。你應該要用口頭的方式,說明你的想法和如何回答問題。理想上來講,你必須做面對面的資訊架構策略簡報。至少,你要開一場會,討論各方反應以及回答問題。』ㄚ琪覺得報告的呈現就是讓我們的主意跟想法可以變得更清楚,讓參與的人看得懂,就對了。

策略報告樣本

這是以weather.com為例做的一份報告。

執行摘要

『執行摘要應該提出目標和方法的概觀,從5萬英呎高空觀看主要問題和主要的建議事項。』書中的樣本可以讓你知道詳請,ㄚ琪不再贅述。

網站的觀眾&任務/願景

『界定出網站的觀眾和目標,以確保報告和讀者都能融入較寬廣的情境中,是相當重要的。』

學習而得

『把你的研究、分析,與你的建議事項連結起來。』

架構策略和方法

內容管理

『說明資訊架構和內容管理之間大略關係,一開始是簡單說明有效』的內容管理三個部份:

  • 規則
  • 角色
  • 資源

這裡的樣本,還有一些建議事項:

  • 範本
  • 中介資料
  • 彙編詞彙

專案計畫

『替資訊架構設計產生專案計畫,當成策略階段輸出結果的一部分,是相當有用的。』

這樣可以達到兩個目標,『與策略報告平行發展時,可以迫使該小組不斷的問下列問題:

我們怎麼做?

要花多久時間?

誰來做?

需要哪些輸出結果?

前提是什麼?

這樣可以確保資訊架構策略根植於實際中。第二個目標是搭起策略和設計之間的橋樑,可以和其他小組的計畫整合,替整個網站的設計,取得完善的時程規劃。』

簡報

『沒有一些簡報和討論,你的最佳建議永遠不見天日。』

Print Friendly

Tags: Information Architecture for the World Wide Web, MOO, TACT, 中介資料, 彙編詞彙, 標籤系統, 程式設計, 組織系統, 腦力激盪, 資訊建築師, 資訊架構學, 高速公路
Posted in Information Architecture for the World Wide Web | No Comments »

Yo! Research

2011-10-02,Last modified: 2011-09-28Please wait

 Powered by Max Banner Ads 

這是資訊架構學–網站應用,第三版的第十章:研究(Research),前面己章都在講解觀念和元件架構,從先在開始課本要介紹建造資訊架構的流程和方法了,這一部份看起來比較對ㄚ琪的喔。eh,讓我們開始吧。

流程概觀

上圖是一個擷取來的資訊架構開發的流程圖,研究->策略->設計->實作->管理是整個的程序,但是專案會只到實作的階段,ㄚ琪不想打太多字在每個階段的敘述,由圖應該可以很簡單地看出接下來的流程。但是最隱ㄚ琪興趣的倒是這句話話,『在網站設計的早期,很多公司採取單階段流程,名為「撰寫HTML」。』ㄚ琪應該也算這樣子的人吧,不過我很清楚目標的設定,可是這個設定,不會是像我這樣的網頁程式設計師做的,所以大部分也是與我無關的,我可能比較著重在設計跟實作等階段吧。

研究框架

ㄚ琪發現用圖解來分享心得其實算是不錯的idea,不過大部分只能找到英文的資訊,算是比較不利華人吧,不過ㄚ琪可以大概說明一下中文的意義,另外也就不太需要進行詳細的說明,真是好用。

三圈圖是作者很喜歡用的圖示的一種,課本接著會講解

Context(情境):考量到商業目標、資金、政治、文化、技術、人力資源

Content(內容):考量到文件/資料類型、內容物件、中介資料、資料量、現存結構

Users(用戶):考量到觀眾、任務、需求、資訊搜尋行為、經驗、詞彙

要實作這個三圈圖,這裡又有個矩陣圖分析每個模式使用的工具,對於工具來說,應該是我輩中人喜歡的吧。

情境:背景研究、會議和報告、投資人面談、技術估價

內容:探索式評估、中介資料和內容分析、內容對映、標竿

用戶:搜尋紀錄和點閱路徑分析、使用案例和人物、情境式查詢、用戶面談和用戶測試

看起來除了搜尋紀錄和點閱路徑分析ㄚ琪比較有感覺之外,其餘都覺很煩,而且很抽象。

接下來會依照這樣的順序再細部分解。

情境

跟情境有關的政治問題就是「以管理階層為中心的設計」VS 「以用戶為中心的設計」,我想哪個孰盛孰優應該很容意辨認。

令人信服

這一節這個主旨,ㄚ琪算是在業界打滾多年之後所獲得的經驗,增強你的口才以說服你的敵人同意你的想法,這是最高招,也是最高境界,想把事情做得少,口才一定要有,出這張嘴非常必要。

背景研究

『檢視背景材料是好的開始。』

初步簡報

沒想到花時間作簡報是值得的,學起來了。

研究會議

真沒想到還可以分成三類的會議:

策略小組會議

『策略小組要設定高階目標,定義任務、願景、觀眾、內容,和功能。這個小組要處理的就是在中央和地方之間取得平衡。…面對面的會議是必要的。…五到七人是最理想的。…會議的關鍵之處就是你嗅到了什麼。』

我用以上幾個簡短的摘錄以表示ㄚ琪所瞭解的事。

內容管理會議

這些問題可以列成一張checklist,所以請看課本的詳細介紹,會很有幫助。

資訊技術會議

投資人面談

這裡的面談屬於非正式討論,討論的問題ㄚ琪也不再贅述。

技術評估

『你會想知道有什麼現存的東西,流程中有什麼,誰可以幫得上忙。然而,你可以做落差分析(gap analysis),找出商業目標、用戶需求,和現存技術基礎架構的實際限制之間的缺口處。』

什麼是落差分析?課本突然冒出這樣一段話,用英文去Google可以發現有時也翻成差異分析,ㄚ琪看了之後大概可以清楚其意義,也感覺是商業的工具手法,所以就不再多說了。

內容

『內容大致定義為「網站上的東西」…

用戶必須能夠找到內容才能使用,可尋性位在可用性之前。如果你想建立可尋性物件,必須花時間研究這些物件。必須找出物件之間的區別,以及文件結構與中介資料如何影響可尋性。你會想在這種由下而上的研究,與對網站現存資訊架構由上往下的觀點之間取得平衡。』

探索式評估

『重新設計既存的網站,…有機會站在別人的肩膀上。可惜的是,因為人總是習慣把焦點放在錯誤上,而且有想從頭開始的慾望,所以,常常錯失這種機會。』作為一個接案者為了生存,不可諱言地,『如果客戶把他們的網站視為垃圾』,我們一定要順從客戶的意見,把舊思想、舊東西批的體無完膚,這樣我們才能有機會建構新思想、新的網站,這才是機會,這是ㄚ琪與課本持不同的方向,因為這是從獲利的角度著眼的,沒有對錯。

不過這種從現存網站找到東西來的的工具,還是得上手。

『探索式評估(heuristic evaluation)是一種專家判斷,以一組正式或非正式的設計準則測試網站。最好是讓某個局外人做評斷,這樣才能不帶有色眼光看事情,而且沒有政治因素的可量。理想上來講,檢視背景材料前,就要做探索式評估以避免偏見。』

看起來這個錢是一定要花的,本想省起錢來自己捲起袖子動手幹,看起來是不可能的,如果自己做,很可能落入自我感覺良好的情形。

可以參考Jakob Nielsen的Ten Usability Heuristics (http://www.useit.com/papers/heuristic/heuristic_list.html),ㄚ琪列出這十點:

  1. Visibility of system status
  2. Match between system and the real world
  3. User control and freedom
  4. Consistency and standards
  5. Error prevention
  6. Recognition rather than recall
  7. Flexibility and efficiency of use
  8. Aesthetic and minimalist design
  9. Help users recognize, diagnose, and recover from errors
  10. Help and documentation

ㄚ琪以為若是沒有財力,用這個指導方針似乎不錯,或許還可以無師自通。

內容分析

『內容分析可以非正式調查或細節式的稽核。在研究階段初期,高階的內容調查,是瞭解內容的範圍與本直的一個有效工具。到了後面的流程,一頁一頁的內容稽核或者清點可以產生一個移植的路徑,把內容移植到CMS(content management system),或者至少有一個便利的組織化方法,進行網頁層級的寫作和設計。』

這兩種方式似乎只有點出初步的作法,但是的作法好像沒有,也不知後面有沒有,ㄚ琪先Mark起來留待後續查考。

收集內容

『為了開始作業,必須找出、列印、分析網站內容中具代表性的樣本。…

我們建議採用諾亞方舟(Noah’s Ark)法。

下面是一些建議,可以從中找出樣本:

  • 格式:目標是各種格式的混合。
    文件類型:最高優先權應該是找出一群多樣的文件類型。
    來源:樣本應該反應出內容來源的多樣性。
    主題:找些專門針對業界設計,可用的公用分類體系或彙編詞彙。
    現有架構:

注意一個因素報酬遞減率。』

分析內容

這裡頭敘述的作法也不大清楚,僅提到參考的事項:

  • 結構化中介資料
    描述性中介資料
    管理性中介資料
  • 要精通這個方法,還是靠自己多摸索了。

內容對映

現在,是發展內容對映圖,把探索式評估所瞭解的網站的組織和導覽結構跟內容分析中所瞭解網站的內容物件連接起來的時候了。

內容對映圖(content map)是對現存資訊環境的視覺表達法(如圖所示),其實在這一章中,有鑑於敘述資料很多而且很細,ㄚ琪在這章中還算滿多敘述圖解的,一來也方便,二來可以節省打字,三來確實可以從圖看出重點,這就是ㄚ琪想要分享的心得,否則你就自己買書來看就好了。

2011-09-20_165442

內容來源(content sources)考量到行銷、顧客服務、法律。
內容模型(content model)考量到產品、流程、參考。
內容類型(content types)考量到聯絡處理、系統用法。
內容範本(content templates)考量到步驟、表格。

標竿

這一節看起來ㄚ琪覺得比較重要,引用課本這段話:

『標竿(benchmark)…指要做一些比較性衡量或研判…。在此情境下,標竿牽涉到系統性的鑑定、評估,以及網站和企業網路的資訊架構特色之比較。

這些比較可能是量化或是質化。我們可以評估,用戶在使用對手網站執行任務時所需的秒數,或者記下每個網站最有趣的特色。「比較」可以是不同網站之間的比較(競爭性標竿),也可以是相同網站不同版本的比較(前後性標竿)。就此二例而言,我們發現標竿是相當有彈性而且有價值的工具。』

競爭性標竿

『這裡的重點是,從競爭對手那兒借用資訊架構是有價值的,但是,必須很謹慎。』書本自行敘述這是重點,ㄚ琪就不用很麻煩地摘錄及分享了,而且這也確實是ㄚ琪慣用的方法。

前後式標竿

這裡列出兩種標竿的優點,Google不到資料,所以辛苦地打出來囉

『

  • 在現存網站中,可以找出資訊架構特色,並突顯其優先地位。
    從廣泛的一般化描述(例如,「我們網站的導覽系統臭名滿天飛。」),轉變成特定而可行動的定義。
    建立你正要改進之處的參考點。

…

競爭式標竿的優點:

  • 列出資訊架構特色表,把新的想法帶上檯面。
    從廣泛的一般化描述(例如,「Amazon的模式不錯。」),轉變成特定而可行動的定義(例如,「Amazon的個人化特色對常去的用戶而言很不錯。」)。
    挑戰深陷腦中的假設(例如,「我們應該像Fidelity那樣。」),避免因錯誤理由把錯誤特色複製過來。
    以競爭者為準,建立當前的地位。建立參考點,以評估改進的效率。

』

希望能繼續看到這兩種方式的工具及實作,這個功能很不錯。

用戶

『這是網際網路的快轉式演化。』ㄚ琪從前面一段讀來,書中就給與一個註解,但是這個註解,並沒有在ㄚ琪的腦中起漣漪,所以只能保留這個文字紀錄以備查考了。

『用戶是最大的。』在任何經濟的產業中,沒有人敢反駁這個說法,對一個工人來說,老闆一樣是最大的。

所以要學會研究用戶人口很重要,書中列出一個參考資料,Joann Hackos跟Janice Redish著的 (Wiley)User and Task Analysis for Interface Design, 另外可用性專家Jakob Nielsen的網站

useit.com: Jakob Nielsen’s Website,也是值得拜訪的一個網站。

因為沒有一種單一的方法是正確的,所以『最好是採用五次面談和五次可用性測試,而不是同一測試跑十次。每一種做法都符合報酬遞減綠的法則。』看起來就是多讀資料,看看人家的經驗,並且運用在自己身上,那就是最好的了。

重點來了,『首先,奉行打折可用工程的黃金律:有測試比沒測試好。不要讓預算或時程變成藉口。其次,記住用戶是你最強而有力的盟友。…用戶研究是極為有效的政治工具。』

以客為尊真好。

使用量統計

『你的網站上之使用量統計資料是開始工作的合理地點。大部分統計資料軟體套件(像是Google Analytics) 會提供下列報告:

  • 網頁資訊
  • 訪客資訊

…用戶在網站中移動的路徑就稱為點閱路徑(Click Stream)。…』 但是用統計資料軟體很難有所作為,如果要有價值,『就是從用戶得來的回饋資料,讓他說明為什麼會來這個網站,他找到什麼,以及為什麼離開。』

後面說的才是重點,ㄚ琪以前也會這樣訪問訪客,不過這很耗時,而且多次的結果,訪客都表示他忘了,看起來即時的面談調查是很重要的,否則客戶不會記得當時的情境,另外有些客戶會對這樣的行為感到突兀,所以怎樣避免引起不悅的感覺也要注意。

搜尋日誌分析

『一個比較簡單但相當有價值的做法,就是去追蹤和分析搜尋引擎所取得的查詢內容。』

『當你在開發控制詞彙時,這是相當有用的資料。當你要把某些術語當成最佳猜測策略下,優先考量的術語時,它就相當有用。』

『搜尋日誌的分析,可以讓你對用戶真正在搜尋的東西有敏感度。』

顧客支援資料

參與者的定義和召募

『對大型專案而言,資訊建築師應該考慮與傳統市場研究公司合作,他們有界定觀眾類型的經驗,可以在這些觀眾類型之中找出各種參與者,召募參與者,後勤處理,像是設備、獎勵,以及紀錄。』

能夠做到這程度,花些錢找專家也無可厚非了。

問卷

『問卷(survey)是一種寬而淺的研究工具,提供一種機會,從一大群人那兒快速而廉價的取得輸入資料。…

除了用戶意見的價值之外,問卷也提供一個強而有力的政治工具。如果90%的用戶說員工名冊是最重要,但卻是最令人失望的企業網路資源,那就是必須予以改進的強迫性理由。』

好像每次提到人,就會跟政治扯上關係,唉。

情境式調查

『田野調查是各學科研究課題中相當重要的部份,從動物行為到人類學皆然。…』

田野調查(Field study)又譯為田野工作或實地考察,為對於描述原始資料蒐集的概括術語,其所應用的領域包括民俗學、考古學、生物學、生態學、環境科學、地質學、地形學、地球物理學、古生物學、人類學、語言學、哲學、建築學、及社會學等自然或社會科學領域。

真沒想到『這些情境式調查(contextual inquiry)方法對資訊建築師而言也有用。』不過應該是相當費時,課本也推薦,Hugh Beyer跟Karen Holtzblatt 寫的Contextual Design(Morgan Kaufmann)一書。

焦點小組

焦點小組(英文:Focus group),也稱焦點團體、焦點群眾,是質性研究的一種方法,就某一產品、服務、概念、廣告和設計,而通過詢問和面談的方式採訪一個群體以獲取其觀點和評價。該焦點小組的成員往往經過實驗者選擇而定,並保證在實驗過程中被試方能夠充分分享其意見和主張。

上述這一段維基的解釋,ㄚ琪就覺得很完整了,要應用在資訊架構學中,應該不難。不過這個工具,課本說明這是『測試網站可用性中相當弱勢的工具』,看起來是參考用用就行的樣子。

用戶研究會議

面談

整節讀來抓不出重點來,不過倒是有checklist可以用,ㄚ琪不列了。

卡片排序

『卡片排序時要考慮下列諸點,開放/封閉、措辭、粗細程度、異質性、交叉列出、隨機性、量化/質化。』

聽說有MindCanvas可以使用,不過上去看看支後肢有DEMO,玩起來也不覺得順,看來也是要收費的,所以作罷。

用戶測試

『用戶測試有很多別名,包括可用性工程和資訊需求分析。』

你可以考慮以下的路線來著手:『容易到不可能、已知項目到詳盡的、主題到任務、人工到真實。』

研究的保衛戰

『沒有時間作研究會怎麼樣?』這裡舉出一個案例,然後直指這個專案落入『死亡盤旋』,這還真可怕啊。

克服研究阻力

這裡頭常見的原因有:

『

  1. 我們沒有時間或沒有錢。
  2. 我們已經知道要什麼。
  3. 我們已經做了研究。

』

看到正中ㄚ琪的下懷的原因了,看來這應該是要改進的地方。

另外另一個重點,『害怕分析癱瘓(analysis paralysis)的危險,商業經理人傾向於行動導向。「讓我們跳過研究,開始做事吧」是相當常見的說法。』

這個問題其實換另外一種方式講,應該是經驗不足導致我們沒法子估計狀況,就無法事先去做研究,於是我們常會落入且戰且走的心態,沒有廣泛的認知情況及經驗確實是很危險的,今天好在ㄚ琪看了,所以可以更有深度的做這方面的工作。

今天其實也剛好碰到一個新進人員,突然要求改善他們的資料庫的欄位,但是這並不尋常,結果發現他並不瞭解情況,更無法決定這個欄位長度,只會問你的容量最大可以到哪裡,但是完全沒有使用的經驗值,這個結果終將導致系統的肥大及不適用,唉。

現在提出做研究的好處了:『

做研究可以節省時間和經費:習慣性跳過研究而進入設計是專案經理常犯的錯誤,他們看到效率假象,卻看不見真正的效率。』

2011-09-23_150600

這個剪圖可以清楚看出,如果你是先開工,找目標,那麼整個專案的時間會比先找目標,開工的時間要長。少了研究(Research),其餘的策略(Strategy)、設計(Design)、實作(Implementation)的時間將加長。

另外的好處:

『經理不知道你們的用戶要什麼』:對啊,他們會很直覺用他想要什麼來跟你說,所以經理人的智慧就變得很重要了,成敗都在乎他。

『我們需要做資訊架構研究』:對啊,不然我花這麼多時間看這一篇,所為何來?Of course,why not?

Print Friendly

Tags: benchmark, Click Stream, Field study, Focus group, gap analysis, heuristic evaluation, Information Architecture for the World Wide Web, Noah’s Ark, Research, survey, 問卷, 探索式評估, 標竿, 焦點小組, 田野調查, 研究, 落差分析, 諾亞方舟, 資訊架構學, 點閱路徑
Posted in Information Architecture for the World Wide Web | No Comments »

Yo!Thesauri, Controlled Vocabularies, and Metadata

2011-09-02,Last modified: 2011-09-01Please wait

 Powered by Max Banner Ads 

中介資料

從Dictionary.com來的定義:『對資料處理而言,中介資料是一種用於定義的資料,能夠提供其他被某種應用軟體或環境所管理的資料之相關資訊或者說明。例如,中介資料可以替資料說明其元素或屬性(名稱、大小、資料類型等等),或者其紀錄或結構(長度、欄位、資料欄等等),或者其相關資料(位於何處、如何繫結、擁有者等等)。中介資料可能包含描述性資訊,說明資料的情境,品質和狀態,或者特質。』

另一種實用的說法就是,『中介資料的標記(tag)是用於描述文件、網頁、影像、軟體、視訊檔、音效檔、以及其他可以改進導覽和取出的內容物件。很多網站都用到HTML的關鍵字<META>標記,這就是一簡單實例。』這簡單的應用,再工作達人上非常方便設定,你真的不需會用到程式及HTML,但是在ㄚ琪琪的家則是有點小麻煩,而且花的時間卻也比較多。

控制詞彙

2011-08-31_135851

看起來有很多的定義方式,從這個剪圖可以看出類似的定義和關係,『控制詞彙是一份對等術語(equivalent term)清單,按同義詞環圈(synonym ring)的形式排列,或者是一份優先術語(preferred term)清單,儲存權威檔案(authority file)中。定義術語之間的階層關係(如較寬、較窄),就有了分類體系。建立概念之間聯想關係的模型(如另見(see also)、參見(see related)),就是在做彙編詞彙。』這裡頭字看得很清楚,但是卻感覺很模糊,如果說對等術語,這個ㄚ琪比較有概念,但是如果談到優先術語這就有考驗了,而且還什麼較寬或較窄,簡直進入模糊科學的範疇中,但是到了聯想關係,就又彷彿有一種親切感,親切的感覺是來自於中工作達人有安裝WordPress 相關日誌插件,到目前為止還用的不錯。

同義詞環圈

首先,要注意的是,同義詞環圈不一定是同義字。基本上這好像來自於溝通的問題,就像我懂JavaScript的語法,可是有些新手,他會習慣說成Java之類的,但其實他要談的就是JavaScript,所以有時可能又會涉及到是否真的是Java的術語。

書裡頭有提到,如果將同義詞環圈用在檢索中,那麼就會發生Yo!Search Systems裡說的檢索和精準的問題,但是在Thomas K. Landauer 著的The Trouble with Computers: Usefulness, Usability, and Productivity,(MIT Press)的研究中顯示,『在一小資料庫中使用同義詞環圈,可以增加20%~80%的檢索量。…但是也會降低精準度。…對超大型網站而言,實在沒有藉口不提供同義詞環圈功能。』嗯,ㄚ琪在想那我的工作達人是否應提供這樣的功能?ㄚ琪好奇地Google了一下,這個idea在一年多前曾被提出過說,不過目前看起來WordPress中沒有這功能,或許ㄚ琪懂的話,就可以開發這個功能。

權威檔案

『精確的講,權威檔案放的就是一份優先術語或是可接受值的清單,不含有變異詞或同義詞。圖書館和政府單位以前都用權威檔案替某個領域的東西定義專有名稱。』

2011-08-31_144405

像這一份Utah State Archives & Records Service提供的權威檔案,ㄚ琪查到的是2011/7/29更新的,比起書中舊版的來說看起來是更多了,且索引從A-S、T-Z的分類進步到每個字母的分類了。

書中另外指出,『權威檔案通常包含優先術語和變異術語。』

正如書中提到的問題,我們真的需要去定義優先術語嗎?或者同義詞環圈本身就能把事情辦好?

這裡提到答案,『權威檔案對內容作者和索引者而言都是有用的工具,可以讓他們有效而一致的使用眾所任可的術語。此外,從控制詞彙管理的角度來看,優先術語可以事唯美一組對等術語中的唯一識別字,這樣在對變異術語進行新增、刪除,和修改時更有效率。』以溝通的角度來看,這似乎是有其必要性,而這一塊在WordPress中看起來也是缺乏的。

分類體系

『所謂的分類體系(classification scheme),指的就是優先術語的階層式排法。最近,很多人喜歡改用分類法這個詞。無論是哪一種說法,瞭解這些階層分法有好幾種形式,而且有很多種用途,是很重要的。如下所示:

  • 前端可瀏覽類似Yahoo作法的階層系統,是操作介面中可看見而不可或缺的一部分。
  • 由資訊建築師、作者,以及索引者使用的後端工具,可以組織文件,替文件定標記。

』

最有名的杜威十進制圖書分類法,請自行參考維基解釋。

彙編詞彙

彙編詞彙(thesaurus),這在在維基翻成索引典,也稱為類語辭典,是主題分析的一種實作方法,你也可以參考Dictionary.com的解釋。

但是我想從書中的定義來引用,『彙編詞彙是整合在網站或企業網路內,用以改善導覽和取出作業,這和參考書有相同的傳統,但是,具有不同的形式和功能。和參考書類似的是,彙編慈會是一種觀念的語義網,把字和同義字、同音意義字、反義字、較寬術語和較窄術語,以及相關術語連接起來。』說到這裡,ㄚ琪還滿恨Google把字典功能關起來的說,因為他的字典功能確實就像這裡所提的彙編詞彙這樣的功能說。

但從書中的目的,所謂的彙編詞彙:『一種控制詞彙,其中的對等、階層和聯想關係會被識別出來,以改善資訊的擷取。…

彙編詞彙建構在較簡單的控制詞彙之上,建立這三種基本類型的語義關係之模型。』

上面的解釋可以參考Guidelines for the Construction, Format, and Management of Monolingual Thesauri. ANSI/NISO Z39.191993 (R1998)。

並且可以參考下面這個剪圖:

2011-08-31_161758

技術行話

優先術語(perferred Term,PT)

也稱為可接受術語、可接受值、主題標頭,或描述語。所有的關係都是根據優先術語定義的。

變異術語(Variant Term,VT)

也稱為入門術語(entry term)或非優先術語。變異術語的定義是對等於優先術語,或者大致上和優先術語同義。

較寬術語(Broader Term,BT)

較寬術語是優先術語的上層術語,在階層中的較高一層位置。

較窄術語(Narrower Term,NT)

較窄術語是優先術語的子術語,在階層中的較低一層位置。

相關術語(Related Term,RT)

相關術語是透過聯想關係與優先術語相連結。這種關係通常是用「另見」(See Also)的方式說明。

指(Use,U)

傳統的彙編詞彙,時常採用下面的語法作為索引者和使用者的工具:變異術語指優先術語。

慣用(Used For,UF)

這是指優先術語慣用變異術語的相互關係。這是用來列出在優先術語的紀錄上所有的變異詞。

範圍註解(Scope Note,SN)

範圍註解本質上是優先術語定義的特定型態,用來限制術語的意義,儘可能把模糊性消除掉。

原來較寬跟較窄是專業術語,跟模糊不同義,呵呵,誤會大了。

彙編詞彙實例

ㄚ琪一直想在WordPress上找到有這一類的外掛,但是正如書中所說的,網站有用到這個彙編詞彙的真是少,而且也不易察覺的出來,書中有提到PubMed的功能,看起來醫學界常用這個資料庫,不錯。

彙編詞彙的種類

『決定要替網站建立彙編詞彙時,有三種可以選:經典式彙編詞彙(Classic Thesaurus):高階、全功能工具,索引式彙編詞彙(Inedexing Thesaurus):賦予可瀏覽式索引的價值,以及搜尋式彙編詞彙(Searching Thesaurus):不加標記的內容可以豐富查詢。』

這裡貼出英文的分類圖給大家瞧瞧。

經典式彙編詞彙

『經典式彙編慈會是用於索引和搜尋的時刻。索引者對文件做索引時,以彙編詞彙把變異術語對照到優先術語。進行搜尋者以彙編詞彙取出資料,而無論是否瞭解彙編詞彙在他們的搜尋經驗中所扮演的角色。查詢的術語會和彙編詞彙的豐富詞彙進行比對,因而得以獲得同義詞管理、階層式瀏覽,以及聯想式連結。

索引式彙編詞彙

採用索引式彙編詞彙有一些理由:『

  • 索引式彙編詞彙會將整個做索引的過程結構化,提昇一致性和效率。其各所引者做事時,就像是整合一體的單位,彼此都瞭解優先術語和索引的原則。
    索引式彙編詞彙,可以讓你建立優先術語的可瀏覽式索引,賦予用戶經由單一管道就找到某個主題或產品的所有文件。

』

搜尋式彙編詞彙

看起人前面的人工成本很高,所以採用搜尋式彙編詞彙,相形之下變得容易,並且有很多的參考資料:

  • Anderson, James D. 跟 Frederick A. Rowley. "Building End User Thesauri From Full Text." In Advances in Classification Research, Volume 2; Proceedings of the Second ASIS SIG/CR Classification Research Workshop, October 27, 1991, eds. Barbara H. Kwasnik and Raya Fidel, 113. Medford, NJ: Learned Information, 1992.

  • Bates, Marcia J. "Design For a Subject Search Interface and Online Thesaurus For a Very Large Records Management Database." In American Society for Information Science. Annual Meeting. Proceedings, v. 27, 2028. Medford, NJ: Learned Information, 1990.

  • 是英文的技術性論文,ㄚ琪就跳過了。

  • 彙編詞彙的標準

  • 1993年David A. Krooks 跟 F.W. Lancaster在"The evolution of guidelines for thesaurus construction,"這篇文章裡說『建造彙編詞彙的主要基本問題已在1967年找出來並獲得解決了。』

  • 這裡頭列出了一些標準:

  • ISO 2788 (1974, 1985, 1986, International)

  • BS 5723 (1987, British)

  • AFNOR NFZ 47-100 (1981, French)

  • DIN 1463 (19871993, German)

  • ANSI/NISO Z39.19 (1994, 1998, 2005, United States)

這看起來就讓人頭大了不是嗎?還好書中講到這些標準的問題,我們不一定要全用這些標準,當然善用這些標準也有優點如下:

  • 這些原則中有很多考量和智慧在內。
    大部分彙編詞彙管理軟體的設計都是相容ANSI/NISO,所以,從技術整合觀點來看,和標準走在一起是有用的。
    和標準相容可以提高跨資料庫相容的機會,所以,當你的公司和競爭者合併時,你就有從容的時間把兩種詞彙合併起來。

說到這裡ㄚ琪對於竹南一位要離職的同事一直不開放某資料庫的管理權限給我,想必是要給我好看就對了,看來我要自力救濟了。

語義關係

對等

『對等關係是連接優先術語和變異術語(見下圖)。我們可泛稱此為「同義詞管理」,但是,對等是比同義詞更寬的術語。』

『目標是把術語群集起來,定義為「取出用的對等術語」。其中可能包含同義詞、近似同義詞、反義詞、縮寫、詞語變異詞,以及常見的錯誤拼法。』

階層

『階層關係把資訊空間分成類別和子類別,經由父子關係把較寬和較窄的觀念連接起來。』(見下圖)

『階層關係有三種子類型:

屬(Generic)

這是我們從生物分類法中傳統的「綱-種」關係借用過來的。

整體-部份

在此階層關係中,B是A的一部分。

實體

就此例而言,B是A的實體或實例。

』

這後面還會有面向式彙編詞彙(faceted thesaurus)能夠滿足多階層的常見需求,而多階曾在這裡其石臼是個很大的問題,另外還有階層粗細的問題,要解決這個問題還有卡片排序法。

聯想

『聯想關係通常比較難處理,但是,當其他兩種關係有好的開始,通常也有必要開發聯想關係。』(見下圖)。『在彙編詞彙建造上,聯想關係通常是定義為強烈暗示其語義的連接關係,但是,它們無法在對等關係或階層關係中看出來。』

這個工具可以讓行銷人員進行所謂的「交叉銷售」,讀來這裡ㄚ琪會發現這本書真的是很像是ㄚ琪需要的說。

優先術語

術語形式

這裡遵循標準有一些建議,以前ㄚ琪在標籤上也是如此進行,只是從沒想到這裡有一些標準:

文法形式:標準非常鼓勵以名詞作為優先術語。

拼法:標準建議選擇「明確的權威資料」,像是特定的辭典或小辭典,或者,你也可以用自己的風格。

單數和複數:標準建議對「可數名詞」採用複數。對觀念性名詞應保留單數。

簡寫和縮寫:原則建議採用最常見的寫法。

這裡對單數和複數的建議,ㄚ琪本以為都是以單數為原則,沒想到還分可數不可數的,不過這在華文裡頭沒有差別。

術語選擇

ANSI/NISO標準這樣說:

第3.0節:「文件中出現的術語是選擇優先術語的主要原則。」

第5.2.2節:「優先術語的選擇應能滿足多數用戶的需求。」

術語定義

『括號式術語限定詞(parenthetical term qualifier)提供了一種方式控制同形異義字。』

這個方式ㄚ琪偶而會做。

術語精確度

『術語精確度(specificity)是所有彙編詞彙設計者必須要面對的另一難題。例如,「knowledge management software」代表一個術語、還是兩個或是三個』。

標準這樣說:

ANSI/NISO Z39.19:「每一描述詞…應該代表單一概念。」

ISO 2788:「通則是…複合術語應該拆解程簡單元素。」

原來這裡頭牽涉到標準,不過ㄚ琪以前在論文中所採用的方式,倒不是這樣去做的,而是在具有同類性直的文件中,根據術語的統計結果予以叢集來自動判斷是一個術語還是兩個術語抑或是分成三個術語的方式來看待,結果顯示倒是令人滿意的,所以不一定要使用標準吧。

複合階層系統

『在嚴格的階層系統中,每一個術語出現在一個且只能出現在一個地方。』這個規定,ㄚ琪從來沒遵守過,而且也覺得不可能就這樣簡單的分類成這樣的階層關係。

不過就像書中所提到的挑戰,『如何表達導覽情境。大部分的系統都允許在階層中有主位置和次位置的觀念。』有時候還滿令人兩難的說。

面向式分類法

Faceted Classification這個術語用英文很好找,但是用面向式分類法則無法找到很多資料,反倒是層面分類法是華人常用的翻譯,ㄚ琪從林雯瑤的層面分類的概念與應用看到了很多說明,像是層面分析、多面向分析、分面分析、截面分析、面向分析、不同面分析、層面分析也是指同樣的事情。

許多文獻都將S. R. Ranganathan於1933年出版的「冒號分類法」(Colon Classification, CC)視為層面分類法的濫觴(參考Broughton, V. (2001). Faceted classification as a basis for knowledge organization in a digital environment; the bliss bibliographic classification as a model for vocabulary management and the creating of multidimensional knowledge structures. The New Review of Hypermedia and Multimedia, 7(1) : 67-102.,以及陳敏珍(1995)。綜合分類。在胡述兆編著,圖書館學與資訊科學大辭典(頁2123)。台北市:漢美),或認為層面分析起源於Ranganathan的作品(參考Kwasnik, B. H. (1999). The role of classification in knowledge representation and discovery.Library Trends, 48(1), 22-47.)。然而實際上,層面分類概念的提出與使用卻遠早於此(參考Taylor, A. G. (2000). Wynar’s introduction to cataloging and classification. Englewood, Colo.:Libraries Unlimited.)。

當然討論歷史看起來是較沒意義的,倒是怎麼用,比較是王道。

關於層面分類的定義為,廣義來說,對任何系統(system)其文獻描述的方式可以用文字或標記來表現其要素,並且加以組合,這樣的技術即是層面分類(Broughton, 2001)。狹義地從文獻主題分析角度而言,層面分類是將主題概念分解為數個簡單、個別的概念(或概念因素),按照它們所屬的方面或範疇,分別編列成表,標引時使用兩個或多個簡單概念的分類號(或各種標記)的組合來表達一個複雜的主題概念(參考白國應(1993)。分面組配式分類法。在中國大百科全書智慧藏。上網日期:2004年5月20日,檢自:http://edu1.wordpedia.com/Cpedia/Content.asp?ID=249)。通常在形成層面分類的架構前,必先進行層面分析,Ranganathan對層面分析的定義則為「是以主題類別為基礎,列舉一連串可能特質的心智歷程,特質的相關屬性之衡量則伴隨著主題而定」(參考Foskett, D. J. (1972). Facet analysis. In A. Kent & H. Lancour (Eds.), Encyclopedia of library and information science (pp. 338-346). New York: Marcel Dekker.)。如果進一步從層面分類的技術再推進到層面分類法,通常其結構會更嚴謹。層面分類法常用於文獻的組織,是一種有標準詞彙可用以描述文件主題的類表。首先這些詞彙被依其主題特質區分開,某個特定的類別則含括不同主題。在每個類別之內,詞彙再被區分成不同的層面,每個層面在類表中可能以階層的方式排列。這些層面可以再從不同的類別中被挑選出來,然後依照事先規定好的順序重新組合(參考

Vickery, B. C. (1960). Faceted classification: A guide to the construction and use of special schemes. London: Aslib)。

全文很多,ㄚ琪建議你直接研讀這份論文會對瞭解面向式分類法很有幫助。

文末提了很多參考資料:

ANSI-NISO Z-39.19-2005

Guidelines for the Construction, Format, and Management of Monolingual Controlled Vocabularies. Completely rewritten (and renamed) in 2005; http://www.niso.org/standards/standard_detail.cfm?std_id=814

Controlled Vocabularies: A Glosso-Thesaurus

Written by Fred Leise, Karl Fast, and Mike Steckel; http://www.boxesandarrows.com/view/controlled_vocabularies_a_glosso_thesaurus

Dublin Core Metadata Initiative

http://dublincore.org

Flamenco Search Interface Project

http://flamenco.berkeley.edu

Glossary of Terms Relating to Thesauri

http://www.willpowerinfo.co.uk/glossary.htm

Taxonomy Warehouse

http://www.taxonomywarehouse.com/

ThesauriOnline

http://www.asindexing.org/site/thesonet.shtml

只能說哇,怎麼這麼多啊,慢慢看吧。

Print Friendly

Tags: Controlled Vocabularies, Faceted Classification, Information Architecture for the World Wide Web, Metadata, Thesauri, 中介資料, 優先術語, 分析-組合式分類法, 分類法, 同義詞環圈, 層面分析, 層面分類, 彙編詞彙, 技術行話, 控制詞彙, 權威檔案, 面向式分類法
Posted in Information Architecture for the World Wide Web | No Comments »

Yo!Search Systems

2011-08-29,Last modified: 2011-08-26Please wait

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

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

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

網站需要搜尋功能嗎?

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

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

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

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

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

搜尋不是一種IT玩意

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

選擇要搜尋什麼

決定搜尋區域(search 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,另一種則是結果太多,這時該怎麼辦?

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

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

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

上哪兒學更多?

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

  • 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/

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

Print Friendly

Tags: Computing (magazine), Google, Information Architecture for the World Wide Web, Information retrieval, search, Search Systems, 搜尋系統
Posted in Information Architecture for the World Wide Web | No Comments »

Yo!Navigation Systems

2011-08-03,Last modified: 2011-08-02Please wait

這是資訊架構學–網站應用,第三版的第七章:導覽系統(Navigation Systems),開場白有這樣一段『等一下,葛瑞蒂,月亮還沒昇上來。等到月亮昇上來,才能看見我灑的麵包屑。麵包屑會告訴我們回家的路。- 《韓森與葛瑞蒂》』一開始就來這樣的故是很丈二摸不著頭腦說,而且用韓森與葛瑞蒂Google不出什麼東西來,後來還是用Hansel and Gretel原文來Google才找到糖果屋的維基,而且維基的中文翻作漢賽爾與葛麗特,難怪用韓森與葛瑞蒂找不到,這也凸顯出除了前面所說的有關命名的問題,會因為語言的不同導致翻譯更加地不同,好了,這只是在稍微敘述一下,問題的複雜而已,這個故事其實是一則由格林兄弟所收錄的德國童話,所以感覺ㄚ琪小時後有看過這樣的童話故是喔,原來我已經忘記了。

提起導覽系統,ㄚ琪一開始就先享用很務實的作法來看看這一章會有什麼建議,所以也Google了Wordpress的導覽系統,很不幸用中文找還是失敗,但是當我們用Navigation Systems來找時,就發現了一些很有趣的問題了:

Can WordPress handle sub-navigation systems?

大意是WordPress可以處理子導覽系統嗎?

聽到有人回說分頁可以有子分頁,聽到這裡,想必大家會比較清楚,WordPress可以用分頁來做導覽系統。

Where do I get menu navigation systems from?

大意是我可以從哪裡獲得選單式的導覽系統?

這裡的回覆是說可以從外掛程式來做。

這是ㄚ琪目前可以很快找到的問題,也猜想如果要做好工作達人的導覽系統,可能要從分頁來做,OK,接下來就來細看文章,看如何做好工作達人的導覽系統囉。

導覽系統的種類

導覽系統是由好幾個基本元素或者子系統所組成的。首先,我們有全站、區域、和情境式導覽系統,可以在網頁內自行整合。

2011-07-28_151158

其次,我們有輔助性導覽系統,像是網站地圖、索引、指南,會出現在存放內容網頁以外的地方。

2011-07-28_151841

看起來好像是Wordpress用左邊的側邊攔可以做導覽系統,而輔助性導覽系統,還是可以由分頁或是側邊攔,可能是下方的側邊攔來做吧,我猜。但是如果工作達人的側邊欄是在右邊的話,是不是就跟上述的導覽系統不一致了,很是好奇,有人說側邊欄要在右邊,又有人說要在左邊,很亂說。

重要的灰色地帶

『導覽系統的設計會讓我們深入資訊架構、互動設計、資訊設計、視覺設計以及可用工程之間的灰色地帶。』

『我們一開始談全站、區域和情境式導覽時,就發現我們處在連結策略、結構、設計和實作細節的滑坡上。區域導覽棒放在網頁頂端是否最好?或者放在左邊會比較好?我們要不要用下拉式選單、彈跳式選單、或者串接式選單(cascading menu),減少點選的次數?用戶會不會注意到灰色的連結?使用藍/紅連結的顏色慣例會不會比較好?』

這裡的問題就是ㄚ琪在前面所提到的類似問題,導覽放的位置這類的實作技術問題,但似乎是很模糊,作者好像也沒說清楚,他只說會丟救生索給我們,會有一堆參考資料跟書籍給我們看,這下可就暈倒了。

瀏覽器的導覽特點

這裡頭主要討論Mozilla Firefox跟Microsoft Internet Explorer兩個瀏覽器,有關他們的特點或者說是功能,我就不再贅述,但是從『預期檢視(prospective view),會影響用戶的導覽行為。』這倒是ㄚ琪沒有注意到的,感覺好像是有這麼一回事,可是可能沒有確實注意到吧。而這個檢視就是『當用戶把滑鼠游標移到某個超連結上面時,目的地的URL會出現在瀏覽器視窗底端,暗示該內容的本質。』例如當滑鼠游標移到張擇端上面時,底端會顯示該網頁的URL,ㄚ琪似曾用這樣的方式來檢驗這個連結的合理性,原來有特別的意義在,另外在IE裡頭其實有個困擾,就是中文的連結會顯示原來的編碼結構,可是在Firefox裡頭還是可以顯示中文的,這裡頭就又顯示出Firefox的超人一等了。

2011-07-29_135216

因為這樣的特點,有時候網站攝記者會犯了一些錯誤:

  • 沒有改變參觀過/未參觀連結的顏色。
    殺掉(Back)鈕。
    把書籤功能廢掉。

建立情境

『和一般旅行不同的是,超文字的導覽,可以讓用戶立刻連結到某個不熟悉的網站內部去。來自於遠端網頁的連結和搜尋引擎回傳的連結,可以讓用戶完全跳過網站的主頁或前門。更複雜的是,我們常常會列印網頁,以供後續閱讀,或者傳給某位同事,結果就讓情境完全消失了。基於上述原因,設計導覽系統時,情境是老大!』

『你一定要遵守一些法則,確保你的網站有提供情境的線索。』

『導覽系統應該以明確而一致的風格,展現資訊階層的結構,且要指出用戶當前的位置。』如圖所示。這是新版的Wal-Mart版面,它跟舊版的版面類似,還是可以顯示用戶在階層系統中的位置,方法是在網頁左邊側邊欄上方使用『Search In』,雖然跟舊版的『You Are Here』有別,但是一樣可以幫助用戶建立一個組織體系的心智模式,可以方便導覽且使他們覺得舒適。』

2011-07-29_143957

說到工作達人的實作,ㄚ琪其實當初有看過breadcrumb這類的使用,不過當初對這個文字看起來不熟,這個英文字典查(烹調食物時)在…上覆以麵包屑,看來這個麵包屑已經被延伸到導覽列的意義了,後來忘記了,也不瞭解其重要性,看到這裡有重新點燃ㄚ琪的感覺了,不過已經忘記了這個叫什麼?

這一次ㄚ琪試著用You Are Here這個關鍵詞Google時,很神奇地找到了Wordpress的Breadcrumb NavXT這個外掛,看起來可以測試看看,其實也有另一個叫做You Are Here的外掛,不過久沒更新了,不推薦。

這裡再重述之前Keith Instone提出的導覽壓力測試(Navigation Stress Test)的基本步驟:

  1. 1.忽略首頁,直接跳到網站裡面。
    2.隨機選一網頁,你能知道你的位置與網站其他部份的關係嗎?你正在哪一區?上層網頁是什麼?
    3.你能知道這張網頁會把你帶到哪一頁嗎?連結的文字說明足夠讓你知道連結背後是什麼嗎?連結是否有足夠的差異性,可以讓你根據你想要做的事做選擇?

改善彈性

『階層式系統是組織資訊相當常用而有力的方式。』就像Gopher系統這樣,但是這個有一些缺點,『要在樹枝之間跳動(橫向導覽)或者多個階層之間跳動(直向導覽)』就不行了。

2011-08-01_134248

『網站的超文字功能把這些限制消除掉,給予導覽相當大的自由度。就像下圖這樣的結構,跳來跳去的有點讓人困惑。

2011-08-01_140830

『設計導覽系統的技巧是平衡彈性的優點和混亂的危險。』

嵌入式導覽系統

全站導覽系統

『所謂的全站導覽系統就是要在網站上的每一頁,都展示的全域導覽系統。』

區域導覽系統

這裡頭有一個重要的概念,就是子網站或網站中的網站,根據參考的資料,說這是Jakob Nielsen在1996年的一篇文章The Rise of the Subsite提到大網站中的一群網頁,有共同的風格,可共享導覽機制。『子網站存在的理由有二。首先,內容和功能的某些區域實際上是值得採取獨立的導覽手段。其次,由於大型組織有分散的本質,不同的人通常負責不同的內容區域,且每一群組會以不同的方式處理導覽。

情境式導覽

『有些關係不適合放在全站和區域導覽結構分類中。此時就需要建立情境式導覽連結,指向特定的網頁、文件或物件。』

『設計情境式導覽系統時,要想像網站上的每一頁都是主頁,或者本身就是入口網頁。』

實作嵌入式導覽

剛剛介紹了三種導覽系統,當然ㄚ琪建議去翻一下這本書,內容我就不再浪費我的手指去打這些字了,現在要談到實作,雖然ㄚ琪看完這章還是覺得有點模糊,作者也沒提供解答,一切都是架構者自主地決定吧。不過還是有一些重點提出來參考。

例如,文字式導覽棒比較好,還是圖形式導覽棒比較好?這個答案看起來是文字式導覽棒了,但是如果使用圖形式導覽棒可以做到一些防範,也不是不可啦。

導覽棒應該放在網頁的哪裡?全站導覽棒放在網頁頂端,區域導覽放在左手邊,已是慣例。這樣看起來工作達人好像有需要動土了,不過看在ㄚ琪懶,這就算了吧,希望讀者可以習慣工作達人的安排。

文字標籤和圖示要選哪一種?看起來又是文字標籤比較好一點。

逐漸普遍使用的DHTML和JavaScript的rollover,在類別或選單選項下顯示導覽選項的方式呢?答案是視情況而定,當然這是作者說的,而且ㄚ琪雖然知道這個功能算是很炫的,但是我也沒想要玩這個功能,主因是WordPress是否有支援,還得找一下,另外還是要花時間來做,所以時間不太允許我來瞭解這個功能吧。

用框格(frame)行嗎?根據現況看起來是不流行了,可是Google的Blogger卻大玩iframe的功能,Facebook也是,看起來這是另一種流行了。

輔助性導覽系統

這包括網站地圖、索引和指南。

『輔助性導覽系統是確保大型網站的可用性和可尋性的關鍵因子。然而,它們常常不受重視,而且也沒得到應有的發展。』這倒是事實,工作達人現在看起來都沒有這些系統,而且也不知是否有必要。

網站地圖

『典型的網站地圖是展示資訊階層的頂端幾層,在內容上提供更寬廣的視野,方便隨機存取被區隔的各部份內容。』

『如果架構本身的階層不強,則採用索引或另一種是覺表達方式可能比較好。』咦,這樣說來工作達人看來比較不需要網站地圖囉。

網站索引

前文提到工作達人可能需要網站索引,但是書裡的介紹,說『最主要的困難是粗細程度的問題』,這倒是沒錯,因為ㄚ琪剛想到用標籤(tag)似乎可以做索引系統,但是如果是這樣的話,又牽涉到大標籤跟小標籤的困難。

『建立網站索引有兩種方法。對小網站而言,可以利用你對內容瞭解的知識來決定要引入哪些連結,然後手動建造索引。這種中央控制的,手工建置的方式會得到單階段索引(one-stop index)。』

2011-08-01_155945

這個新版的AOL Discover很像舊版的AOL Anywhere,一樣有索引,不過ㄚ琪上到AOL首頁時,點網頁的導覽時,最右邊的More連結才能進來此,這還折騰了一會兒時間,看來導覽的設計對我這個使用者來說是有問題的,不過AOL Discover的設計看起來倒是沒問題。

另外,『對大型網站而且有分散式內容管理特性者,在文件層次上採控制詞彙編制索引,再自動產生網站索引,可能比較合理。因為很多控制詞彙可能會出現在很多文件內,這種索引必須經過兩階段步驟。首先,用戶從索引中選擇術語,然後,再從以該術語為索引的文件清單中選出想要的。』

『設計索引的有用技巧牽涉到術語輪替,也稱為替換(permutation)。』

指南

指南(guide)的形式有好幾種,包括導引參觀、教學課程,以及針對特定觀眾、主題或任務而設的小入口網站。無論是哪一種,指南都能補足現有的瀏覽和理解網站內容的方法。』

設計指南的原則如下:

  1. 1.指南應該要短。
    2.無論何時,用戶都能離開指南。
    3.導覽的位置在每一頁上應該都相同,這樣用戶才能在指南中來來回來。
    4.指南的設計應該是用來回答問題的。
    5.快照應該乾脆、明確,及最佳化,具有把重點功能放大的效果。
    6.如果指南有好幾頁,則可能需要目錄。

精靈和組態器

這是特殊的指南形式,而且圖例是更先進的精靈和組態器:

2011-08-01_164224

搜尋

『搜尋系統是輔助導覽的核心部份。…語言的模糊性使得大部份的搜尋經驗都有問題。』

進階的導覽方法

個人化和客製化

『個人化(personalization)就是針對個人的行為、需求和喜好的模式,提供剪裁後的網頁給用戶。相反地,客製化(customization)是給用戶直接控制權,可以針對展現格式導覽和內容選項的組合作調整。』

另外個人化和客製化:

通常扮演重要但有限的角色。
需要有扎實的結構和組織基礎。
很難做得好。

個人化其實ㄚ琪很想做,但是看到這裡後,就覺得沒有必要了,書裡還分析這是來自於Don Peppers跟Martha Rogers的The One to One Future (Doubleday)一書的影響,也不知是不是這樣,有興趣的人可以翻一翻外文書看怎樣。

這是一把兩刃刀,好處我就不提了,壞處值得一提:

『個人化在特定情境中運作得很好,但是,當你將之擴展到整各用戶經驗時,就會失敗。』

『客製化的問題則是大部分的人都不想花時間自訂什麼,也只願意在少部份對他們而言很重要的網站上這麼做。』這倒是很真實,對我來說是如此,但是我覺得也有例外吧,像有些人對Google的客製化就很有興趣,但是我還是興致缺缺。

還有一個問題就是連自己都無法預測明天會做什麼,那麼客製化的效果就很有限了。

視覺化

ㄚ琪沒有這樣的才能,自然看到不是很有用的話時,會特別興奮,所以也不會多說什麼囉。

社群導覽

『從比較正面的觀點看,社群導覽(social navigation)的願景是建立在個人的價值觀可以從觀察其他用戶的行為中推論出來;社群導覽依然保有偉大的願景,而且已經是最快被接納的主流意見。』這包括New York Times的Most Popular、Amazon的協同過濾引擎、Epinion的推薦引擎及Flickr的標記群,這種流行的區是應該再很多的網站上多看得到,我就不多舉例了。

看完這裡,ㄚ琪還沒什麼想法可以替工作達人做什麼,如果讀者有建議可以撥冗留個言吧。

Print Friendly

Tags: breadcrumb, Information Architecture for the World Wide Web, 全站導覽系統, 區域導覽系統, 情境式導覽, 指南, 架構, 網站地圖, 網站索引
Posted in Information Architecture for the World Wide Web | No Comments »

Yo!Labeling Systems

2011-07-27,Last modified: 2011-07-25Please wait

這是資訊架構學–網站應用,第三版的第六章:標籤系統(Labeling Systems),『分類標籤的命名是一種表達形式。…所以,標籤的目標是有效地溝通訊息;也就是說,傳遞意義時,不用佔用太多網頁的垂直或者說是用戶的認知空間。』這個目標其實是很清楚的,主要就是用來溝通,但是清楚並不代表容易做,這一章與上一章相形之下,ㄚ琪會更注重這個目標。

『…我們標籤的產生遠超過網站,從亞當替動物命名開始,標籤命名的事就是人類之所以為人類的基本能力之一。』這裡引用到了亞當的故事,ㄚ琪重複一次經文的使用,在舊約創世紀2:19,『耶和華神用土所造成的野地各樣走獸和空中各樣飛鳥都帶到那人面前,看他叫什麼。那人怎樣叫各樣的活物,那就是他的名字。』,所以標籤的命名不是新技術,而是自有人類以來,神創造我們就有的能力。而就因為如此,我們往往在我們的網站上訂了很爛的標籤,當然是因為是網站,所以與人互動的模式比較慢,而且難,所以像ㄚ琪的工作達人的標籤訂定,ㄚ琪還沒見過有人抗議的,一切都在自我感覺良好的模式下進行著,也就是如此,ㄚ琪很有警惕自我的自知之明,希望從這一章的建議,可以思考工作達人的標籤系統。

為何關心標籤命名之事?

『當我們經由自己設計的網站與用戶「交談」時,對方有任何的言行反應就無法立刻得知。』書中說部落格較例外,但是ㄚ琪經營這麼久的工作達人,還是發現多數的人潛水居多,事實上還是很難跟用戶對話。正因為溝通便得如此困難,所以『命名標籤之事更顯重要』了。

『用戶和網站擁有者之間的對話,通常是從網站的主頁開始。要瞭解對話是否成功,可以連到某個網站的主頁,盡可能忽略設計上的其他面向,然後,問你自己一些問題:主頁上顯著的標籤是否吸引你?如果是,原因是什麼?如果標籤是新的,沒看過的,或者令人困惑的,網站上是否有說明?或者,你是否必須點一下才能知道?雖然不科學,這種標籤測試的行為,可以讓你瞭解用戶實際對話的情形。』

2011-07-18_172601

現在的版面

2011-07-18_172856

過去的版面

ㄚ琪只要說,現在的版面裡面的標籤看起來是很直覺得了,真的是比以前的要好。

過去的標籤系統有這些的缺點:

  • 標籤的代表性不夠,而且沒有做區隔
  • 標籤行話成份太重,沒有以用戶為核心
  • 標籤浪費錢
  • 標籤無法讓用戶得到好印象

各式各樣的標籤

情境式連結

指向其他網頁中大塊資訊的超連結,或者指向同一張網頁中的另一個位置。

標題

用來描述接在其下的內容。

導覽系統選項

代表導覽系統中選項的標籤。

索引術語

供應搜尋或瀏覽的關鍵字和主旨標題。關鍵字和主旨標題代表的是內容。

標籤作為情境式連結

這裡有關於個人網誌(blog:部落格)的說明,『情境式連結就沒必要那麼講究。來看網站的都是作者的朋友,作者可以假定他的讀者都擁有相當程度的背景,也就是情境知識。或者,作者覺得讓連結標籤的意義模糊一點,可以讓讀者在瀏覽時有一點神秘感。所以,作者可能會決定在設計情境式連結標籤時少一點代表性意義。』

個人網誌似乎是這樣子沒錯,倒是工作達人一開始就沒有設限為朋友之間的溝通,所以我發覺也不能太神秘,設定標籤還是要有意義一點,比較可以讓ㄚ琪較不熟的朋友更自在使用吧。

資訊建築師在這裡應該可以自問:『用戶點下去之後,期待看到怎樣的資訊?』

另一方面要承認情境式連結,常常不在資訊建築師的掌控之中是很重要的。而且大部分是作者自己知道的,好在ㄚ琪既是作者,也自詡是這各的資訊建築師,所以這個問題就比較可以克服。

將標籤作為標題

『標籤時常被作為標題使用,而標題就是描述接在其下面的大塊資訊。』

『標題之間的階層關係,無論是大標題、小標題或同層次的標題,通常是透過一致的編號、字型大小、顏色和樣式、空白和縮排、或者是這些組合起來建立的。』

有關標題的討論,可以參考ㄚ琪的部落格內容密技-標題是所有的一切及站內最佳化這兩篇文章。

導覽系統內的標籤

『因為導覽系統內通常有一小群選項,因此標籤應用上的一致性要求,就比其他種類的標籤更嚴格。』

『用戶是仰賴導覽系統的,經由一致的網頁位置和外觀,產生合理的行為;標籤也應當如此。』

這裡有一些參考作法:

  • 總頁(Main)、主頁(Main Page)、首頁(Home)
    搜尋(Search)、尋找(Find)、瀏覽(Browse)、搜尋/瀏覽(Search/Browse)
    網站地圖(Site Map)、內容(Contents)、目錄(Table of Contents)、索引(Index)
    聯絡方式(Contact)、與我們聯絡(Contace us)
    說明(Help)、FAQ、常問問題與解答(Frequently Asked Questions)
    新聞(News)、新聞&大事紀(News&Events)、新聞&聲明(News&Announcements)、聲明(Announcements)
    關於(About)、關於我們(About Us)、關於(公司名稱)(About <company name>),話說本站(Who We Are)

『同樣的標籤通常可以代表不同類別的資訊。…如果你在網站中以不同方式使用相同的標籤,用戶會感到困惑。』 『為了解決這些問題,導覽標籤可以在主頁上做簡單的說明以強化其意義(也稱為範圍註解)。』這個的意義甚佳,ㄚ琪也滿想要這樣做的,讀者也贊成嗎?給個留言讓我知道吧。

標籤作為索引術語

『索引術語標籤時常被稱為關鍵字、標記、描述性中介資料、分類法、控制詞彙、以及彙編詞彙,有幾組索引術語標籤可以描述任何型態的內容:網站、子網站、網頁、內容區塊等等。』 『索引術語也可以讓瀏覽更容易一些:來自於一群文件的中介資料,可以作為可瀏覽清單或選單的來源資料。這一點對用戶很有益處,因為索引術語提供另一種途徑觀看網站的主要組織系統(像是游士頁單位所組織的資訊架構)。』 Search Engine Watch (http://www.searchenginewatch.com)是最有用的資源網站,你可以在此學到Web搜尋引擎與目錄的運作方式,以及如何替網站的主頁和其他主要網頁做索引,以增加你的網站跑到搜尋結果最上端的機會。

圖示型標籤

『除非你的網站有一群忠實而有耐心的群眾,願意學習你的視覺語言,否則,我們建議你指針對系統的少量選項使用圖示標籤;要小心不要把造型放在功能之上。』還好ㄚ琪也不太會畫圖,所以工作達人上也不會有太多這種圖示,不知讀者又是怎樣的感覺?

設計標籤

下面是一些原則:

通用的原則

盡量窄化範圍

『窄化的商業情境,意指網站的目標和架構更明確,顯然,標籤也會達到更明確的效果』。

『如果你正在規劃網站的範圍,例如,誰要用網站、內容是什麼、以及網站要怎麼用、何時用、為什麼別人要用等等,鎖定簡化為其目標,就會讓你的標籤更有效。』

『如果你的網站必須擠入所有的生意,則要避免使用會代表整個網站內容的標籤。』

發展一致的標籤系統,而非標籤

『為什麼一致性很重要?因為一致性代表的就是可預測性,當系統可預測時,就容易學習。』

一致性會受到的因素:

  • 風格
    版面形式
    語法
    粗細程度:『不考慮例外情況,用戶要是碰到一組標籤其含義有不同的粗細程度,則會感到很困惑的。例如,「中國菜餐廳」、「餐廳」、「法式速食店」、「漢堡王」等等。』這樣子說來,工作達人的分類系統倒是做得像是這回事,但是標籤好像就很難分出粗細程度,我向或多或少會影響到使用者的困惑了。
    理解性:例如,如果服飾零售商的網站列出「褲子」、「領帶」、「鞋子」,但不知怎地,漏掉了「襯衫」,我們可能就會覺得哪裡出錯了。
    觀眾:把「淋巴瘤」和「肚子痛」這樣的詞混在某個標籤系統中,也會讓用戶感到不解,即使只有暫時性的困惑。

標籤系統的來源

『你的網站、或類似網站、或競爭對手網站上,現存的標籤系統可能包含你需要的標籤。』

你的網站

『一個有用的做法是抓出單一文件內現有的標籤。』哇,這個工程可浩大了,而且感覺是修正網站的所有標籤使其一致性,至少ㄚ琪現在看起來是這樣,ㄚ琪直接剪圖來看範例:

2011-07-20_141221

『以表格的方式整理標籤,可以用更集中、更完整、更精確的觀點,看待網站的導覽系統,將之視為一種系統。不一致性就很容易抓出來。』這就正如ㄚ琪所預料的,讀來這裡直拍案叫絕。

類似網站和競爭對手網站

2011-07-20_142007

ㄚ琪直接舉書中的範例,看上圖這四家Compaq、Gateway、Dell和IBM的標籤系統,我只能說大家都學到借用的能力了,講白點就是抄,不過網路是共享的,沒有人可以管你怎麼抄,但是要注意內容可不能大抄啊,否則隨時會被注意到。

控制詞彙以及彙編詞彙

一些圖書館或特定領域專家所建立的詞彙既是公開且被廣泛使用的。

這裡有個實例,『教育資源資訊中心彙編詞彙(Educational Resources Information Center(ERIC) Thesaurus)。』

這裡列出四個標籤來源:

  • Taxonomy Warehouse: http://taxonomywarehouse.com/
  • ThesauriOnline (American Society of Indexers): http://www.asindexing.org/site/thesonet.shtml
  • Controlled vocabularies (Michael Middleton): http://sky.fit.qut.edu.au/~middletm/cont_voc.html
  • Web Thesaurus Compendium (Barbara Lutes): http://www.ipsi.fraunhofer.de/~lutes/thesoecd.html

真沒想過有人會建這樣的系統,而且ㄚ琪也從不知道有這樣的系統可以幫忙建構標籤系統,但不知華文的世界又是如何?

建立新的標籤系統

內容分析

『你可以讀取網站中有代表性的內容,然後替每份文件速記一些描述性的關鍵字。』快一點的作法是『把焦點放在內容中具代表性的資料,像是標題、總結和摘要』。

另外有一種自動粹取工具,可以幫你解決80%的工作。

讀來這裡ㄚ琪覺的這一小節有點奇怪,要建立新的標籤系統,可是卻是由你現有的內容來做分析,看起來好像是原來的網站系統沒有作標籤,現在要增加這個功能的樣子。而自動萃取工具除了後文會介紹之外,ㄚ琪算是也頗有心得的,因為碩士論文就是主攻這一類的技術,不過我是寫自動分類,看起來倒是像自動標籤了。讀來這裡,ㄚ琪馬上想到工作達人是否可以有自動標籤的功能,很快地Google了一下,發現有用Simple Tags來強化WordPress的標籤功能,提到了這個外掛有自動邊籤的功能,怎以前沒注意到,以前總以為Simple Tags就是簡單的意思,所以想說WordPress有了飆籤的功能後,應該就不需要這個外掛了,現在透過這書的教導,聯想,查詢,實作,原來學問可能就是這樣養成的吧。馬上試用看看。糟糕,該篇文章說明好像有點過時,圖文對不太起來,看來有空需要再另起一篇文介紹了,ㄚ琪先擱著了。

內容作者

對工作達人來說,ㄚ琪就是其中的一位作者,而且算是最主力的作者,所以要球內容作者替內容建議標籤,當然責無旁貸了,不過有時也會發生矛盾的情形,因為ㄚ琪自己可能也無法為這內容提供洽當的標籤,這就陷入了困擾了。

用戶代言人以及主題專家

除了上述兩種方法之外,『找到專門的用戶或者所謂的用戶代言人,可以從用戶的角度發言。像這樣的人可能有圖書館管理員、接線生、或者主題專家(subject matter expert , SME)。』

直接來自用戶

卡片排序(card sort)

『卡片排序練習是瞭解用戶如何使用資訊的最佳方式之一。』有開放式跟封閉式兩種。『開放式卡片排序可以替現有內容按主題分成各自的類別,然後,再替這些類別命名標籤。封閉式卡片排序乃根據現有的類別分主題,然後再將內容排序到這些類別。』卡片排序方法很有用,但是不能作為唯一的一種工具。

自由表列

『這是取得用戶建議之標籤成本更低的方法』。這方法參考Rashmi Sinha’s在Februrary 2003 Boxes & Arrows, “Beyond cardsorting: Free-listing methods to explore user categorizations” (http://www.boxesandarrows.com/view/beyond_cardsorting_free_listing_methods_to_explore_user_categorizations).

作法:選個項目,讓實驗對象瞬間想出一些字眼予以描述。

間接來自用戶

『多數機構都是立於描述需求的用戶資料範疇頂端。分析這些搜尋查詢是調整標籤系統的絕佳方式,更別提用於診斷網站其他各種問題。此外,最近出現的通俗標記法,也是一種有關用戶需求的間接來源,相當有價值,有助於資訊建築師發展標籤系統。

搜尋日誌分析

搜尋日誌分析(也稱為搜尋分析法)是最沒有入侵性的資料來源方式,以取得網站觀眾實際使用的標籤資訊。可以參考”Search Analytics for Your Site: Conversations with Your Customers ”,Louis Rosenfeld 及Rich Wiggins合著。

ㄚ琪覺得這裡大家可以用Google Analytics(分析)或是AWStats,應該就可以符合我們的使用需求了。

標記分析

『採用通俗標記法的網站最近爆增,這意謂著你有另一種有用的間接標籤來源可以學習。』你可以參考del.icio.us或是Funp等之類的工具。

調整和微調

『首先,以字母順序排序術語清單。』我想這也是英文語系的國家比較可以做出來,華文的語系可能無法這樣做。

『然後,檢討清單,檢查其用法、標點符號、字母大小寫等等的一致性』。

『考慮系統的寬度及廣度』

『盡量把你的範圍窄化,集中焦點,使得它能夠清楚地描述你的網站讀有的內容之需求,解決觀眾的特殊需求,以及滿足事業目標,而且在定義明確的範圍之內又能充分得到理解。當然,追求這種目標是很困難的;所有的平衡舉措都是如此。』所以第一次看到書裡有稍微提到資訊建築師的收費應該是很高的,相信這在你選擇這個工作作為你的餬口生活一定有幫助的。

好吧,因為時代不斷變遷、環境不斷再變,相對的標籤也得一直變,看來要投入這個工作是很累人的。

Print Friendly

Tags: Labeling Systems, 架構, 標籤系統, 標題
Posted in Information Architecture for the World Wide Web | No Comments »

« Older Entries
  • 1
  • 2
  • 下一頁>

廠商贊助

贊助廠商連結請點我

最新照片

P3070130 P3070116 P3070114 P3070104 P1111402 IMAGE_958 IMAGE_941 DSC_6159 P1121426
觀看更多的相片 >

熱門文章

  • GTK+ 2.0 教學 - 13,446 views
  • jQuery UI入門 - 7,623 views
  • 介紹NetBeans下的Android開發 - 6,967 views
  • 正確使用java array - 5,898 views
  • eclipse 3.4.1 中文 好好玩 - 5,125 views
  • 程式語言教學 – C、C++、OpenGL、STL - 4,233 views
  • GTK+ 2.0 教學-從這裡開始 - 3,648 views
  • jQuery UI 的 Demos展示及說明文件 - 3,562 views
  • Python 圖形使用者介面程式設計 - 2,813 views
  • 如何在手機裡安裝Java ME應用程式 - 2,603 views
  • Microsoft Visual C# 2010 Express更新 - 2,532 views
  • sudo apt-get install sun-java5-jdk - 2,332 views

隨便看看

  • Yo! User Needs and Behaviors
  • Yo!Navigation Systems
  • Yo! Research
  • Yo!Search Systems
  • Yo! Strategy
  • Yo!Thesauri, Controlled Vocabularies, and Metadata
  • 讀資訊架構學--網站應用
  • Yo!The Anatomy of an Information Architecture
  • Yo!Organization Systems
  • Yo!Labeling Systems

懶得上網看文章!

就來訂閱我的電子報吧!

輸入你的電子郵件地址:

發送者為 FeedBurner

近期文章

  • 感興趣的xampp-win32-1.7.7
  • 與其給我邀請送禮物,倒不如幫工作達人按讚
  • 【夏日保養】小心辦公室冷氣,讓雙手提早變老!
  • 成人紙尿褲價格戰 苦了父母
  • Smart Life創意無痕壁貼
  • 不用出國的專業全美語兒童營隊
  • 試用BUGSLOCK純天然香茅防蚊手環(防蚊效果一級棒)
  • 多功能的除污達人
  • 五月連結Fun Taiwan送【DIANA】愛媽咪施華洛彩鑽項鍊
  • 網購熱銷缺貨!titan抗菌活力襪,抑菌除臭、護腳2合1

鳥鳴啾啾

    Follow Me on Twitter

    與我交誼!做我的粉絲!

    • technorati
    • Twitter

    其它

    • 登入
    • 文章 RSS 訂閱
    • 迴響 RSS 訂閱
    • WordPress.org

    快上www.blognews.com.tw,就有機會天天免費吃大餐!

    我的書摘

    RSS 科技新聞 – 頭條新聞 – Yahoo!奇摩新聞

    • 摩托行動侵權 部分手機遭禁 2012/05/19
    • 臉書掛牌上市 電腦出包 2012/05/19
    • 揭祕深海不明物體 專家:罕見水母! 2012/05/19
    • 大馬發明展 台灣學子溫馨奪金 2012/05/19
    • 亞洲市場成長趨緩 臉書新挑戰 2012/05/18
    • 蘋果亞馬遜相爭 面板雙虎得利 2012/05/18
    • 擁近10億用戶個資 將是獲利關鍵 2012/05/18
    • 小行星撞地球 中日菲會重創 2012/05/18
    • 小行星若撞地球 大陸先遭殃 2012/05/18
    • 英「條碼」小鎮 維基百科導遊 2012/05/18
    • 臉書濫用個資 人權組織要告 2012/05/18
    • 美報告:陸藉西方科技壯大軍力 2012/05/18
    • 點閱率低 臉書廣告效果惹議 2012/05/18
    • 英小鎮掃條碼 維基百科當導遊 2012/05/18
    • 玻璃構成的一天 影片解密未來世界 2012/05/18

    Blogroll

    • 628之巨蟹座的水世界
    • Blog語法研究室
    • Chip123創新論壇
    • Chungyuchen's Blog
    • Daphne's Fresh Look
    • Frank的雜記
    • Fun Taiwan
    • GOWEIS的好康分享記事簿
    • L K K 的心聲
    • LuckyDog 抽獎達人
    • Office 達人空間(章美蘭)
    • Potato的探索樂園
    • QK3000小遊戲
    • Russian Brides
    • Web Game @Live
    • yal's blog
    • 《心靈翅膀》發現不同的聲音
    • 『PDF』點滴夯發現
    • ㄚ晟的IT筆記
    • 企鵝碎碎唸
    • 傑尼斯部落
    • 免費訊息軟體下載
    • 免費軟體下載
    • 凱特打結該該叫
    • 台中蔣小姐
    • 台灣天氣網
    • 台灣排行榜 Rank.tw
    • 台灣部落格網站目錄
    • 嗡財財嚕嚕唆哈
    • 大紀元賀卡城
    • 好朋友二手家具
    • 小遊戲388
    • 小遊戲天堂
    • 小邱邱的測量放樣工程
    • 拆組達人
    • 敗家誌°
    • 時間不等於金錢
    • 月光下的嘆息!
    • 梅森手扎
    • 淘淘寶小遊戲天堂區
    • 玩物尚誌
    • 生活工場家
    • 白文MIMI與小鸚KIKI的生活記事
    • 紅色死神
    • 綠色工廠 Easylife Blog
    • 網路聯盟行銷中心
    • 美食美景紐西蘭美女的家
    • 蓉兒ㄉ天空
    • 遊戲世界
    • 遊戲阿布
    • 遨遊天地任我行
    • 野兔村
    • 阿文兄A日誌
    第五屆部落客百傑 第五屆部落客百傑 第五屆部落客百傑



    GetRank - Webmaster and Seo Tools
  • 分類
    • Android
    • ASP
    • BU幣任務區
    • C#
    • CentOS
    • CGI
    • CompScience
    • C_and_CPP
    • Database
    • DB2
    • debian
    • Featured
    • In Search of Stupidity
    • Information Architecture for the World Wide Web
    • j2me
    • java
    • JavaScript
    • JavaScript權威指南:ECMAScript5 + HTML5 DOM + HTML5 BOM 範例精粹
    • Languages
    • lds
    • Linux
    • LinuxDev
    • MSSQL
    • MySQL
    • NetSecurity
    • Office
    • Oracle
    • Palm
    • Peopleware: Productive Projects and Teams
    • perl
    • php應用
    • PostgreSQL
    • Python
    • Quality is Still Free
    • ruby
    • Solaris 系統
    • Sponsored Reviews
    • Symbian
    • System
    • THE MYTHICAL MAN-MONTH
    • The Peter Principle
    • TinyERP
    • ubuntu
    • Uncategorized
    • VBA
    • VoIP
    • Web Blog
    • weberp
    • Windows
    • windows mobile
    • Wordpress
    • xml
    • ㄚ琪走透透
    • 中壢社大河川踏查社
    • 人才庫
    • 企業ERP
    • 免費好康
    • 公司簡介
    • 口碑貼文
    • 商品推銷
    • 就業資源
    • 工作大未來
    • 工作訓練
    • 廠商簡介
    • 我攝過的教堂
    • 我的論文
    • 掌握Google關鍵字:SEO搜尋秘技全攻略
    • 數位拍古蹟
    • 文章導讀
    • 求才訊息
    • 生活與社會
    • 發燒鑑貨文
    • 直到路的盡頭
    • 神社
    • 科技通訊
    • 笑話
    • 約耳趣談軟體
    • 組合語言
    • 網站報報
    • 網站評論
    • 網路賺錢
    • 美味食記
    • 翻譯
    • 職業達人
    • 自然與科學
    • 藝術與表演
    • 觀察力培養
    • 設計模式之禪
    • 貼貼樂
    • 資料處理
    • 軟體報報
    • 閒聊
  • 最新的回應

    • 小倆口東京自由行-Day 2一日乘車券 | 工作達人(Job Da Ren) 在 小倆口東京自由行-Day 2明治神宮
    • Washer Parts - Our site provides essential information on ge appliance parts - Ge Appliance Parts 在 Whirlpool Appliance Parts
    • ㄚ琪 在 四月連結Fun Taiwan送好市特超大附門掛衣架組
    • MESON 在 四月連結Fun Taiwan送好市特超大附門掛衣架組
    • GP 超霸充電池高電力鎳氫(NiMH)電池第十五次使用 | 工作達人(Job Da Ren) 在 GP 超霸充電池高電力鎳氫(NiMH)電池試用
    • ㄚ琪 在 webERP : WebERP 4.03.5 推出

    請幫工作達人按讚

    • Copyright c 2005 - 2009 工作達人(Job Da Ren) and is proudly powered by WordPress
    • Entries (RSS)
    • Comments (RSS)
    • Home
    • About achi
    • Archives
    • 隱私權政策
    • stock photos
    • Contact
    • Top Posts
    • Poll
    • wp-buzz
    • Advertise
    ss_blog_claim=fec8047405cd9a7a8d8d623b47b39edf
    Creative Commons Attribution-NonCommercial-ShareAlike 2.5 台灣
    This work by ㄚ琪 is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 2.5 台灣.

    无觅相关文章插件,快速提升流量