網頁應用程式測試工具Selenium IDE介紹

最近在學習程式開發的時候，發現許多人都推崇Selenium使用者端網頁應用程式測試工具。於是我試著使用Selenium來建立最近撰寫的圖片延緩載入與無限捲動功能，並學習如何使用Selenium IDE來撰寫測試案例。

Selenium簡介

網頁應用程式開發中，使用者介面的功能測試一向是相當困難的工程。以手動操作進行測試會受限於人力、時間，不僅容易出錯，也難以達到自動化迴歸測試的目標。

Selenium是用來解決上述測試問題的方案。它可以在Firefox中輕易地建立測試案例（Test Case），測試案例中一條一條的指令將會像自動機器人一樣確實地執行，並且記錄一切測試的過程與錯誤。然後測試案例可以用多種程式語言（Java、PHP、Ruby）模擬不同的瀏覽器（Firefox、IE、Safari）在不同的作業系統下（Windows、OS X、Linux）的運作情況，並將Selenium的功能測試整合到你的專案中，成為完整的整合測試。

下圖將說明Selenium專案如何運作，圖片來自於How Selenium Works網頁。

Selenium IDE

Selenium的功能眾多，在此篇要講的是Selenium IDE，也就是Firefox以擴充套件（add-on）方式安裝、用於撰寫Selenium測試案例的工具。光是Selenium IDE，就足以寫網站自動執行機器人了。詳細的用法可以閱讀官方的Selenium IDE介紹。Gossip也有寫過Selenium Web測試工具的介紹。稍後幾篇建立測試案例的過程中，我也會一一帶過Selenium IDE的常用功能。

安裝

Selenium IDE可以直接從他的網站連結上安裝（SkyDrive備份：1.0.12），Firefox add-ons搜尋會找到很多其他輔助的功能。

快速建立測試案例

Selenium IDE製作的這段影片簡單易懂地告訴了我們要怎麼建立測試案例。真的，幾乎就跟你在Word裡面建立巨集一樣地簡單。它做了幾件事情：

1. 開啟Selenium IDE
2. 開啟Selenium IDE中的錄製功能
3. 在Google搜尋selenium wikipedia
4. 進入Selenium維基頁面中
5. 確認文字「popular」的存在
6. 停止錄製，然後重播整個錄製過程

這個方法可以讓你很簡單地建立一個測試案例，然後再來微調測試案例的指令。

Selenium指令

Selenium最重要的核心功能就是指令了，所有測試都是以一條一條的指令所組成。Selenium的指令簡稱為「Selenese」。以下是摘錄Selenium 0.8 Reference的主要概述內容：

Selenium的指令（command）是告訴Selenium要做些什麼事情。Selenium的指令有三種類型：操作（Actions）、存取（Accessors）與驗證（Assertions）。每一個指令都會是以下表單中測試表格中的一行：

操作（Actions）

操作（Actions）是用來操作應用程式（指瀏覽器及網頁）的指令。它會執行像是「點選這個連結」、「選擇那個選項」的動作。如果操作失敗（Action fails）、或是發生了錯誤，將會導致現在的測試中止。

許多操作會伴隨著「AndWait」的後綴詞，例如「clickAndWait」。這個後綴詞是告訴Selenium這個操作將會導致瀏覽器去呼叫遠端的伺服器，而Selenium應該要等待新的頁面讀取之後再進行後續的檢查。

存取（Accessors）

存取（Accessors）是檢查應用程式的狀態，並將結果儲存在變數中，例如「storeTitle」（儲存網頁標題到變數中）。它們也用來自動產生驗證（Assertions）。

驗證（Assertions）

驗證（Assertions）就像是存取（Accessors），但它們是用來確認應用程式的狀態是否符合預期的結果。這些例子包括「確定網頁標題是否是X」（X將會寫在驗證指令中）、「確認這個核取表單（checkbox）是呈現勾選狀態」。

Selenium中所有的驗證都有三種模式：「驗證（assert）」、「辨識（verify）」以及「等待（waitFor）」。例如，同樣是驗證網頁中是否有某段文字存在，你可以執行「assertText」、「verifyText」以及「waitForText」。

前兩者之間的差別在於處理錯誤的方式。當「驗證」發生錯誤時，測試將會終止。當「辨識」發生錯誤時，測試將會繼續執行，並在記錄中保留錯誤訊息。你可以用「驗證」來確保應用程式是在正確的網頁中，如果不在正確網頁，那麼就不執行後續的測試。而「辨識」的驗證指令則可以用於測試表單的欄位值、標題文字等細節是否正確。

「等待（waitFor）」指令將會等待某些情況發生時才生效，這對AJAX應用來說特別好用，例如頁面等待著從伺服器回傳的資料時。當指定情況發生時，等待指令會馬上變成成功的狀態。反之，當情況一直沒有發生時，而等待時間又超過了逾時（timeout）設定，等待指令就會失敗，並終止後續的測試。

元素定位器（Element Locators）

