:::

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

布丁布丁吃布丁

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

CameraZOOM-20110419150245

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


內容大綱

目錄

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

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

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

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

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


加工

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

先從書背開始設計

image

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

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

封面

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

目錄

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

各章首頁

CameraZOOM-20110628183021

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

CameraZOOM-20110630161455

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

側標

CameraZOOM-20110628183002

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

CameraZOOM-20110630164019

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

image

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

image

側標的內容則是這樣子。

浮貼標籤

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

 CameraZOOM-20110628183106

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

image

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

貼上去的成績單

CameraZOOM-20110628183204(馬賽克)

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


結語

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

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

(more...)

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

布丁布丁吃布丁

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

2011-06-28_125518 研究架構圖 

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


摘要

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

檔案下載

研究計畫文件
心智圖草稿


結語:博士到底要做什麼?

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

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

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

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

(more...)

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

布丁布丁吃布丁

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

2011-06-28_125623 研究架構圖

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

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


摘要

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

 

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

檔案下載

研究計劃文件
心智圖草稿

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


結語

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

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

(more...)

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

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

image image

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


圖片延緩載入

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

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

image

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

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

image

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

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

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

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

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

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

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


安裝圖片延緩載入

安裝小工具

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

2011-06-25_233326 設計 網頁元素

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

2011-06-25_233246 新增JavaScript

選擇其中的HTML/JavaScript。

image

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

<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使用的語法而已。


結語

image

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

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

(more...)

Blogger 無限捲頁功能 (infinite scroll)

Blogger 無限捲頁功能 (infinite scroll)

17510352447 首頁圖

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


無限捲頁功能介紹

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

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

image

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

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

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

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


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

2011-06-25_231655 文章數量設定

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

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

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

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


安裝無限捲頁

2011-06-25_233326 設計 網頁元素

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

2011-06-25_233246 新增JavaScript

選擇其中的HTML/JavaScript。

image

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

<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

annotation_tool_original

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

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


結語

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

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

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

(more...)

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

合作式閱讀標註之知識萃取機制研究 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日。

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

畢業論文送繳

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

2011-06-24_131518

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

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

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


論文摘要

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

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

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

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

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

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


論文檔案

正文內容

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

畢業口試投影片


結語:論文未完成

image

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

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

kals_interface_original

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

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

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

(more...)

Blogger範本應用CSS Sprites技術記事

Blogger範本應用CSS Sprites技術記事

padding_header_footer

blogger-icon-set subscribe-icon-set

最近我在學習CSS Sprites技巧,並嘗試將此技巧應用於「布丁布丁吃什麼?」blog中。以下記錄開始修改的機緣、簡單介紹CSS Scrites的原理,然後一一記錄我如何將CSS Scrites應用於Blogger的範本中的過程。


機緣

最近在修改Blogger範本之後,就想說應該拿個什麼測速工具之類的檢測一下Blog有什麼問題。赫然想起之前電腦玩物介紹了Google Page Speed Online,他可以提供網站速度評測指標的分析與指導,似乎頗值得拿來參考。

image

分析之後,Page Speed Online指出「布丁布丁吃什麼?」最優先需要修改的建議是「將圖片合併到CSS合併圖片」,也就是它建議我應用CSS sprites技巧來改善網頁的讀取速度。

image

我用Firebug檢查了一下圖片的請求狀況,發現光是布丁的自我簡介(2011年版)就有56個請求(如上圖)。趁著改良Blog的機會,我也想來練習做做看CSS Sprites,提昇自己的程設能力。


CSS Scrites原理

CSS Scrites是一種提高網頁讀取速度的技巧。其原理是降低圖片請求(request)數量,以節省請求時額外消耗的速度。

概要作法是將網頁中多張圖片結合起來,再透過CSS語法調整,讓每個位置都只顯示該部分的圖片。應用CSS Scrites之後,原本網頁需要讀取多張圖片時需要跟伺服器請求的數量,會因為合併成一張圖片,而大幅降低了請求數量,因此也節省了多次請求而消耗的速度。

