分類: 網站設計
Google Code Prettify
發表於 2007-03-23 12:28:09
在 Idea Grapes 看到介紹的這個可以將網頁上程序碼顯示美化的小程式，非常喜歡，拿來更新了 TAKOR 裡面的頁面，順便幫忙推薦一下。
範例：
--- upated 2007/1017 ---
前一個版本有時候會造成頁面載入不順的 bug，更新版本後已經沒有這樣的問題。
範例：
function login()
{
if (frmLogin.uid.value == "") return false;
frmSubmit.setFormAction("action_login.php");
frmSubmit.enableCallBack();
frmSubmit.addInput("uid", frmLogin.uid.value);
frmSubmit.addInput("pwd", frmLogin.pwd.value);
frmSubmit.submitForm();
frmLogin.reset();
}
--- upated 2007/1017 ---
前一個版本有時候會造成頁面載入不順的 bug，更新版本後已經沒有這樣的問題。
適切的網頁文字大小
發表於 2007-02-05 14:09:36
（本來想要寫篇有用的文章，計算出目前通行的各種螢幕尺寸、解析度和實際觀看文字的大小之間關係，但因為懶得找資料，暫且作罷。為了怕這個想法再次流失，先post這篇上來引發話題）
之前看過一個 無障礙網路空間 的東西，開始注意到自己網站的 Layout 對於視力不佳的朋友來說，是否會看來太過吃力等等這類的問題，於是從 2004 年左右開始，我的網站文字大小就儘量遵照不用小字體或多彩文字夾雜等原則。
以羅馬字母為基礎的外文網站，因為每個詞的長度、拼字重點、前後文的群聚慣例等都足以提供讀者迅讀略讀的「視覺印象」，因此在設計網站外觀時往往可以將文字尺寸縮小，提供塊狀的文字區，搭配底色、圖示後呈現出近似印刷品非常漂亮的配置。
漢字是方塊字，且每個字都可以獨立存在，與前後字詞依附的必要性不若羅馬拼字來得強，因此在設計網站外觀時很難拿捏文字尺寸大小。設定得太大了些，系統預帶的細明體看起來「細弱無力」，設定得小些，辨識筆畫繁複的文字時又令人非常吃力。有些人會改用楷書字體，但在非 Windows 作業系統或大陸簡體字作業系統中又無法顯示，且這樣設定並不符合 W3C 的 font-family 標準字體規則。
在 Blog 盛行後，許多人開始大玩特玩 CSS 樣式表，為了呈現出類外文網站的視覺經驗，往往將漢字的尺寸設置為 12~14px (Pixel)，甚至有小到 8~10px的，那真是小到要用放大鏡才看得清楚。px 的單位就是實際的像素，以主流通行的 XGA (1024x768)、SXGA (1280x1024)，或是最近盛行的 WXGA (1280x768/800) ，不管螢幕解析度高低，總之 12px 就是高寬均為 12 個螢幕像素的大小。這個顯示大小在不同對角線尺寸的螢幕上，卻會呈現不同的實際大小。例如同樣 12px 的字在 17" XGA 上用尺來量的實際顯示寬度，與在 19" XGA 螢幕上的實際顯示寬度就小了一點。現在的螢幕越做越大，理論上來說實際顯示尺寸應該也會愈來愈大，但因為解析度也同時提高了，造成文字的實際尺量大小反倒日形微縮。
有些人說，應該改用 pt 單位 (points) 取代 px，這樣當螢幕解析度改變時，瀏覽器會調整實際顯示尺寸以符合設計時條件。但這卻無解於螢幕對角線尺寸差異的問題。我有段時期，為了兼容顯示美觀與提供觀看便利，會利用顯示比例 (%) 來設定文字大小，一般顯示文字就用 100% 以顯示瀏覽器預設或自訂的字體尺寸，標題 h1 / h2 用 130% 來提高比例凸顯重要性。這樣的好處是當使用者自行設定瀏覽器的「字形大小」選項時，利用顯示比例設定的文字大小會隨之調整。反之以 px 為單位固定尺寸的文字，不管瀏覽器怎麼調整字形大小，都會固定不變。
我後來沒有繼續沿用百分比例方式來設定文字大小，而回頭用 pt 單位。但在設定文字大小時，儘量使用 11~12pt 為一般顯示，偶爾一些不重要的附加資訊使用 10pt 當作小字減輕版面複雜度，標題文字都在粗體 13~14pt 之間。這樣的設計雖然版面看來不甚清新，但眼睛不吃力，讀起來輕鬆愉快。況且因為字體放大了，同樣字數的段落內容感覺也比較豐富，算是別種意料外的收穫。
放大文字後最麻煩的，就是整塊版面看起來會很平，有點小醜。如果要稍加增強橫向行列的感覺，這時候可以在 CSS 中設定 line-height 增加行與行之間的距離。通常只要將 line-height 設定比你的文字高度多 30~50%，行列的感覺就可以出得來。各位不妨試試看。
切記，小文字對於一般讀者沒有視覺障礙者而言沒問題，但對於視障（含弱視、近視、老花眼）人士來說，都會帶來非常痛苦的閱讀經驗。既然網頁是要對外開放給他人閱讀使用，建議還是多體貼一點，放大網頁文字設定，幫助視力稍弱的朋友一點忙吧。
PS. to 墨綠,
這篇並不是專門給你的，雖然你最近的舒暢也是受惠於同樣的思惟結果。
之前看過一個 無障礙網路空間 的東西，開始注意到自己網站的 Layout 對於視力不佳的朋友來說，是否會看來太過吃力等等這類的問題，於是從 2004 年左右開始，我的網站文字大小就儘量遵照不用小字體或多彩文字夾雜等原則。
以羅馬字母為基礎的外文網站，因為每個詞的長度、拼字重點、前後文的群聚慣例等都足以提供讀者迅讀略讀的「視覺印象」，因此在設計網站外觀時往往可以將文字尺寸縮小，提供塊狀的文字區，搭配底色、圖示後呈現出近似印刷品非常漂亮的配置。
漢字是方塊字，且每個字都可以獨立存在，與前後字詞依附的必要性不若羅馬拼字來得強，因此在設計網站外觀時很難拿捏文字尺寸大小。設定得太大了些，系統預帶的細明體看起來「細弱無力」，設定得小些，辨識筆畫繁複的文字時又令人非常吃力。有些人會改用楷書字體，但在非 Windows 作業系統或大陸簡體字作業系統中又無法顯示，且這樣設定並不符合 W3C 的 font-family 標準字體規則。
在 Blog 盛行後，許多人開始大玩特玩 CSS 樣式表，為了呈現出類外文網站的視覺經驗，往往將漢字的尺寸設置為 12~14px (Pixel)，甚至有小到 8~10px的，那真是小到要用放大鏡才看得清楚。px 的單位就是實際的像素，以主流通行的 XGA (1024x768)、SXGA (1280x1024)，或是最近盛行的 WXGA (1280x768/800) ，不管螢幕解析度高低，總之 12px 就是高寬均為 12 個螢幕像素的大小。這個顯示大小在不同對角線尺寸的螢幕上，卻會呈現不同的實際大小。例如同樣 12px 的字在 17" XGA 上用尺來量的實際顯示寬度，與在 19" XGA 螢幕上的實際顯示寬度就小了一點。現在的螢幕越做越大，理論上來說實際顯示尺寸應該也會愈來愈大，但因為解析度也同時提高了，造成文字的實際尺量大小反倒日形微縮。
有些人說，應該改用 pt 單位 (points) 取代 px，這樣當螢幕解析度改變時，瀏覽器會調整實際顯示尺寸以符合設計時條件。但這卻無解於螢幕對角線尺寸差異的問題。我有段時期，為了兼容顯示美觀與提供觀看便利，會利用顯示比例 (%) 來設定文字大小，一般顯示文字就用 100% 以顯示瀏覽器預設或自訂的字體尺寸，標題 h1 / h2 用 130% 來提高比例凸顯重要性。這樣的好處是當使用者自行設定瀏覽器的「字形大小」選項時，利用顯示比例設定的文字大小會隨之調整。反之以 px 為單位固定尺寸的文字，不管瀏覽器怎麼調整字形大小，都會固定不變。
我後來沒有繼續沿用百分比例方式來設定文字大小，而回頭用 pt 單位。但在設定文字大小時，儘量使用 11~12pt 為一般顯示，偶爾一些不重要的附加資訊使用 10pt 當作小字減輕版面複雜度，標題文字都在粗體 13~14pt 之間。這樣的設計雖然版面看來不甚清新，但眼睛不吃力，讀起來輕鬆愉快。況且因為字體放大了，同樣字數的段落內容感覺也比較豐富，算是別種意料外的收穫。
放大文字後最麻煩的，就是整塊版面看起來會很平，有點小醜。如果要稍加增強橫向行列的感覺，這時候可以在 CSS 中設定 line-height 增加行與行之間的距離。通常只要將 line-height 設定比你的文字高度多 30~50%，行列的感覺就可以出得來。各位不妨試試看。
切記，小文字對於一般讀者沒有視覺障礙者而言沒問題，但對於視障（含弱視、近視、老花眼）人士來說，都會帶來非常痛苦的閱讀經驗。既然網頁是要對外開放給他人閱讀使用，建議還是多體貼一點，放大網頁文字設定，幫助視力稍弱的朋友一點忙吧。
PS. to 墨綠,
這篇並不是專門給你的，雖然你最近的舒暢也是受惠於同樣的思惟結果。
有關網站版面設計解析度問題
發表於 2007-01-01 22:17:16
2007年1元旦，我常看的 Mr. 6 - 趨勢．創業．投資．策進 改版了，將原本寬度 800px 的版面改為較適合 1024x768 以上螢幕解析度 (resolution) 閱覽的寬版。反之，我從2002年開設個人網站以來一直都沿用 800px 版面。早幾年個人電腦的螢幕解析度還有泰半的人留在 800x600，這倒說的過去，但現在大家的螢幕越來越大，17", 19", 20", 21", 22"... XGA (1024x768), SXGA (1280x1024), WXGA, (1280x768)... 究竟版面要設計成哪種寬度好呢？
我的網站有裝設 Google Analytics 分析程式碼，利用 Google 的工具幫我分析統計訪客的各項資料。其中有個訪客電腦螢幕解析度的比例圖，大致上呈現出以下結果：
- XGA 1024x768: 75~78%
- SVGA 800x600: 9~11%
- SXGA 1280x1024: 9~10%
當然還有其他寬螢幕的怪解析度，甚至還有古早時代的 VGA 640x480，但所佔比例都低於 1%，幾乎可以不計。這其中我最在意的就是 SVGA 800x600 的比例數字了，根據我的長期觀察，並且詢問過其他網站主人他們的分析統計結果，基本上仍在使用 SVGA 解析度的訪客都保持在 10% 上下。一成的訪客人口說多不多，但要忽視他們的存在直接採 1024px 寬度設計版面也說不過去。
況且，以 Blog 的書寫方式來說，文字內容很少以長段落來撰寫，將版面拉寬後每個段落的行數都不多，段落間跳行比文字還多，看起來似乎也挺不豐富的。按照我這幾年來不斷嘗試各種版面的結果來說，將文章內容的版面寬度保持在 500px 以下，同時將間雜其中的照片寬高也都限制在 480px 以內，不但網頁總檔案大小的頻寬需求不至過大，且訪客的注意力會更為集中在文章版塊內。
至於邊欄的各種快速連結，包括最近文章、分類、回應、月曆等 Blog 幾乎約定俗成的各種元件和連結，寬度在 200px 以內足夠，就算是以圖案方式提供連結按鈕也夠寬了。同時，根據各網站訪客瀏覽的習性不同演變，有些元件漸漸發現不需要一直出現在邊欄。譬如說分類和月曆，這種便利於訪客翻查庫存文章的連結工具，可以另備專頁呈現之，不一定要在每個網頁都放置，這樣不僅 Blog 系統可以減少存取資料庫等耗費資源的動作而加快效率，而且邊欄版面也可以更精簡避免訪客因為太多資訊而喪失焦點。
廣告，是近來大家注目和議論的焦點。有些人很反對嵌入式廣告的存在，認為個人網站被廣告入侵後，有了商業化目的就容易失去業餘身分而陷入譁眾取寵的囹囿。這就好比馬英九沾上特別費弊案，就算號稱不沾鍋也從此污穢難堪。
我長期寫網誌，請注意我始終用的是「網誌」這個名詞，也就是早期網站用來當作 Change Log 的 Weblog 一詞被戲稱為 We Blog 而有了 Blog 部落格這個名詞由來的本初。寫網誌是在記錄生活，寫下想法，分享心情，詢問意見。我不是在寫什麼萬世共表的不朽文章，也不一定會提供有參考價值的資訊內容，我發現在網路上類似我這種寫網誌的朋友很多，從 2005 年起突然間興起的風潮，到了 2006 下半年似乎有冷卻的趨勢。
部落格冷卻的主因，應該在於網誌形態的 Blog 會讓出版者越寫越沒勁。有固定訪客班底聊天形成社群倒還能夠幫助出版者繼續經營，若是訪客不多，甚或孤芳自賞的那些 Blog 到後來往往就荒廢不再更新。若是能提供一個誘因，讓出版者保持繼續耕耘 Blog 的動力，等到隨著時間累積長久，網頁內容關鍵字在搜尋引擎的排行日漸上升，或許就能撐過這段尷尬期。
我相信廣告可以是個非常有誘惑力的動力。就算每日訪客人次不多，但看著自己廣告累積金額慢慢增加，會感覺到自己努力敲鍵盤寫文章是有所代價和回報的。否則當網誌一直處在虛擬網路世界中，無法幫助你和現實生活連結在一塊，自然就會覺得網誌可有可無，容易輕易拋棄與中斷維護。
這就是我之所以會在網站上放廣告的目的。一方面的確可以幫我賺錢，二方面也可以幫助我產生持續地經營網站內容的意願。我沒辦法像 Mr.6 那樣篇篇文章都言之有物，且將寫創業相關文章的部落格當作目前的本業來經營，但至少看在錢的份上，就只好勉為其難地繼續和眾位好友、訪客們分享我的中年危機。
回來說版面寬度。各位可以發現各大入口網站的網頁版面，大多維持左右兩個邊欄，左邊欄通常都放置連結與重要資訊，右邊欄就放置一些廣告 Banner 或可以忽略的參考資料。這都是為了顧慮到目前仍有不少的網路使用人口 (10%)，仍在使用 800x600 解析度的電腦螢幕，而不得不然的折衷結果。
就如同三年前微軟的 Internet Explorer 瀏覽器佔了網路用戶的 97% 以上，Netscape/Mozilla 除了少數固執己見的忌客 (Geek) 之外幾乎沒有市場，於是設計網頁者可以大方地遵循 IE 特有規格，並且在網頁上明言建議使用 IE 觀看。但現在 Mozilla Firefox 捲土重來，短時間內搶回瀏覽器的 10~15% 比例，致使網站設計師和軟體人員不得不開始正視 Firefox 瀏覽器的重要性，而得考慮網頁美工與程式碼的兼容性問題。
同樣的，使用 SVGA 螢幕解析度的比例始終都在一成左右，聰明的網站設計師和系統軟體人員勢必不可能也不可以忽視或放棄這樣的用戶權益。因此我在這裡強烈建議，網站版面（或主要版面）在短時間內仍應維持在顯現寬度 800px 以內，直到使用這類解析度比例普世降至 2% 以下才可重行檢討。
我的網站有裝設 Google Analytics 分析程式碼，利用 Google 的工具幫我分析統計訪客的各項資料。其中有個訪客電腦螢幕解析度的比例圖，大致上呈現出以下結果：
- XGA 1024x768: 75~78%
- SVGA 800x600: 9~11%
- SXGA 1280x1024: 9~10%
當然還有其他寬螢幕的怪解析度，甚至還有古早時代的 VGA 640x480，但所佔比例都低於 1%，幾乎可以不計。這其中我最在意的就是 SVGA 800x600 的比例數字了，根據我的長期觀察，並且詢問過其他網站主人他們的分析統計結果，基本上仍在使用 SVGA 解析度的訪客都保持在 10% 上下。一成的訪客人口說多不多，但要忽視他們的存在直接採 1024px 寬度設計版面也說不過去。
況且，以 Blog 的書寫方式來說，文字內容很少以長段落來撰寫，將版面拉寬後每個段落的行數都不多，段落間跳行比文字還多，看起來似乎也挺不豐富的。按照我這幾年來不斷嘗試各種版面的結果來說，將文章內容的版面寬度保持在 500px 以下，同時將間雜其中的照片寬高也都限制在 480px 以內，不但網頁總檔案大小的頻寬需求不至過大，且訪客的注意力會更為集中在文章版塊內。
至於邊欄的各種快速連結，包括最近文章、分類、回應、月曆等 Blog 幾乎約定俗成的各種元件和連結，寬度在 200px 以內足夠，就算是以圖案方式提供連結按鈕也夠寬了。同時，根據各網站訪客瀏覽的習性不同演變，有些元件漸漸發現不需要一直出現在邊欄。譬如說分類和月曆，這種便利於訪客翻查庫存文章的連結工具，可以另備專頁呈現之，不一定要在每個網頁都放置，這樣不僅 Blog 系統可以減少存取資料庫等耗費資源的動作而加快效率，而且邊欄版面也可以更精簡避免訪客因為太多資訊而喪失焦點。
廣告，是近來大家注目和議論的焦點。有些人很反對嵌入式廣告的存在，認為個人網站被廣告入侵後，有了商業化目的就容易失去業餘身分而陷入譁眾取寵的囹囿。這就好比馬英九沾上特別費弊案，就算號稱不沾鍋也從此污穢難堪。
我長期寫網誌，請注意我始終用的是「網誌」這個名詞，也就是早期網站用來當作 Change Log 的 Weblog 一詞被戲稱為 We Blog 而有了 Blog 部落格這個名詞由來的本初。寫網誌是在記錄生活，寫下想法，分享心情，詢問意見。我不是在寫什麼萬世共表的不朽文章，也不一定會提供有參考價值的資訊內容，我發現在網路上類似我這種寫網誌的朋友很多，從 2005 年起突然間興起的風潮，到了 2006 下半年似乎有冷卻的趨勢。
部落格冷卻的主因，應該在於網誌形態的 Blog 會讓出版者越寫越沒勁。有固定訪客班底聊天形成社群倒還能夠幫助出版者繼續經營，若是訪客不多，甚或孤芳自賞的那些 Blog 到後來往往就荒廢不再更新。若是能提供一個誘因，讓出版者保持繼續耕耘 Blog 的動力，等到隨著時間累積長久，網頁內容關鍵字在搜尋引擎的排行日漸上升，或許就能撐過這段尷尬期。
我相信廣告可以是個非常有誘惑力的動力。就算每日訪客人次不多，但看著自己廣告累積金額慢慢增加，會感覺到自己努力敲鍵盤寫文章是有所代價和回報的。否則當網誌一直處在虛擬網路世界中，無法幫助你和現實生活連結在一塊，自然就會覺得網誌可有可無，容易輕易拋棄與中斷維護。
這就是我之所以會在網站上放廣告的目的。一方面的確可以幫我賺錢，二方面也可以幫助我產生持續地經營網站內容的意願。我沒辦法像 Mr.6 那樣篇篇文章都言之有物，且將寫創業相關文章的部落格當作目前的本業來經營，但至少看在錢的份上，就只好勉為其難地繼續和眾位好友、訪客們分享我的中年危機。
回來說版面寬度。各位可以發現各大入口網站的網頁版面，大多維持左右兩個邊欄，左邊欄通常都放置連結與重要資訊，右邊欄就放置一些廣告 Banner 或可以忽略的參考資料。這都是為了顧慮到目前仍有不少的網路使用人口 (10%)，仍在使用 800x600 解析度的電腦螢幕，而不得不然的折衷結果。
就如同三年前微軟的 Internet Explorer 瀏覽器佔了網路用戶的 97% 以上，Netscape/Mozilla 除了少數固執己見的忌客 (Geek) 之外幾乎沒有市場，於是設計網頁者可以大方地遵循 IE 特有規格，並且在網頁上明言建議使用 IE 觀看。但現在 Mozilla Firefox 捲土重來，短時間內搶回瀏覽器的 10~15% 比例，致使網站設計師和軟體人員不得不開始正視 Firefox 瀏覽器的重要性，而得考慮網頁美工與程式碼的兼容性問題。
同樣的，使用 SVGA 螢幕解析度的比例始終都在一成左右，聰明的網站設計師和系統軟體人員勢必不可能也不可以忽視或放棄這樣的用戶權益。因此我在這裡強烈建議，網站版面（或主要版面）在短時間內仍應維持在顯現寬度 800px 以內，直到使用這類解析度比例普世降至 2% 以下才可重行檢討。
RSS 該怎麼發佈才好？
發表於 2006-12-22 11:05:09
前陣子把這個網站原本依照 RDF 格式發佈的 RSS 文件改成遵循 RSS 2.0 Specification 的標準，如此可以讓無名小站這種低功力的網站也能讀取，算是一種妥協的辦法。按照 XML 的原始意義，只要在 XML 文件中註明 DTD 與 NameSpace，就應該可以參考格式標準以提供最大的相容支援度，只不過情勢比人強，有些主流的趨勢還是會影響到實際技術的走向。
格式改了，卻仍有點不滿意。我的網站資料庫，當初採用一種我自稱為 TDC (Takol Data Center) 的自有技術，將整個網站的構成由三大「物件」 (Object) 組成：Category, Node, Type (View)。其中的 Node 涵蓋了所有的文章和回應，且按照設計初衷理論上應該要包含所有的推薦連結、廣告等靜態與動態的物件。這個設計的概念是從 Oracle Portal 系統而來，可以說是完全的物件化系統。但是後來一方面因為懶惰沒有繼續開發 TDC 的核心程式，二方面通用和簡潔的物件化背後代表的就是效率降低和程式複雜導致可讀性降低，造成系統維護上的困難。因此資料庫漸漸長出一些枝節藤蔓，到後來我也不再堅持用 Node 包含一切結構性的物件了。
在 TDC 當中我也利用了 Type (現在覺得應該重新命名為 View 或 Present) 來當作資料呈現的方式，很像是 Template 模板，但差異在於各 Node 可分別設定不同定義的 Type 在網頁上呈現出多樣的結果。以目前各大 BSP (Blog Service Provider) 系統來說雖可以讓版主有多種模板選擇和自定，但似乎還沒有可以根據各文章設定模板的功能。所以各位可以看到我的網站上文章有很多樣的呈現方式，有的圖片放在左邊，有的圖片放在右邊，有的標題有連結可以連到其他網站，有的完整呈現通篇文章，有的在首頁只有簡介段落須得連進去文章網頁才能看到完整內容... 這就是因為我利用了 Type 來定義各篇文章的呈現方式，不同的呈現方式所需要的資料欄位不盡相同，亦均定義在 Type 的格式之內。當我要在後台管理系統發佈一篇新文章時，除了得先選擇一個 Category 分類之外，還得先選擇一個 Type 來輸入該格式所需要欄位。
在這個網站原本的 RSS 文件中的 description 欄位內只放入很簡短的說明，即便該文章的 Type 格式應該是直接在網頁上呈現通篇文章，也會擷取文章內容取得約 200 字左右當作 RSS 網誌片段。但是後來發現這樣的做法似乎違背了現今 RSS Feed 的使用習慣，於是修改了 RSS 產生器，將完整的文章內容放到 RSS 文件中，以利使用者閱讀 RSS 方便。但有些其他欄位像是 標題圖片、對外連結等，因為是定義在 Type 當中就很難在 Parse RSS XML 時判斷要否一併放入到 RSS 裡。當然要做還是做得到，只是我就是一個懶字了得。
新版的 IE7 已經提供了 RSS 訂閱的功能，只要網頁有提供如下的 Metadata 訊息，就能夠提示瀏覽者要否訂閱該網頁的 RSS 文件。
這個功能在 Firefox 早就有了，但由於畢竟 IE 的市場佔有率一直在七成以上，因此現在大部分的朋友都還是在利用網路上的 RSS Feed Portal (例如 Google Reader) 來觀看文章摘要，很少利用瀏覽器的這個內建功能。可預見的是在 IE7 日漸推廣後，會有越來越多人直接利用瀏覽器上的 RSS Subscription + Viewer 來查閱網誌摘要，這個時候 RSS 內容發佈的方式就開始值得討論。（呼終於講到主題）
根據我這段時間以來觀察的結果，大部分的 BSP 為了吸引訂閱戶回到網站觀看完整文章內容以達到衝人氣的目的，都只會擷取文章的部份內容放入 RSS 文件內，這樣你就不得不點擊 [繼續讀完...] 的連結回到 BSP 讓他賺 hit rate。這個尤以無名小站 Wretch 為之最。少部份的個人網誌或雜誌新知類的網站 RSS 文件，才會提供完整的文章內容，甚或包括完整連結路徑的圖片。這種 RSS 文件幾乎就和觀看網站沒兩樣，很有那麼一點離線觀看的意味在。
究竟在 RSS 說明欄位中要放入完整文章，或只有摘要片段，這見仁見智沒有定論。不過以網路媒體化的趨勢而言，百分之九十的媒體內容放送方向是 one to many，只有百分之十或更少的讀者會需要雙向互動，例如留言回應 (Comment)、反向連結引用 (Traceback) 或點擊推薦按鈕 (Digg) 等等，我建議最好還是在 RSS 中放入完整文章內容，方便訂閱戶觀看以培養長期黏性，再考慮讀者回流產生廣告效應等。否則一味地用片段摘要勾引讀者前往，若文章內容不甚可口久了之後讀者也會對這樣的 RSS 失去興趣以致退訂，得不償失。
格式改了，卻仍有點不滿意。我的網站資料庫，當初採用一種我自稱為 TDC (Takol Data Center) 的自有技術，將整個網站的構成由三大「物件」 (Object) 組成：Category, Node, Type (View)。其中的 Node 涵蓋了所有的文章和回應，且按照設計初衷理論上應該要包含所有的推薦連結、廣告等靜態與動態的物件。這個設計的概念是從 Oracle Portal 系統而來，可以說是完全的物件化系統。但是後來一方面因為懶惰沒有繼續開發 TDC 的核心程式，二方面通用和簡潔的物件化背後代表的就是效率降低和程式複雜導致可讀性降低，造成系統維護上的困難。因此資料庫漸漸長出一些枝節藤蔓，到後來我也不再堅持用 Node 包含一切結構性的物件了。
在 TDC 當中我也利用了 Type (現在覺得應該重新命名為 View 或 Present) 來當作資料呈現的方式，很像是 Template 模板，但差異在於各 Node 可分別設定不同定義的 Type 在網頁上呈現出多樣的結果。以目前各大 BSP (Blog Service Provider) 系統來說雖可以讓版主有多種模板選擇和自定，但似乎還沒有可以根據各文章設定模板的功能。所以各位可以看到我的網站上文章有很多樣的呈現方式，有的圖片放在左邊，有的圖片放在右邊，有的標題有連結可以連到其他網站，有的完整呈現通篇文章，有的在首頁只有簡介段落須得連進去文章網頁才能看到完整內容... 這就是因為我利用了 Type 來定義各篇文章的呈現方式，不同的呈現方式所需要的資料欄位不盡相同，亦均定義在 Type 的格式之內。當我要在後台管理系統發佈一篇新文章時，除了得先選擇一個 Category 分類之外，還得先選擇一個 Type 來輸入該格式所需要欄位。
在這個網站原本的 RSS 文件中的 description 欄位內只放入很簡短的說明，即便該文章的 Type 格式應該是直接在網頁上呈現通篇文章，也會擷取文章內容取得約 200 字左右當作 RSS 網誌片段。但是後來發現這樣的做法似乎違背了現今 RSS Feed 的使用習慣，於是修改了 RSS 產生器，將完整的文章內容放到 RSS 文件中，以利使用者閱讀 RSS 方便。但有些其他欄位像是 標題圖片、對外連結等，因為是定義在 Type 當中就很難在 Parse RSS XML 時判斷要否一併放入到 RSS 裡。當然要做還是做得到，只是我就是一個懶字了得。
新版的 IE7 已經提供了 RSS 訂閱的功能，只要網頁有提供如下的 Metadata 訊息，就能夠提示瀏覽者要否訂閱該網頁的 RSS 文件。
<link rel="alternate" type="application/rss+xml" title="RSS" href="/rss.xml" />
這個功能在 Firefox 早就有了，但由於畢竟 IE 的市場佔有率一直在七成以上，因此現在大部分的朋友都還是在利用網路上的 RSS Feed Portal (例如 Google Reader) 來觀看文章摘要，很少利用瀏覽器的這個內建功能。可預見的是在 IE7 日漸推廣後，會有越來越多人直接利用瀏覽器上的 RSS Subscription + Viewer 來查閱網誌摘要，這個時候 RSS 內容發佈的方式就開始值得討論。（呼終於講到主題）
根據我這段時間以來觀察的結果，大部分的 BSP 為了吸引訂閱戶回到網站觀看完整文章內容以達到衝人氣的目的，都只會擷取文章的部份內容放入 RSS 文件內，這樣你就不得不點擊 [繼續讀完...] 的連結回到 BSP 讓他賺 hit rate。這個尤以無名小站 Wretch 為之最。少部份的個人網誌或雜誌新知類的網站 RSS 文件，才會提供完整的文章內容，甚或包括完整連結路徑的圖片。這種 RSS 文件幾乎就和觀看網站沒兩樣，很有那麼一點離線觀看的意味在。
究竟在 RSS 說明欄位中要放入完整文章，或只有摘要片段，這見仁見智沒有定論。不過以網路媒體化的趨勢而言，百分之九十的媒體內容放送方向是 one to many，只有百分之十或更少的讀者會需要雙向互動，例如留言回應 (Comment)、反向連結引用 (Traceback) 或點擊推薦按鈕 (Digg) 等等，我建議最好還是在 RSS 中放入完整文章內容，方便訂閱戶觀看以培養長期黏性，再考慮讀者回流產生廣告效應等。否則一味地用片段摘要勾引讀者前往，若文章內容不甚可口久了之後讀者也會對這樣的 RSS 失去興趣以致退訂，得不償失。
| #1 |