元素定位器（Element Locators）是用來告訴Selenium哪些HTML元素將會用於指令中。許多指令都需要元素定位器作為「目標（target）」屬性。常見的元素定位器包括「elementId」（元素的ID屬性）、「document.forms[0].element」（文件中、第1個表單底下的元素）。

Selenium支援多種定位器寫法：

• identifier=id
  選擇帶有特定@id屬性的元素。如果@id沒有找到元素，則會改以選擇@name中符合 id 的值。指令需要元素定位器為參數時，大多都是以此作為預設值。
• name=name
  選擇帶有特定@name屬性的元素。
• dom=javascriptExpression
  以JavaScript的方式選擇DOM，開頭必定是「document.」。例如「dom=document.images[56]」。
• xpath=xpathExpression
  以XPath表示式來定位元素。
• link=textPattern
  選擇包含指定文字比對模式（text patterns）的連結（link）或錨點（anchor）元素，也就是<a>。
• css=cssSelectorSyntax
  以CSS選擇器來選擇元素，請參考CSS2選擇器、CSS3選擇器的說明。這應該是網頁工程師最容易使用的定位器吧。

  比對模式（Patterns）

  比對模式（Patterns）有許多用途，例如，檢查輸入欄位或是選項中是否有預期的字串出現。Selenium支援多種比對模式，包含正規表示式（regular expressions）。

小結

其實我本來是打算做個Selenium的簡介，然後主要是介紹以Selenium IDE建置測試案例的過程。不過光是簡介好像就足以成為一篇文章了，而Selenium令人值得一提的功能還多著呢。

接下來兩篇文章都是介紹以Selenium IDE建置測試案例的過程，希望能以Step by Step的方式，簡單易懂地說明如何建置。讓人光看就知道怎麼建置測試案例。

這兩篇文章是：

• 以Selenium IDE建立測試案例：圖片延緩載入
• 以Selenium IDE建立測試案例：無限捲頁

請多多指教。

政大博士班報考書面審查資料

上圖是2011年4月18日報考政大圖檔所博士班時使用的書面審查資料，一式五份。因為每次看到這些像是電話簿一樣厚的資料都覺得頗為有趣，所以在這邊稍微記錄一下這本的製作過程。

內容大綱

按照招生規定（SkyDrive備份），書面審查資料必須要有「自傳及履歷（含相關工作經驗）」、「研究計畫」、「學術著作清單及代表作」、「碩士論文或相當碩士論文之學術著作」、「大學（含）以上全部成績單」、「推薦書2份（格式不拘）」、「其他有利審查之資料」。

我按照自己的想法，將書面審查資料的內容組織如下：

1. 自傳：
   1. 履歷：簡單的自我介紹摘要表格，以及自己的照片。
   2. 自我介紹：敘述自己的經歷。
   3. 工作經驗與經歷：研究所、大學時期的經歷列表，由近到遠排序。
   4. 程式開發成果：因為我想展示自己做過的程式成果，所以在這邊介紹了三個做過的作品：論文系統、教育部全國通識網以及百年圖書館史。
2. 研究計畫：
   1. 學習計畫：簡單描述我想要在博士班學習的方向。儘管通常不會符合老師的期望，不過我還是想在此講一下自己的規劃。
   2. 研究計畫：數位圖書館之閱讀標註學習社群經營與加值應用研究。
3. 學術著作：
   1. 著作目錄：以專書、期刊論文、研討會論文、報告等分類陳列自己的著作書目。
   2. 代表作：DSpace開放源碼數位典藏系統建置理論與實務，是一本專書。這是二校中的版本，書面審查資料一半的厚度是來自於這份代表作。
4. 碩士論文：合作式閱讀標註之知識萃取機制研究。這本份量也大概佔了整本論文的三分之一。
5. 成績單：研究所與大學的成績單。
6. 獎狀證明：我附上了研究所與大學時期做過事蹟的相關證明，就像是研究所推甄時大家都會做的事情一樣。

至於推薦書，由於所上禁止由所上自己的老師撰寫，所以我是請大學時期的老師幫忙撰寫推薦書。

上述大部分內容都已經寫在布丁的自我簡介（2011年版）中，像是自我介紹、工作經驗與經歷、著作目錄等等。這一本大約八百多頁，有照片的地方大多是以彩頁呈現，因此印製成本一本大概是一千多元。然後依照規定，必須印製五本，這對於貧窮的學生來說真是一筆不小的開銷。

加工

即使我的美感是令人遺憾等級的差勁，我還是想辦法令枯燥乏味的書面審查資料加點東西進去。

先從書背開始設計

當初一邊做設計一邊跟朋友聊天，朋友覺得我這書背做這麼大幹嘛。不過事實上，其實書背還有很大的空間可以考量。

至於為什麼是先從書背開始設計……因為我就是想要做書背而已！

做完書背之後是做封面，設計參考狼與辛香料。嗯，唉，怎麼做都讓人難以滿意。

之後是設計目錄中每一章的圖示，背後用淡藍色梅花圖形是表示政大校徽。當時因為常用的ICON FINDER壞掉，我還大費周章去從其他網站找圖示來加工。