其原理很容易懂,但是實作的時候卻不容易。這需要熟悉HTML跟CSS語法才能進行,而且也需要分辨哪些圖片可以應用CSS Scrites,或是哪些不行。

Page Speed Online有給我們一些建議,我嘗試翻譯如下:

  • 合併會一起讀取的圖片:建議合併時常在同一頁面中同時讀取的圖片。例如,每一頁都會用到的同一組圖示,就適合進行合併。相反的,每一次讀取都會改變的動態圖片,例如大頭貼照片、或是在頁面中會時常變更的圖片,就不建議進行合併。
  • 優先合併GIF跟PNG圖片:GIF跟PNG圖片使用無損壓縮法,因此合併時並不會因此降低合併圖片的品質。
  • 優先合併小型圖片:每一個圖片請求都會需要固定的額外請求時間(request overhead),即使是下載小型圖片,瀏覽器也會需要為此耗費額外的請求時間。藉由合併小型圖片,將可以從每一次請求一張圖片到一次請求就讀取整張合併的圖片,因此降低了額外請求的時間。
  • 合併可以快取的圖片:建議合併快取時間(caching lifetime)較長的圖片。如果圖片已經被瀏覽器快取,那瀏覽器就不需要再次下載該張圖片,以提高讀取的效率。
  • 使用CSS Sprite服務:合併圖片時,可以使用SpriteMe之類的服務,讓你輕易應用CSS sprites。
  • 最小化合併圖片中的空白處:為了顯示圖片,瀏覽器必須解壓縮並解碼該圖片。圖片的尺寸通常是跟圖片的解析度成正比。因此,當合併圖片中的空白處過多的時候,即使沒有明顯改變圖片的檔案大小,但是沒有顯示的像素依然會佔據記憶體的用量,造成瀏覽器回應速度變慢。
  • 合併使用同樣色彩的圖片:合併圖片如果超過256色,將會讓PNG從palette type改成使用truecolor type,並造成合併圖片檔案變大。為了產生最佳化的合併圖片,要合併的圖片最好都使用相同的256色。如果你的圖片還有調整的空間,建議考慮想辦法讓你的合併圖片色彩數量降低到256色。

SpriteMe的安裝與分析建議

image

既然Page Speed Online都建議我先從SpriteMe開始了,那就先用SpriteMe看看有什麼好的建議吧。

安裝SpriteMe書籤

SpriteMe是一個書籤小工具(Bookmarklet)請把下面的連結拖曳到書籤列上吧。

SpriteMe

使用SpriteMe

image

打開你要分析的網頁,這邊我一樣以布丁的自我簡介(2011年版)來做做看。SpriteMe將網頁中的圖片分成「Suggested Sprites」(建議合併)與「Non-Sprited Images」(不合併圖片)這兩種。以下是詳細的列表:

image

接著讓我們來看看SpriteMe為什麼建議合併與不建議合併的理由。

合併建議1:合併不重複的圖片

第一項是「vertical, varied width」(垂直的,多變的寬度),直接翻譯還真是看不懂是什麼意思,但仔細一看他列出的圖片,大多都是寬度、高度不等,而且在CSS中都是不重複(no-repeat)的圖片,簡單來說就是建議合併的大雜匯啦。

以下舉幾張例子:

  • image
    頁首標題前的箭頭
  • image
    擺在頁首的底部圖片
  • image 
    日期前的箭頭
合併建議2:X軸重複、寬度相等

這一個建議很特別,他分析出兩張寬度相等(760px)的背景圖,而且他們也都是設定為X軸重複(repeat-x),因此也適合合併成一張圖。

這兩張圖各別是:

  • image
    頁首的背景
  • image
    頁尾的背景

他們都Y軸的漸層效果。仔細一看,似乎這背景圖也不需要這麼寬,就能用X軸重複達到填滿的效果了。

不合併的建議

