<?xml version="1.0" encoding="UTF-8"?><!-- generator="WordPress/2.9.2" -->
<rss version="0.92">
<channel>
	<title>色胚子部落</title>
	<link>http://blog.colorbase.tw</link>
	<description>訊息多變的時代裡，需要多學習多思考</description>
	<lastBuildDate>Mon, 15 Aug 2011 03:29:59 +0000</lastBuildDate>
	<docs>http://backend.userland.com/rss092</docs>
	<language>en</language>
	
	<item>
		<title>利用Photoshop做出專業單眼才能拍出的模型效果</title>
		<description><![CDATA[因為最近剛入手LUMIX GF3，發現它內建的一個功能可以拍出專業單眼才能拍出的「模型效果」，更具體的說就是可以把實景拍的好像是用微距鏡頭拍攝模型一樣的效果；這個功能其實蠻好玩的，如果拿專業單眼要將實景拍出模型效果，則須利用攝影原理搭配如移軸鏡、淺景深濾鏡之類的東西，多敗點家才能達到。
至於GF3的模型效果，可想而知它是利用相機內建的軟體功能即時處理得到這個效果，所以既然相機內建的軟體能夠模擬出這種效果，那麼對Photoshop來說當然只是小菜一碟囉，而且效果甚至有過之而無不及。

一般效果與模型效果的比較
先來看一下兩張比較圖
▼用GF3拍的模型效果（點圖可放大）

▼原本的風貌，沒經過特殊處理的一般效果（點圖可放大）

模型效果的重點
仔細觀察上面這兩張圖，若從攝影的角度來看，就是將色彩模式調整為鮮豔，並在適當的地方製造出淺景深。
而從影像處理的角度來看，要讓照片看起來像模型世界的話將有三個重點：

適度的調高飽和度。
適度的調高反差(對比)。
在正確的地方適度的模糊化。

掌握這三個重點基本上就能讓照片看起來像是在拍模型一樣。
照片素材來源的重點
拍攝模型化照片需要注意兩個重點：

站在高處往下拍。
站在遠處拍。

這兩個重點其實很容易理解，因為我們看模型通常是往下看，而且模型小，所以需要站在高處拍才能讓景物變小。
開始模型化你的照片
這裡將使用一般效果那張照片當做素材來進行照片模型效果的處理。
建立新圖層
首先開啟要處理的素材照片，接著複製背景圖層，如果不重新命名圖層，自動產生的圖層名稱為「圖層 1」或「Layer 1」。

調高飽和度
選擇圖層1，並使用「影像 &#62;&#62; 調整 &#62;&#62; 自然飽和度」調高自然飽和度與飽和度，如下圖所示。

▼調高飽和度後的效果如下（點圖可放大）

高反差
同樣在圖層1使用「影像 &#62;&#62; 調整 &#62;&#62; 曲線」，調整曲線如下圖所示。

▼調高反差後的效果如下（點圖可放大）

建立淺景深圖層
接著將圖層1複製為一個新的圖層，並給他一個名稱，例如：「淺景深」。

接著在「淺景深」圖層使用「濾鏡 &#62;&#62; 模糊 &#62;&#62; 高斯模糊」，將淺景深圖層模糊化。

▼高斯模糊後的效果如下（點圖可放大）

建立遮色區域在適當的區域做出淺景深效果
有了經過高斯模糊後的「淺景深」圖層，這時還需要適度的保留照片中需要淺景深的部分。保留的方式有很多種，觀念當然是使用遮罩的方式來去除或保留，如果你瞭解遮色片的概念的話，只需參考下圖保留黑色的部份即可，這個步驟比較繁雜可以跳過不看。
▼遮色的區域如下，黑色為要保留高斯模糊，也就是需要淺景深的部位（點圖可放大）

這裡我習慣用以下的方式來做，為了方便文字的陳述，將不以快速鍵的方式來說明，而是以選單操作的方式來說明：
首先在圖層面板的最上方建立一個新的空白圖層，可以將它命名為「遮色區域」。接著在「遮色區域」圖層上，使用漸層工具以「黑色 漸層至 透明」畫出要保留的遮色區域如上圖所示。
接著選擇遮色區域圖層，並使用「選取 &#62;&#62; 載入選取範圍」，將跳出以下對話框（色版為遮色區域透明度），接著按下確定即可選中「遮色區域」圖層的黑色部分。

現在已經得到選取範圍了，接著再選擇「淺景深」圖層，並使用「圖層 &#62;&#62; 圖層遮色片 &#62;&#62; 顯現選取範圍」就可以保留需要的淺景深部分了。
最後再將「遮色區域」圖層關閉或刪除即可得到成品了。
成品
▼用Photoshop處理過的模型效果，很像用微距鏡頭拍攝模型吧！（點圖可放大）

▼再次比較用GF3拍的模型效果（點圖可放大）

利用Photoshop的「動作」巨集功能自動處理模型效果
在這邊我順便將過程錄製成Phooshop動作巨集，利用這個巨集基本上已經能處理大部分的場景了，這個巨集使用方式很簡單：

首先下載模型效果巨集。
在Photoshop的動作面板中載入模型效果巨集。
打開一張要處理的照片，並使用矩型選取工具圈選畫面中要保持清晰（不做淺景深效果）的部位。
▼例如這張素材我選擇中間建築的部份不做淺景深（點圖可放大）

最後執行這個巨集即可。

]]></description>
		<link>http://blog.colorbase.tw/design/1263</link>
			</item>
	<item>
		<title>Google+ v.s. 社交</title>
		<description><![CDATA[我所認為的Google+
我想Google可能是在經歷過多次社群平台創傷之後痛定思痛，又或者它之前所做的就是在為Google+鋪路，因為目前我看到的Google+的確有它過人之處，它像是結合了各家主要社群平台Twitter、Facebook、Plurk的概念於一身，卻又去蕪存菁的保留、甚至加強優點並創造出屬於自己的概念，可以把它當成Twitter用、可以把它當成Facebook用，也可以把它當成Plurk用，又或者把它當成一個「真正的社交工具」。


而在Google+的功能或概念中最吸引我的就是「社交圈」，而他的社交圈功能比起Plurk做一半的社交圈（小圈圈）功能著實好太多了。
什麼是社交圈(Circle)？
每個人的人際關係中一定都至少兩個以上的社交圈

最基本的就是自己的求學過程，例如：國小、國中、高中、大學&#8230;出了社會後至少你目前的公司就是一個社交圈，如果你已經換了兩個以上的社交圈，那麼光是職場上的社交圈就會至少有兩個以上。
大部分的人應該都至少有一個以上的興趣，而你可能因為興趣而結交了不同的朋友，例如：資訊科技、攝影、動漫、電玩、運動、電影、音樂&#8230;等等。
這些因興趣而認識的朋友，都可能可以分別獨立為一個社交圈。
最後，當然還有人與生俱來的社交圈，那就「家族」。
所以通常一個人的社交圈最基本的四大分類就是：


求學過程社交圈。
工作職場或社會交際社交圈。
興趣社交圈。
家族社交圈。


為什麼需要劃分社交圈？
有個問題其實可以仔細思考一下，在你的每個社交圈中的朋友中，有幾個是重複的？他們彼此認識嗎？共同經歷及興趣都相同嗎？
舉個例子來說，真實的情況有可能是像下面這張圖這樣，少部分彼此重疊，甚至可能有些社交圈完全不相干。

這個問題有一個重點，就是他們的「彼此是否有交集？」
如果很少或根本沒有，那麼在Google+中就可以好好的為他們的為他們劃分社交圈。
從為朋友著想的角度來看
假設一個情況&#8230;
如果你在某段時間比較常與某個社交圈的朋友做訊息交流，如果沒有劃分好社交圈或者是根本沒有社交全功能這種東西，請記得你對某個社交圈所發佈的的訊息，其他社交圈中的朋友很有可能完全看不懂，又或者是他們根本也不感興趣。
這個時候你其他社交圈的朋友就得被迫的接受這些訊息，我經常在噗浪或Facebook上看到某個人的好友清單超過300位以上，我一想到他們每次登入都要看到鋪天蓋地而來的訊息都為他們起雞皮疙瘩。
其實到最後我猜他們根本也沒有在看，每次上線只是自顧自的發表自己的訊息，然後下線。
這樣的社群環境是不是已經失去了「交流」了？
沒有交流何來的社交？
如果在沒有交流的情況下是不是比較像名人與粉絲之間的關係，名人頂多偶爾回應一下，而大部分則做單向的訊息發佈（雖然名人說這也是一種互動），但那根本不是社交行為。

從資訊過濾的角度來看
如同為朋友著想的角度一樣，現在只是把角色對調，我想沒有人希望每天接收自己完全看不懂，或者不那麼感興趣的事情，尤其在當你不是每天有那麼多閒功夫去看這麼多訊息的時候。
當然，多面向的吸收訊息，或者多關心各種不同的朋友是一件非常好的事情，但你或許把每天接收跟你的職業或興趣相關的資訊當成每日的功課，也或許把每天關心重要的朋友當成你每天必做的事情。
當我們在時間上或精力上不那麼許可的時候，就只好挑重點做，而想要接收什麼樣的訊息，應該由我們自己來決定，Google+社交圈便提供了這樣的功能，你可以決定現在要看哪一個社交圈的訊息。當然，在那之前你必須先善用社交圈的概念根據自己的情況明確的定義好各個社交圈。

或許在這種情況下，可以把Google+社交圈功能當成是一種「訊息過濾器」，只是這個過濾器的過濾規則很簡單，它是以「人」去做過濾，而應該怎麼過濾，則由使用者（你）自己決定。
如果沒有適當的過濾機制，或許你將會發現你每天有太多時間浪費在社群平台的訊息世界中了。
從隱私的角度來看
你可能跟我一樣，也很喜歡在Facebook上向朋友分享自己的行蹤或者生活中的照片，但我想你應該不希望一個在你的好友名單中，但是卻不太熟的朋友也對你的一舉一動瞭若指掌吧？又或者，你可能也不希望你的每一句話都被身在你好友名單中的老闆看到吧？
一樣的，多多的向你的各種朋友公開你的一切，或許有助於彼此的感情交流，但這應該由我們（使用者）自己決定，而不是被強迫的，每個人的界限與想法不同，其實無所謂對與錯。
而Google+的社交圈功能，可以讓我們自己決定個別的訊息對誰開放？個別的照片對誰開放？個別的影片對誰開放？這樣的隱私設定，能夠讓我們有更多的主控權，而不是被社交平台以規則及功能強制性的開放，有這樣的隱私設定可以讓我們更加的暢所欲言。
在 Google+中也可以當個稱職的粉絲
「只要不是互加社交圈（好友），就是單向的粉絲追蹤」
有用過Twitter、Plurk應該很容易了解Google+社交圈的好友設定概念，它類似Twitter的Following（你正在追蹤的人）與Followers（正在追蹤你的人），或者類似Plurk的粉絲一樣，當你對一個人的訊息很感興趣，但你並不需要他與你更進一步交流，而且他願意公開他的訊息時，你也可以單向追蹤他的訊息，就像我也常有這方面的需求，只想要單向接收某個IT界名人的訊息，而不需要強迫他也去接收我所發佈可能對他完全沒用的訊息。
這跟Facebook的概念就不一樣了，在Facebook中所有的交友動作都需要雙方確定，好友關係一旦確定就代表著雙方都會接收到彼此的訊息，除非使用訊息隱藏的方式。
而在Google+中卻可以只是單向的追蹤(Follw)他的「公開訊息」，而且也可以回應他的公開訊息，比如表示支持。
Google+社交圈也可以這麼用
Google+的社交圈功能也可以讓它搖身一變成為一個網路上的個人心情筆記簿或是「個人記錄」之類的的東西。
建立一個社交圈，例如叫做「自我記錄」，成員只有一個，那就是「自己」，從今爾後當想要做自我記錄的時候，就可以在這個社交圈裡面發佈，想當然爾，這裡的訊息只有自己看的到，過一陣子後想要自我檢視的時候，就可以進入這個「社交圈訊息串」來看看自己過去的自我紀錄。
這看起來像是在搞自閉，但我覺得這也可以是一種「與自己對話」的方式。

Google+的 Sparks 話題靈感
多面向的接觸各種不同的朋友，可以讓自己的視野寬廣，而Google+的Sparks話題靈感，就是一個讓我們增加與不同朋友接觸的懶人工具，Google善用了他的老本行「搜尋技術」，提供了這樣一個功能，每天（或甚至即時？）提供各種不同分類的話題來源讓我們可以很簡單的找到話題，擦出更多友誼的火花(Spark)。
有了共同的話題，才有可能有交流
這也呼應了前面所提到的一個概念：「沒有交流，何來社交？」是嗎？所以我比較傾向於將Facebook、Plurk、Twitter定義為「社群平台」而不是「社交平台」。
]]></description>
		<link>http://blog.colorbase.tw/e-commerce/1145</link>
			</item>
	<item>
		<title>解決使用 jQuery.getJSON 時 Session 卻過期期的問題</title>
		<description><![CDATA[當我們在做具有權限控管的網頁時，將會用到Session來做為是否已登入的紀錄及處理，通常在判斷為尚未登入時，將直接顯示錯誤訊息頁面或轉到登入表單頁面，但如果使用jQuery.getJSON()來做AJAX應用的話這樣的處理就不恰當了，因為這樣一來Session因為閒置過久而過期的話 getJSON() 將會得到非預期的結果而導致程式發生錯誤。
 
當然這種問題的解決的辦法有許多個，我們也可以在getJSON()取得資料後再判斷目前得到的資料是否正確，但這樣一來前端的程式碼將會顯得很囉嗦，因此解決辦法中有一個簡單又實用的就是直接取代 jQuery 的 getJOSN()，並搭配後端的對於不同請求給予不同的回應，來統一簡化整個判斷流程。
這裡主要用到了之前所提「使用 PHP 判斷 jQuery 傳來的 AJAX 請求類型」及「取代jQuery內置函數」兩種技巧。
在Javascript中寫入取代jQuery.getJSON()的函數：

(function($) {

	/**
	 * 取代 jQuery 的 JSON
	 */
	$.getJSON = function(url,paramData,callback){

		if($.isFunction(paramData)) {
			callback = paramData;
			paramData = null;
		}

		var opt = {
			url: url,
			dataType: 'json',
			cache: false,
			data: paramData,
			success: function(data, textStatus, XMLHttpRequest){

				if(null === data) return opt.error(XMLHttpRequest,textStatus);

				var handleError = false;

				if(data.TimeoutError != undefined ){
					if(data.TimeoutError == true){
						handleError = true;
						//提示錯誤訊息
						alert('您可能閒置過久，請重新登入系統再重試');
						//進一步轉向登入頁面
						window.location = '登入頁面URL';
					}
				}

				if(!handleError &#38;&#38; callback ...]]></description>
		<link>http://blog.colorbase.tw/web-development/1141</link>
			</item>
	<item>
		<title>檢測訪客瀏覽器對 HTML5 與 CSS3 的支援程度</title>
		<description><![CDATA[由於各主流瀏覽器對於 HTML5 與 CSS3 中支援的程度不一，如果我們想要搶先嘗試使用它們的的新功能，卻又想要在各種瀏覽器中保持一定的可用性，那麼勢必要在 Javascript 中撰寫相關的判斷程式碼來進行判斷瀏覽器是否支援新特性，如果訪客的瀏覽器支援，則使用新功能，而反之則執行替代的程式碼或者提示使用者所使用的瀏覽器將會有部分進階功能無法使用。
 
關於目前各主流瀏覽器的支援情況可參考之前的文章 HTML5 與 CSS3 準備好了嗎？
自行撰寫 Javascript 進行 HTML5 與 CSS3 的檢測
如果我們使用到的 HTML5 與 CSS3 新特性並不多，則可以自行撰寫相關的檢測碼來進行判斷，至於該如何檢測，則可參考：    The All-In-One Almost-Alphabetical No-Bullshit Guide to Detecting Everything
文章中除了羅列一大堆 HTML5 等檢測的片段程式碼，也提到了一個很好用的函式庫 Modernizer。

Modernizr
 
Modernizr 是一個非常小巧的函式庫 (大約 8 KB，gzip壓縮後大約3.9 KB)，它用於檢測瀏覽器對於 HTML5 與 CSS3 支援程度，其首頁也提供了一份即時的檢測表，當使用不同的瀏覽器進入該網站時，將可看到不同的檢測結果，這個檢測表其實也可以當做一種瀏覽器支援參考，當安裝了新版本的瀏覽器時只要進入這個網站就可以即時知道瀏覽器是否有增加了什麼 HTML5 或 CSS3 的新功能。
先讓&#160; IE 支援 HTML5 的新標籤
由於 IE9 ...]]></description>
		<link>http://blog.colorbase.tw/web-development/1099</link>
			</item>
	<item>
		<title>HTML5 與 CSS3 準備好了嗎？</title>
		<description><![CDATA[HTML5 與 CSS3 不斷出現各種令人驚艷的應用，引起了業界的高度關注，它把許多原本屬於 Flash 的特殊應用搬到了 Web 標準中，而標準化的好處在哪我想不需要我多說了，但 HTML5 與 CSS3 真的準備好了嗎？
從 HTML &#38; CSS3 Readiness 這份圖表可以很容易看出一些關鍵，它把 HTML5 與 CSS3 從 2008 年到 2010 年各個主流瀏覽器的支援情形以扇形區色塊圖的方式呈現，每個瀏覽器及渲染引擎都有自己的色系。

目前支援度最高的新特性為 Drag and Drop / @font-face / contenteditable 。
目前支援度最佳的瀏覽器為 Chrome 與 Safari。
目前支援度最差的瀏覽器為 IE 系列。


HTML &#38; CSS3 Reandiness
HTML5 與  CSS3 現在最需要什麼？
良好的集成式開發環境
我想對於開發人員而言，最需要的還是工具，因為純手工編製複雜的 Web 應用可真是一件吃力不討好的工作，但我相信只要有市場便不怕沒工具，之前 Adobe CTO Kevin Lynch 也已經說要為HTML5開發工具了，我也相信在公開的標準規範之下將會有更多軟體開發商投入精力創造出更好用的產品。
廣泛的普及
既然工具的問題排除了，那麼剩下的便是普及性的問題了，但很顯然的它們仍然還沒完全準備好，在 When can I use ...]]></description>
		<link>http://blog.colorbase.tw/web-development/1070</link>
			</item>
	<item>
		<title>有趣的 jQuery 快速顯示隱藏元素技巧</title>
		<description><![CDATA[今天在 Now you see me… show/hide performance 一文中，看到該文作者分析了各種jQuery顯示、隱藏的作法及其效能比較，最後還提到了一個非常有趣的好方法，他利用禁用、啟用&#60;style&#62;元素的方法來達到套用顯示、隱藏效果，在頁面中需要大量套用情況下效能特別好。
 
首先利用&#60;style&#62;來定義樣式為隱藏：

&#60;style id="special_hide"&#62;
	.special_hide {	display: none;}
&#60;/style&#62;


接著在將該&#60;style&#62;元素的disabled屬性設為true使其失去作用，也就是讓他變為顯示，例如jQuery中可以這麼寫：

 $('#special_hide').attr('disabled', true);  // 禁用指定&#60;style&#62;元素

 $('#special_hide').attr('disabled', false); // 啟用指定&#60;style&#62;元素

以下為完整的範例 

&#60;!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"&#62;
&#60;html&#62;
  &#60;head&#62;
    &#60;script class="jsbin" src="http://ajax.googleapis.com/ajax/libs/jquery/1/jquery.min.js"&#62;
	&#60;/script&#62;
	&#60;script type="text/javascript"&#62;
	$(function (){
		$('#disableBtn').click(function(){
			$('#special_hide').attr('disabled', true); // 禁用樣式
		});

		$('#enableBtn').click(function(){
			$('#special_hide').attr('disabled', false); // 啟用樣式
		});
	});
	&#60;/script&#62;

    &#60;title&#62;&#60;/title&#62;
    &#60;meta http-equiv="Content-Type" content="text/html; charset=UTF-8"&#62;
 ...]]></description>
		<link>http://blog.colorbase.tw/web-development/1063</link>
			</item>
	<item>
		<title>Diigo &#8211; 書籤連結分享與知識共享的結合</title>
		<description><![CDATA[Diigo 是一個 Social Bookmarking (社群書籤或稱社會性書籤)，它除了可以是個人的線上書籤，更可以是一種分享平台，而其分享的不只是書籤連結，更是一種知識共享，其功能之強大，著實讓我一用就愛上它，因為它幾乎把我已知對於書籤或閱讀的工具及方法全都整合在一起了。


Diigo 可以拿來做什麼？
簡單來說，它主要可成為：

研究與學習的輔助工具。
知識管理分享的平台。
以知識分享為基礎的社交平台。
個人線上知識管理工具。
個人線上書籤。

Diigo 具備什麼樣的功能及特色？

線上書籤分享
當書籤設為Public時。
線上個人書籤
當書籤設為Private時。
線上畫重點
當我們閱讀文章時，適時的畫重點可以幫助我們於日後再次複習時節省許多不必要的時間，如果你願意甚至可以將你的重點標記設置為Public，讓別人造訪該網頁時也能夠看到你所標記的重點。
給予網頁評論及備註
Diigo可以給予網頁備註及評論，也可以只針對我們所畫重點給予備註或評論，並且可以設定評論或備註的開放權限，如果要分享就可以設定為Public，如果別人的備註或評論我們有權限讀取時(例如對方設定為Public)，當我們在那之後閱讀該網頁時，就可以看到對方給予的備註或評論，甚至我們可以加入自己的備註作為補述或討論，因此Diigo所提供的不僅僅是一種線上網頁備註，更是一種開放性的交流、討論平台。
網頁快取
類似Google的庫存頁面，當我們加入書籤後Diigo會自動建立一份當時的快取，連收藏的動作它都幫我們做好了。
網頁快照
俗話說有圖有真相，Diigo能幫我們建立書籤時頁面的screenshot(螢幕截圖)並儲存在線上。
待讀清單
如果有一篇好文我們在當下沒有時間好好閱讀時，將可以利用此功能將它加入到待讀清單中，有時間再來好好閱讀。
書籤清單
Diigo的書籤管理方式完全採用Tag的方式，而此功能可視為一個特殊的分類方式，例如當我們正在研究某種東西的時候，我們可以為其建立一個書籤清單(List)，並再加入書籤時額外指定加入清單中，方便整理及回顧。
共享群組
共享群組(Group)可以視為一種特殊的共享方式，也可以視為一種特殊的分類方式，與List不同的是Group提供更多的共享與交流功能，例如，Group可以指定開放的權限，讓特定人士才能過閱讀這個共享群組，在這個群組中的成員將可以彼此分享、交流相似話題的書籤、評論等等。

如何使用 Diigo？
Diigo 在 User Experience 方面處理的相當好，除了可以特別註冊 Diigo帳號之外，也可以直接使用Google、Facebook、Twitter、Yahoo!的帳號註冊。對於其操作 Diigo也提供了簡易的影音教學。
安裝 Diigo 瀏覽器擴充功能
Diigo提供各種瀏覽器的擴充功能，透過對於瀏覽器額外的擴充可以把Diigo的功能完全發揮出來，因此建議如果要完全感受 Diigo的強大就一定要安裝官方提供的擴充功能。
怪不得我說 Diigo 的 User Experience 做的好，因為它的安裝方式很簡單，進入首頁後你將會看到一個很大的安裝鈕，這個安裝鈕會根據你所使用的瀏覽器而有所不同，例如使用Firefox瀏覽時將會看到：

而當使用Google Chrome瀏覽時將會看到：

安裝完之後，將會出現其功能列，例如：Firefox將會出現如下的Toolbar

安裝完瀏覽器擴充之後，不妨回來這個網頁看看，將會有很新奇的發現！
Diigo 操作及使用重點簡介
MyLibrary 就是自己收藏的書籤庫，下圖為 Web 介面，分為以下三種瀏覽模式，可依據需求於這三種模式下切換檢視。

緊實模式 (Compact Display)
瀏覽模式 (Best for Browsering)
管理模式 (Best for Edit or Manage)


加入書籤
Diigo提供許多加入書籤的方式，除了可透過 Toolbar 提供的功能，也可以使用Web介面的方式加入書籤收藏。在此只簡單介紹Toolbar的方式。
首先我們可以先選取網頁中的一段重點，並按下 Toolbar 中的 Bookmark，就會出現以下的對話視窗，此時在 Description 中將會自動加入我們選取的文字。
Diigo 的 Tag 是以 空白 區隔

這時候我們可以設定這個書籤是否為私有(Private），若設定(Unread)未讀則如同使用 Toolbar 上的 Read Later 一樣，也就是將書籤一併加入待讀清單中，之後就可以在Unread裡面閱讀這些待讀的書籤連結。
而如果勾選Snapshot則會一併將網頁快照拍下來成為一張圖片，儲存在線上。
另外還可以一併把這個書籤加入 Group ...]]></description>
		<link>http://blog.colorbase.tw/resource/1049</link>
			</item>
	<item>
		<title>兩款用於開發 iPhone Web 應用的 UI Framework</title>
		<description><![CDATA[最近在雜誌上看到了關於手機平台開發的專欄，裡面提到了手機平台Web上很難做出如同本機應用程式所能做出的使用者體驗(User experience)，雖然這是事實，但透過Framework的輔助多少可降低難度及開發成本。
 

iUI: iPhone User Interface Framework

為iPhone Web UI提供完整的解決方案，只需利用Javascript與標準的HTML就能開發出長得很像iPhone應用程式的Web應用。
網址：http://code.google.com/p/iui/
概觀：http://www.k10design.net/articles/iui/
範例：http://www.k10design.net/articles/iui/demo/
jQTouch

這是一個jQuery Plugin，如果熟悉jQuery的話是個不錯的選擇。
網址：http://www.jqtouch.com/
範例：http://www.jqtouch.com/preview/demos/main/
]]></description>
		<link>http://blog.colorbase.tw/web-development/1010</link>
			</item>
	<item>
		<title>再談談Tag的知識關聯性與軟體操作設計</title>
		<description><![CDATA[Tag是伴隨著Web2.0而生的一個產物。因為Tag的多變化以及完整的定義性讓我自從認同了Tag所具備的價值之後我便愛上這種定義方式， 因為它除了可以幫助我們歸納整理知識或資料之外，還能夠幫助我們了解某個事物所在領域。

Tag Cloud
Tag的應用概念中最廣為人之的就是 Tag cloud (標籤雲)，它以出現的次數來賦予Tag權重，藉此來區分出Tag的重要性程度，越重要的Tag 字級就會越大。
透過Tag cloud我們可以很清楚的知道某個事物所代表的含意，例如：一個部落格的Tag Cloud可以顯示出該部落格文章的方向，如果把它用在人身上就可以知道這個人所接觸的領域落在什麼樣區塊，以及其所佔的程度比例。
例如 Wordle 可以透過手動輸入或其他上傳方式來產生屬於自己的Tag Cloud，如果你看到一張名片上印著那個人的Tag Cloud，那麼你是不是在短短的幾秒鐘就能清楚的了解到這個人所接觸的領域範圍呢？事實上我真的曾經把類似這樣的東西印成個人的名片，因為我覺得這總比告訴人家：我是工程師、我是廚師、我是音樂家之類的名稱來的更具體，因為不管哪一種職業，遇到對方對這個行業有一定的認知時，他第二句話很可能就會再問：「是哪方面的(工程師、廚師、音樂家)？」但透過Tag cloud的方式，千言萬語都比不過一張小小的圖，而且只需幾秒鐘的時間就能讓對方清楚了解。

Tag的關聯網路
當我們定義了數量非常龐大的Tag之後，我們將會很明顯的感受到一件事情，這些Tag並不會全部都是獨立的存在，它們彼此之間是會有關連性而且並不會全部都有關連，因為有些東西壓根扯不上邊。
若把它們依據關連性繪製成一張圖，將會形成一個獨特的Tag關連網路，這樣的網路結構不僅僅指出定義者所關注的事物，也表明了這些Tag彼此的關聯性，如下圖所示。

而在數量的增大同時會帶來另一個問題，因為Tag的雜亂將會帶給我們很大的困擾，即使有了Tag我們一樣很難找到自己所定義過的Tag，但如果軟體能夠透過這樣的關聯性以及排斥性幫我們加以篩選Tag的關聯性，這將會成為一種非常方便好用的Tag檢索方式。
在之前的另一篇文章：談談Tag用於知識管理與軟體操作設計 中我談到了：
理想中的Tag應該具備AND(且)及OR(或)的概念，以方便我們快速的檢索及篩選所需要的內容，它應該具備針對Tag本身的過濾性。
最近我發現有兩種軟體除了具備了Tag過濾性也同時具備了Tag的關聯性的功能，雖然使用它們已經有很長的一段時間了，但我是直到最近才真正體會到它們設計上的概念，我想我應該修正之前說過的話，真正理想的Tag管理應該是：
能結合Tag之間的關連性與Tag的過濾性。
這兩種軟體都是 Firefox addon ，它們都具備了Tag關連性與過濾性的操作：
TagSieve
前身是 TagSifter 用於加強 Firefox 書籤管理功能，讓Tag真正發揮效用。
Zetero
一套非常強悍的知識管理與文獻收集軟體。
以TagSieve舉例來說，當我們定義了四個書籤的Tag分別為：
書籤一：jquery, plugin, bubble
書籤二：jquery, tutorial, bubble
書籤三：jquery, plugin, menu
書籤四：photoshop, logo, tutorial
首先在關連性的Tag管理操作中，我們必須先輸入一個或選擇一個主要的Tag，例如，當我們選擇了jquery時，有哪幾個Tag與他有關連呢？答案是：
plugin, tutorial, bubble, menu
這裡我們可以看出，有兩個Tag與jquery是完全扯不上邊的：
photoshop, logo
接著我們將會只剩下有關連的那四個Tag可以選擇，這樣是不是大大的減少操作上的視覺負擔及操作速度呢？
再接著我們如果又從剩下的四個Tag中點選了例如：tutorial，那將會只剩下：
bubble
到了這裡，我們已經選擇了兩個Tag
jquery, tutorial
以這樣的關聯性Tag選取方式，加上Tag的過濾性來說，如果以AND的方式來做過濾，將會剩下哪幾種書籤呢？答案將會只剩下：
書籤二：jquery, tutorial, bubble
仔細想想，當在內容或知識的龐大且Tag數量也相當龐大時，這樣的操作方式是不是會為我們日後的管理或回顧帶來相當大的便利呢？
TagSieve 實際Tag篩選操作畫面
一開始有非常多的Tag及201個書籤。

點選了jquery，只剩下74個書籤，因為只保留關連的Tag，因此去除了許多不必要的Tag，這樣也讓我們很容易的了解到jquery這個Tag與什麼樣的Tag有所關連。

從剩下的Tag中，再點選plugin，於是軟體自動再次篩選關連的Tag與符合條件的文章，因此剩下更少的Tag與60個符合條件的書籤。

最終再點選bubble，只剩下10個書籤，如果再搭配關鍵字搜尋將可以更快更精確的找到我們所需的東西。

結論與感想
軟體介面的設計經過一代又一代不斷的改革、改進，一直趨近於對使用者最為友善的方式，各個領域的專家一直不斷在思考、創造，最友善最易用的操作方式。
從Tag cloud所呈現出的意義中我得到了一個延伸的啟示，不論我們在設計軟體介面或Web介面時，有一個很值得思考的關鍵點就是：
一個好的介面設計應該要能夠在最短時間讓受者清楚的了解我們想要呈現的是什麼。
電腦的發明不是在增加我們的工作負擔，當我們身為使用者時，我們可以多多了解各種操作對於我們的幫助以增進使用電腦的效率，而當我們身為開發者時，應該多多注意別人有什麼樣的好的介面設計構想，並進一步思考它且加以改善、整合，相信最終定能對我們所開發的軟體有正面的附加價值。
相關連結

Wordle
TagSieve
Zetero

]]></description>
		<link>http://blog.colorbase.tw/knowledge-management/987</link>
			</item>
	<item>
		<title>開始HTML5 &#8211; Video</title>
		<description><![CDATA[在HTML5以前若我們要在網頁中播放影片時，需要使用ActiveX或Plug-in的方式來達到，例如：Flash Player、QuickTime等等，但在HTML5之後這些東西成了標準，我們不需再透過額外的外掛來達成，相信這也意味著Web的相關應用將更趨於豐富化。
現在就連 YouTube 也已經測試使用HTML5的Video來做為影片播放介面，因此在實際應用上雖然我們並不一定要走在時代的尖端，但了解一下新技術是有其必要的。
 
&#160; 
HTML 5&#160; Video 基礎
基本的 HTML5 Video 標記如下，我們可以透過 src 屬性來標明影片的URL：

&#60;video src=影片URL &#62;很抱歉！您的瀏覽器不支援HTML5 Video&#60;/video&#62;

雖然上面的方式很簡短，但可惜的是因為目前各家瀏覽器在HTML5 Video的影片格式方面支援不一致，而導致我們若我們想要影片能夠兼容各種主流瀏覽器，我們必須提供這兩種主要的HTML5 Video 格式的影片檔案：

Theora/Vorbis (*.ogg ; *.ogv) 
H.264 / AAC (*.mp4 ; *.m4v) 

所以我們必須提供兩種格式讓瀏覽器自行依照自己支援的格式下載並播放，因此我們加入 &#60;source&#62; 來定義多個影片來源，而不是用 &#60;video&#62; 的 src 屬性，例如：

&#60;video&#62;
	&#60;source src="video.ogg"&#62;
	&#60;source src="video.m4v"&#62;
	很抱歉！您的瀏覽器不支援HTML5 Video
&#60;/video&#62;

&#60;video&#62; 的屬性
&#60;video&#62; 除了可以使用 src 屬性來標明影片的URL，我們還可以使用其他的屬性來定義 &#60;video&#62; 的基本樣式或行為。
src 
影片的URL。
autoplay
影片是否自動播放，預設為 false。
controls
是否顯示播放控制列，若設定為ture將會顯示播放控制列，這個控制器的樣式是依據瀏覽器而定的，預設為 false。
width
&#60;video&#62; 所佔寬度。
height 
&#60;video&#62; 所佔高度。
poster 
這如同一些以Flash實現的播放器所提供的「預覽圖」功能一樣，可於此指定預覽圖的URL，當影片尚未開始播放時，將會先顯示這裡所指定的圖片。
其他的屬性
&#60;video&#62;的屬性還有 loopend / loopstart ...]]></description>
		<link>http://blog.colorbase.tw/web-development/947</link>
			</item>
</channel>
</rss>