各章首頁

上述的六章中，每一章的開頭首頁，我都以色紙來印製。色紙跟一般影印紙相較之下比較硬，讓人翻頁時很容易就停在各章首頁中。

另一個效果，是讓人從側面就很容易知道各章首頁的位置。綠色色紙的各章首頁夾在白色的影印紙中，呈現出一條條綠色的標示線，相當明顯。

側標

當然，區隔各章的位置，還是用側標最方便了。像上圖一樣，我使用見出分類片黏在各章首頁、代表作、其他著作的側邊，並用顏色來分類。

此處用的並不是用書店常見的手寫側標，用的是塑膠材質的見出分類片。見出分類片可以像活頁夾一樣，自行印製小紙條夾入，免去自行手寫側標的困擾。一盒裡附有4種顏色，也方便利用顏色來分類。

CS-見出分類片(3CM)，一盒24片，紅、藍、白、綠各4片，定價35元。PChome購物有賣，我是在政大門口的今日書局買的。

側標的內容則是這樣子。

浮貼標籤

有許多資料是直接印成A4大小呈現，通常沒有額外加入標題、說明的空間。我一直在想，這樣人家翻到這一頁的時候，不是很難判斷現在文章的內容是什麼嗎？儘管文章裡面都有標題，但是因為排版不一，讀者可能會難以判斷。

所以我就印了浮貼的標籤，將一邊貼在頁面中的空白處，另一邊浮貼在上。當讀者看到浮貼標籤時，就可以從浮貼標籤上看到統一格式的標題，應該會比較清楚吧。

浮貼標籤的內容就像上圖一樣。但是設計依舊是讓人遺憾的等級……

貼上去的成績單

書面審查資料需要附上成績單，但是成績單大小不一，而且通常都會大於A4尺寸，無法直接單頁附在書面審查資料中。因此我將成績單沿線對摺，黏貼在A4紙的兩側，並貼上浮貼標籤作為標題。這樣子比較容易讓讀者翻閱，而不必讓成績單一張一張獨立分散。

結語

這本書面審查資料，除了內容撰寫之外，也用了不少手工作業來製作。感謝實驗室學弟妹與助理的協助，讓我得以在最後一刻完成並繳交。

說是這樣說，但其實我也只有備取而已。也就是說，光是用上面的方式來製作書面審查資料，仍然是有待加強。這篇記錄的製作過程僅作為參考（至於令人遺憾的設計請不要參考吧），希望未來的人可以做出更令人眼睛為之一亮的書面審查資料吧。

數位圖書館之閱讀標註學習社群經營與加值應用研究

自從上一份研究計畫之後，我重寫了這一份研究計畫。這次主題格局都變大了，參考老師與實驗室撰寫的多年期計畫架構，融合學弟妹的論文主題，將研究計畫擴大、分成多篇主題來完成。

摘要

近年由於國際閱讀素養研究的評比結果，臺灣的閱讀教育逐漸受到重視。數位圖書館提供了大量的閱讀資源，適合培育網路閱讀學習社群。本研究欲在數位圖書館的網路環境中，以合作式閱讀標註學習模式與網路學習社群經營理論，設計閱讀標註推薦機制、閱讀達人激勵機制，營造一個以閱讀學習為目的的閱讀標註學習社群。在閱讀標註學習社群在閱讀標註過程中會留下標註資料，本研究將之作為社群的集體智慧，結合Library 2.0與社群導覽支援的概念，在數位圖書館中發展以閱讀社群為中心的閱讀社群導覽系統，提供更佳的閱讀學習服務，促進閱讀標註學習社群蓬勃永續發展。

檔案下載

研究計畫文件

• docx文件（SkyDrive）
• PDF文件（SkyDrive）

心智圖草稿

• XMind心智圖草稿

結語：博士到底要做什麼？

儘管研究計畫改寫是改寫了，但在寫的時候我一直有個疑惑：「這真的做得到嗎？」由於我的碩士畢業論文只是一個很小的研究，對於這種多年期規劃的研究計畫，我並沒有什麼踏實感。不過，如果我當時就能將研究計畫寫得非常漂亮，那其實也不太需要來學習了吧。

說到頭來，究竟博士論文是要做到什麼程度呢？我常常會問老師這個問題，老師都會說：「博士畢業論文要具備點、線、面，將多篇研究串聯誠一個完整的構面。」可惜我資質駑頓、難以理解老師的形容。我只知道研究是做不完的，感覺怎麼做都只是在點與點之間打轉，要串成一條線還有可能，但做到全面……我就沒個概念了。

具體來說，大部分學校對於博士論文的要求是「一本書」，我也看過很多學術書籍是以類似論文集的方式呈現，莫非就是要做到這種程度嗎？

這個問題還沒個解，留待未來有機會再來思考吧！總之，博士班書面資料差不多就是如此了。

合作式閱讀標註之知識萃取機制改良與驗證研究