除了合併的建議之外,SpriteMe也給了不合併的建議。我把圖片的長寬尺寸與理由列舉如下:

  • bg_body.gif 5x600:因為X軸重複,而且太短
  • bg_sidebar_arrow.gif 80x98:Y軸重複而且太窄
  • icon_list_item_left.gif 9x7:因為包含他的區塊(block)比他高且比他寬。(意思是這種情況還是用背景圖來顯示比較好)
  • bg_sidebar.gif 5x464:因為看不到。(我動態地把導覽列隱藏起來的關係)

SpriteMe的使用過程

SpriteMe不僅僅是分析建議很詳細,就連使用起來也很容易。

建立合併

image

上面提到SpriteMe建議我合併X軸重複、寬度相等的圖片,而該區右上角有個「make sprite」按鈕,就能夠自動產生CSS Sprite的效果。

image

按下去之後稍待一會,圖片就合併成一張了。打開項目的詳細事項,裡面記載著SpriteMe調整過的元素內容。點選該元素,他會在元素外圍描繪上紅色的框線。

image

他同時也提供了一張合併後的圖片,如上圖。儘管我很好奇的是,不知道為什麼SpriteMe合併之後的圖片間會有這麼多空白間隔(padding)。可能是預留排版出錯時的緩衝空間吧?

image

SpriteMe直接將合併之後圖片的語法寫在受到調整的元素中。上圖是頁首背景圖片直接套用了SpriteMe的合併圖片,可以看到他以background-image跟background-position設定直接寫在元素的style屬性中了。

輸出CSS

image

雖然右上角有個「export CSS」功能,可以把合併後的圖片與語法輸出成CSS。只是在Chrome裡面發生了JavaScript錯誤而無法執行,後來我改用Firefox 4來操作,就能夠開啟SpriteMe Export CSS網頁。

image

Export CSS網頁中,先告訴我剛剛我合併的圖片網址。

然後下面列出了這個網頁使用的CSS檔案,並嘗試在這些檔案中找尋剛剛修改的元素設定位置。可惜因為Firefox的跨網域限制,SpriteMe沒辦法自動幫我分析這些CSS檔案的內容。

接著他列出CSS的建議修改方式,包括刪掉原本的圖片,並替換上新的圖片。這個建議可以讓我輕易地修改CSS檔案,非常地實用。其內容如下:

DIV id=header class=header section
{
  background-image: url("http://www.blogblog.com/thisaway/bg_header.gif")
  background-image: url("http://www.jaredhirsch.com/coolrunnings/public_images/a98ceddb07/spriteme2.png");
  background-position: 0px -18px;

}
DIV id=footer class=footer section
{
  background-image: url("http://www.blogblog.com/thisaway/bg_footer.gif")
  background-image: url("http://www.jaredhirsch.com/coolrunnings/public_images/a98ceddb07/spriteme2.png");
  background-position: 0px -118px;

}

當然,我會把SpriteMe產生的合併圖片下載之後,上傳到自己的空間,然後再把之間的網址改成我的空間,這樣才不會造成SpriteMe伺服器的負擔。

image

修改完成之後,圖片的請求數從原本的56個降低為55個囉。

分組寬度相當、顏色相近的圖片來建立合併圖片

image

如果直接採用SpriteMe的建議,把寬度、高度不等的圖片直接合併,就會出現像上面的合併圖片。在Page Speed Online建議合併圖片要盡量降低空白處,而上圖很明顯的違反了這個建議。多次嘗試之後,我發現SpriteMe只會將圖片垂直排列來合併。因此,如果只將寬度相當的圖片進行合併,就能夠將合併圖片的空白處降低到最小。

image

上圖是SpriteMe預設的建議,圖片的寬度從760px到10px都有,合併起來將會出現相當多的空白。還好,SpriteMe也提供了讓使用者自訂合併圖片的功能,請按下上面的「new sprite」按鈕。

image

這時候上面就會出現新的合併列表,但是是空的。

image

你可以從下面的圖片,將寬度差不多的圖片拖曳到這個區塊,SpriteMe就會依照你指定的圖片建立新的合併圖片。