這是一份研究計畫，是在報名師大圖資所博士班時書面審查所需要的研究計畫。因為報考師大的準備時間很短，我寫得很匆促，也沒有請其他人幫忙檢查，所以寫出來其實不甚滿意。在口試的時候，口委老師也覺得這份研究計畫寫得很差，實在令人汗顏。

不過總之洋洋灑灑還是一篇二十幾頁的研究計畫，就放在這邊做個記錄吧。

摘要

本研究係繼承先導研究之「合作式閱讀標註之知識萃取機制研究」開發出來的知識萃取機制，改良先導研究中發現的問題，重新將知識萃取機制應用於提昇閱讀理解成效之驗證中。同時深入探討不同控制源（Locus of Control）的學生之間，在合作式閱讀標註學習環境中以知識萃取機制來激勵的閱讀效果是否有所差異，以了解知識萃取機制各方面的適用性。

……對不起，連我自己看了都覺得寫得很糟orz

檔案下載

研究計劃文件

• Google Doc文件
• docx文件（SkyDrive）
• pdf文件（SkyDrive）

心智圖草稿

• 201103 研究計畫 合作式閱讀標註之知識萃取機制改良與驗證研究.xmind

很趕的草稿、很趕的研究計畫orz

結語

這份研究計畫寫完這份之後，我感覺自己這樣子實在是不行。拿這份研究計畫出去給人看，簡直是一種羞恥。於是之後我又花了很多時間重寫了另一份研究計畫。

「其他學校不是用同一份資料去報考就可以了嗎？」雖然很多朋友都對我提出這個疑問，而我也老實跟他們說，我覺得這一份急就章的書面審查資料並不太好，我想要花時間重寫。儘管礙於時間限制，當時也只能做到這種程度，不過既然後面學校的報名截止之間還有點時間，那麼我一定會繼續改善到最後一刻。（事實上，最後一所政大報名的時間點也真的是在最後一刻）雖然考試結果都已經出來了，但我還是想跟繳交這樣一份研究計畫去的師大說聲抱歉。能力不足，讓老師見笑了。

Blogger 圖片延緩載入功能 (image lazy load)

繼前一篇無限捲頁功能，這一篇實作了Blogger說要做但是尚未實裝的圖片延緩載入功能。我先簡單地介紹一下圖片延緩載入的原理，然後再講述要如何安裝。

圖片延緩載入

當網頁開啟之後，瀏覽器會嘗試讀取網頁中的所有圖片。如果電腦效能不足、網頁圖片數量過多，剛開啟網頁的時候，瀏覽器就會像是當機一樣無法動彈，甚至連拉個捲軸看看其他地方都不行。

為了解決網頁圖片數量過多的問題，之前我提到的CSS Sprites是一個解決方案，它嘗試將許多零星的圖片合併成一張，以節省讀取圖片需要的額外載入時間（overhead）。

另一個更直接的作法，就是這篇要談的圖片延緩載入功能。當網頁內容相當多的時候，使用者並不會一口氣就閱讀所有的內容，而只會瀏覽到「視窗所看到」的範圍。那麼在這個範圍之外的圖片，就可以暫時先不載入，而可以用像是上圖一樣的灰色背景來替代。那個灰色並不是圖片本身，只是一個佔位圖片（placeholder）而已。

圖片延緩載入功能會分析網頁指定範圍中的所有圖片，先將使用者瀏覽範圍之外圖片全部替換成佔位圖片，停止網頁進行實際上的載入動作。

當網頁瀏覽到該圖片位置的附近時，圖片延緩載入功能會偵測到這個事件發生，並將佔位圖片替換成真正的圖片，這時才即時進行載入。也許使用者在瀏覽時會覺得怎麼突然會卡一下，不過那個瞬間也是相當地短。如果每一張要讀取的圖片也不大的話，圖片延緩載入功能並不太會影響使用者瀏覽的節奏。

題外話：圖片預先載入功能

提到圖片延緩載入功能，就會讓人想起另一種相反的作法：圖片預先載入功能。

圖片預先載入是先在使用者看不到的地方載入圖片，讓圖片存入瀏覽器的快取。當使用者真的要瀏覽該圖片的時候，從快取中載入的圖片會讓瀏覽更為流暢。

實作時，通常是在讀取這網頁的前一個網頁中實作。例如有些網站會在真正的首頁前放一個Flash影片播放的網頁，那麼當使用者欣賞影片的時候，JavaScript或其他程式就在背後偷偷地載入真正首頁中的圖片。那麼當使用者看完影片、進入真正的首頁時，首頁中的圖片就能夠快速地顯示出來。

圖片預先載入功能的重點在於「猜得到使用者接下來要看的圖片」。在導覽功能四通八達的現代網站，我們難以預料使用者的下一頁究竟會看是什麼資料、到底要預先載入什麼圖片。而早期網站設計都喜歡的假首頁（就像上面說的，用來擺放影片之類的首頁），現在也逐漸為人捨棄不用。就算是一踏入假首頁，使用者也多會略過而直接進入真正的首頁，而沒有機會用到圖片預先載入的功能。