image

我將合併圖片分成三組,個別是寬度為10px的圖片、寬度為760px的圖片,以及寬度為47px到54px之間的圖片來進行合併。

合併之後的結果如下:

  • image
  • image
  • image

這樣子空白處就減少很多囉。

另外Page Speed Online也建議將合併圖片的顏色數量降低到256色之內,這也是分組時的一個參考依據。

SpriteMe忽略了<img>圖片

仔細比較一下Page Speed Online給的建議,會發現SpriteMe還忽略了很多圖片。再細部分析一下,這些圖片都是以<img>圖片標籤顯示的內容。

image

上面的「訂閱所有留言」功能就用了大量的<img>標籤,而且都是固定常出現的小型圖片。Page Speed Online建議我合併這些圖片,但是SpriteMe並沒有分析到這邊。

為了要讓SpriteMe偵測到這些圖片,我必須先把<img>中src指定的圖片,改成以background-image背景圖片的方式來顯示。

原本我是想在<img>直接設定背景圖片,但是效果卻不如預期。Firefox中,只有將<img>顯示型態設為block的時候,才能順利顯示背景圖。因此,我決定將<img>改成<div>,並以CSS的background-image來顯示圖片。


<img>改成<div>背景圖

以下我以這個「訂閱所有留言」的功能來說明修改的過程。這是一個寫在小工具區的HTML程式碼,內容如下:

<div class="subscribe-wrapper subscribe-type-COMMENT">
    <div style="display: none;" id="SW_READER_LIST_Subscribe1COMMENT" class="subscribe expanded subscribe-type-COMMENT">
        <div class="top">
            <span onclick="return(_SW_toggleReaderList(event, &quot;Subscribe1COMMENT&quot;));" class="inner">
                <img src="http://img2.blogblog.com/img/widgets/arrow_dropdown.gif" class="subscribe-dropdown-arrow" />
                <img border="0" align="absmiddle" src="http://img1.blogblog.com/img/icon_feed12.png" class="feed-icon" alt="" />
                訂閱所有留言
            </span>
        <div class="feed-reader-links">
            <a target="_blank" href="http://www.google.com/ig/add?source=bstp&amp;feedurl=http%3A%2F%2Fpulipuli.blogspot.com%2Ffeeds%2Fcomments%2Fdefault" class="feed-reader-link">
                <img src="http://img1.blogblog.com/img/widgets/subscribe-google.png" />
            </a>
            <a target="_blank" href="http://www.bloglines.com/sub/http://pulipuli.blogspot.com/feeds/comments/default" class="feed-reader-link">
                <img src="http://img1.blogblog.com/img/widgets/subscribe-bloglines.png" />
            </a>
            <a target="_blank" href="http://www.netvibes.com/subscribe.php?url=http%3A%2F%2Fpulipuli.blogspot.com%2Ffeeds%2Fcomments%2Fdefault" class="feed-reader-link">
                <img src="http://img1.blogblog.com/img/widgets/subscribe-netvibes.png" />
            </a>
            <a target="_blank" href="http://www.newsgator.com/ngs/subscriber/subext.aspx?url=http%3A%2F%2Fpulipuli.blogspot.com%2Ffeeds%2Fcomments%2Fdefault" class="feed-reader-link">
                <img src="http://img1.blogblog.com/img/widgets/subscribe-newsgator.png" />
            </a>
            <a target="_blank" href="http://add.my.yahoo.com/content?url=http%3A%2F%2Fpulipuli.blogspot.com%2Ffeeds%2Fcomments%2Fdefault" class="feed-reader-link">
                <img src="http://img1.blogblog.com/img/widgets/subscribe-yahoo.png" />
            </a>
            <a target="_blank" href="http://pulipuli.blogspot.com/feeds/comments/default" class="feed-reader-link">
                <img align="absmiddle" src="http://img1.blogblog.com/img/icon_feed12.png" class="feed-icon" />
                Atom
            </a>
        </div>
    </div>
    <div class="bottom"></div>