另一個使用圖片預先載入功能的時機是「停留替換圖片」（hover）。當滑鼠移到某張圖片或某個位置時，將該位置顯示的圖片替換成其他圖片。許多網頁都會使用這一技巧，它也很容易讓人猜到使用者接下來要讀取的下一張圖片是什麼，因此特別適合用於圖片預先載入。圖片延緩載入Image Lazy Load Plugin for jQuery的作者Mika Tuupola也有針對圖片預先載入功能提出一個方法，詳情請看Preload Images Sequentially With jQuery這篇文章。

安裝圖片延緩載入

安裝小工具

跟大多數Blogger額外設定的功能一樣，圖片延緩載入功能也是從新增HTML/JavaScript小工具開始。

進入Blogger的管理介面，進入「設計」的「網頁元素」，在頁尾的地方新增小工具。

選擇其中的HTML/JavaScript。

標題留空，內容填入以下圖片延緩載入程式碼：

<script src='http://www.google.com/jsapi' type='text/javascript'></script>
<script type='text/javascript'>google.load("jquery","1.2.6");</script>
<script src='http://sites.google.com/site/puddingchen35/2011-06-blogger-image-lazy-load/jquery.lazyload.mini.js' type='text/javascript'></script>
<script type="text/javascript">
$("#main .blog-posts .post-body img").lazyload({
    effect : "fadeIn",
    placeholder: "https://sites.google.com/site/puddingchen35/2011-06-blogger-image-lazy-load/grey.gif"
});
</script>

儲存設定，這樣就完成了。

設定圖片延遲載入

在圖片延遲載入的程式碼中，有兩個地方可以設定，位於以下範圍中：

$("#main .blog-posts .post-body img").lazyload({
    effect : "fadeIn",
    placeholder: "https://sites.google.com/site/puddingchen35/2011-06-blogger-image-lazy-load/grey.gif"
});

1. effect：顯示真正圖片時的特效。預設值是「show」，表示直接替換；「faceIn」是淡入效果。
2. placeholder：佔位圖片。不使用佔位圖片的話，圖片甚至連保留位置都沒有，而讀取時就會像是突然插入一張圖片、即時改變頁面的排版，我覺得不是很好看。在此採用原作者建議的灰色底圖作為佔位圖片，你也可以自行改為其他佔位圖片。

其他還有很多設定，詳情請看Lazy Load Plugin for jQuery的說明。

製作參考

我在建構此功能時，一開始是先從別人的Word Press網站上看到的jQuery Image Lazy Load外掛。而這個外掛其實又是源自於jQuery的Lazy Load插件。製作者Mika Tuupola將圖片延緩載入功能寫得相當完整，因此我也沒有多做修改，以下只是額外撰寫了供Blogger使用的語法而已。

結語

圖片延緩載入功能安裝之後，基本上就可以放著正常運作。可是我用一用赫然發現，偶爾還是會出現像上圖一樣的讀取失敗畫面。我在想這比較可能是Chrome功能的問題，而不是圖片延緩載入功能的問題吧。

其實圖片延緩載入比前一篇的無限捲頁還要早做，而且比無限捲頁還簡單很多，但因為怕無限捲頁做到最後自己都忘了，所以這一篇才延緩到現在才寫吧。

Blogger 無限捲頁功能 (infinite scroll)

Google的Blog平台「Blogger」一直都有持續改進的消息，最近電腦玩物介紹了其中功能，其中一項是眾所期待的「無限捲頁」（或稱為無限捲動、自動換頁）。不過此功能目前尚未正式安裝，我看了好多Blogger也都沒有出現。所以我想就自己手動寫一個，並在此分享給有興趣的人來安裝。

無限捲頁功能介紹

傳統網頁中，使用者讀到網頁最下方時，必須要自己按換頁連結。在Blogger中就是「較舊的文章」。對使用者來說，每次都要按連結以重新讀取文章，還要載入文章之外的資料，往往會打擾使用者的閱讀節奏。

如果有無限捲頁的話，當使用者讀到網頁最下方時，程式會自動載入下一頁的網頁中顯示文章的內容，並貼到現在閱讀文章的最後面，讓使用者感覺就像是文章延長了一樣。

Google圖片搜尋也有應用到無限捲頁，這種使用經驗讓許多人稱讚不已。

使用者也可以自行安裝Auto Pager套件來擁有無限捲頁的功能。Firefox跟Chrome都可以使用，詳情請看電腦玩物的介紹。不過Auto Pager的功能不一定能配合的上Blogger，也不是每個使用者都有裝Auto Pager。那麼自己動手改造，讓Blogger具備無限捲頁功能，這樣也是不錯的作法。

由於Blogger並沒有提供大量換頁的功能，使用者只能一直按「較舊的文章」，因此也是相當適合使用無限捲頁功能。

Blogger官方將無限捲頁稱為「Auto Pagination」（自動換頁）。為了避免混淆，這邊我是用「Infinite Scroll」（無限捲頁）來稱之。一方面也是因為我是用jQuery的Infinite Scroll插件來建構此功能的緣故。不知道何時Blogger才會正式安裝此功能，在這之前，你也可以像我一樣裝個無限捲頁來玩玩。