</div>
<div onclick="return(_SW_toggleReaderList(event, &quot;Subscribe1COMMENT&quot;));" id="SW_READER_LIST_CLOSED_Subscribe1COMMENT" class="subscribe">
    <div class="top">
        <span class="inner">
            <img src="http://img2.blogblog.com/img/widgets/arrow_dropdown.gif" class="subscribe-dropdown-arrow" />
            <span onclick="return(_SW_toggleReaderList(event, &quot;Subscribe1COMMENT&quot;));">
                <img border="0" align="absmiddle" src="http://img1.blogblog.com/img/icon_feed12.png" class="feed-icon" alt="" />
                訂閱所有留言
            </span>
        </span>
    </div>
    <div class="bottom"></div>
    </div>
</div>

 

程式碼有點長,不過構造還算簡單。大致上需要改的有兩種類型,以下一一敘述作法。

修改顯示類型為block(區塊)圖片

image

有些<img>被賦予了display:block;的設定,表示他會跟<div>一樣以block(區塊)的樣式顯示。在「訂閱所有留言」中,下拉選單的各種圖示都是以這種形式呈現。

這種形式的<img>圖片可以很容易地修改成<div>背景圖,也不容易影響排版。

讓我們先看看image Add to Google這個圖示的原始碼:

   1: <a target="_blank" 
   2:     href="http://www.google.com/ig/add?source=bstp&amp;feedurl=http%3A%2F%2Fpulipuli.blogspot.com%2Ffeeds%2Fcomments%2Fdefault" 
   3:     class="feed-reader-link">
   4:     <img src="http://img1.blogblog.com/img/widgets/subscribe-google.png" />
   5: </a>

這是一個<a>連結標籤包含著<img>圖片標籤的元素。在其他的CSS當中,此處的<img>被設定為display:block;,因此我們可以考慮直接把這種<img>換成<div>,並加上額外的CSS設定。

修改的過程有幾個步驟:

  1. 在<img>後面建立<div>,並給予適當的class名稱,以便後續CSS設定中可以正確地選擇到該<div>。這邊要注意的是,必須完整撰寫<div></div>標籤,而不能用<div/>這種空標籤喔。
  2. 增加額外的CSS設定,包括:
    • background-image: url(圖片網址):指定<img>讀取的圖片
    • background-repeat: no-repeat:不重複圖片
    • width & height:根據圖片大小設定
  3. 移除原本的<img>