Blogger文章數量與設定不合的問題

Blogger可以在後臺中設定主頁最多顯示的文章數量，注意，是「最多」，而不是「固定」顯示。

因為Blogger有單頁最多顯示1MB的限制，如果當文章的內容過多的時候，首頁可能會因為這個限制而顯示不出設定中的文章數量。「布丁布丁吃什麼？」的首頁時常只會顯示一篇文章，可能就是這個原因。

不少Blogger的使用者都有提出這個問題，官方的解決方案之一是使用「繼續閱讀」功能，降低每一篇文章的顯示字數，就可以在單頁中顯示較多文章量。不過我自己用布丁式自動摘要功能，懶得每次都要插入「繼續閱讀」，所以這方案並不適合我。

另一個方案是官方推薦自己的「Auto Pagination」（自動換頁）功能，讓人閱讀到最後時自動載入下一頁的內容，就不會有單頁顯示文章數量過少的問題。不過至今「Auto Pagination」還是沒有實裝，所以我乾脆自己寫一個吧！

安裝無限捲頁

進入Blogger的管理介面，進入「設計」的「網頁元素」，在頁尾的地方新增小工具。

選擇其中的HTML/JavaScript。

標題留空，內容貼上以下無限捲頁的程式碼：

<script src='http://www.google.com/jsapi' type='text/javascript'></script>
<script type='text/javascript'>google.load("jquery","1.2.6");</script>
<script src='https://sites.google.com/site/puddingchen35/blogger-infinite-scroll/jquery.blogger.infinitescroll.js' type='text/javascript'></script>
<script src='https://sites.google.com/site/puddingchen35/blogger-infinite-scroll/blogger-infinite-scroll-setup.js' type='text/javascript'></script>
<script type="text/javascript">
setup_blogger_infinite_scroll({
    loadingImg: "https://sites.google.com/site/puddingchen35/blogger-infinite-scroll/infinite-scroll-loading.gif",
    loadingText: "<em>下一頁讀取中……</em>"
});
</script>

儲存設定，這樣就完成了。

設定無限捲頁

在無限捲頁的程式碼中，可以設定兩個地方，位於以下範圍中：

<script type="text/javascript">
setup_blogger_infinite_scroll({
    loadingImg: "https://sites.google.com/site/puddingchen35/blogger-infinite-scroll/infinite-scroll-loading.gif",
    loadingText: "<em>下一頁讀取中……</em>"
});
</script>

1. loadingImg：讀取時顯示的圖片。預設是用Infinite Scroll提供的讀取動畫，我傳到了自己的空間去：
   
2. loadingText：讀取時顯示的文字。預設是「<em>下一頁讀取中……</em>」，可以使用HTML語法。

這個功能是改自jQuery的Infinite Scroll插件，雖然名字跟大部分功能都是一樣的，但是為了適應Blogger的版型，我修改了它原本自動判斷換頁連結的演算法，改成每一次都是去找尋「較舊的文章」的連結來讀取。修改後的Infinite Scroll插件檔案可以由此下載。

比較Endless Scroll跟Infinite Scroll

題外話，其實我在論文系統當中也用了無限捲頁的技巧。上圖中下面的標註列表就是用無限捲頁來實作，一開始JavaScript只會讀取少量標註，但隨著使用者往下捲動，JavaScript會讀取更多標註，直到沒有其他標註為止。

當時用的是jQuery的Endless Scroll插件，它比較適用於建構新功能時使用。Infinite Scroll則比較偏向修改既有功能，主要是以找尋下一頁連結而插入新文章的方式來實作無限捲頁。

結語

儘管一開始看到電腦玩物的介紹時，我還蠻期待Blogger趕快推出無限捲頁的功能，但事後想想，「布丁布丁吃什麼？」版面被我改了這麼多，Blogger要加入功能，恐怕也沒這麼容易。既然如此，那就自己改吧。一直以來我都是這樣走過來的。

做到一半的時候，我也有想過要不要將它設計成「小工具」（Gadget for Blogger）。研究了半天，才發現原來第三方的小工具是用iframe來實作，這樣就不能像無限捲頁一樣跟Blog內容有所互動，只能放棄這個途徑，乖乖插入HTML/JavaScript小工具吧。

不過經過這一課，又學到一些東西，感覺還是挺令人開心的就是。

合作式閱讀標註之知識萃取機制研究 A Study on Developing Knowledge Extraction Mechanisms from Cooperative Reading Annotation

這是我在國立政治大學圖書資訊與檔案學研究所撰寫的碩士畢業論文，指導教授為陳志銘博士。撰寫完成時間為99學年度下學期，實際上是民國2011年（民國100年）3月。

作為一份記錄，這一篇將會簡單地回顧一下整個論文的撰寫過程、論文的摘要，以及附上論文的相關檔案。

論文撰寫過程回顧

計劃書

圖資系所在碩士生撰寫畢業論文之前，通常都需要先撰寫論文的計劃書，陳述為何要做這個題目、要怎麼做這個題目、需要什麼步驟，並請口試委員幫學生審核是否可行，然後才開始進行碩士的畢業論文。

跟其他在政大圖檔所的學生差不多，我也是在碩二上的時候進行計劃書口試，日期是2008年12月，之前有寫一篇計劃書口試通過的記事，裡面包含了計劃書口試時使用的簡報。通過之後再依照口試委員的建議進行修改，這一篇則是在講修改後的計劃書檔案。

我的論文計劃書拿去參加國立臺中圖書館（簡稱國中圖）博碩士論文獎助並有幸獲獎，約定要於畢業時呈繳論文，才算是完成獎助契約。

論文聚焦與系統開發

之後有非常長的一段時間，我都在處理DSpace跟其他的外務，是個不務正業、玩物(?)喪志的學生。大概到2010年4月又回到論文的工作上，不定其地在此blog撰寫meeting時的論文進度報告，督促自己要積極撰寫論文、儘快畢業。論文相關的文章請看碩士畢業論文的分類標籤。經過一些文獻探討之後，毅然決然調整了論文進行的方向。

在聚焦研究問題的同時，我也開始學習以專案管理與UML的方式規劃論文系統的專案，並且閱讀極致軟體製程（eXtreme Programming explanined）、測試導向開發、PHP專業程式設計、物件導向設計模式等程式設計的書籍，努力提昇自己的程設能力。系統規劃大概是從2010年5月左右開始進行，實際上大約是2010年6月才開始撰寫系統。不過就算是到現在，我也不覺得系統算得上是完成品。關於系統的內容與功能請看KALS!標註工具說明一篇。

實驗進行與數據分析

2010年下學期學期中，由於論文系統撰寫時程大幅度地延長，導致論文的實驗並沒有按照預期希望的進行。老師建議我改以老師正在上課的同學來進行實驗，而我因此以目前系統的完成狀況、更改觀察的變項，大幅度地修改了整個實驗的設計。由於當時並不想告訴同學這是一個實驗，因此並沒有在此blog提到這些事情。變更的過程與細節請看論文進度報告(2011/1/19)：變更的研究架構一篇。實驗的設計與內容都鉅細靡遺地寫在論文之中，稍後請參考論文的內容。

實驗完成之後接著是數據的分析。這段期間學習了內外控量表、序列分析與循序樣式探勘等研究工具，不過論文最後並沒有派上用場，單純成為了學好玩的知識。當時在分析時到處找了相當多的方法，甚至自創演算法來加權數值。後來是在聆聽學弟妹的計劃書口試中找到靈感，並以統計的方式完成了現在的論文。

最後分析主要還是用統計的獨立樣本t檢定、單因子變異數分析、相關分析以及無母數分析等方法進行。在此推薦一下吳明隆的「SPSS操作與應用：變異數分析實務」（ISBN：9789571145754）一書，不僅可以讓人依樣畫葫蘆操作SPSS，理論說明也相當清楚。即使原本沒有學過單因子變異數與無母數分析的我，照這本書所講的內容，也只要一天就能夠輕易上手、完成論文分析。

分析完成的時間點大概是2011年1月過年之前，並與老師報告分析結果，讓老師確認沒有問題之後，才是撰寫論文內容。

論文撰寫與口試

有了分析結果之後，就能夠開始推論結論、撰寫論文。撰寫過程請看我的論文寫作工具：XMind心智圖一篇。之間與老師多次來回討論、修正，經過各章節二次以上的校對之後，終於完成了論文的初稿，可以準備舉辦碩士畢業論文的口試。

口試的邀約相當地匆促，大概是二月底的時候開始邀請老師。有的老師沒問題，有的老師時間橋不攏，有的老師工作事務繁忙而推辭，前前後後共問了六位老師。最後碩士論文口試邀請的口委為卜小蝶老師、林巧敏老師、侯惠澤老師，以及我的指導教授陳志銘老師，以上共四位口試委員。口試時間排定在2011年3月4日。

老師們給了我很多建議，因為現有的論文分析方式不太像是社會科學的角度，而是相當工程的分析，因此老師建議應該更往社會科學的方式來分析會比較好。此外，老師們讚賞系統開發，認為其本身就已經是一種研究貢獻。然而除了論文寫作細節挑些毛病之外，論文內複雜的實作與分析過程居然沒有人提出質疑，讓我個人挺訝異。口試時的簡報將於本文後面附上。

畢業論文送繳

口試之後即動手撰寫論文的修改版，再來進行論文的印製，之前我也有寫了篇印製過程的心得。

畢業前將論文呈繳到政大圖書館，圖書館會在轉送到國家圖書館，因此我的畢業論文現在也在臺灣博碩士論文知識加值系統中出現了。

在畢業事務處理期間，我也完成了與國中圖的契約、呈繳了十本畢業論文。之後回去國中圖找論文的時候，發現我的論文也已經編目上架了。

以上就是整個論文的大致撰寫過程。

論文摘要

• 題目：合作式閱讀標註之知識萃取機制研究
• 關鍵詞：合作式閱讀標註；知識標註學習系統；知識萃取機制；模糊綜合評判；閱讀學習。