以下是修改之後的元素程式碼與CSS設定:

   1: <a target="_blank" href="http://www.google.com/ig/add?source=bstp&amp;feedurl=http%3A%2F%2Fpulipuli.blogspot.com%2Ffeeds%2Fcomments%2Fdefault" class="feed-reader-link">
   2:     <div class="subscribe-google"></div>
   3: </a>
   4: <style type="text/css">
   5: .feed-reader-link .subscribe-google {
   6:     background-image: url(http://img1.blogblog.com/img/widgets/subscribe-google.png);
   7:     background-repeat: no-repeat;
   8:     width: 104px;
   9:     height: 17px;
  10: }
  11: </style>

儘管大致上改到如此就可以告一段落,但是這段HTML還有繼續改善的空間。

由於<a>標籤中只包含<img>(後來被我換成<div>了)一個元素,因此我們可以考慮將樣式直接套用到<a>中,省略掉多餘的<div>。

更進一步修改之後的程式碼如下。必須注意的是,CSS中選擇器改成指定<a>的class名稱,並加入顯示類型display: block的設定囉:

   1: <a target="_blank" href="http://www.google.com/ig/add?source=bstp&amp;feedurl=http%3A%2F%2Fpulipuli.blogspot.com%2Ffeeds%2Fcomments%2Fdefault" class="feed-reader-link subscribe-google">
   2: </a>
   3: <style type="text/css">
   4: .feed-reader-link.subscribe-google {
   5:     background-image: url(http://img1.blogblog.com/img/widgets/subscribe-google.png);
   6:     background-repeat: no-repeat;
   7:     width: 104px;
   8:     height: 17px;    display: block;
   9: }
  10: </style>

修改之後的程式碼又更簡潔了。實際應用的時候,CSS設定會集中在其他檔案中,而不會像上面一樣跟HTML寫在一起。

修改顯示類型為inline(同軸)的圖片

image

<img>圖片的預設顯示類型是inline,意思是會跟文字一樣一起排列。而<div>卻是block顯示類型,會強制將後面的內容換行。

有些時候,<img>會以原始的inline跟其他文字一起排列,這種情況要改成<div>就比較困難,通常還要搭配float浮動樣式、margin外距調整、以及搭配一些CSS修改經驗才能達成。

這次我要修改的是「訂閱所有留言」左邊的RSS圖片,這張圖片與「訂閱所有留言」文字一起排列,是以預設的inline顯示類型呈現。它的原始碼如下:

   1: <span 
   2:  onclick="return(_SW_toggleReaderList(event, &quot;Subscribe1COMMENT&quot;));">
   3:     <img border="0" 
   4:      align="absmiddle" 
   5:      src="http://img1.blogblog.com/img/icon_feed12.png" 
   6:      class="feed-icon" alt="" />
   7:     訂閱所有留言
   8: </span>

我為它進行的修改步驟為:

  1. 在<img>後面建立<div>,並給予適當的class名稱,以便後續CSS設定中可以正確地選擇到該<div>。
  2. 增加額外的CSS設定,包括:
    1. background-image: url(圖片網址):指定<img>讀取的圖片
    2. background-repeat: no-repeat:不重複圖片
    3. width & height:根據圖片大小設定
    4. float: left:因為該圖片位於文字的左方,所以用此設定
    5. margin 調整外距
  3. 移除原本的<img>

修改後的程式碼與新增的CSS設定如下:

   1: <span 
   2:  onclick="return(_SW_toggleReaderList(event, &quot;Subscribe1COMMENT&quot;));">
   3:     <div class="feed-icon"></div>
   4:     訂閱所有留言
   5: </span>
   6: <style type="text/css">
   7: .inner .feed-icon {
   8:     background-image: url(http://img1.blogblog.com/img/icon_feed12.png);
   9:     background-repeat: no-repeat;
  10:     width: 12px;
  11:     height: 12px;
  12:     float: left;
  13:     margin-top: 2px;
  14:     margin-left: 7px;
  15: }
  16: </style>

image

修改之後,因為加上了margin外距調整,感覺比之前的<img>更順眼了點呢。

顯示圖片讓SpriteMe能夠偵測

即使把<img>改成<div>的背景圖片了,還要記得把他們顯示出來(visible),SpriteMe才能夠偵測並判斷它是否適合成為合併的圖片,否則會被歸類成不適合合併的圖片。

image

在分析之前,我先將「訂閱所有留言」的選單打開,再使用SpriteMe的功能,如上圖。

image

這下子SpriteMe總算偵測到剛剛我修改的<div>背景圖,而且將它列入建議合併的圖片中了。

其他CSS Sprites技巧

SpriteMe是分析背景圖片(background-image)以達到CSS Sprites技巧的效果,不過除了背景圖片之外,還有其他技巧可以使用。

CSS擁有無限的可能性,而且隨著瀏覽器跟標準不斷地改變,未來也可能會有更好用的技巧出現也說不定吧。


真的有必要做CSS Sprites嗎?

儘管CSS Sprites能夠降低圖片請求數量、提昇網頁讀取的速度,但任何技術都不是萬靈丹,在使用CSS Sprites的時候我也發現到一些限制,在此提出來跟大家討論一下:

合併後的圖片難以管理

現在我們將多張圖片合併成一張大型圖片,用CSS Sprites設定背景圖片與背景位置。如果未來需要變更其中一張圖片的高度,這不僅要把之前所有的圖片都找回來,還需要修正下面的圖片的背景位置。

為了避免這種情況發生,在使用CSS Sprites技巧時,盡量挑選不會變更的圖片,或是將可能會一起變更的圖片一起合併,要改的時候也一起改。

最後,要記得保留合併前的舊圖片,以免未來要重新合併時找不到圖片。我在CSS樣式檔中,就會將舊圖片的連結先註解掉,讓未來還有回復成原本圖片的機會:

   1: #header {
   2:   background-color: #634320;
   3:   /*background-image: url(http://www.blogblog.com/thisaway/bg_header.gif);*/
   4:   background-image: url(http://dl.dropbox.com/u/717137/blogger/img/bg_header_footer.png);
   5:   background-position: 0px -18px;
   6:   background-repeat: repeat-x;
   7: }
將<img>轉換成<div>的人工成本與風險相當高

SpriteMe不會分析<img>中的圖片,而需要我們手動將<img>轉換成<div>背景圖,才能順利讓SpriteMe分析。前面我也簡單地敘述了兩種轉換的過程,不過實際使用時一定會遇到許多更棘手的情況。

最大的問題仍是在<img>以inline顯示類型與<div>的block顯示類型基本上就有很大的差別。由於<div>一定要設定為block才能設定寬度與高度,所以不能單純轉換為inline顯示類型。

當然,還有許多CSS設計技巧可以迴避掉類似的問題,但不論是哪種方法,都需要相當有經驗的CSS設計師才能做到。隨隨便便套用CSS設定,都會帶來版面構造破壞的風險。

區塊有重複延展的需求時,盡量不要做CSS Sprites

前面SpriteMe的建議都是針對不重複、或是針對X軸重複的圖片建議合併,但是有時候SpriteMe的建議也不是萬能,它並不能預測到你這個區塊未來是否有需要延展的空間。

有一種CSS設計,是在指定不重複(background-repeat: no-repeat)的背景圖片(background-image),同時搭配背景顏色(background-color)的情況。這種設計並不是讓背景圖片重複來填滿背景,而是用背景顏色來填滿,但只有特定的地方顯示背景圖片而已。

image

「布丁布丁吃什麼?」的範本中時常出現這種設計,例如上圖的頁首區塊。它的CSS設定如下:

   1: #header {
   2:   background-color: #634320;
   3:   background-image: url(http://www.blogblog.com/thisaway/bg_header.gif);
   4:   background-repeat: repeat-x;
   5: }

image

如果當頁首資料量太多的時候(我繞了好多遠路),背景還能順利地延展開來,不會讓版面變得很奇怪。

image

但是如果照前述的方式將頁首區塊的背景合併成CSS Sprites,當資料量一多的時候,就會發現頁首喪失了延展性,背景變得很奇怪了。

即使不是資料量變多,而只是單純地縮小視窗寬度,資料自動往下擠壓而造成額外的高度需求,那也可能發生類似的破版畫面。

儘管有很多技巧可以避免上述的問題,不過這邊我想說的是,當區塊有擴增、延展的需求時,不要輕易地將它的背景圖片做成CSS Sprites,以免徒增版面發生錯誤的風險。


成果與結語

image

經過CSS Sprites調整之後,布丁的自我簡介(2011年版)從56個圖片請求數降低到了47個請求數。老實說,感覺成效並不明顯。

image

另一方面主要的原因在於大多數圖片並不是我能掌控的範圍,像是Google Friend Connect的大頭像、Plurk的顯示圖片。結果Page Speed Online還是建議我去合併這些圖片,我也沒輒了。

附帶一提,我並沒有特別去注意下載速度與圖片壓縮的數量,因為實際上都是小圖片的整併,比較這一點點差距沒有多大意義。

總之,經過這次的把玩,總算對CSS Sprites這個技巧有更深入的了解。以後在設計網頁的時候,不妨預先考量到可以進行CSS Sprites的轉換空間,將<img>以<div>替代,然後最後再利用SpriteMe來動手術,努力提昇提昇網頁讀取效率吧。

(more...)