本研究在合作式數位閱讀環境中發展了一套「知識標註學習系統」，可以支援多人同時針對一篇數位文本進行閱讀標註與互動討論，以提升讀者閱讀的深度與廣度。此外，本研究更進一步地以專家評估法設計「知識萃取機制」，用於判斷讀者閱讀標註的重要度。

「知識萃取機制」是基於讀者閱讀標註中所蘊含的閱讀理解策略與閱讀技巧，以及合作式閱讀社群中產生的標註共識，考量了「標註範圍長度」、「標註範圍詞性」、「標註範圍位置」、「標註策略類型」、「標註範圍共識」與「標註喜愛共識」等六項因素，以專家評估法制定的標註重要度模糊隸屬函數來評定各因素的重要度並量化為「標註因素分數」指標，最後將六項因素以模糊綜合評判進行推論，再將推論結果解模糊化而成為代表標註重要度的量化指標「標註分數」。基於「知識萃取機制」所計算代表標註重要度的「標註分數」，可作為讀者進行閱讀標註是否不佳的判斷，並據此提供標註技巧建議與優質標註內容推薦的「標註建議」，以幫助讀者提昇閱讀理解能力。

為了驗證「知識萃取機制」計算「標註分數」的有效性，以及探討未來改善「知識萃取機制」和可加入的考量因素與適性化設計的可能方向，本研究以單組後測設計規劃實驗，並以國立政治大學圖書資訊數位碩士在職專班19位學生作為實驗對象，進行一份數位學習論文的合作式閱讀標註學習，並於實驗後評估實驗對象閱讀文章之後的閱讀理解能力，作為評鑑「知識萃取機制」計算方式是否有效的指標。最後再以問卷蒐集實驗對象對於「知識萃取機制」的意見，歸納成為未來研究改善的參考依據。

研究結果發現，本研究所提出「知識萃取機制」中計算標註重要度的「標註分數」與實驗對象的閱讀理解能力呈現低度正相關，一定程度地證實了「知識萃取機制」計算方式的有效性。而「知識萃取機制」六項考量因素中，「標註範圍長度」與「標註喜愛共識」為分辨實驗對象閱讀理解能力的關鍵因素；「標註策略類型」與「標註範圍詞性」的標註重要度模糊隸屬函數有待修正；「標註範圍共識」與「標註範圍位置」為無效因素，但這可能是受到計算方式錯誤與閱讀文章類型的影響，未來仍有待進一步評估。在未來發展方面，系統操作標註行為頻率越高，實驗對象的閱讀理解能力也有較高的跡象，未來可以將其納入「知識萃取機制」作為考量因素之一；而閱讀理解能力較差的實驗對象，呈現出比較不願意回應「標註建議」與較常使用社群互動的現象。本研究歸納可能原因為實驗對象自身的閱讀素養不成熟，以至於無法判斷「標註建議」的正確性，而需要參考他人閱讀標註。

未來研究可針對本研究的實驗對象與閱讀標註資料進行更深入的分析，並且將改良後的「知識萃取機制」擴大至探討其他類型的數位文本閱讀標註與實驗對象。也可以搭配認知策略教學法建構閱讀教學鷹架，或是將「知識標註學習系統」用於支援數位典藏與數位圖書館閱讀學習，以激發更多不同領域的應用研究。

論文檔案

正文內容

裡面有很多工程技術與計算過程，因此相當地枯燥乏味。有需要的人再打開來看吧。

• 正文 docx (2,459KB)
• 正文 pdf (2.640KB)
• 書背 doc (32KB)：供學弟妹參考用的檔案

畢業口試投影片

• 投影片 ppt (2,230KB)
• 投影片 Google Doc
• 投影片主題樣板 thmx (120KB)
• 投影片列印 pdf (1,111KB)

結語：論文未完成

論文即使寫完了，卻仍有許多資料並沒有善加利用。例如上圖的標註範圍次數分配表中，可以看到標註範圍為4個字的次數佔了最多。不過這數據究竟能怎麼解釋，我還沒有什麼頭緒。總之，這份論文的資料還有很多利用價值，也許可以再分析出些什麼關連，也許也可以從不同角度進行不同的分析。

這個論文，總覺得只能說是「做到告了一段落」，還不能說是「完成了論文」的感覺。很多未探究的地方都還沒好好釐清，我就這樣子被趕著畢業了。

至於論文中的KALS系統，儘管我希望他以開放原始碼的形式公開（請看KALS的Wiki），不過至今仍尚未動手進行。日後我可能會先將原始碼公開，並在實驗室架設一個公開使用的系統，屆時會再告知大家。

最後我應該會放棄KALS開發。因為我想要用其他技術來撰寫，嘗試更效率更好、更容易開發、更具有可維護性的方式來開發系統。

這份論文並不是寫的很好，有任何看不懂、發現有問題、覺得不太可行的地方，歡迎大家提出來討論。也祝往後接手的學弟妹能夠順利畢業，大家加油。