BobChao the Blogger

Firebug 頁籤文字太小的繞路解法

2011-11-08T18:01:00.001+08:00

只有在 Windows XP 加上新細明體會出事，整個頁籤文字會小到難以辨識，差不多像這樣：（圖片來自 issue 4489 comment 38)

翻了一下 Firebug 的 issue list，似乎目前卡在 issue 4696；Dark 也寫了篇筆記教人怎麼改 Firebug 的安裝檔以便暫時繞過這個問題。不過改安裝檔雖然能解，每次 Firebug 升級時又要再修一次也是麻煩。這邊提供一個 userChrome.css，下載後放進個人設定檔資料夾裡的「chrome」中就可以了。雖然治標不治本，聊勝於無。詳細步驟如下：

下載 userChrome.css 備用
打開 Firefox 你所使用中的個人設定檔資料夾。不知道在哪裡的話，請從選單的「說明 > 疑難排解資訊」頁面裡按下「開啟所在資料夾」鈕。
開啟個人設定檔資料夾後，進入其中的 chrome 資料夾。如果這個資料夾不存在，就自己建立一個。
將剛剛下載的 userChrome.css 丟進去 chrome 資料夾裡。如果資料夾裡已經有同名的檔案，則開啟原先存在的 userChrome.css，把這行 CSS 碼貼在最後面以後存檔：
```
.innerToolbar, .panelTab-text {font-size-adjust: 0 !important;}
```

重新啟動 Firefox

因為治標不治本，所以不能視為已經解決了這個問題，只是至少升級時也不必再修改了就是。待以後 Firebug 有所更動，或許可以把這個檔（或你剛剛自己加上去的 CSS 碼）砍掉。至於這個 userChrome.css 是幹嘛的？可以看一下 Mozilla 的舊版自訂文章，這可是從 Mozilla Suite 時代就存留下來的自訂法。

關於社群式管理的心得隨筆

2011-10-24T21:33:00.000+08:00

本來今天打算來 MozTW Lab 整理一下週末討論的活動定位，不過今天在公車上看的書 -- 「約耳續談軟體」，裡面頭幾篇跟管理相關的文章，實在與我對社群的看法太也相近，決定先把一些東西打起來分享給大家。第四章的第一句話就是作為社群協調者要面對的、最重要的問題：「如果你想領導一個團隊、一家公司、一支軍隊，甚至是一個國家，首要問題就是讓大家都朝著同一個方向前進。這話說得很客氣，意思就是『讓別人做你想要的事』。」

正如大家所知，Open Source 程式貢獻者本質上都是做爽的。記得以前 XDite 也曾經提過類似的話：這群被視為「愛分享」的人不見得真的那麼愛分享，許多情形下分享出去的東西都只是自己已經獲得利益後的殘渣。我們撰寫程式許多時候是為了讓自己用更好的軟體，至於別人怎麼用那些成果，反正我們也不太介意 -- 我們的問題已經解決了。當然，某些人更會因為基於「我也踏在別人的肩膀上，應該回饋」的心情，把這些想法更提升到道德的層次，但這畢竟不是多數人。

所以，我覺得志工就是不能要求（註）的 -- 要用什麼當作這份「要求」的誘因？用約耳說的「指揮與控制管理法」，以嚴厲的恐懼讓大家能以最快的速度反應一致嗎？還是「經濟學 101 管理法」，用獎勵代替懲罰，鼓勵這群人往一致的目標前進？書裡提到，「軍隊裡會使用指揮與控制的方法，是因為沒有別的辦法能讓 18 歲青年衝過地雷區，並不是認為在各種狀況下，這都是最好的管理方法」；又說經濟學101管理法的大問題「就是內在動機會被外在動機取代」。我想這兩種方法也就是所謂的棒子與胡蘿蔔，一則脅之以威，另一則誘之以利。

我相信 Open Source 專案裡是這樣的：你有意見就送補綴（patch），讓比較有信譽、受信任的人審閱程式碼。審過以後，補綴就會被收進主幹裡，成為之後新軟體的一部分，皆大歡喜。而萬一審不過，或許代表程式寫得不夠好（例如不符合 coding style，這會讓別人日後維護非常麻煩），也還有另一種可能是解法不被認同。一旦兩人在程式解法上出現爭議，這時雙方一般會開始辯論可行作法，接著若仍無法取得審閱者的同意，則要不就不補，要不就把這套程式直接搬回家打上自己的補綴、出自己的版本。這套作法裡，審閱者跟補綴者並沒有層級上的差別，審閱者只是把自己工作做好，而補綴者也可以選擇自己用行動（把程式搬回家自己出一版）來證明所持方案的可行性。

那麼審閱者若真的希望補綴者能繼續投入貢獻（我相信每個居於協調人的角色都會把這件事情視為使命），該怎麼「讓別人做你想要的事」？我想「利誘」還是正確的作法，不過這邊要用以誘之的「利」我想並不真指錢財禮品等的東西，更重要的是自我動機，這也就是約耳提的認同管理法。審閱者站在「程式上游」（mainstream）的角度，能做的就是說服補綴者也認同自己的方法即使不是最佳、也是比較能被接受的作法。這麼一來，補綴者才可能願意以審閱者的論調貢獻重寫後的程式。由於補綴者是志工，並沒有人可以用扣薪水的方式「逼迫」他何時要把問題解決，也沒人可以用加薪水的方式「獎勵」他把問題解決，那麼只能讓他自己也接受「這種方式是這個時間點上最可行的解決方案」才行。

我們當然可以「要求」補綴者照自己的作法走，但在過程中必然含有非常多的溝通與討論，而到最後當某一方被說服，也就不會是「要求」了，因為被說服的那方已然認同了對方的思考。做事也是一樣的。希望某件事情改變作法，就動手參與；覺得「審閱者」或「補綴者」做得不對，就以開放態度盡力溝通，以求讓對方能夠繼續（在這個問題、或其他方面）貢獻心力。

那我怎麼知道你是更好的？請證明。此時你是審閱者，如果我送的補綴你不想接，請證明你的想法即使不是最佳、也是比較能被接受的作法。否則，我可以不做。

註：「要求」的定義或有不同，我這邊採取是以最壞的「我是對的，請照我的方法做」這種態度行事的作為。當然你可以說這個詞非常中性，我同意，只是我也相信每個人的感受會有差異、也不真的都能這麼邏輯分明地就事論事。

A fox in your pocket - 測試 Firefox 行動版瀏覽器

2011-09-26T22:55:00.000+08:00

你的電腦裡安裝了 Firefox Beta、Aurora 或甚至 Nightly 版嗎？或許你也會想幫忙測試 Firefox 行動版。如果你的手機符合系統需求，就可以從 Android Market 上下載 Firefox Beta 來用，提前體驗新版 Firefox 的行動魅力。

Aurora 與 Nightly

有行動版的 Beta，那有沒有 Aurora 與 Nightly？這位客官您問得好，當然有！要安裝也並不是件難事。首先，別忘記在「設定 > 應用程式」下勾選「未知的來源」，以便安裝來自 Market 以以外的程式。

接著，你想測試 Aurora（可以視為 alpha 版）還是 Nightly（每天都會更新，反映最新的程式修改）？

想測試 Aurora 曙光版，可以到 http://www.mozilla.org/en-US/firefox/channel/，或直接掃描這個 QRCode 下載 apk 檔：
想測試 Nightly ~~天天想你~~逐日版，可以到 http://nightly.mozilla.org/mobile.html，或直接掃描這個 QRCode 下載 apk 檔：

下載完安裝好就可以用了，同一台手機上可以四個版本（正式、測試、曙光、逐日）全部都裝也沒問題，設定上都會分開。

如果你完全不知道怎麼安裝... 建議你不要裝，因為這兩個版本主要還是給人測試用的，三不五時還是會有地雷出現 -- 還記得以前的 Nightly 叫做 Minefield 嗎？ :P

秉持著 Mozilla 的優秀傳統「Nightly 太好、Beta 不夠好 (c) 彼得大光」，我現在就是用 Nightly 當預設的手機瀏覽器，其實除了天天都會更新要花時間下載安裝、以及套件的版本相容外，沒什麼大問題。同時，即時完全不想寫程式，你還是可以藉由使用測試版來幫助 Mozilla 蒐集效能資料，打造更好的 Firefox 行動版，何樂而不為呢？

中文在哪？

但是這下又有一個問題：現在桌面版的 Nightly 都有中文了，那行動版為什麼四個版本都還是沒有中文可以用？其實當然是有的！不過預設情形下，你確實打破砂鍋也找不到。目前的火狐中文老師陳大光表示，把行動版的 4x 國語言都包進去同一個安裝程式會很可怕，所以 Mozilla 目前只先挑了幾個放，中文很不幸市場太小沒入圍。預定從 Firefox 7 起的新版會在第一啟動時讓使用者下載適用的語系檔，到時就有中文啦！

等等，那不就是後天嗎？ XD 後天 Firefox 7 就要上場了，請大家多指教啊！

不過為了確保中文環境使用上沒有問題，我們仍然需要大家從現在起就協助測試，那麼就自力救濟吧！其實開放如 Mozilla，FTP 上早就都把語言包傳便便了，只要用行動版 Firefox 開啟如下網址，把 xpi 點下去就可以裝語言套件囉！

正式版正體中文套件由此去：http://bit.ly/fxmobilezhtw

測試版正體中文套件放在這：http://bit.ly/fxmobilezhtwbeta

Aurora 曙光版正體中文套件抵嘉：http://bit.ly/fxmobilezhtwaurora

Nightly 逐日版正體中文套件看過來：http://bit.ly/fxmobilezhtwnightly 是說這個版本每天更新、語言套件也要每天重裝有點麻煩就是了 orz

有圖有真相，由於這個語言包是從測試版抓來裝的，所以瀏覽器名稱會叫做 Fennec，大家別棄嫌啊：

回饋

歡迎一起來幫忙測試給意見，也歡迎各位勇敢踩雷~~、追求以後靈魂可以過彩虹橋~~的勇士到討論區與大家分享想法，或者加一下 MozTW 的 Facebook 粉絲團～

無題

2011-02-21T14:01:00.000+08:00

「根據總統府處理人民陳情作業要點第三條，府方應該要主動記錄陳情者意見，並在陳情結束後朗讀給陳情者聽，確認有無錯誤，最後還要將陳情記錄寄給陳情者，但黃大鈞一開始根本沒帶紙筆，，記錄也是我們主動要求後才姍姍來遲，態度實在過於輕忽傲慢！」

這不是浪費去陳情的人的時間嗎？新聞連結

Link Mozilla F1 with Ping.fm

2011-02-10T09:54:00.000+08:00

I use Ping.fm to cross-post my updates between Twitter, Plurk, Facebook, and Status.net. Unfortunately, Mozilla F1, the latest experiment from Mozilla Labs which focus on sharing URLs, is not support Ping.fm (yet.)

So how if I really wanna use Mozilla F1 to share URL across services? Simple, just link F1 to your Gmail or Y!Mail account, and send message to your Ping.fm posting email address, that's it! It might not that straightforward, but kinda of a lifesaver workaround. You might also want to add the Ping.fm address to Contact in Gmail first, in order to auto-complete the address in the To field.

Remember to put your additional message in the mail body, since Ping.fm will ignore your message subject.

2011 年的第一天，午夜子時你在哪裡？

2011-01-01T02:36:00.000+08:00

我在跟暗黑破壞神的子民們玩。

「今年的跨年我還真是無感啊。」邊這麼想的同時，邊發現根本忘了自己去年 1/1 0:00 在哪裡。不過回頭看看自己的網誌，那麼應該就是在寫文章中渡過的吧？今年網誌產量不多，嚴格說來只有 41 篇（有篇文章拆成三次，算一篇），約半數與 MozTW 相關、而也有四分之一與牽扯上 CC。之前也講過，說忙不如說懶。雖然完全沒有興趣要求自己每天寫一篇，但確實是有些思慮僅在草稿階段就荒廢了。

社群

今年 MozTW，對內來講沒做什麼，不過對外倒是成果不錯。小 B、我、Tim 三個人都各有兩次以上的機會與其他國家及 Mozilla HQ 的人實際碰面交流，先是小 B 一月去了 Mozilla 總部接受 Jetpack 大使培訓，然後六月我在韓國與 Mozilla KR 的 Channy 約了一趟，了解韓國社群狀況，又在七月與小 B 前往加拿大參加 Mozilla Summit，與全球數百位社群成員共聚一堂 (It's just AMAZING, really)；八月因為 COSCUP 的關係，我們與 Mozilla PH 的 Alen 有一次社群小聚會交流心得，而十一月 Tim 到日本參加 Firefox Conference（讓 jQuery 作者戴了小莎的耳朵），又趁十二月到美國的機會訪問了 Mozilla 總部，還當了一天全球明星抽了獎！

在網路上的溝通也有點斬獲，由於 Firefox 4 的使用意見專案「Firefox Input」的關係，品光每次測試版都會協助使用正體中文的你，將你的意見整理給核心開發團隊；我高中同學現任室友 Ernest 更是適時跳出來辦了成果不錯的全球首創 SUMO Party。以上種種都讓台灣的狀況跟其他國家更接近了點，這會比較像這個專案該有的「全球團隊」的樣子。當有人問起 MozTW 是不是只做介面翻譯時，我都因為這些人的努力，可以很有信心地說：不只，我們參與全球社群，而 Mozilla 原本就遠遠不只 Firefox。

國內的部分，網上活動幾乎是沒有進展。這是個危機，但沒有人幫忙就是殘念。建宏哥哥如果真的不工作的話來幫忙吧哈哈！Jetpack 工作坊、SUMO Party 算是成功的活動，也謝謝 Toomore 處理了一些擺攤的事情（雖然我跟他對於實體活動的目的想法不太相同，不過各做各的、各補一塊，正是自由軟體的風格）。小莎的部分進展不多，我可以感覺到已經幫忙了一年多的小莎妹妹有點疲乏了，但我身上似乎攬了太多實在無暇，希望 2011 能確實達成把小莎的角色再拆開強化的原訂目標。至少現在電腦君很有意願協助我們同步推動小莎及火狐擬人的事情，民氣可用、柏強要多放點心思比較好。

有點遺憾因為軟體時程關係，年終仍沒有辦法辦 Firefox 4 Party，我需要點實際、而不僅是精神上的支持。

BTW 真的要再感謝一次 Nokia 出借 N900 測試，我也確實很認真地把每一版 Fennec 都想辦法裝上去跟中文碰碰看。雖然沒有機會搶頭香報到什麼 Bug，但有機子可以測，的確踏實點，也讓我對 Mozilla 的 Mobile 策略有了不一樣的想法。

COSCUP 2010 在外界眼中是很成功的研討會，以「社群共創」的角度來講也真的是超水準。但身為議程組長，我其實沒有做到自己想像中的程度，但似乎原先就太高估自己，也或許是因為想有那樣的水準得再投注更多的時間（就覺得 Jouston 和 Rex 實在猛到炸開了）。不過，一則不小心出場很多次卻也沒漏什麼氣，二則確實做了 UX in OSS 這樣的題目出來，三則維持 MozTW 必有正妹的傳統（什麼時候有這種傳統了？），算是也沒什麼遺憾了。

明年我想要在行銷推廣的部分幫忙，把小莎的經驗拉進去做點事情，以及協助議程組。但遺憾的是現在似乎總召難產中啊....

年中，再度被選為軟體自由協會的理事。其實投票前說得明白：「我只做自己想做的事情，所以其實是不很建議投我。」我不想處理捐款辦法之外的事情，尤其無心關照 ICOS，優先權降得太低之下就掉了一大堆球，這樣不好，對大家也不好意思。不過如 ilya 所言，出席了會員大會就八成要被選上了；又，馬兒再推了一把，說會支持對於捐款辦法的所有提案。那麼好吧。是說，目前為止的半年，我也還沒做些什麼，隨緣吧。

其他

其實今年寫了不少跟工作有關的文章，有興趣的朋友可以看一下 Creative Commons 這個標籤。而在知世 ISOBAR 已經滿四個月了，想學的事情也確實努力地在學習著。在這方面應該還是有點天分的，只是仍太也有限 -- 這樣的能力有時蠻困擾，什麼都一點點一點點，想更提高時卻是不足。麻煩。

算了不想寫了。乘興而來，興盡而歸。

MozTW 的聖誕禮物？Foxmosa & Firefox 明信片來了！

2010-12-08T01:25:00.142+08:00

從去年 COSCUP 之後，MozTW 已經好久沒有印些什麼來跟大家分享了。這次很感謝電腦君的支援，MozTW 第一套明信片正式登場！如果你想要參加寄明信片同慶 Firefox 生日活動跟 Mozilla 凹獎品，這是最適合的明信片啦！

除了你我熟知的 Foxmosa 小莎之外，電腦君作品「瀏覽器物語」的火狐大哥也正式開始為 MozTW 站台囉！這套明信片全部只印了 200 套（一套五張），行政事項感謝蝌蚪、幻影協助，而當然印好之後就又見來我家做家庭代工了：

感謝 othree、timdream、玉米、幻影、Whiteg、Bryan 等夥伴協助包裝（以上人名排列為從我開始的逆時針 :P），大家投入的時間用時薪加一加，又貢獻了幾千塊 XD。

挑兩張柏強個人最喜歡的給大家看一下正反面：

我家小莎真是可愛，是說哪一個是影分身變出來的？

小莎跟火狐大哥的優閒午後，背面的 Q 版真是... Q 啊~ （這不是廢話嗎？...）

廢話不多說，這篇的重點就是怎麼拿到超限量明信片！

本次明信片，依據日期排列將於下列各處現身，請把握機會：

城市	時間	地點	管理	取得條件
台北	12/11 12/12	台大巨蛋體育館 3F, CWT26 光與影攤位	蝌蚪	加特典，每套售 100 元
台南	12/11	南台科技大學, StudyArea 群英會 MozTW 攤位	toomore	捐款就送
台北	12/13	生態綠咖啡, MozTW Labs 台北場	柏強	免費索取，須先登記
高雄	12/17	彩色巴黎富民店, MozTW Labs 高雄場	alicekey	免費索取，須先登記
台中	?	MozTW Labs 台中首辦場?	徵求中	?

由於數量十分有限，所以每個地方的數量都很少！CWT26 會場限量 25 套、StudyArea 群英會會場限量 35 套，而各地 Lab 以 30 套為原則（視情況調整）。想要的朋友可要快點看準了衝一套喔！

FAQ

MozTW 是什麼神秘組織，有什麼目的？

MozTW 是 Mozilla Taiwan 的簡稱。作為全球 Mozilla 社群的一員，我們與數百萬熱愛網路的夥伴一同為您的網路體驗打拼。目前社群的明星軟體為 Firefox 網頁瀏覽器，除此之外 MozTW 也希望成為使用者接觸自由文化的起點。我們持續辦理推廣自由文化的課程與活動，歡迎閱讀我們的想法、訪問我們的網站，或者一起動手吧！

是用送的還是要付錢？

雖然我們窮得半死，不過這些卡片除 CWT26 會場採搭配特典販售外，其餘都屬於自由樂捐索取的。在 SA 群英會會場只要捐款（額度不限）就可以索取一份，而 MozTW Lab 發送的明信片則是直接贈送、在當場也歡迎自由樂捐的。

CWT26 會場販售的部分結餘，蝌蚪大人會再捐回 MozTW -- 事實上這些全部都是他畫的，還協助印製的行政工作，小小弟真是銘感五內啊~~

其餘各地的捐款，我們採分散式管理，請參考非組織帳戶管理。每筆出入都會在 moztw-general 摩茲將軍郵件群組公布。您的捐款都會用於推廣開放網路、自由文化的事務與活動上。

你們哪裡有錢印這些？

這次的經費主要來自 COSCUP 會場群眾的贊助，及語意偵探肯尼洛克的捐贈，特此致謝。（Linked Data Rocks!）

一人可以拿幾套？

MozTW Lab 聚會現場及 SA 群英會會場，一人限領一套（於 MozTW Lab 領取者請預先登記，沒登記的只能現場排候補喔！）。CWT26 會場隨你買，但反正最多就是 25 套了 :P

什麼時候開放登記索取？

MozTW Labs 高雄跟台北的預約，都將在台灣時間 12/8，就是今天，的晚上 20:00 開始開放登記。

我還有問題！

那就留言發問吧！

生活與工作的雜記，一篇。

2010-12-05T02:55:00.001+08:00

最近都好久才寫些什麼。「忙吧？」或許也是，但更多是懶。說懶，其實把下班後的很多時間開始分配在休閒上，看日劇、玩遊戲什麼的，很多很多也給了書，想在年底前完成 anobii 登記閱畢書籍 35 本的個人紀錄；又，書架上那些沒看完的，總得看完吧？跟玉米爭辯著：沒看過的書就是新書。我確實這樣想，雖然那時只是在玩新舊定義的文字遊戲而已。

在知世剛過了三個月，在大家的照顧下過得還不錯。這份工作有個很棒的地方是，我總可以、也被要求要想著使用者、而不（單）是出錢的客戶。我盡量地讓自己不要太忘形，不然工作氣氛太歡樂、怕又像小學那般聒噪。聽人講話還是更有趣的。

很喜歡公司那裡我的辦公桌，這一組的人之間並不是用 Cube 隔開、抬頭就看得見彼此，左右鄰居間亦沒有區隔。兩個人中間的界線不明其實也是另一種趣味及交流，例如我跟同事的座位之間是微型劇場，現在加入了四面八方來的新夥伴越來越熱鬧；工作環境光線蠻充足的，眼睛不容易累，又、我只要抬頭望向前就可以看見陽台及窗外，這是種特權 -- 只有大頭們圍繞在辦公室周邊的獨立隔間有這種享受，而 IT 部靠窗的夥伴們又常關著窗廉。天氣好的時候心情總不錯，跟在中山看到松鼠時一樣，很容易被小事取悅。

目前手上案子，覺得自己還不算太差。雖然（也是當然）仍有不少可以改進之處，但就客戶及同事的反應來看，還算及格。排演時被說「柏強問起來蠻有樣子，不像是第一次啊，而且你一定很會把妹！」我笑著反駁了這個誤解，那其實是最不擅長的事情之一。與此無關，只要一直保持對所有話題的全面好奇心就可以了。

啊，不過我並不否認自己確實更樂意與年輕女孩多聊點。

今天上課，一開始的分組，講師要求與「最不想跟他共事」的人一起，我問是否早已認識的就不算？其實唯一不想就是跟認識的人一組（會害羞，也想自然點認識新的人），所以既然這件事情原本也不被允許，便再沒有真的「不想共事的人」。但有件有趣的事：即便被要求與「不想共事的人」同組，大家找到的反而都是很類似的人。例如來找我的夥伴也是資管出身，與我也都對科學化的證據有興趣，並參加過幾次相同的聚會。講師吃飯時的解釋是，不想共事的人通常是與自己相像的人。我可以接受這個論點，但另一方面還是要想：會不會我們還是在潛意識裡找能溝通的對象，而這「能溝通」必然有相似之處？

不太同意那位大哥講的話。單身與否從來很少是中華文化裡與人見面會問的東西，也就是接近「不可測」。如果這很容易就問出口，Facebook 就不用加感情狀態這種欄位，所以在上面做文章就稍嫌多了。but well 我的意見只是我的意見.

「況且這個問題本質上不重要。」你或許會這麼說吧？

下課原本要直接回家，但轉身就進了服飾店買了襯衫、褲子、外套。這沒什麼大不了，只是過去不太發生而已。悠識那位在各大活動報到時常幫忙，在禮貌微笑背後總透著緊張的小姑娘，原來是中原資管的（這行資管的真多啊）。想起這間學校，我還是有點介意地想知道：為什麼當初他們退了我申請的件？無法理解耶，都是類似的資料，中山中正都收了也都在最後給了名額，中原覺得我哪裡不好？不過想到曾說的「那就來努力讓他們後悔沒收我吧」，倒是因為那時幼稚又直率的想法微笑了，並沒有人對於不會記得的事情後悔。

最近好像很常跑醫院，什麼原因都有。我也不想但就是那樣了；這篇裡面都沒有寫到 MozTW 的事情，最近的步伐緩慢，一方面抱怨那都是我的錯，二方面能力與時間就是這樣。不開心的話，報名幫忙，然後咬我吧。

在 Aptana 中開啟 JSLint，即時打槍你的 JavaScript

2010-11-15T17:46:00.001+08:00

設定一下就好了，享受邊寫 JavaScript 邊被打槍的淒慘感覺，從失敗中邁向光明之路。不知道 JSLint 是什麼的可以參考歐三哥哥的文章，很詳細：JavaScript Best Practice Part.1: JSLint

It's official: Firefox 4 Party 延期

2010-11-13T10:23:00.000+08:00

其實決定一段時間了，再聯絡原本預定支援的贊助商們之後才來發這篇。Firefox 4 一如預期般延後，不過延後到超出預期的 2011 年初 XD 為此，Party 當然也沒辦法太早辦。只好向各位說聲抱歉。

目前預期是延到 2011 年 1 月 29 或 30，看場地而定。原先已經定好當時要同歡的朋友們，或許我們也仍然可以考慮約一下、聊聊 MozTW 及 Firefox 的近況。有興趣可留個言什麼的，咱們隨興點。

Firefox 4 的 HTML5 表單

2010-11-13T09:38:00.005+08:00

（廣義的）HTML5 除了絢麗的各種 CSS3 及新 JavaScript API 組合技之外，還有一個十分實用、卻比較容易忽略的 HTML5 Forms。Firefox 4 實作了其中不少東西，這篇文章將大致介紹一下這玩意。

本文編譯自 Mozilla Hacks 的文章：Firefox 4: HTML5 Forms。原文亦採 CC:BY-SA 3.0 釋出。要實際試用文中的表單效果，你需要以支援 HTML5 表單的瀏覽器觀看此頁。關於各瀏覽器的支援程度，文末將略提一下目前的概況，可逕自參考。

輸入欄位新型態

HTML5 中新增了不少 INPUT 元素的 type 屬性值，可以表達我們希望使用者輸入哪一類的資料，從而在語意甚至互動呈現方式上獲得更好的結果。

舉例而言，手機上虛擬鍵盤的輸入一向受限於顯示區域、經常得在各種模式（中文、英文、數字）間切換。假若一開始就擺明了要輸入電話號碼、那麼瀏覽器就可以自動呼叫數字鍵盤出來，節省時間也增進體驗；又或者，如果這個欄位就是要輸入 URL，那麼或許也可以跟瀏覽器的瀏覽紀錄互相結合以節省使用者記憶的功夫。

Firefox 4 Beta 7 裡新增了以下幾種 type：

<input type="search">
<input type="tel">
<input type="url">
<input type="email">

其中 url 與 email 會自動驗證使用者是否確實輸入了網址或電子郵件地址格式的資料，等下會再提一下這個部份。

輸「出」欄位

還有一個新的 OUTPUT 元素，用來表達某個區域的內容是因應表單的輸入而改變的。例如，你填了出生年月日後，就在此顯示你幾歲那類的。寫法如下：

<output for="i1 i2">

for 屬性中是以空白字元分隔的、「構成這個輸出結果」的表單元素 ID 清單。使用這個元素主要是可以讓補助工具（如螢幕閱讀軟體）了解該區域的語意並提供對應服務，但 OUTPUT 裡的內容並不會「自動」計算出來，你還是得用 JavaScript 算好後填進去。畢竟，瀏覽器怎麼知道你想如何計算呢？

輸入欄位的備選清單

長久以來，網頁世界裡一直缺乏「ComboBox」這樣的元件：一方面能接受使用者自由輸入、二方面也能提供預選的清單，讓使用者更方便。過去我們可以利用 JavaScript 「做」出類似的效果，而以後則可以使用 DATALIST這個新元素來處理。在DATALIST 中所有的 OPTION元素，都會被視為是這份清單裡的備選答案。在清單定義完畢之後，則可在 INPUT 裡加上 list 來使用。範例如下：

輸入所在城市：

或從清單中挑選


<label>輸入所在城市：<input list="cities"></label>
<datalist id="cities">
  或
  <label>從清單中挑選
    <select>
      <option value="Taipei">台北</option>
      <option value="Tainan">台南</option>
      <option value="Taichung">台中</option>
      <option value="Taidong">台東</option>
      <option value="Taihsi">台西</option>
    </select>
  </label>
</datalist>

以這個方式書寫的話，如果訪客的瀏覽器不支援這個功能，也會直接略過 DATALIST 而將當中的 SELECT 選單顯示出來，所以不必擔心使用者就因此無法使用。你可以另外拿一個不支援這個標籤的瀏覽器來看本頁試試。

輸入元素新屬性

autofocus

不必再仰賴 JavaScript 將輸入焦點移到使用者第一個要輸入的表單欄位了！只要在要搶輸入焦點的 INPUT 元素上加入 autofocus 屬性即可：

<input autofocus>

placeholder

在使用者未輸入文字前，要在欄位裡顯示的東西。可以用來提示使用者該輸入些什麼，例如：

電話：

意見：

<label>電話：<input placeholder="02-22223333#311"></label>
<label>意見：<textarea placeholder="請輸入您對本產品的意見。"></textarea>

解構式表單

現在表單元素的書寫方式將有更多靈活的變化。

`form` 屬性

INPUT 不再需要放在 FORM 元素中了，現在放在任何地方都行，只要加上 form 屬性指明要歸屬的 FORM id，此部份的資料就會隨該表單一併送出。

舉個實用的例子：你想在網頁頁首放一個簡單的搜尋欄位，又想在頁尾另外提供更進階的搜尋功能選項。那麼，頁首可以這麼寫：

<input type="search" name="search_field" form="search_form">

而頁尾可以這麼寫：

<form id="search_form" action="search.php" method="post">
  <fieldset>
    <legend>進階選項</legend>
    <input type="checkbox">也搜尋私人內容
    <!-- 其他內容 -->
  </fieldset>
</form>

這麼一來，兩個部份就屬於同一個表單，而你可以更自由地隨意擺放。

欄位中的各種表單選項

在 FORM 元素中定義的屬性，都可以視情況、由表單欄位中的設定來推翻。目前表單的送出按鈕（包括 BUTTON 跟 type="submit" 的 FORM）支援的相關屬性有：formenctype、formaction、formmethod 及 formtarget。

有個可能的使用情境是，若表單尾附上「預覽」及「送出」兩個按鈕，則按下去後的表單行為不見得要都相同：

<form action="new_post.php" method="post">
<label>標題：<input type="text"></label>
<label>內文：<textarea></textarea></label>
<input type="submit" formaction="preview.php" formmethod="get" value="預覽">
<input type="submit" value="送出">
</form>

若使用者按下「預覽」鈕，則表單送出的方式會從 POST 改為 GET，且傳送目標也從 new_post.php 改為 preview.php。

表單驗證

我們經常需要驗證表單中的資料，確定使用者輸入了正確資訊。我們可以在表單送出前用 JavaScript 驗證資料，也可以在表單送出後以 PHP 等後端語言驗證。一般來說我們都希望使用者盡早知道自己輸入錯誤的地方，所以前端的 JavaScript 多少是會做的，那麼如果瀏覽器就可以處理這塊，不是很好？

必填資訊 `required`

在表單元素中加上 required 屬性，就代表要求使用者一定要填寫這個欄位。以 Checkbox （多選方塊）來說就代表這個格子一定要勾，而 Radio button （單選鈕）的情況則代表這群按鈕中要選一個。

直接試試以下範例吧！

<input type="text" required>

<input type="checkbox" required>

<input type="radio" name="radiogroup" required>
<input type="radio" name="radiogroup" required>
<input type="radio" name="radiogroup" required>

網址 `url`

自動驗證是否為 URL。

<input type="url" value="mozilla">
<input type="url" value="http://mozilla.org">

電子郵件地址 `email`

自動驗證是否為電子郵件地址。如果再加上 multiple 屬性的話，就可以驗證以逗號分隔的多個郵件地址。（multiple 屬性也適用於 type="file" 的欄位。）

<input type="email" value="foo">
<input type="email" value="foo@bar.org">

<input type="email" multiple value="foo@bar.org, spongebob">
<input type="email" multiple value="foo@bar.org, spongebob@squarepants.org">

這種驗證方式並不會排除有「+」號的 email 地址，所以 Gmail 那類可以在帳號上另外指定標籤（如 bobchao+spam@gmail.com）的方式也適用。

進階驗證 API

如果你想進一步控制驗證方式，可以使用 setCustomValidity 方法撰寫 JavaScript 來驗證表單。傳入字串就代表未通過驗證的錯誤訊息，以 tooltip 方式顯現（且，該表單元素會被標為未通過驗證）；傳入空字串則表示驗證通過。

請輸入密碼：

請再輸入一次密碼：

<label>請輸入密碼：<input type="password" id="password1" oninput="checkPasswords()"></label>
<label>請再輸入一次密碼：<input type="password" id="password2" oninput="checkPasswords()"></label>
<script>
function checkPasswords() {
  var password1 = document.getElementById('password1');
  var password2 = document.getElementById('password2');
  if (password1.value != password2.value) {
    password2.setCustomValidity('您這兩次輸入的密碼不同，請再次確認！');
  } else {
    password2.setCustomValidity('');
  }
}
</script>

若表單中有任何元素被標為未通過驗證，則送出表單前就會被擋下來、將輸入焦點自動移至第一個未通過驗證的表單元素、顯示錯誤訊息。若你想自訂這樣的行為，可以在 FORM 元素上設定 novalidate 屬性，或於送出表單的按鈕加上 formnovalidate 屬性。

關於驗證表單這點，Mounir 寫了另一篇文章，可參考。我（柏強）可能也會翻譯那篇，資訊很豐富。

新的 CSS 選取符

因應這些新增的表單功能，CSS 部份也有些新的選取符。

`:required`、`:optional`

預設情形下，所有的元素都屬於 :optional 的影響範圍。如果你為某元素加上 required 屬性中是以空白字元分隔的，則該元素會改套用 :required 的樣式。以下是自訂樣式的必填資訊輸入欄位：

`:-moz-placeholder`

這個擬似類別可以調整 placeholder 的樣式。這種設定方法還沒進入 CSS 標準，這麼寫就只有 Gecko 相關瀏覽器看得到了。WebKit 瀏覽器也有一個一樣的東西，以下為兩類瀏覽器都能看到效果的範例：

<style>
#selectors2 :-moz-placeholder {
  font-style: italic;
}
#selectors2 ::-webkit-placeholder {
  font-style: italic;
}
</style>
<form id="selectors2">
  <input placeholder="Style me">
</form>

瀏覽器相容性與標準制定

HTML5 Forms 還算比較新的功能，各瀏覽器的支援程度也大不相同。Opera 在 HTML5 Forms 還叫做 Webforms 2 時就實做了部份規格草案內容，所以雖然支援情形良好，但有些行為反而與後來的規格修訂結果有些出入；WebKit 的瀏覽器也已經支援了部份規格，所以也可以實際試試看。

Firefox 4 已經不會再加上更多表單相關功能，而要完整支援 HTML5 Forms 則還有一段路要走：還有些新的欄位型態（數字、色彩、日期）、屬性（數字變動間距、最大值、最小值）、事件（onforminput、onformchange）等等，尚未實做。在未來的版本中，我們會一步步加上去。

這篇文章只是表單功能的概括介紹。Mozilla Developer Network 上還有更詳細的資訊，歡迎參考。

互動素描標記法 v0.1

2010-10-05T08:27:00.000+08:00

Interactive Sketching Notes 0.1，姑且譯為「互動素描標記法」。前端工程的工作裡，無論是跟別人解釋互動點子、跟設計師溝通出圖什麼的，有套一致的標記方式應該是比較有幫助。

字不多，又是 CC:BY-SA，我就翻完了，請用。有什麼翻譯建議，或者你實務上的經驗想分享的話，也當然歡迎留言。

有點遺憾沒能用語義良好的 SVG 來呈現，搞不好哪天會發瘋把 Style 全部抽出來 XDD 有空再說吧。

紀錄片從業人員職業工會 CC 介紹

2010-09-26T22:25:00.000+08:00

需要投影片的話請到簡報室下載 :)

時間剛剛好 55 分鐘，不過只留 5 分鐘發問看來是太少。這次算是整合了幾次修改的投影片，以後若還有機會講 CC 應該都會用這份了吧？

Creative Commons 介紹

View more presentations from Bob Chao.

這也是第一次使用 Jouston 給我的簡報筆，使用上還不太熟練，要多練習。

完美的 404

2010-09-25T13:33:00.001+08:00

原文 The Perfect 404 by Ian Lloyd

Translated with the permission of A List Apart Magazine and the author[s]. 授權採 CC:BY-NC-SA 3.0（因為 ALA 不給商業利用。）

Bob: 我譯得很隨性，就原有的句子的意思、在描述上自由發揮了。也就是說，我不會變更作者的意思，但如果發現原意用中文不好體會，就會改用容易體會的方法換句話說。所以總之，相當程度上，我在改寫。但，翻譯原本就是改寫了，我並不真的是信達雅的信徒。

又，原文程式碼部份採「對讀者友善」的方式用了折行標記等東西，我這邊改採「對剪貼簿友善」的作法、把原文折行的部份又併回一行了。這樣比較好複製，至於如果你要印出來… well…

如果您發現哪些部份翻譯有誤，請留言指教。

糟，好像有什麼出了問題，但你也不確定是什麼 — 是你的問題、還是網站的問題？接下來又該怎麼辦？

歡迎來到 404 錯誤頁的世界。你直接輸入網址、也或許是點了某個已經年久失修的連結，向伺服器要求一份網頁，隨即發現自己身處虛擬世界中的飄渺之處。對訪客好一點的網站還會提供幫助，但大部分則就什麼事也不做、單純仰賴瀏覽器內建的功能向訪客描述目前狀況。我們當然能做得更好點，不是嗎？

對於在伺服器上設定自訂 404 頁的方法，我就不提了，建議你可以讀這些文章：

Creating a Custom 404 Error Page (4 Guys From Rolla)
Creating Custom Error Messages in Apache (4WebHelp)

然而，我在此將針對大部分造成這種錯誤的原因，提出打造自訂 404 網頁的策略建議。

要開始著手設計，我們得先看看大眾發現自己身處 404 網頁的常見理由：

打錯網址、書籤過期未更新等
搜尋引擎連往過期的網址
網站管理員沒發現的站內錯誤連結

這些理由都會前往同樣的地方，但處理的方法卻應該稍有不同 — 404 網頁必須針對不同狀況分別量身訂作。有些小技巧可以用來處理上述的情境，但我的第一個建議卻非常簡單…

不要指責

無論如何，都要告知訪客情況有誤，但不要指責訪客、就算你知道真的是他們的錯也一樣！這邊可用「可能」、「或許」等詞彙，別弄壞與網站訪客的關係，一旦搞砸、搞不好再也沒機會彌補了。

404 必備

除了「出錯了」的文字外，請確保錯誤訊息網頁上包含這些：

通往網站首頁及網站地圖（若有此頁）的連結：最容易解放訪客的方法，這個不花腦筋的作法用不到什麼奇技淫巧。
搜尋欄位：如果你的網站有搜尋功能，就放到 404 網頁上。若網站沒有搜尋功能、又常常出現 404 問題，那麼或許該弄一個來。
清楚簡約的外觀：避免把網站的標準導覽元素都放到 404 網頁上。一方面你應該避免讓使用者分心，二方面在 404 網頁上放導覽元素很可能造成更新不同步的問題。你的 404 網頁若非以程式動態更新，則更新狀況很容易就落後網站其他頁面。連 404 網頁上的導覽元素都失效絕對是你最不想發生的事，尷尬！

也請避免使用術語。我的意思是，因為我們算一掛的，所以在這裡可以討論 404；不過 60 歲的阿姨逛編織網站碰上錯誤連結，來到這頁後可能就完全不瞭「404」是什麼東西。如果你想使用「Error 404」這樣的詞，那便隱晦點 — 例如放在頁尾，留它向看得懂這些電腦黑話的網路咖打聲招呼。

接著，來看看怎麼打造 404 網頁可以讓它幫你一把、而非推你一下。

聰明點

到此，我得先說清楚，這邊的技巧需要用上不少 JavaScript（你不見得可以用伺服端的程式來解決這些問題，這端視伺服器設定）。所以，記得使用 <noscript> 標籤，讓關掉 JavaScript 的訪客也能獲得妥當的訊息。如果你能用伺服端程式，那便最好，可以無視瀏覽器跟網頁無障礙等等的問題，下面這些程式碼就斟酌參考。

首先，要設定一些變數：

var strReferrer=document.referrer.toLowerCase();
var blnSearchReferral = false;
var blnInsiteReferral = false;
var str="";
var strSite = "";

接著，要拿這些變數做什麼呢？

打錯的網址

網址打錯，或從過期書籤來的訪客不會有 HTTP referrer，所以要處理這種狀況的程式如下：

if (strReferrer.length==0)
{
  str+='我們猜想下列連結對您可能有用：<\/p>';
  str+='<a href="\/home.php"><img src="/images/home.gif" alt="Home Page" width="100" height="30"\/> <\/a>';
  str+='<a href="\/site-map.php"><img src="/images/site-map.gif" alt="Site Map" width="100" height="30" \/><\/a>';
  str+='<hr \/>';
  str+='<p><strong>您找不到這個網頁，或許是因為：<\/strong><\/p>';
  str+='<ol type="a">';
  str+=' <li><strong>書籤\/我的最愛過期了<\/strong><\/li>';
  str+=' <li>搜尋引擎上<strong>關於我們網站的連結過期了</strong><\/li>';
  str+=' <li><strong>打錯網址</strong><\/li>';
  str+='<\/ol>';
  document.write(str);
}

搜尋引擎連結過期

如果訪客有 referrer 值，我們可以先辨識出幾個特定的搜尋引擎（你可以依據自己的喜好調整辨識清單）。辨識後，我們拆解搜尋參數，看是否有與此次搜尋相關的頁面：

if (strReferrer.length!=0)
  {
  if ((strReferrer.indexOf(".looksmart.co")>0)||
  (strReferrer.indexOf(".ifind.freeserve")>0)||
  (strReferrer.indexOf(".ask.co")>0)||
  (strReferrer.indexOf("google.co")>0)||
  (strReferrer.indexOf("altavista.co")>0)||
  (strReferrer.indexOf("msn.co")>0)||
  (strReferrer.indexOf("yahoo.co")>0))
  {
  blnSearchReferral=true;
  //取得網址 — 切到第一個斜線為止
  var arrSite=strReferrer.split("/");
  //找出搜尋字串
  var arrParams=strReferrer.split("?"); 
  var strSearchTerms = arrParams[1];
  arrParams=strSearchTerms.split("&");
 
  strSite=arrSite[2];
  var sQryStr="";
 
  //定義不同引擎查詢關鍵字的方式
  var arrQueryStrings = new Array();
  arrQueryStrings[0]="q=";  //google, altavista, msn
  arrQueryStrings[1]="p=";  //yahoo
  arrQueryStrings[2]="ask=";  //ask jeeves
  arrQueryStrings[3]="key=";  //looksmart
 
  for (i=0;i<arrParams.length;i++)
  //跑 URL 中所有的參數
    {
    for (q=0;q<arrQueryStrings.length;q++)
    {
    sQryStr = arrQueryStrings[q];
    if (arrParams[i].indexOf(sQryStr)==0)
      {//找到搜尋關鍵字了！
      strSearchTerms = arrParams[i];
      strSearchTerms = strSearchTerms.split(sQryStr);
      strSearchTerms = strSearchTerms[1];
      strSearchTerms = strSearchTerms.replace("+", " ");
      }
    }
    }
  //告知訪客網站有誤，以及原先搜尋的詞彙
  document.write ("<p>您先前在 <a href='" + strReferrer + "' target='_blank'>" + strSite + "<\/a> <\/strong> 搜尋 「<strong>" + strSearchTerms + "<\/strong>」。然而，這個搜尋引擎可能有段時間沒來了，你找到的連結已經過期。<\/p><h2>放心，一切都好<\/h2><p>我們猜想下列連結對您可能有用：<\/p>");

接著，針對不想流失訪客的特定來源關鍵字詞，可以加上幾行識別程式。舉例來說，假如搜尋「電器」跟「設備」時你的網站排得蠻前面、但相關的網頁卻搬家了，這時你當然不想流失那些 Google 來的訪客，對吧？

if (
  (strSearchTerms.indexOf("widgets")>=0)||
  (strSearchTerms.indexOf("electronics")>=0)
  )
    {
    document.write("<a href='\/cool-widgets.htm'>我的電器設備大展<\/a><br \/>");
    }
  }
  }

當然，如果你的網站有站內搜尋功能，現在可以拿這個搜尋關鍵字來搜尋一次。站內搜尋或許能自動產生相同搜尋字詞的網頁連結，無須動用上述的工人智慧。但無論如何，建議採用工人智慧的方法，不然可能只是讓訪客多增加一次找不到網頁的機會而已。

站內失效連結

從搜尋引擎來的迷途羔羊們都關照過了，接下來就必須對付 referrer 不是從搜尋引擎來（或至少不是從你挑的那幾個引擎來）的情況。我們得再增加些條件：

if (!blnSearchReferral)
  {
  strSite = strReferrer;
  strSite = strSite.split("/");
  strSite = strSite[2];
  document.write("<p>從 <strong><a href='" + strReferrer + "'target='_blank'>" + strSite + "</a></strong> 來的這一頁已經不存在消失。<br/>建議您試試看下列連結：</p>");
  }

接著提供的連結就是首頁、網站地圖等等。

那如果你自己的網站有問題呢？

即使發現 referrer 是從自己的網站來，你也不好在 404 網頁上單單說「本網站有錯誤連結」。在這種情形下，你可能需要調整字詞，承認犯了小錯：

blnInsiteReferral =((strReferrer.indexOf("http://www.mysite.co.uk")>=0)||
    (strReferrer.indexOf("http://www.myothersite.com")>=0))
  if (blnInsiteReferral)
    {
    document.write("<p>這是我們的疏失！對您說聲抱歉，我們會揪出負責這條連結的人，在他修完錯誤後給他二十鞭。<\/p>");
    }

修正錯誤

這下我們已經提供逃離 404 黑洞的路，但真的修好了什麼東西嗎？沒有。既然已經知道訪客索求的文件網址及其來源（如果有來源），那確實還有一些事情可作。我們可以自動、或要求碰上 404 網頁的訪客按下「回報錯誤」鈕，接著把這些資訊存進資料庫裡。要求訪客手動回報可以減少雜音，確保你看到的都是最重要的錯誤連結。接著要怎麼處理這些錯誤連結，就看你了。

24 個你可以提昇 Firefox 使用體驗的機會

2010-09-22T16:27:00.000+08:00

Firefox 使用體驗團隊的頭兒 Alexander Limi 貼了篇文，列了 24 + 9 個 UX 團隊希望能在 Firefox 4 解決的問題。這些問題，都（還）不會阻擋 Firefox 4 釋出，卻也不單是修圖、微調那類的東西。希望能人異士出手相助，幫助大家提昇使用體驗，或者最少，如果你覺得這問題很重要，到 Bugzilla 提出 block 的建議。以下依據優先序筆記一下前幾項的內容：

升級時，將未經使用者明確授權即安裝的第三方附加元件（Plug-ins or so）停用，主要影響啟動效能。有點類似 IE9 Beta 啟動時提醒你某個附加元件太拖累的東西，但另外也在意「不經使用者授權即自行安裝」的元件（如 Skype、Norton 軟體、Java 等）。
自動清理重複的附加元件，又是 Java，似乎 Microsoft DRM 也會重複灌版本號碼不同、但只是升級而已的套件。這應該是沒有好好指定套件 ID 的緣故。
Windows 下視窗最大化時，分頁與標題列同置一行，就像 Google Chrome 一樣，增加瀏覽空間。這好像有人在試了。
在 Windows 上啟動時，螢幕繪製的狀況比 Fx 3.6 慘。
更聰明的網址自動補完。有人動手了。
即便是 HTTPS 的網站，當掉後也要能自動復原。似乎是政策問題多過實做。
合併停止與重新讀取鈕後，不應使停止鈕出現「停用」狀態。
萬一頁面讀得很慢，使用者想按下「停止」鈕的時候會發生兩種狀況：
- 順利停止網頁讀取，或是
- 網頁在按下前的一瞬間已經讀取完畢、按鈕變成「重新讀取」，所以使用者按到的是「重新讀取」鈕、暴怒。
為了防止這種情形發生，目前的作法是在網頁讀取完畢後仍暫時顯示「停止」鈕、但採停用狀態以防止誤觸。雖然實際上對網頁讀取速度沒有影響，但多那半秒的「停止」模樣可能會讓使用者以為網頁讀取變慢了。
又，你覺得 Firefox「抄」其他瀏覽器嗎？這個 Bug 有 Google Chrome 的開發者上去分享 Chrome 設計的理由 XD 且不論「原創」所指為何，請搞清楚在這個世界裡的共創理念。（這個 bug 有人動手了）
網址列中，網域部份加重顯示，其實我記得以前 Firefox 曾經有過測試版是如此作用的，但沒加到最後版本的原因不明。有人動手了。
強化拖曳分頁時的視覺提示，MozTW 討論區之前有人提過，目前沒人動手，我也很想要這個功能 :/
減弱搜尋欄圖示的干擾，或者更準確點描述問題：「那個區域現在已經有星星、RSS icon、重讀、停止等各種顏色的圖示會出現，搜尋引擎的圖示則是另一種本身就五顏六色的干擾源」。不過個人覺得，現在 Fx 的搜尋欄已經是各家有此功能的瀏覽器中最好的一種了（我尤其不喜歡 Safari 的方式，原因同 Comment 5），接下來可以走的方向應該就只有與位址列合併了吧？
在選單中增加縮放控制的介面元素，類似 Google Chrome 現在的作法。討論中，我不是很喜歡 Google Chrome 7 dev 實做選單中多重控制項的方法，尤其 keyboard inaccessible、and no tooltips 這些小細節。
「應用程式分頁」中的外部連結，應該開在新分頁裡。可以來討論「什麼叫做外部連結」 XD
應用程式分頁隱藏瀏覽工具列等元素。好處：很多 Web 應用程式確實不需要瀏覽器內建的導覽列。壞處：但，有的需要啊！又，「外部連結」的 Bug 裡有人提到，這會讓辨識釣魚網站變得比較困難。應該是不用期待 Firefox 4 會有這個。
多重選取分頁，又一個邁向提姆所謂「Firefox OS」的東西？

因為我也沒有每個 bug 都點進去看，所以先紀錄到這裡吧。有興趣的可以去看一下原文。其實整份清單還很長，如果你對相關的問題有興趣，可常回 Mozilla Wiki 上參考完整清單。

New Ubuntu, count down!

2010-09-22T01:48:00.000+08:00

我特別貼了，只是因為它上面有兔子！真是有過節氣氛！

失敗的 SEO 例子 (update)

2010-09-08T17:52:00.004+08:00

可惜當時忘了先查一下，應該先了解是什麼時候開始阿貴老師的排名跑到第一個，這樣才有個比較基準。

Yahoo!結果 (我想這是他們的主打)

Google 結果

幾點筆記：

正版 = 購買，這是 BSA 希望你記住的思維，不過對於自由軟體使用者來說倒是笑話了。
但其實 BSA 就是要大眾這麼想，他們並不是笨到連這點都不清楚，事實上網站也列得很詳細。不過，商業軟體組織會這樣，很自然，也沒錯。反應著 BSA 的存在目的就是協助商業公司遊說政府、遏止無授權的軟體流竄。
「全部換正版」應該是個很容易被攻擊的關鍵詞，因為平常實在不多人用，相對來說稍微對搜尋引擎有點了解、就可以輕鬆爬到比官方網站還前面的排名，況且...
況且，BSA 這個活動的網站是全 Flash、看起來也沒有提供 accessibility 功能，所以搜尋引擎都討厭他。你看連畫面上僅有的那幾筆都是新聞頁面，第一頁除了 paid result 外也沒有活動網站連結。

不過這個活動有沒有成功？畢竟，他們就是要喊出來而已。或許這個結果對他們來說，是能接受的結果。我不相信不能接受還用全 Flash, inaccessible 的網站 orz 連 meta tag 跟網站標題都沒有活動關鍵字，真是服了他。說到底，「100 萬」和馬如龍（搭上艋舺的風潮）確實是賺了不少新聞版面（且不論有多少是購買的，我們不會知道）。

BTW 我不知道這網站是誰做的，我寫這篇跟目前任職的公司毫無關係。我都超支持 BSA 的，活動還沒開始就衝了：

嘿，我要走了

2010-08-31T19:02:00.001+08:00

「你好，我是明天離職的柏強。」這是我今天跟每個同事打招呼的話，握個手。

通常接下來的問句是「真的嗎」，真的。「為什麼？」其實從半年前在跟朋友聊天時，我就不斷必須面對這個問題。回答有很多，像是「想去做別的事情」、「覺得不知道該怎麼繼續」、「我有種應該當 CC 志工的感覺，或許這樣更有發展」，甚至「這邊太好了，我開始安逸」都是閃過念頭的理由。但最近這個月我不再這樣回答了，終於我只剩下一個理由：因為我覺得該走了。現在離開，不見得往後不再來，誰知道是逗號還句號呢？

但中研院真的不錯，我也很幸運第一份工作就有 Tim Berners-Lee 等級的老闆 ^註1，至少我自己覺得要離開，確實只是因為覺得該離開了。我想我一定會很想念 CC 這裡永遠的辦公室一哥生活、一進去就能有一群人哈拉的 OSSF 辦公室、天南地北什麼都扯的 Daodin 等等。但總之是如此。

不過如你所想，對於 CC 的想法已經成為我的一部份，只會繼續而已 -- 我跟小 B 合作的 CC Media Collector 仍會按進度持續，而研究生泰然即將推出的報告，或許就是我想繼續努力的方向，敬請期待 CC Blog。

「那之後會去哪裡？」或許你曾聽過我想去唸書、想去日本打工旅遊等等的，但由於 XXC 不嫌棄，我也想把握跟前輩學習的機會，所以從明天起我將在知世 ISOBAR 服務。我一直對行銷很有興趣，會到 Media Agency 卻是偶然，希望可以存活下來、並且帶走我想帶的東西。

而 MozTW 是我的興趣，我當然只會持續而已，事實上也有些計畫在醞釀中，希望很快可以成型。

註1: Kenny 前陣子從日本回來跟大家聊天時，提到他的老闆 TimBL 基本上都不太管你要做什麼，自由發展，我會心一笑 :)

社群？

2010-08-26T14:23:00.001+08:00

也是紀錄一下對話。

社群的英文是「Community」，中國譯為「社區」，這個詞也確實從地理概念下手比較容易理解：住在某個區域範圍的人都是那個「社區」的一份子，無論他多喜歡或不喜歡鄰居、他會說「我住大東夜市旁」、「我是左營人」，那類的。他們都是這個地理社區的成員，也（大多）會關心衍生的相關事情，例如巷口開了一家小七、或者垃圾車幾點會到等等。

所以換到虛擬的環境來，社群（或社區，看你的翻譯）也必然是共享某些屬性的人。這個「屬性」可能是使用的工具、可能是興趣、可能（仍舊）是地理區域、可能是對某件事情的看法。社群是自然形成的，那些所謂「建立社群」的事情，大部分（if not all）是把原本已經有的一群人兜起來，再加以發展。例如說 TOSSUG 是「台北開放原始碼軟體使用者社群」，在還沒有這個名字之前台北也是有一群使用 FLOSS 的人，他們難道是因為 TOSSUG 建立所以一下子蹦出來的嗎？當然不是。確實，有些人會因為這個社群有個名字、有集體辦些活動，所以被吸引而萌發興趣、「加入」社群，但若討論「創立」這件事情，我想更多是創立「組織」，不會是創立「社群」。

如果其實沒什麼「建立社群」這種事情，那麼我們談的「建立」、或者一旦這群人有了個名字，那其實早就已經進入了組織階段。這個「組織」不必然是社團法人或其他有階級的型態，但如果會仰賴特定一小組人來號招，「階級」已經自然形成。其實這也很正常，沒什麼好擔心的。一群小孩子玩在一起，也必然有個「孩子王」，而他們的關係也不一定是上對下，只是某些人講的話就是會比較有人聽、或者有些人就是想要多做點事情，很正常。

孩子王會不會覺得自己是這群朋友間的 leader？我想不盡然。我知道因為個性關係，朋友經常都願意了解我的想法，不過我並不預期他們就會照著我講的做，從來也不會這麼預期。

有空再整理。

Default Settings of CamStudio For UX Test

2010-08-25T03:20:00.001+08:00

CamStudio, for Windows, can record the entire screen and voice, plus a few features to make it a good software for UX Test, and it's free software (amazing!) Here's my default setting of CamStudio:

Video Options

Compressor: Microsoft Video 1
Quality: 65
Check the Auto Adjust in the frame rate section

It's not necessary to use the loseless codec, since 65% is good enough, at least in my case.

Cursor Options

Check Show Cursor, and Use Actual Cursor
I use light yellow Circle in Halfsize (the default value) for Highlight Cursor

Actual Cursor is context-rich and helpful for quickly figure the position of cursor (on a link, along with the window border… etc.)

Recording

Check Record audio from microphone in the main Option menu
Audio Options > Audio Options for Microphone
- Recording Format: 11.025 kHz, mono, 16-bit
- Keep the default value in other sections.

Program Options

The worst part of the setting UI in CamStudio, IMO.

Check these options:
- Minimize program on start recoding
- Hide flashing rectangle during recording
- Save setting on exit
- Capture translucent/layered Windows
In Play AVI file when recording stops, choose Do not playing AVI file. You may want to play the video clip right after your "test run" recording to check if everything goes well, but I'll suggest to switch back once you make sure the settings are suit your need.
In Temporary directory for recording, choose Use Windows temporary directory.
In Recording Thread Priority, choose Above Normal.
In Name of AVI file, choose Automatic file naming

CamStudio should have someone revisit this part of UI, really inconvenient.

立馬加入 W3C 中文 HTML5 討論郵件群組！

2010-08-21T21:38:00.000+08:00

我已經加入囉，其他就直接看 Ping 的文章吧，全文轉載如下：

W3C 的 Chinese HTML Interest Group 要成立了！

這個小組目前還在籌備階段，要等章程寫完、被 W3C 批准才能正式成立，但 mailing list 在 W3C 的 Kenny Lu 和 Mike Smith 的熱心幫忙之下，已經建好了！

如果你熱血到要馬上加入，請發信到 public-html-ig-zh-request@w3.org，主題寫 subscribe，然後依收到的指示進行就可以了。

如果你不確定這是什麼，那請繼續往下讀。

W3C Chinese HTML Interest Group 是什麼？

來逐字解讀好了。

W3C = World Wide Web Consortium = 制定 Web 規格的單位，有興趣了解的人可以看維基百科上的中文和英文說明。

Chinese = 中文，包括正體中文和簡體中文。

HTML = HyperText Markup Language = 用來表現網頁的語言，如果你不知道 HTML 是什麼，你大可以忽略這篇文章。 :)

Interest Group 是什麼？如果你去問 Google translate，它會告訴你 "interest group" 是「利益集團」，台灣霹靂火瞬間上身！ XD

其實 Interest = 興趣，Group = 一群人，所以 Chinese HTML Interest Group 就是「對 HTML 有興趣的一群講中文的人」。當然任何人都可以號召這樣的一群人，組織起來討論 HTML 的技術和講中文的人對它的需求，但成立在 W3C 裡有不一樣的意義，根據 W3C Groups 網頁的說明，W3C 的任務性小組有四種：

Working Groups（工作小組，暫譯）：進行規格相關工作並有實際產出的小組，產出可以是技術報告、軟體、測試套件、評審他組產出的報告等等。

Interest Groups（興趣小組，暫譯）：對評估有潛力的 Web 技術和政策有興趣的人的集結，主要是個交換想法的論壇。

Coordination Groups（協調小組，暫譯）：和其他組溝通和協調資源的小組。

Incubator Groups（培育小組，暫譯）：在一年之內快速開發新 Web 技術的小組。

另外有兩個永久編組，就不多說了，對 W3C 組織架構有興趣的人可以上網查。

W3C Chinese HTML Interest Group 可以做什麼？

成立這個「中文 HTML 興趣小組」（暫譯）的想法是 2010 年 8 月 14 日在 COSCUP / GNOME.Asia 2010 的 HTML5 BOF 期間由 Kenny Lu 找 Mike Smith、柏強和我談的，初期的想法是可以在這裡讓大家用中文討論 HTML 的技術和中文這種文字對 HTML 的需求，如果能把全世界各地講中文、關心這個議題的人聚集起來，如果大家成熟到可以理性討論、凝聚出共識，就能把需求遞交給 HTML Working Group 或讓主要瀏覽器開發者重視我們的需求。

一開始提出的議題是：

直排文書的 CSS3 規格和實作

Ruby 的 HTML(5) 規格和實作，Ruby 就是像國小課本文字旁的注音符號那樣縮小排到本文旁邊的字。

Web font 的中文支援

但小組成員可以自由提出其他議題。

我在 8 月 17 日的 Tossug HTML5 讀書會中宣傳了興趣小組的構想，立刻得到 21 位熱血社群朋友連署響應！申請一個興趣小組據說總是要一個月以上，而 mailing list 在小組成立前是不會建的；但是顯然台灣社群的熱力燒到了 Mike Smith，讓他破格先建了 mailing list，讓大家不用引頸企盼太久。

我有沒有說過 Mike Smith 是 HTML Working Group 的正式窗口，同時是 HTML 規格書的編輯？

所以，熱情的台灣社群朋友們，你還在等什麼呢？

2010 CC 亞洲會見聞錄 (3): 社群，結語

2010-07-28T13:51:00.002+08:00

承前一篇。本文一開始，筆者提過這次去主要想觀察他們的社群，在會議結束之後我也額外多留一點時間，前往韓國 CC 辦公室一探究竟，並且與專案經理 Mi Young 聊到差點趕不上飛機。這次會談的內容大致圍繞社群運作模式，幾個有趣的要點如下：

「其實我們也不知道為什麼」

有趣的事實：大部分的開放社群，都不知道社群成員為什麼會來。不過這當然只是一瞬間的感覺，仔細探究一下還是會發現一些可能的原因 – 說是「可能的」原因，因為人太多種、原因也太多了，其實很難直接複製一套作法就想通吃所有人。不過好在我們到底是個佛心非營利組織，往良善的方向去通常也會有不錯的結果。

給30歲左右人士的實體活動

韓國 CC 與 TEDxSeoul 等實體研討會、活動合作，自己也辦了好幾次的 CC Salon、CC Hopeday 等派對、工作坊。Mi Young 特別提到她個人的觀察：成年人進入社會工作一段時間後，常會感覺精神上只是在付出而沒有獲得，他們也會想加入許多的社團、組織，擴大交友圈或培養興趣。雖然韓國 CC 一開始並沒有針對這群人規劃活動，但或許以他們為目標可以收到不錯的效果。

資金充裕？

這次的研討會是過去三次亞洲會中最盛大的一次（大到讓筆者有點擔心往後沒人敢接手），且韓國 CC 居然在高級地段有辦公室，這讓人對他們的資金來源十分好奇。Mi Young 表示，這個辦公室第一年的資金由社團法人的理事長贊助，而他們現在也已經與韓國前兩大入口網站 NAVER 及 Daum 簽訂合作條款、並可望找到另外的大贊助商。不過當筆者問到目前是否能確保這個協會能穩穩邁入第三年？Mi Young 搖了搖頭「我們會努力，但目前不能確定。」

目前韓國 CC 協會大約有上百名會員，會費是月繳數百台幣。扣除大公司贊助不談，這應該算是少量、但比較穩定的收入。筆者覺得可以慶幸的是他們至少還不需要四處「接案」來過活，若今天總得擔心明天是否溫飽，經常就只來得及「把事情做對」，很難要求再將心思放在「做對的事情」上。

實體空間是重要的

雖然「網路」是CC誕生的重要因素，但見面三分情，實際面對面的互動體驗畢竟還是網路交流無可取代的部份。韓國CC辦公室開放時間內，社群成員皆可自由進出，現場也有白板、文具等工具協助社群成員動腦發想新點子。筆者剛進辦公室時，也有社群成員正在討論網站製作的問題，認真但不過份嚴肅，氣氛不錯。

另外有實體空間也能讓記憶留存，例如牆上貼了這次研討會籌辦之始，韓國CC團隊思考會議目標的腦力激盪圖表、排班表等佈告，讓社群成員對一個地方有記憶、有感情，也越容易產生認同感。

有魅力的領導人會加分

上圖是 Jay，吉他手、足球員、愛打雪仗。他同時也是法官，以及韓國 CC 的領導人。這次去開會，筆者觀察到社群成員對他都有非常高的認同感，他也很能跟大夥打成一片 – 或者說，是大家對他都沒大沒小 :P 在與 Mi Young 聊天時提到「Jay 應該也很忙吧？」她跟暑期實習生 Ji Hye 兩人相視一笑：「很忙啊... 嗯啊，忙著... 玩 Band 那類的！」這當然不是說只顧玩都不用做事了，不過在得知 Jay 同時還參加了足球隊跟冬季雪球比賽，還真是著實讓筆者吃了一驚。大家都愛跟有趣的人一起做事，有這樣一個興趣多元又親和的領導人，想來對社群營運也是十分有幫助的。

世界的自由社群都一樣

筆者過去曾有一些機會與其他國家的社群接觸，這次到韓國也做了訪談，再加上七月參與 Mozilla 全球會議。有個越來越深的感覺是，全球的自由文化相關社群，目前在營運上遇到的問題大同小異，想出來的實驗性解決方案也很類似。這有兩種解釋：首先，台灣社群並不差到哪裡去，我們實在沒有必要經常用「人口太少、市場太小」或「東方人不主動」這類事情困住自己。另一方面，目前全球的自由文化社群都卡在某些關卡上不去，我們極力追求提高社群參與的方式，但如之前筆者在自己的網誌曾寫的，貢獻率總是百分之一，我們老是想辦法提昇人數，卻很難提昇貢獻率。或許這就是極限了，也或許我們該再增強彼此的交流，試圖讓各種創意快速實驗並分享經驗？

結語

在 iSummit 2008 之後，CC 已經很久沒有真正全球性的會議了。這次的 CC Asia Conference 有來自中東與 CC 總部的夥伴，第二天的討論也蠻熱絡（雖然對於怎麼跨區域合作，好像還是沒什麼進展），稍微有點全球會的樣子。明年的亞洲年會將在澳洲舉辦，據說他們很想再「復興」一下全球會的盛況，或許我們可以再次期待明年有一個聚集四方「Commoner」的盛會。

而一如往常地，這次會議我們解決了一些問題，例如從去年會議結束後發出的「CC 亞洲電子報」在成功發出兩期後，也催生了亞洲 CC 網站建置計畫。未來亞洲的 CC 社群活動將有可能以更快的速度分享，提昇跨區域合作機會。但，也一如往常地，我們總是發現還有很多事情處理不完，例如各司法領域都很缺乏技術人才、因此筆者發表的題目「Fun with Metadata」意外獲得比想像中更多的迴響 – 不過就是個 CC 套件原型而已啊！其他還有資金、提昇參與等事情，這些議題或許三五年內還不會消失，也或許就永遠不會消失了，但相信我們可以找出方法與之共舞，不致失敗。

最後還是廣告一下：創用CC計畫下半年有一連串的工作坊，從技術、音樂、文件寫作等部份出發，希望慢慢將這些聽起來比較「硬」的著作權議題帶入創作者的生活。又、日前台灣創用 CC 計畫也啟動了兩個合作研究案，一個關於 CC 帶給創作環境的影響、一個則探討 CC 運動本質的反思。這些事情需要各位的支持，也請別忘經常訪問台灣創用 CC 計畫的網站。

2010 CC 亞洲會見聞錄 (2): Open, 以及 CC 司法領域專案會議

2010-07-28T13:41:00.003+08:00

接續前一篇「CC 亞洲會」而來...

Closing Keynote: Open

「好像是第三次看 Lessig『現場表演』，我就像戲迷一般。」雷席格教授的演講術舉世聞名，是很富表演魅力的。這一天的最後，CC 發起人雷席格教授上台演講，我在 Twitter 上有感而發寫了這句。這場演講據他本人說「有 95% 新內容」，環繞在一個越來越明顯的問題：「開放、自由」這件事情，在平台、內容上，是否是必須的？

最好的例子仍是蘋果電腦，一個似乎推崇開放與創意，但行為上十分封閉的公司。這樣的公司獲得經濟上的巨大成功，那麼我們對於開放與自由的態度到底該如何？如果我們相信「有開放、自由會更好」，如何證明？需要證明嗎？千古大哉問。

又，這段演說對筆者來講有另一個重點：基於理念與面對的議題十分相近，自由文化相關社群的合作勢在必行。CC 的主事者開始關注「平台的自由」，Mozilla 也提出 Drumbeat試圖將觸角延伸到非關軟體的地方。我想可以預見這些組織未來將更頻繁地合作，為彼此共同的目標努力。

雷席格教授的演講已經放上 YouTube，有興趣的朋友也可以上網觀看。

CC Asia Meeting

第二天屬於 CC 司法領域專案的關門會議 – 說「關門」，其實也不是因為不能公開，只是一般民眾大概也不會有興趣而已 :P 一如往常，大家分享這一年以來的工作狀況，討論相關議題。

除了各自發表的內容之外，韓國CC很貼心地還另外邀請兩位訪客分享關於募捐的事情。其中韓國延世大學的「Blue Butterfly」方案十分有趣，放進了一點遊戲元素，利用神秘感誘使校友閱讀、並提倡一天捐款 1 美元（1000 韓圜）連成蝴蝶，贊助經濟較為困難的學生。由於這個募款方式十分特殊，甚至還上了外文媒體！此專案有英文版簡介影片，可以參考。

談到資金，過去各司法領域專案對於與 CC 總部之間的關係總有點不滿意，畢竟各區專案必須得自力更生、而 CC 總部的募款計畫從來不曾協助在地專案（見去年的「華文地區訪談」）。為了這個問題，CC 總部日前已經開始嘗試提出贊助方案，以實際的資金協助全球社群的相關計畫。這是個開始，希望以後還能更好。

在去年台灣創用 CC 計畫把網誌移到首頁後，我們每個月都花了些時間看看其他人做些什麼、發生了什麼，因此在這次工作報告的部份，比較多是我們早已知道的事情，相對來講也很遺憾地比較難留下印象。好在這到底是個注重分享的社群，很多人都已經把投影片上傳到網站上了，有興趣的朋友也可以到英文版網站上查詢。

下一篇來談一下社群的部份

2010 CC 亞洲會見聞錄 (1): CC 亞洲會

2010-07-28T13:17:00.001+08:00

前言：由於我被 OpenOffice 的字數計算騙了，所以下個月的專文不小心拉哩拉雜就寫了五千多字，害編輯的同事刪得很辛苦 orz。依據慣例，還是在這裡刊一下一刀未剪版 -- 太長了，分三集播出。

你知道嗎？創用CC電子報的專文是辦公室的成員「輪值」的，若沒有人投稿、則負責的成員就得自己寫一篇，或邀請別人撰稿。筆者通常習慣自己寫，也蠻喜歡接手「研討會報告」這類的文章（暱稱為「遊記」） – 這通常是給自己一個整理的機會，否則忙著忙著，通常就什麼都沒有了。總而言之，這篇文章將跟大家分享六月在韓國舉辦的CC 亞洲區會議心得。

先來點歷史：CC 亞洲會今年是第三度召開，台灣創用CC計畫在 2008 年發起這個會議後，去年的菲律賓、今年的韓國 CC 團隊們都陸續把棒子接下去，也一年比一年盛大。每年這項亞洲區研討會都大致分成對外、對內兩個部份：對外者，一般大眾都可以參與、容易入口，主要圍繞在案例、概念等部份；對內的部份，則是各國 CC 團隊討論一些工作上的相關議題，例如社群經營、推廣經驗、技術實作、資金等等。正所謂外行看熱鬧、內行看門道，不需要當爐主煩惱授權條款在地化的熱情大眾可以在此碰面、交流，各國團隊也能討論實務上操作的經驗。由於去年在菲律賓時「見識」到韓國團隊社群經營的實力，也一致覺得促進參與（當然）是重要議題，於是韓國 CC 就被拱出來當今年的主辦。

韓國 CC 是少有的、在美國以外也成立獨立法人團體的 CC 司法領域區團隊，去年的菲律賓會議裡，他們是訪客最多的團體之一，且其中只有一個是組織內的受薪成員，其他皆為志工。會議中，他們也分享過數個由志工自行企劃實踐的網站、活動專案，實力非凡。由於去年的印象太深，因此這大概是筆者參加過的 CC 會議中，最具「目的」的一次：在 MozTW 與創用 CC 計畫中，我給自己的定位都是社群發展、聯繫，所以打開始就非常期待能實際看他們的社群成員以怎樣的方式在團隊中遊走、幫助這個團隊壯大。

這篇裡，我將大概介紹一下這次會議中的事情，下一篇再來談與韓國 CC 專案經理之間關於社群經營的訪談心得。

CC Conference

第一天是開放大眾參加的 CC Conference，由於錄影的內容韓國 CC 都已經公佈在他們的網誌上，有興趣的朋友可以直接過去看，就不用流水帳的方式一個個寫了。會議中筆者較感興趣的一些東西，紀錄如下：

Sharism

由CC的朋友 Jon Phillips、毛向輝、Christopher Adams 等人提出的「分享主義」，其中的「分享貨幣」機制圍繞在「分享的人能獲得更多」或說「分享者更能獲得別人的分享」的理念，讓分享的程度成為實際可計算、可交換的東西。這跟時間貨幣、碳交易那類的東西似乎有異曲同工之妙，而目標則是讓全體的創意流通與構建更上層樓。有鑑於我們的創意都奠基在過往的經驗中，讓想法加速流通、多被利用確實可以提昇整體的創新層次，不過由於又牽扯到將抽象化為具體的計算，大概也會受到與碳交易等機制一樣的批評。

目前 Sharism.org 上可以看到的資料並沒有很好地組織，剛進去的人應該都看不太懂吧？其實除了毛向輝日前曾訪問台灣以外，接下來八月的開源人年會 COSCUP 有一場 Christopher Adams 的演講、九月的開放源碼國際研討會 ICOS 也有場 Jon Phillips 的演說，有興趣的朋友或許可以參加這兩個研討會、當面向這些發起人請教一下 :)

NHK Creative Library

NHK Creative Library 是由日本的公共電視 – NHK 發起的網站。這個跟「公視創用」網站一樣，搭上了全球公共電視台分享資源的列車，將 NHK 所擁有的各項資源釋出、讓大眾利用。NHK 在歷史與年度預算上畢竟是台灣公視的數倍，這次釋出的資源也一口氣將影片、照片、音樂等項目一網打盡。

網站上除了素材庫之外，也提供「My List」讓訪客編輯自己要使用的作品清單，然後就可以直接簡單地剪接；或許也因為有這個功能，網站上另外還有一區「作品集」，放置各地投稿的作品、並同時列出這份剪輯影片中利用的素材清單，這算是一種「自動化姓名標示」的實驗，十分令人激賞。

不過，要特別強調一點：這個網站上的素材，並非採用創用 CC 授權！演說者表示，NHK 仍朝向選用創用 CC 條款授權的方向努力，但目前他們認為創用 CC 條款對於一般人仍太複雜，且就組織的角度來說，也希望對於條款內容有更高的主控權。雖然要不要用創用CC絕對是著作權所有人的自由選擇，不過建立太多種條款就如同有好幾套標準，對授權者來說或許比較穩當、但對利用人來說反而可能徒增麻煩。畢竟，如果我已經認識創用 CC，那麼看一眼圖示就可以了解能做什麼、不能做什麼，更能加速理解。

現在說的「太複雜」，或許是在於要理解任何著作權條款，都不是容易的事情 – 但創用 CC 該鼓勵大家理解著作權到什麼地步呢？或者我們是否該揚棄現有規則、另外想一下怎麼兼顧分享與保護作者權益？這扯遠了，與之相關的議題還很多，日後有機會再與大家討論。

CC to the Museum

博物館、美術館等地方，經常可見到「禁止拍照」這類告示。這個題目的演說者是日本東京六本木「森美術館」的館長，他藉由允許大眾拍照、上網張貼展館照片並以 CC 授權的方式，成功為美術館創造口碑、也從而帶入另一種「與參觀者互動創作」的創作形式。

館長提出的一個論點蠻有趣：藝術該像是空氣一般，人人可取、人人可用而無所謂「原創者」是誰 – 這真是超激進的！但他也說，這個論點的挑戰在於如何讓創作者付出的時間與心力也獲得回饋（具體地說，物質上的回饋）– 嗯，大約就抵銷了前面那句話 :P 不過確實，只要解決後面這個問題，反對分享自己的作品的人將大幅減少。

下一篇是關於雷席格教授的演講「Open」，以及 CC 司法領域關門會議的心得。

舊文：CC 華文地區團隊訪談‏

2010-07-23T06:19:00.000+08:00

在寫這期 CC 專文時，發現去年寫的一篇忘了貼上來自己的 Blog，索性貼一下讓大家參考。文章發表時間是 2009 年 7 月，所以內容若提到什麼相對時間（例如「自去年香港推出...」），請自行轉譯一下 :P 另外我多加了一些標題，方便區隔。

自去年香港推出「共享創意」之後，華文世界已經有三個 CC 相關團隊：台灣「創用 CC」、中國大陸「知識共享」、香港「共享創意」。今年二月，台灣創用 CC 計劃前往菲律賓馬尼拉開了一次亞洲 CC 會議，筆者也趁這個機會訪問到三個團隊，受訪者包括創用 CC 莊庭瑞老師、知識共享王春燕老師、知識共享張安定先生、共享創意蘇孝恆博士，以下為各位摘要訪問內容。雖然筆者是主要提問人，但問答過程中往往也會激發其他的問題，這些都很有價值，也都值得保留，故本文的問題部份請各位讀者姑且當作討論的引導，回答與討論無需拘泥於筆者原始的提問。

組織結構

筆者 (以下簡稱「趙」)：華文區的三組團隊雖然都在學術研究機構中，但所屬單位剛好都在不同的學術領域。可否為我們簡述一下發展緣起、目前發展上的感想等等？

莊庭瑞老師 (以下簡稱「莊」)：台灣的創用 CC 計劃發源地為中央研究院資訊科學研究所，一開始是 2003 年我們在做自由軟體相關的工作，而不免會遇到許多不同種類的 Public License (公眾授權條款)，也需要比較各種授權方式的異同。當時所內有兩位同仁：舜玲和士傑知道有 CC 這個授權條款，就找我一起推動、在所內成立相應的計劃，資訊所的李德財所長也很支持，就這麼在資訊所內生根。

不過，我們畢竟是資訊科學研究所、不是法律學研究所，在授權條款本身已經開始跳脫資訊軟體範圍的情況下，要做事情就必須有比較嚴謹的理由；再者，這類將授權條款在地化並推廣的工作，比較偏重服務性質而非單純研究性的工作，所以研究機構做這件事情就有適切與否的問題；再加上CC 在某種層面上已經是社會運動的議題，在政府出資的研究單位下面對這些議題，有時也令人感到有點尷尬。

王春燕老師 (以下簡稱「王」)：中國大陸的部份，原先就有一些社群在推動 CC 相關活動，也做了授權條款文字上的翻譯。後來 CC 總部找我協助，一方面與原先推動的社群有一定默契，另外中國人民大學法學院很支持這樣的專案，我也覺得很有意義，就因緣際會接下來了。

其實 CC 找我幫忙只是因為我在哈佛時曾經幫 CC 看過中國大陸這邊的發展狀況，並協助本地化這份授權條款。CCi 那邊曾經做過一個調查，其中一個問題是「在接手 CC 在地專案前，是否想過會有這麼多工作？」我說我根本沒想到，這也差不多就是個全職的工作了；另外的麻煩是例如財務上，本地化的各項事務財源都得自力更生，CC 總部不會支援，有時就比較費神。

莊：關於這點我也有些想法，我們一直覺得跟 CC 總部的關係應該是 Partner、可以相互支援，但他們比較愛用一個我不是很滿意的詞：Affiliate。其實很多人應該都沒想到要投入這麼多，還會遇到很多意外的困難。

蘇孝恆博士 (以下簡稱「蘇」)：香港這邊是由香港大學的傳播學院開設計劃，而法學院也是共同合作的伙伴。工作量的部份我自己是覺得還可以，主要因為自己以前念的東西跟社會運動很相關，也參與開放源碼運動，對於這些事情有些了解，而且我們比較幸運的一點是作為華文區最後一個成立 CC 專案的地方，除了可以參考台灣跟中國大陸的東西之外，香港很多人在香港 CC 還沒創立之前就已經認識或使用過 CC 授權條款了，推動起來就容易很多。

趙：想請問知識共享團隊，我注意到知識共享有個特殊的「國際委員會」機制，是否可以談談這個委員會當初成立的理由、目前的工作等等？

王：其實「委員會」這樣的組織結構，在 CCi (CC International) 的文件裡本來就有列出，只是不要求各司法領域專案一定要有。在我們啟動會時，很多知名人士前來參與，其中包括像 Lessig、Fisher 等國際知名的公眾授權相關人物；當時就想，一方面是專案初期有很多事情方才草創，需要討論，我自己的教學工作也另有負擔，希望找些智囊團幫忙提供意見，也比較有力。因此，啟動會當時就問了在場人的意見，大家也都同意，就水到渠成設立了委員會，「國際」也是剛好因應當時前來參與的各界人士中外皆有。

目前這個國際委員會就是以顧問的角色存在，多少是因為大家也都非常忙碌，但更重要的是可以獲得他們的支持本身就很有意義。

名稱翻譯

趙：接下來想請問共享創意的蘇博士，在香港之前，台灣與中國大陸分別推出了不同名稱的 CC 計劃，香港作為第三個華文世界的 CC 計劃，也提出了不同的專案名稱 —— 共享創意，可以與我們談談這個名稱翻譯的經過？

蘇：一開始我們其實是覺得香港人基本上都懂點英文，也就不用翻譯了，不過後來宣傳時發現對中文媒體還是需要個中文名稱。其實早先提出的兩個翻譯我們也覺得不錯，不過還是依據香港的文化情形重新在郵件群組上發展討論。後來選定「共享創意」，也同時有識別三個不同司法領域的功能。

有個趣事是，「CC」這個詞在香港其實會跟風塵女子常用的藝名同音，當初在討論名字時也有人提出、擔心造成不良影響，不過我們覺得這畢竟是想太遠了…另外當時有一份報紙剛建立網上電視台，網址中也有CC兩個字，但到現在也沒有人混淆過。

趙：那可以請問台灣與中國大陸的 CC 名稱翻譯過程？

莊：我們本來也認為不用翻譯，不過當時的同事覺得，一般人的英文不見得都很好，況且中文其實沒有「Commons」這個概念，所以還是需要中文名稱。我也不敢魯莽決定，所以開了一次會議，召集當時較早期的 CC 授權使用者、智慧局專家、法界人士等，一起討論這個名稱。我們使用的方法是把大家想到的關聯字全部抓出來，例如「創意」、「創造」、「共享」、「公用」等，然後分別排列組合，最後就選出了「創用 CC」這個詞。我其實當時不很滿意中英混雜的名詞，不過大家討論結果可以接受，而且創造、使用是一體兩面，成為一個循環，涵意很好；「CC」就當作是識別標示，也保留下來。

王：在一開始由 CNBlog.org 的毛向輝等人負責翻譯授權條款草案時，使用的是「創作共用」這個名字，而後因為 CC 主要還是依據司法領域的觀念而非國別，於是英文名稱修改為「Creative Commons China Mainland」，而中文名稱則是在徵詢眾人意見後，定名為「知識共享中國大陸」。

中國大陸「CC攝影比賽」

趙：接下來還是想請問知識共享團隊，中國大陸這兩年推出 CC 攝影比賽，獲得不錯的迴響，我想請問關於這個活動當初是怎麼設計出來的，藉此推廣 CC 又有何心得？

王：一開始知識共享創立時，就有攝影界的相關人士前來關心相關內容，討論過後我們就決定舉辦攝影比賽，並從參與別人的攝影比賽、成立子項目開始。不過後來覺得，與其參與別人的攝影競賽，何不自己做一個全部要以 CC 發佈的比賽呢？於是我們就連繫了攝影社群「新攝影」，一起籌畫第一屆的 CC 攝影大賽。

第一屆攝影比賽經過宣傳，大家都蠻有興趣的，收件狀況也比想像中還要踴躍，竟然收了超過一萬件的作品！這讓我們很受鼓舞，且在攝影大賽結束後，中國的攝影網站有遍地開花的感覺，紛紛支援了 CC 授權協議。後來又有攝影家加入團隊，加上我們在第一屆時建立的平台仍可沿用，就決定繼續再辦。

第二屆比賽的時間點剛好搭上奧運風潮，我們把主題定為「運動分享」，而這單一個主題也收了超過三千件的作品，反應依然良好。這次在比賽期間，我們邀請知名的攝影家舉辦攝影見面分享會，且請到了非常頂尖的攝影評論家擔任評審，攝影記者也稱讚我們選出的照片品質很高。

有些較為偏遠地區的人獲獎後，覺得是很好的機會，讓當地的生活更被人看見。有人也因此建議我們，可以辦理當地采風等局部地區的活動，與當地的學校、NGO、藝術團體等合作。這些立即的反饋，都鼓勵我們繼續做下去。

張安定先生 (以下簡稱「張」)：我覺得從攝影大賽中可以歸納出兩個 CC 推廣活動的要點。首先是要選一個作品產生方式較容易，人人都可以是產生作品的社群，攝影是個不錯的目標；再來，業餘的社群裡，通常領頭的人很重要，領頭的動大家就會一起動。由於這個活動一開始就有專業社群人士加入規劃，讓活動並不是只想推廣，而更是了解社群需求後推出的企劃，同時讓「選用 CC 授權」不僅僅是價值的表達，而是有讓自己加入一個群體、進入「Commons」的感覺。

社群參與、發展目的

趙：我們知道 CC 這個運動緣起於自由軟體的 GNU GPL 等公眾授權條款，自由軟體一直很強調「社群」，社群也是推動運動發展的核心，不曉得各位通常都與哪些社群連繫？有什麼心得？

蘇：香港從一開始啟動的時候就有很多義工從自由軟體相關的社群來。此外，由於我在還沒任職 CC 工作之前也是做關於自由軟體的研究，所以跟維基百科、Bloggers 社群也蠻熟悉，他們也幫了很多忙。

王：我們有連結的例如剛剛提到的攝影社群，還有其他音樂、新媒體 (數位媒體等) 藝術家等社群，我們接下來會做些展覽、例如一百位藝術家的 CC 衍生作品展等等。

張：我覺得有一點可提，大陸太大了，要能連繫各地社群並不很容易。我們也想在今年多利用社交網路等機制，以網路連繫社群，不過現在這些使用者多為重度使用者，還是算少數。我認為要推動社會運動還是需要有活躍的成員加入，從不同的思路下手讓社群成員發揮。這部份我覺得韓國做得很好，在這兩天的會議裡也只有他們真正提到行銷與品牌的層面；他們已經進入到將商業、大眾思維包含進來，而我們大多還是屬於學術研究的範圍裡而已。我覺得要真正推廣的話非常需要社群的活躍成員協助，才能向大眾真正地推廣。

莊：這問題真的蠻困難，就創用 CC 來講與社群的連結其實做得很少，這有其原因。但我的想法是，授權條款本身還是工具，有需要的人可以來取用。我認為我最主要的工作是，某個人需要這類工具時，他可以清楚了解這個工具的優劣，進而決定是否採用。而從這個角度我就不是要去「推廣大家用 CC」，而是去告訴大家有這個工具，可以考慮是否使用。如果真的要定「客戶群」的話，我自己把目標放在政府及教育學術單位，這兩類單位連結起來對我們研究所本身的使命才比較能結合。

而作為一個社會運動，我認為真正的目的並不只是要讓原本不知道 CC 的人了解、使用 CC 而已，更是要讓 CC 帶給大家對著作權的反思，去思考目前制度上的好壞、該怎麼改變才能改善整體環境。例如孤兒著作在台灣就是蠻嚴重的問題，大家對於一些找不到著作權所有人的作品，沒有先繳法定授權金後就可使用的機制，因而不敢利用，很可惜。比起社群經營來講、我更想投注心力在這些部份。

張：每個人看事情的角度真的蠻不同，我喜歡 CC 並不是因為它的工具角色 —— 其實即使是用 CC，在大陸這邊照樣是被人家隨意侵權的，所以我進來參與的原因主要是因為喜歡他的精神，喜歡這一份態度，還有就是互聯網的開放、給人類自由文化的新機會，許多人相互分享、重混等等激發出的東西，我覺得很多人會被這個吸引。

趙：我想這真的沒有什麼對錯問題，大家分別按照自己的角度為這個專案貢獻。

張：所以是每個司法領域的 CC 團隊給自己的定位不同吧，例如莊老師剛剛談到的孤兒著作問題，我覺得這也是運動裡很底層的東西，也需要很多人去努力推動。而在我自己的定位來說，我就希望去連繫更多人讓他們認識這個精神，不是要要求別人用 CC，而是讓他們對這個精神有所感受、尊重著作權，希望藉此形成社群去推動一些變化。

王：CC 的本質上來講是自願，例如我們這些團隊對 CC 組織來說都是志願者，而了解 CC 授權後願不願意使用也是著作人自己的意願。所以就我們的職責來講，我覺得也是一直在強調我們不是要「說服」你來用這個授權條款，只是要告訴你有這麼一個東西，喜歡的話可以用，要用哪種授權也是你自己決定。當初辦攝影比賽時，(CC 總經理) Joi Ito 曾問我是不是就提供一種授權條款讓參賽者使用就好，我們還是決定讓參賽者依其意願自由挑選。所以就這點上，我覺得我們不應該有「指標」，也不需要給我們指標 —— 如果要要求推廣指標，那就說不通了，因為大家應該都是自願者的。

張：就是說，把授權條款本地化完成後或許團隊就已經達到百分之七十的目的了，而後作為在地團隊我們再告訴使用者這個東西的詳細情形，用或不用有什麼考量與風險，也就足夠了。

王：所以，如果要做一些數字上的統計，有時候我也覺得可能會有些問題。數字背後代表什麼意義，如果錯誤解讀，那把數字掛出來也會造成不好的影響。

著作權在中國大陸的狀況

趙：之前跟大陸的一些朋友閒談 CC，他們給我一個觀念是中國的著作權保護方式比較不同，剛剛安定也提到很多人基本上不管著作權保護的，不曉得在這個部份知識共享的看法與對策為何？

王：這問題我們其實也一直被問到，主要是詢問推動的重點為何，我想接下來最起碼還是會做一些著作權的教育。我們曾與一些網誌作者連繫，他們表示很多人對著作權是不了解的，而事實上之前也有案例，即使是著名的作家都不見得了解著作權。我們在推動 CC 時強調這不是讓你放棄著作權，反而是要讓你意識到你有著作權，而且你有哪些自由可以運用你的著作權。所以我們先談著作權、再談 CC。

判例？

趙：最後一個問題，就我所知日前香港曾發生過 CC 圖片的侵權事件，有公司違反 CC 授權條款而採用照片作為廣告，不曉得目前的狀況如何？台灣就我所知是沒有案例，也想請問中國大陸是否曾有 CC 案例？

張：中國大陸目前是沒有，其實我們也很想有。

趙：我們也是，很多法律上的議題其實有個案例後會容易判斷得多。

蘇：香港這邊的案例是某銀行違規使用照片作為廣告，但標示不清楚，而被民眾揭發。不過香港的公司真的很重形象，這個案子目前已經和解了，正在執行和解中的細節。

後記：這次的訪談促進了華文世界三個司法領域 CC 專案的互相了解，其實放大來說，自去年開始舉辦的 CC 亞洲會議也正是為了讓亞洲區 CC 專案交流而設的研討會 —— 這次研討會中的各項議程，筆者個人覺得重點並不是知識上的增進，而是經驗上的學習。在此也非常感謝三個司法領域成員的配合，讓我能完成這次的訪談。

附註：此內容因編排需求，並不完全依據提問的時間順序排列；另兩岸三地的語詞偶有不同，為了台灣讀者閱讀方便，盡可能改以台灣的辭彙書寫，特此聲明。

創用 CC 好簡單工作坊 — 網站與應用程式嵌入

2010-07-16T17:14:00.002+08:00

創用 CC 是創意工作者發揮威力的絕佳工具，而您的網站、程式也可以利用簡單的手法嵌入創用 CC 相關功能，協助使用者妥善使用網站、創造附加價值。本次工作坊將簡介創用 CC 後設資料「ccREL」，以及在網站平台方面的使用方法，同時探討網站平台嵌入創用 CC 的「眉角」。

總之，我們要辦小型技術 Workshop，免費、有吃的、可以幫你更了解 CC 網站整合，快來報名吧 XD 以下是其他資訊。

適合對象

網站應用程式開發者
對網站與創用 CC 結合方式有興趣者
對後設資料連結與利用有興趣者

注意事項

免費報名，還有吃的 :P
歡迎自備筆記型電腦實作，會場有網路及電源

活動內容

19:00-19:20 Greeting (創用 CC — 趙柏強 / BobChao)
19:15-20:00 RDF 與 CC REL (W3C 日本辦公室 — 呂康豪 / Kenny Lu)
20:00-20:20 實作: RDF & CC REL
20:20-20:30 Break
20:30-21:10 網站平台嵌入創用 CC 實務 (創用 CC — 趙柏強 / BobChao)
21:10-21:30 實作: 網站平台嵌入創用 CC
21:30-22:00 自由交流

報名由此去！

刀口

2010-07-13T09:05:00.000+08:00

久了之後，我開始有點懷疑是否要堅持所謂的「錢要花在刀口上」：當然浪費絕對是不好的，但缺失的「刀口」實在多到難以計數啊！每一個小東西，包括貼紙什麼的，影響力或許不是那麼容易評價的。又，我們是社群，沒有、也不會有「一定要」做的事情 -- 雖然如果你加入的是一個非營利組織的活動，那麼應該會想要為信念做些什麼的，只是若沒有、也無妨、歡迎同樂。

所以其實... 之前有人提到，「如果這麼嚴肅的話幹麼還要做什麼社群」，其實這跟我的想法完全不同，因為我自己參加的是非營利組織，不只是同樂會，只是依然歡迎想當成同樂會的人一起來玩而已。

又轉個彎，從「參加同樂會」心態轉變成「參加非營利組織」心態的人，當然也會有的，所以同樂是個開端，無須責難或什麼。你可以對一件事情非常嚴肅，但在這裡真的別「要求」大家跟你一樣嚴肅。若你想做什麼，試著說服，不是強迫，在這裡強迫只會讓人離開而已。

我真的相信，我看到的是對的方向。

粉簡單非組織帳務管理：MozTW 篇

2010-07-13T05:28:00.005+08:00

MozTW 剛成立時，對於捐款我們基本上不收，因為那時的想法是「有捐款就向軟體自由協會捐，我們真的有需要再請軟體自由協會幫忙」。

這樣的想法簡單，不過後來不太合用，因為沒有資金在手，要印宣傳品或做些什麼事情都不方便。後來在 Firefox 3 Party 之後，由於原先拉到的贊助超過預期，我們確實有留了些錢下來，幫助我們處理後來兩年的活動交通印刷、貼紙等東西。我必須要承認自己管的帳很亂，所以也的確有幾次是自己掏錢出來買經驗，不過畢竟社群經營者自己掏錢不是長遠之計，所以 2009 年 COSCUP 時便提出「這次預算無上限，不過接著就歸零吧」的想法。也感謝大家不計較，從去年開始，我們就開始採用「分散式」的方法管理資金。

簡言之，我覺得「所有的錢集中管理」沒有必要，我們手上的資源很少、也不該讓轉帳手續費來蠶食，所以管理的方式應該要能夠支援很多個帳房。為了要支援很多個帳房，我們也應該讓登記這件事情變得十分簡單，人人可學。畢竟，我們不是需要向誰報告的正式組織，大家對於錢這件事情，真正關心的是「從哪來、去哪裡、用在哪，清楚明白」而已，分科目什麼不見得是必要的。

所以我們就簡單用 Google Docs 記帳而已，另外誰有多少錢就直接用統計的。很容易可以看懂這個表：

第 2 行的「宅衣收入」等同捐款，捐款者宅衣團隊、收款者阿民。
第 5-6 行是帳務轉移的處理方式，阿民轉出予 Irvin。
第 14-15 行就柏強拿去花掉了，後面有花費的理由。

幾個問題跟答案：

是有沒有這麼窮？

有，歡迎助印貼紙啥的。

誰可以決定什麼錢該花什麼不該？

原則上在 moztw-general 提出後沒人反對就可以花，有人反對就協調。如果你覺得不該花，請一定要講出來。真有爭執的話看起來可能會是我決定 -- 目前沒有過，你看過去半年我們才因為要去 Mozilla Summit 2010 參展花了 750 元而已，節儉到不行。

捐款怎麼來？

之前有提出過一個倡議是「經由 MozTW 所來的演講、營利機會，可捐 10% 給 MozTW」，不過都說是倡議了，也不會強制就是。若有機會演講、要怎麼判定是「經由 MozTW 來」的呢？自由心證吧，另外當然也講者自己衡量一下交通費什麼的支出再決定。總之，目前你在上面看到的捐款大致上有這些理由：

合作贊助：去年 COSCUP 銷售小莎徽章的結餘捐款
演講贊助：小 B 跟柏強的演講贊助
自發贊助：Irvin 寫的 PlacesCleaner Addons 的捐款交給 MozTW 使用

所以其實還蠻歡迎大家來邀演講的，可以幫忙推廣激歡樂的網路生活、MozTW 也有錢做點事情。

可以把這一頁的權限開給我嗎？

目前不知道會有什麼影響，所以不對路人開放；如果你經常協助 MozTW 做事，卻還看不到這份表，可以跟我提一下。

有興趣捐款助印的也不用擔心，錢進錢出都會在 moztw-general 提一下。理想上你從 moztw-general 歷次錢進錢出的紀錄也該可以整理一份這種東西 XD 又，每次的動作都會有很多人看到，並不會發生捐進來的突然就不見這種事。

我覺得應該還要怎麼怎麼如何如何

可以到 moztw-general 討論，不過請謹記：不要把事情弄得太複雜，除非你要扛下來幫忙、然後別人也好遵守。

但你們不能開捐款收據對吧？

對，剛也說了這不是組織，於法我們不能募捐，所以要「直接請我們幫你印 MozTW 貼紙，然後讓 MozTW 可以送給大家的」的朋友們，看到我跟 Irvin 的時候可以塞一下 XD 部份實體活動有時也會有個花花綠綠的箱子，有興趣也可以塞... 請記得認明是我們家的，基本上都可以在摩茲工寮什麼的地方看到活動宣傳才是，活動後會即時上 moztw-general 回報。

不過如果你的捐款高於五千元，那就可以用軟體自由協會的代收機制，也就會有捐款收據囉！有興趣的公司行號也歡迎協助啊 :P

捐款按鈕，以及為何要捐

2010-06-14T04:54:00.002+08:00

因為 Kenny 拿刀子架在我脖子上要我快點放，所以它又回來了：從首頁的最上方或者每頁的最下方，你現在可以看到黃澄澄的 Donate 按鈕，點選後可以透過 Paypal 捐款給我。

為什麼要捐錢給我？其實一時間也想不到什麼很好的理由。我不像某些大大一樣功績顯著，雖然在 MozTW 社群裡待了蠻久，但程式上的貢獻一直是很少的，我比較常做的事情是：

企劃推廣活動：例如 Firefox Party、自由新生代、GFX.tw 網站、催生 Foxmosa 等，包括找錢找人。（當然也要感謝一同協力的夥伴們，只有企劃沒有執行一樣是零，是因為各位才能成事。）
協助 l10n owner 處理行政雜務，包括交接：MozTW 大概是 Mozilla 全球社群裡 l10n owner 政權轉移次數最多的一個。
推廣社群聚會：MozTW Labs、摩茲連續聚等
隨便逛逛，傳遞新資訊：如 Jetpack、顛覆網路 35 天等。
推廣 CC：但這是我有薪水的工作，請不要因為這點捐錢給我 :P

其實即使我確實不領薪做了些事情，但我從不認為這些付出是「無償」的：經驗、微薄名聲、機會，乃至於實質的好處（例如受邀到日本分享社群經驗等），我是有收穫的，這些收穫也成為我繼續、以及相信各位可以投身社群的理由之一。但無論如何，如果你確實想在經濟上幫我點忙，或者想鼓勵我一下，那麼當然歡迎各位捐款支持這些作為。

也摘與 Kenny 的對話一句：「我要先說你捐了就是我的，我永遠只會按照自己的自由意志行動而已。那天你討厭我的話，可別後悔 XD」。另外，這個捐款是給我個人的，我或許會拿來做 MozTW 的事情，也或許不會。如果你想特別捐款給 MozTW… 礙於法規，我們理論上不能讓你捐款，不過如果你堅持助印貼紙那類的話，碰到我跟 Irvin 的時候可以塞一下、然後到 moztw-general 去盯著我們有沒有昭告天下 :P MozTW 是採分散式的財務管理機制，透過 Google Docs 來管帳，有機會可以再跟大家分享這個。

快速團：MozTW 連續聚 TP 夏季特別篇，週六下午！

2010-06-11T13:10:00.002+08:00

報名網頁由此去，以下轉貼活動資訊：

啊是有沒有那麼趕，今天揪團明天出發？ MozTW 社群成員久違感人的重逢？
本週六下午 14:00-18:00，摩茲連續聚 TP 特別篇，準時放送！

地點：人性空間新生南路店

MozTW 摩茲連續聚，以輕鬆歡樂無負擔的方式、要與大家一起提升彼此的網際體驗。

候選主題

補交接？兩代 l10n owner 輪替心得 (timdream, petercpg)
數位典藏 Personas 專案現況 (bobchao. 只要 5mins)
JetPlurk 移植計畫 (littlebtc)
CSS3 font-face 字體變臉 (evenwu)
CC Asia Conference 2010 + Mozilla 韓國社群見聞錄 (bobchao)
Jetpack SDK 0.5 推廣策略 (littlebtc)
Mozilla Summit 2010 World Expo 規劃討論 (host:bobchao)

MozTW 摩茲連續聚提醒您：

歡迎乘坐大眾運輸工具

聊網路非營利組織社群營運 (1)

2010-06-03T04:58:00.000+08:00

昨天下午難得有機會再跟 Saint 閒聊一些與 Mozilla 相關的事情。或許又經過了一些時日，我終於也能再次精鍊我的想法，於是終於覺得她臉上的疑問減少很多很多，當然也可能因為鐙鐙的用語讓她稍微進入了這個世界，所以我能再更深地描述我的觀點。無論如何，對談的某些問答紀錄，混合晚上與鐙鐙再聊過的事情，希望可以分幾次整理一下，於是這是第一次：

問：企劃總需要一個目的，這個組織的目的到底是什麼？

答：其實在這個組織活動了將近八年，我對於 Mozilla 作為一個非營利組織、而非單純的「開放源碼專案」有日漸加深的認同感。Mozilla，乃至於 MozTW，真正該努力要努力的不是讓 Firefox 這個瀏覽器市佔率極大化，而是如其「使命」所說的，維護網路上的選擇與創新。不過當然，「使命」這種東西，不是能直來直往地對一般使用者說明的 -- 對於這些使用者來說，網路從來都極富創新、也有不少選擇 -- 雖然他們這麼想確實忽略了很多事情，但如果了解他們怎麼想，就能明白直接講根本不可能有用。我們以 Firefox 及其他軟體提供使用者選擇，致力促使網際網路上的良性競爭，同時確保「創新」這件事情能因為保持競爭而持續下去，讓使用者能擁有更好的網路。

因為真正的「目的」不在市佔率，所以有時我甚至會覺得，某個活動能增加多少 Firefox 使用者，隨緣就好。

附帶一提：我覺得 Mozilla 很巧妙地選擇了「平衡」這件事情（維護網路選擇與創新，都屬於「平衡」）作為使命，因為平衡並不是達到了以後就可以不用繼續努力的，反而在求得平衡後還得致力維持平衡才行，這蠻可以確保我們總是有該努力的目標、且方向不會變動。好的非營利組織使命宣言，應當如此。

問：「隨緣就好」，那效率問題呢？

答：其實就我的角度來講，讓社群成員做事情做得開心，並且願意再投入下一次，是更該關心的部份。志工不支薪參與，為的就是要「爽」。這個「爽」有很多可能，或許只是因為跟一群朋友一起做事就是開心、或許是可以提高名望、或許是可以讓自己愛用的軟體變得更好、或許是追求成就感等等，但無論如何，不爽是沒辦法持續的。

而關於我們想推廣的終極目標「使命宣言」部份，其實除了難以對一般消費者描述外，甚至難以對部份既有的社群成員描述。有的人只是要讓自己的不便變得方便，網路開放與否他完全不關心；也有人只關心技術發展方向，「技術會不會因為獨裁而失去創新動機」這個層面，他也不擔心。當然，也有些夥伴才剛加入而已，一下把這些議題丟到他頭上，只怕是難以吸收。

所以首先為了「做得爽」，我個人可以放棄效率。

不過與一般組織合作時會有問題，所以這類時候我的作法是自己接一下類似專案管理的角色，找好願意協助的兵馬、大家簽下「這個專案完全照我的意思進行」的賣身契之後，我就可以跟其他組織用他們願意的方式溝通。

與一般組織相較，我們這類社群在做推廣企劃時很像散兵在打游擊戰，而一般組織則是玩組織團體戰。

又，既然談到效率，總要有個評量方法。開源組織的推廣評量方式是什麼呢？我個人認為現在強烈依賴 SNS 的我們，要評量很難。如同我們家的小莎，什麼好友粉絲幾個人啦、每天發幾噗啦都絕不會是決定性的價值，那麼她的價值如何判斷？我與一些朋友，包括在公關公司工作的老同學討論過這個問題，我想目前應該是沒有好方法。商業組織最後可能可以用營收來算，不巧我們又沒有「營收」這件事情，那就...

總之我最在意的是社群成員願不願意因為做得開心而留下來再做一次，第二次、第三次之後，慢慢感覺這個組織想要做的是什麼，然後從任務的接收者成為規劃者 -- 因為那時他已經懂了，可以依據自己的判斷決定行為，我就不用解釋太多。

當然，偶爾還是會有些不見得那麼熟悉使命的夥伴想嘗試規劃帶兵，我覺得就開放而行即可，如果吸引得到兵來帶，就有存在的價值，有何不可？

MozTW 最近的在地化團隊狀況

2010-05-26T05:10:00.000+08:00

轉貼一下新任在地化經理 Peter 在 moztw-general 發的文章：

大家好，

這封信主要是跟大家提一下幾個 mozilla project 軟體的 l10n 現況。
Firefox: Fx 3.6.4 如大家先前所知，將會包含 OOPP，目前正在做最後的 Beta 測試，預計 6/1 Release。3.7 持續開發中。
Thunderbird: Tb 3.1 RC 1 目前正在 QA 階段，預計 5/26 會放出來。運氣好的話，3.1 正式版會在 6/1 一起 Release，否則還會有 RC2....。
Fennec: Mobile Fx 目前官方還在 1.0.1，可以到官方 ftp 去抓 1.1b2pre 的 l10n 版本，已經有 zh-TW 了。
Sunbird/Lightning: Sunbird 0.9 會是最後一個公開放出來的獨立行事曆軟體，未來會以 Lightning 的形式，作為 Tb 跟 SeaMonkey 的一個擴充套件。 Lightning 目前的版本是 1.0b1(沒有 zh-TW 版本)，對應 Tb 3.0；如果你已經開始用 Tb 3.1 了，一樣也可以到 FTP 去抓 1.0b2 的 Lightning (已有完整 zh-TW 翻譯)。
Firefox Sync: 以前的 Weave Sync 已經改名叫 Firefox Sync，就前幾天的討論看起來應該這個禮拜內就會放出 1.3，當中就會有正體中文的翻譯了，這部分有不少要感謝 bryanyuan2 跟 whaleinblue 所貢獻的翻譯。

L10n Dashboard 轉到 https://l10n-stage-sj.mozilla.org/dashboard/?locale=zh-TW 了。

六月初前後會放出來的東西不少，最近大家有空的話可以到 ftp.mozilla.org 或是 nightly.mozilla.org抓檔案幫忙測試一下，如果有問題就喊個聲吧。

另外，l10n team 持續徵人中，歡迎加入~

因 Google TV 來的雜想

2010-05-21T01:15:00.003+08:00

現在 Google I/O 正在秀 Google TV。說實在很多點子你我也想得到，更別談那堆機上盒和 Apple TV。創新是如此的，一步步搭上，奠基在過去的生活體驗。所以你可以同時搜尋頻道、節目、網路了，你也可以（當然可以）同時上網並用子母畫面看電視。

如果你必須要登入 Google 才能看電視，不意外 XD 而且別忘了你家的電視會當機，偶爾還要擔心有資安問題（把你昨天看過的節目資料竊取而去），或是病毒（…播送不該看的東西？）。

我經常覺得解決舊的問題時，總又要面對新的挑戰。

Don't get me wrong, 用電視作為資訊接收系統一直是我很有興趣的事情，我甚至還有想過要買 Apple TV，剛也覺得 Google TV 不貴的話就很想要。講個有趣的體驗：我的 Flash 常會掛點，特別在全螢幕時，所以後來很習慣地不開全螢幕。因為要邊看 Google I/O 邊寫 Blog，我把電視接上了電腦、將 Google I/O 直播丟上電視螢幕。由於不開全螢幕、所以影片看起來很小 -- 我迅速地按了 Crtl 與 plus，將整個頁面放大 -- 不管網頁放大的技術一開始所為何事，但我這樣用了，而且相信當一個工具除了原本的功能外、還能以創作者沒想過的方法被使用，便是極為成功的工具。

這世界有網路還是很棒的，剛跟人在日本的 Kenny 用 Skype 聊了網路標準的事情，然後上 YouTube 看遠在美國的研討會直播，用 Plurk 跟大家討論（且根本不用管他們在哪裡）。我們還是應該活下去繼續看看會變成什麼樣子，只是為了好玩而已。

Breaking: Download Firefox nightly and try WebM!

2010-05-20T01:32:00.006+08:00

如果你是個關心網路影音發展的開發者，那麼快去下載今天的 Firefox nightly 吧。

方才在 Google I/O 上，Google 終於確實做了大家期待他做的事情：開放 OGG Theora 的同門師弟「VP8」的編碼專利，成立 WebM 專案。目前有包括 Mozilla、Opera 以及想當然爾會相挺 Google 的一些軟硬體廠商為這項計畫站台，這很可能一舉終結目前 HTML 5 中 VIDEO 標籤的編碼大戰。

YouTube 已經開始提供 WebM 的 HTML5 版，首先以支援 WebM 的瀏覽器（例如剛剛請你快點去下載的 Firefox nightly trunk）開啟 www.youtube.com/html5 點選「Join HTML5 Beta」，搜尋影片的時候在網址後加上「&webm=1」即可。目前我還沒辦法測出來，但相信很快就可以玩玩。接下來等 WebM 的硬解晶片上場，我想這場小戰役就可以宣告終結了。財大氣粗有財大氣粗的玩法，看過富豪刑事的人一定很了解啊！

source: http://genta63034.exblog.jp/2922270/

不過還是真的要說句感謝咕狗大神，總算我們可以確保網路持續開放。

近期投影片

2010-05-16T04:30:00.012+08:00

最近走闖江湖的次數不少，投影片也依慣例會丟出來。由於簡報室的網址相對長、難記，所以我通常會說「找我的網誌，我會貼上」，但常忘 orz 今天索性一起來吧！標題是連到簡報室，如果只是要看投影片的話不需要連過去。

雜談著作權、公眾授權

在台北市大的演講，兩小時。基本上延伸「著作權在你身邊」的內容，但加上「實際體驗 CC 創作」的部份。這是易原的建議，其實效果不錯耶，以後可以再試著用不同方式表達看看，大家實際動手會更有感覺。

著作權雜談

Sampling and Copyright Issues

Simpling and Copyright Issues

COSCUP 議程組廣告

既然要徵求 UX in OSS 的講題，那麼就來衝個 UIGathering 吧 :) 其實我這幾次都有參加啦，但倒是真沒想過能有機會拿到這個場子的麥克風。感謝阿修、XXC、David 及 UIGathering 全體成員的協助。

我這週三還要在 HappyPlanner 打一次廣告 XD 內容會有一點點不一樣啦，因為會去的人好像有可能重疊到。不過說實在，如果不會重疊、我就不需要去了。

COSCUP Call for Papers is now open

投影片製作趨勢

又，我發現近期自己製作投影片有三個趨勢：

動畫大量減少

我習慣搭配動畫來表達抽象的東西（相信我，我用得還不錯，不會像這樣。）不過，因為之前升級 OpenOffice 之後動畫好像都會「破碎」地出現，圖片有時也缺角，乾脆順便配合 Slideshare 不支援動畫這件事、就少用了。現在用投影片的切換來處理過去想用動畫展示的東西，例子可以看這次「雜談著作權」的簡報，我把過去討論「衍生著作的授權方式」問答題都改成用切換的就能看了，所以以往用 Slideshare 看不懂那幾張要表達啥的，可以再看一次 :P

這件事間接造成下個現象：

張數爆炸多

我仍愛用 takahashi.xul，不過因為圖片的長寬比設定相對麻煩，而且我又很偏好用圖片建立聽眾的視覺感，所以有時間的話還是會用 Impress 刻投影片。結合高橋流的想法發展自己習慣的演說方式，感覺最近節奏抓得都不錯，已經比較不會發生那種明明給我半小時但只講了十分鐘的事情 (不堪回首的黑歷史，還是有忠實放在簡報室)，所以看到兩百頁請不要太驚訝，真的講得完。

PDF Ready

剛也說了最近升級 OO.o 發生了些麻煩，可能是顯示卡驅動程式的問題吧，懶得處理（反正半年就隨 Ubuntu 升級重灌一次，該灌 10.04 了…）。有鑑於此，為了避免發生投影片無法顯示的慘案，我終於也養成了輸出 PDF 的習慣，現在每場簡報的投影片都是 PDF Ready 了！同時，也是因為單純餵 ODP 給 Slideshare 所出來的字型很醜，所以也改成 Slideshare 一律放 PDF、而原始檔 ODP 就放簡報室。顯示效果確實是好多了。

人會影響工具的形成、工具也會影響人的習慣啊。

你能不能擁有一個音符？一個字？

2010-05-05T07:21:00.000+08:00

網際網路的出現助長許多現象，在要求傳遞速度的同時，我們也越來越能接受片段、或者不甚精確的訊息。而現在噗浪當紅，大家不斷將自己的生活化為 140 字內的句子向外發送，類似於轉貼文章的「轉噗」工具也隨即出現，協助大眾傳佈消息。說到「轉噗」，既然大家已經知道為了尊重著作權，轉貼文章前應先取得作者同意，那麼像噗浪這樣短短 140 字的篇幅、內容或許只是一句搞笑的話語，著作財產權是否也應該被保護？

寫了文章，你就擁有那篇文章的著作權；譜了曲，你就擁有那段旋律的著作權。這些事情在已經習慣著作權的我們眼中天經地義，看起來「要不要保護」好像沒什麼好討論的？但是，由於著作權其實是法律賦予個人的權利，於是在討論「是否應該被保護」前，更基礎的問題（居然）是：「這麼短的篇幅，能不能視為著作權法中所謂的『著作』？」

就中文來說，其實 140 字並不短：七言絕句加起來也才 28 個字，看起來 140 字似乎是十分有「資格」擁有著作財產權？那麼我們把角色換成英文好了，140 個「字母」其實一句話就講完了，一句話能不能擁有著作權呢？更誇張點，有個網站提供舉世最微的微網誌，只能輸入一個字！即便只是一個字，就中文來講也可能是「累」、「餓」、「睏」等能完整表達意涵的東西，能不能擁有著作權呢？

當然「一個字」要擁有著作權是誇張了，要是真的可以、那我們隨便寫一句話可能就侵犯了七八十個人的權利；簡單的「我吃飽了」、「今天天氣真好」等常見語句，也八成不會被視為需要保護的著作。話說回來，從別人文章中僅僅利用一個字的機會不多，而從別人的音樂裡擷取一段旋律、一個聲響的例子卻不少，此即嘻哈風格樂曲裡十分常見的「取樣」。幾年前台灣著名的連續劇角色「劉文聰」有許多經典的台詞，就曾被創作者利用來拼湊成饒舌歌型式表現，當時也有不少人設定為手機鈴聲。像這樣的曲子，聲音取樣自連續劇、再混搭自己譜的旋律與節奏而成，是十分富有創意的行為 -- 但這樣有沒有犯法？有沒有侵害別人的著作權？如果擷取一句話不行，那麼只取一個不到一秒的鼓聲呢？

每個問題的研判都會找出另一個問題，這其實突顯了一個與「合理使用」十分類似的狀況：是否為著作，在法律上來說有時不是你我說了算，而變成得到法院面對法官才有定論；著作的「篇幅」，也連帶影響了合理使用判定準則中的「使用量」一項。

明天 (5 月 6 日) 晚上，城市遊牧影展的主題影片「Copyright Criminals」正是要討論這個問題。這部紀錄片訪問了許多音樂創作者、唱片業者、律師，帶我們從創作、經濟利益、法律等方面角度來檢視這個議題，創用 CC 的發起人雷席格教授也在片中發言描述他的看法。撇開這些嚴肅的事情不談，其實這也是一部適合音樂愛好者的電影 -- 除了片中有大量嘻哈風音樂穿插之外，影片剪輯方式也頗具拼貼風格，在視覺與聽覺上都能帶給觀眾豐富體驗。如果你對這個議題有興趣，或者單純喜歡紀錄片、喜歡音樂、喜歡創作，明天晚上可以藉此機會前往華山藝文中心參與這場盛會（台灣創用 CC 計畫也會出席喔）。

這就不叫置入性行銷了，明著推薦啦 :P

最後來個有趣的問題：剛剛提到「利用一個字的機會不多」，那如果我像很多漫畫、電影裡的罪犯一樣，從報章雜誌及平面廣告上剪裁各種不同文字，然後拼成一篇文章發表，這樣是否侵犯了別人的（任何形式的）著作財產權呢？請到噗浪，用 140 字內的篇幅回答 :)

演講：電書也嘻嘻

2010-04-25T22:21:00.001+08:00

在台灣數位出版聯盟的「數位出版版權講座」發表的 CC 介紹演說。由於對象是「傳統上版權的掌權者」，所以我的內容也稍微做了點調整，主要想傳遞的訊息是「思考加速流通的營利方式」。創用 CC 鼓勵的是流通，並且經由大量流通與混搭拼湊，讓大家的創意發揮最大的作用（影響力），但 DRM 如我們所知，早已脫離原本所說「管理」的層面太遠，而十分關心的是「限制」… 或許這不是唯一的道路？我相信不是，限制流通永遠只會是限制，不會再開創新的東西出來。如果要把餅做大，如果真的相信 Content is king，我們更應注意藝術創作原先的力量：表達、傳遞意念。總該有人把這些東西的經濟價值找出來吧？屆時我們就不用再封這個鎖那個還要擔心被破。

不會有什麼叫做「好的 DRM」這件事情，除去他的本質原先就是限制之外，火雲邪神也告訴你天下武功無堅不破、唯快不破，只有不斷更新的 DRM 才能確保（短暫時間內）無從破除，那所以數位內容擁有者只能跟著那些創作 DRM 的廠商不斷花錢更新嗎？一年砸在 DRM 技術研發上的錢，到底值不值，是有沒有人算過這個錢坑到底多大、還是買了就覺得安心了？「有 DRM，著作財產權所有人才覺得自己的權益受到了保障」，真的覺得他們大部分只是這樣想 XD

當然，要求大家尊重著作權，也是應該推行的理念，不過這不是哪個要先的問題，一起吧？不兩邊同時跑，只是失衡。

同事提到我沒有把一些例如平行授權等的主題放進去，但我倒是刻意不放 ─ 演講的目的不在於聽眾要「會」，只需要他們抓一個概念就夠了。當然，我並不是很有把握自己想講的能正確傳遞，但當我提到「該來想想怎麼藉由加速傳遞讓大家獲得合理利益」，且聽眾點頭時，我想我至少成功地賣掉了我的產品，那也就夠了。

由於是一次場合比較特殊的簡報，所以想談的改良點其實很多，不過因為還有一大堆事情在排班，等之後再說吧。先把簡報丟出來，原始檔可以在我的簡報室下載。

電書也嘻嘻

View more presentations from Bob Chao.

據說這次演說有錄影，或許錄影出來後有空我再來回憶一下自己想講什麼…

台北的 MozTW Lab，都在幹麼？

2010-04-21T04:59:00.001+08:00

集合一下回答 Toomore 的 tweets，整理成這篇：

台北這邊的 Lab 從來都不是為了有什麼目標或者要作什麼事情而聚的：進「研究室」做各自的事，有新消息聊、有困難找人討論，但不需要有統一的目標。

事實上，本來 MozTW Lab 最原始的規劃，就是刻意地不要有集中式的目標。大家不出來見面的理由，有一部分是「有事情要忙」，但其實一起做事可能更容易解決問題，不如來一起忙好了？有忙也可以互幫。

那所以到底為什麼要來？或許你可能經常需要別人的意見、或者你只是想跟大家聊聊天、或者東西吃不完知道那邊有人可以分，啥的。當然，你也可以當成來上 MozTW 的班，不過至少原本「我自己」的設計就是「隨便你」，不是一定要如何。

強調「我自己」，因為那是我在做事的方法，而別人怎麼做，只要有人願意附和、我通常沒什麼意見，也覺得沒什麼立場有意見 -- 若真有意見，我自己會想辦法參與並更正問題。

當然，表達也是種參與，但單向的表達比較難改變什麼就是了。

對了，小莎請不要推這篇，嚴肅過頭了。小朋友也不必想太多，負責來玩就好 :P

演講：著作權在你身邊

2010-04-14T20:17:00.000+08:00

今天下午在淡水的聖約翰科技大學參與校園著作權講座，我把之前的「創用 CC 介紹」及誠夏在自由新生代的「網路著作權法」兩相結合，拼出一個大約 80 分鐘左右的內容。演講的資料，包括投影片原始檔、影片下載連結等，都在柏強簡報室。 (小辣，看到了嗎？ XD)

著作權在你身邊

View more presentations from Bob Chao.

這次的演講機會是從洪朝貴老師那邊轉來的。我十分重視，因為之前跟洪老師聊天的時候，就有提到一個重要的想法：校園著作權講座應該還是要多講點「可以怎麼用」的事情，而不只是「不能亂用」。雖然就我搜尋的資料來看，許多演講者，例如益思科技法律事務所的律師先進們、OSSF 的誠夏大人等，都已經做得很好，但似乎仍不是多數？也或許是我就在創用 CC 工作，十分理所當然地認為這是必然要提到的項目，所以看到別人的簡報沒有、就有點遺憾。

當時洪老師就提到以後會轉介相關的演講機會給我，也要我把過往講過的資料整理起來（因此有了柏強簡報室）。這回是第一次的實驗，內容讓著作權與創用 CC 各佔一半左右；其實架構跟誠夏之前在自由新生代的演講相差無幾，只是改用我自己的風格而已。

這次演講的內容盡可能地避開法條，關於著作權無形財產、著作人格權、不保護的著作類型等，則僅口頭描述不予細談。這或許會造成一些模糊與不確定，不過我這麼想：演講是追求聽眾在概念上的理解，而不是詳細的認知。既然橫豎聽眾一旦真的得碰到著作權法時，都得回去查法條，那我只講大概念，應該更有助於吸收。

況且我不是律師啊 orz

演講過程算是順利，回來看了一下照片，到場者約六十人左右，反應還不錯，而睡倒率約 10%，可以接受。有鑑於準備新版投影片的過程中不斷感到受前人庇蔭良多，一度想直接放棄所有權利就算了，但經考量還是沿用姓名標示-相同方式分享條款授權公眾使用。若對於內容有什麼想法，也歡迎留言指教。

又，柏強簡報室疏於整理，中間有些演講紀錄還沒有登記上去。從這次起，我打算試試「預先」建立頁面，一旦約定演講之後就到簡報室開一頁、甚至構思的過程也公佈出來，所以各位看官已經可以從那邊看到接下來部份演講的行程，有什麼建議歡迎一起討論啊！如果你在找 Mozilla、Creative Commons、自由軟體、著作權等相關資訊，或可考慮去挖挖看有沒有什麼玩意可以直接用。

FreeSound 要求使用者登入後才能下載音樂，是否違反 CC 精神？

2010-04-03T10:25:00.001+08:00

Update: 我在創用 CC 的 Blog 上發表了這篇文章的修改版，主要加上分段標題、補充關於台灣創用 CC 計畫成員的回應引發的想法等，這邊的文章已經更正為最新版。

以下想法僅為個人想法，並且如你所見，有很多「如果 A 成立、則 B」的推論，是可以試著去辯證 A 不成立而整個推翻的。（當然，本文也不代表台灣創用 CC 計畫立場。）

前情提要

FreeSound 是一個 CC 音效網站，大家將自己以 CC 授權的音效檔上傳，也可以從該站下載別人授權的音效檔。FreeSound 要求你在下載音效之前先登入，這也代表你必須先註冊、不註冊不登入就不能下載。上週創用 CC FAQ 重整會議時，我們提出的疑問是，這是否違反 CC 精神呢？

我們都承認必須登入才能下載並不夠方便，甚至也提出「這是否屬於一種限制散佈的數位機制（如 DRM）」的想法。如果這屬於限制散佈的數位機制，那麼此一舉動原本就違反 CC 授權條款了！

這個問題一直延續到昨天的例會，開會時我支支吾吾，無法為自己「FreeSound 要求使用者註冊後才能下載，並不違反 CC 授權條款」這點提出很好的講法。不過，大概是夜晚讓人比較容易思考，晚上突然覺得，好像知道為什麼自己一直覺得這樣的論點不合理了。

我的想法 (1) 被授權人無散布的義務

公堂之上，容我比喻一下：

柏強創作了一個音樂檔，並且決定要以「創用 CC 姓名標示 3.0 台灣版」條款釋出
柏強將此音樂檔交給小強
小強有義務要將此音樂檔散佈給他人

我相信 1 跟 2 不會導致 3，因為小強此時「有權」將音樂檔散佈給他人使用，卻沒有「義務」必然得這麼做。即便是有「相同方式分享」元素的條款，都是限制「改作、並散佈時，需以同樣條款釋出」，卻不要求別人只要改了就必須丟出來，更不論「改了自己用，完全不散佈」這點其實還蠻可能符合合理使用的。

如果我的想法是對的，那麼其實 FreeSound 的例子就可以是：

作者創作了一個音樂檔，並且決定要以「創用 CC 姓名標示 3.0 台灣版」釋出
作者將此音樂檔交給 FreeSound 網站

假設最初柏強跟小強的例子我們可以同意 1 與 2 不會導致 3，那麼就當然也不會從 a 跟 b 導出「FreeSound 網站有義務要將此音樂檔散佈給他人」的結論。這邊甚至不需要牽扯到使用者條款（ToS）的問題，即便把 FreeSound 當成一個利用人，也不會有什麼問題。

我的想法 (2) 網站使用條款介入

又，講狠一點的例子：

甲. 柏強創作了一個音樂檔，並且決定要以「創用 CC 姓名標示-非商業性 3.0 台灣版」釋出（請注意多了「非商業性」的條件）
乙. 柏強將此音樂檔上傳到 example.com
丙. example.com 要求別人必須先付費，才能下載這首柏強的音樂

若有這樣的例子，我十分相信在「乙」這一步時，柏強必然同意了 example.com 的使用條款、條款裡也必然有關於「丙」這個步驟的相關約定事項。此時，「丙」肯定不違反任何 CC 條款（因為在同意 ToS 時，等於柏強跟 example.com 額外約定允許商業利用），但我們能不能說 example.com 違反了 CC 精神呢？

雖然我很努力不要碰觸到「是否違反 CC 精神」這塊（理由容後再述），但我相信答案是「並不違反」。允許權利人與利用人額外約定超越授權條款的事項、以免除授權條款的條件限制，正是 CC 允許的彈性，也因此更體現自由選擇這一點。

或許有個爭議是，example.com 是否不該制定這種 ToS，要求使用者必須授與其商業利用的權利？其實我想這也不是問題，畢竟沒有人押著柏強把檔案傳上去，柏強當然有很多選擇，包括自己架站來散佈、傳到別的（沒有這項約定的）平台等等。利用別人的服務，就守別人的規則 -- 我相信這也是 CC 的一部分。

我的想法 (3) 在使用條款介入後，可能衍生的問題

但「甲~丙」的例子裡再加上這種狀況，我就不很確定會造成什麼影響：

丁. 他人從 example.com 上下載的、柏強的音樂，是經過 example.com 加工、放入 DRM 機制阻止散佈的檔案

這種情況顯然有點麻煩：若該音樂檔以 CC 授權、就不能相容於「會阻止散佈的 DRM」，這是在授權條款裡已經寫好的東西、無可妥協。我想這種狀況下，example.com 或許可以主張網站與柏強間完全依據 ToS 行動、無視 CC 授權（請想做是種平行授權，柏強在同意 ToS 後等於與 example.com 另行訂立了完全不同於 CC 的授權條款），因此網站有權加上 DRM 機制而不致違反 CC 授權條款。但這時，我就不確定柏強能不能對大眾說從該網站下載的音樂將以 CC 授權了，這邊畢竟有衝突。

結論，與隱藏的前提

總之，我的主張是 FreeSound 要求使用者必須先註冊登入後，才能下載別人以 CC 授權之音樂檔的行為，並不違反 CC 授權條款。如果這樣的推論正確，那我們甚至不需要處理「限制需登入，是否屬於在著作中加上限制散佈的數位機制」這點。

我在內部發這封信闡述我的論點時，易原跟莊老師的回應提醒了我，上述都必須先建立在「柏強是此音效檔的創作者，握有此音效檔之權利」這個大前提上，若上傳檔案者並非權利所有人、那麼很可能打一開始便無權就此著作簽署網站的使用授權條款。

與此相關、或對立、或衍生的各種討論，在台灣創用 CC 計畫裡還有一些；我先以本文描述一下我的看法，當然也可以期待同事提出自己的觀點、充實一下我們家網誌啦～當然我也很希望聽到讀者您的意見，目前台灣創用 CC 網站還沒有開訪客留言（新版寶莉已經在處理中、並有規劃討論功能了），如有想法，歡迎到創用 CC 討論室，或我的網誌留言。

CC 精神？

剛提到我盡量不想碰到「是否違反 CC 精神」這個問題，我對 CC 有這些想法：

較 GPL 等自由軟體運動，CC 提供權利人更多種彈性，藉此邀請權利人釋出部份權利（相對就是僅保留部份權利）與他人共享。
CC 試圖以定型的條款、易懂的元素，降低權利人與利用人在法律上的認知負擔；在複雜度降低的情形下，希望權利人更願意給、利用人也更敢拿。
所以，CC 如莊老師曾說的，是為了促進流通而存在。我想更擴張一點說：CC 希望所有的創意都能發揮最大威力。（我承認這是我投影片裡的話 XD）

但其實我不能保證我的想法跟你一樣，我甚至不能保證我的想法與雷席格教授完全相同。這無所謂，因為除了這些比較抽象的東西之外，我們可以真實地拿授權條款來實踐我們的想像。無論我們對 CC 的想像如何，我們至少可以同意這些已經化為嚴謹文字的條款是我們的公約數（若不是，我們就會在下一版修改，或是選擇不支持），因此我可以拿「精神」這件事情要求自己、或許再加上自己所屬的組織，但若要與外界對話，講條款應該是比較可行的。

要是 CC 只是個倡議精神的組織、而沒有提供這些授權條款，那就我個人觀點，這是個只有口號卻難有行動的組織，我可能就不會支持。

Why so serious?

2010-04-01T05:36:00.001+08:00

有兩件跟 Firefox 相關的事情，我的意見可能跟你相左，所以我描述一下自己的看法：

Firefox 佔有率上不去是退步的象徵？

Firefox 的全球市占率在 25%-30% 之間停了一陣子，有些人覺得這是個問題，表示 Firefox 進步緩慢、將被後起之秀追趕過去。

我曾說過的話：

如果拿到 10% 成為關鍵少數，也就算達成任務了。
如果是 Firefox 佔有率過半，我覺得反而才是要擔心的。

以現況來說，IE9 是肯定會有非常不錯的進展，但吃掉的可能是 IE6-8 的市場；同樣，Google Chrome、Opera 等市占率提昇，吃的也是 IE6-7 的市場 ── Firefox 只是之前狂咬了好幾口、現在吃的速度減緩而已，他自己的市占率沒差些什麼。

因此，多方共享的天下、是可以預期的。或許 Opera 終將拿到 10%、或許 Google Chrome 哪天也奪得 30% 與 Firefox 平起平坐，但多方共享是必然結果。只有下面兩件事情，才會讓我擔心：

Mozilla 不再進步了：若然，我八成會比只看佔有率就講話的人先知道，而且自由軟體社群是支持好的軟體、他不行了我們就分支出去，不會有人跟他客氣的。
雖然其他瀏覽器佔有率上升，但吃的都是 Firefox 的市場、而非 IE6-8：那表示 Webkit 及 Opera 陣營推廣的策略完全與「維護網路標準」無關了。

因此，佔有率重不重要？其實破一定水準之後，就不太重要了，只有要拿去唬一下的時候才會看。

瀏覽器的速度十分重要？

瀏覽器的速度本身當然重要。因應網路未來發展，瀏覽器繪製頁面、執行程式的速度是越快越好。

但是做為我的角色而言，比較誰快誰慢，根本不重要：所有瀏覽器將越來越快、直至不分軒輊而人類感覺不到差異，到那時你比較兩個瀏覽器間的毫秒差距，是否有用呢？我懷疑。

又，速度是影響使用者選擇軟體的一環，卻一直不是全部。使用者關心的是足夠、而不是最好，要不然 IE6 早就退出市場了。

「好不好用」除了速度之外，還有很多因素啊！

Mozilla 2010 年第一季網路現況統計

2010-04-01T05:06:00.000+08:00

昨天（或說不久前）Mozilla 發布了 2010 年第一季的網路現況統計報告，當然內容大部分與 Firefox 有關、即便無關也是以 Firefox 蒐集的，必然有所限制、但仍可參考。內容要點，茲列如下：

佔有率

經由很多網站來的綜合評比，Firefox 今年首季的全球瀏覽器市場佔有率約為 30%
亞洲區約為 26.6%，而歐洲區毫無意外以 39.2% 拿下第一名 -- 扣掉南極洲（80%）的話 :P
Fx 佔有率最大幅成長的地區為義大利
關於佔有率，我隨後將另寫一篇來說明一下自己的看法

使用人數

最多的還是美國
俄羅斯過去一季的使用者人數成長了 20%，嘖嘖。「巧合」的是，Mozilla 基金會的主席 Mitchell Backer 訪問俄羅斯時，Firefox 下載量一時大增。

以美國人來說，哪裡的人們最早起工作？

用瀏覽器開啟時間來算，夏威夷人最早起（或者最宅、宅到早上起來第一件事情是開瀏覽器上網），最晚的是紐約。但我個人覺得這個統計方法還蠻有爭議的 :P

哪裡人最愛妝點、自訂自己的瀏覽器？

要妝點，最輕鬆愉快的方法是 Firefox 3.6 內建的 Personas。單以此來看，南美洲的人最愛妝點（超過 20% 的 Firefox 3.6 使用者用了 Personas）、非洲（低於 15%）最不愛。
又或者用使用 1 個以上的套件來算，這時亞洲人反而是套件的高度使用族群，有接近 2% 的 Firefox 3.6 使用者使用套件，成為第一名 -- 還是一樣，扣掉南極洲（超過 4%）的話 XD
超過 4% 是什麼意思？南極上面只有大概 1000 個人，而一月起的套件下載量為 538 次。

使用者通常都開幾個分頁？

TestPilot 日前對上萬名志願參與者做的調查結果顯示，大致上一次約開啟 2 到 3 個分頁左右。
這個調查中的最高紀錄是平均 675.6 個！
BlueT 應該沒有來得及參加這次的調查，有興趣參加日後調查、不花腦筋就可協助 Mozilla 改善易用性的各位，別忘了去下載 TestPilot！

詳情

這份報告的簡報以及圖表可以在 Mozilla Metrics 下載。

我們社群的款項，適不適合交給軟體自由協會代收？

2010-03-31T14:21:00.000+08:00

您的 FLOSS 社群要良善地經營下去，無可避免會遇到錢的問題。事實上，個人早期在 MozTW 的想法是，能不碰錢就不碰、想捐的統統捐給 SLAT 等單位，因為我需要時會跟他們伸手；不過，這樣的型態終究會在社群需要擴大發展時遭遇瓶頸，例如：

您知道嗎：目前除了 Firefox 3.5 mini party 外，所有的 Firefox Party 都是在活動前一個多月才開始籌辦的。為什麼？因為不知道能不能找到經費來辦。
各位拿到的貼紙其實不算什麼大錢，但由於個人並不喜歡出力的人還得自掏腰包的行為，所以以身作則不捐錢給 MozTW 的情況下，我們連印個貼紙都要想看看經費哪裡來，並且不確定這錢是否該花。如果有常備經費的機制，就能夠評估可行性。

即便不搞這麼大，有時您可能還是會希望能辦點活動什麼的，~~宣揚國威~~增加曝光來招募新血。那麼說辦 30 人的中型聚會好了，假設原先的計畫是讓參與者自行付費攤平成本，那場地食物的訂金付下去、就會開始擔心是不是真的能拉到 30 人來… 何必把時間浪費在這種地方呢？有風險管理概念的話就可以比較放心做事，而要做風險管理、先知道有（或可能有）多少資源可以消耗，也是需要的吧！

如果可以讓社群有公款的財務機制，這件事情可能就方便些；有了公款之後，接著就會想到錢要怎麼進入的問題，常見的方法當然就是呼朋引伴齊捐款啦！這時會遭遇的麻煩是，因為社群通常沒有非營利（或營利）的法人組織可以合法收款、開收據，延伸出的問題包括捐款人無法享受稅務減免、道德公信有瑕疵等等。當然，申請個法人就可以解決這個問題，但多少會需要把有形無形的資源消耗在維持法人體制運作的事情上，我們也不能奢求每個社群都有能力與意願經營法人。那怎麼辦？

軟自協的代收辦法正是為此而來。由軟自協以法人的身份，出面代替您的社群收款、開收據，然後協助您依據合法的報帳流程、以較有公信力的方式把錢花到原本想花的地方。目前我們社群已經順利使用過一次這個機制，讓台南某印刷廠的老闆能在贊助 MozTW 印貼紙的同時、也享受一下折抵稅款的優惠。

思考是否交給軟自協代收，當然有很多包括信任關係在內的考量，不過除了這些我什麼也幫不上忙的思量外，您應該會想要了解「某類捐款，適不適合這個代收機制？就算適合好了，在現行辦法上交給軟自協代收，會對我造成什麼麻煩？」這就是我可以回答的問題了！事實上，剛剛正是回答了某社群的來信，我才發現寫一篇這玩意好像不錯 :P 以下其實改寫自我針對此問題的回信，打些馬賽克、並且補註一些要點。在確定信任軟自協、想尋求軟自協代收款項後，輪到代收辦法上場向您提出一些問題：

這次的收費，是營利行為嗎？

營利行為的定義請自由心證… 我的定義是「除了打平開銷外、目標是小賺」。

如果是，那麼其實由公司來收比較好… 事實上，是「才可以」，因為軟自協收到的費用必須有合乎規定的報帳方式，不然還是會被課稅。如果社群這次的收費是會讓某人有一定利益，那這塊利益的部份想來是無法有合乎規定的報帳方式滴～

代收是哪類款項？

反正名義上一定是捐款，這沒有問題。

以這次被問到的例子來說，算是中型研討會的報名費。其實若是報名費，那麼既然當場收了錢就好、且不是營利行為、隨手付清款項也就行，原本就不會有稅務問題，給軟自協代收的理由就大概剩下收據跟人工問題吧。不過軟自協目前不代收單筆不足新台幣 5000 元的捐款，所以也沒辦法省人工，於是除非您的研討會每人入場費要 5000 元，否則此路不通囉！（每人要 5000 元的研討會是租到什麼場地請到什麼講師啊？軟自協講師費只能報每小時 1600 喔！）

但，如果是「由軟自協出面，代表貴社群收企業的贊助款」，那蠻適合的，軟自協的代收辦法就是為此而存在。不過這樣又要考慮另一個問題：

錢會很快花掉嗎？

目前的代收辦法中，最大的缺點是捐款必須在一個月內，依據軟自協的規定，花掉並且提供合乎報帳原則的憑證 ── 事實上，打一開始您申請代收款項，就必須說明這筆款項要用在何處、讓協會協助您用合乎規定的方式報帳。這個期限最多延展至三個月。

也就是說，如果想要「存著等以後用」，那依據規定來說軟自協幫不上忙。我自己也參與社群，當然知道社群會有這方面的需求，不過此辦法推行初期，為了避免搞太大有什麼問題沒考慮到，在各方面都有一定的限縮，例如只收 5000 以上的款項這點也是，還請多擔待。

當然如果社群要作內外帳，那軟自協橫豎是不可能知情，不過就有法律與道德上的瑕疵，責任請自負。

我自己蠻希望在我理事任期滿之前處理完「接受小額捐款」及「捐款流入社群專款帳戶」兩個問題（然後就卸任 XD），不過人很懶，需要有點動力。有興趣一起討論、或具有這方面的法律知識者，找個週一晚上來生態綠一起聊聊吧 :)

關於電子書，需要整理的雜感

2010-03-31T06:11:00.000+08:00

真的只是雜感而已，有鑑於現在的時間詭異，我想我不要花太多時間整理比較好，但需要把想法早點丟出來免得後來太懶。

關於電子書標準進度報告

對於最後選擇 ePUB 的決策我都表支持，其實目前的狀況、這也夠了。畢竟，我們什麼也沒有、同樣也沒有必要在這個時間點奢求一個解決各式需求的規格，那麼選一個開放、已被證明堪用的規格即可。
規格的中文說明很感心，好感度++
中文的簡繁互轉一直都不是「對應表」就可以解決的事情，這有點麻煩。尷尬的是，我想我們很快就會熟悉各種簡體字（實際上很多人，包括我，已經是了），那麼或許簡繁互轉屆時不過是為了參考、以及看起來爽，就不會要求正確的字義對應。這是悲觀了點，要是真有好方法、能處理「我下面給你吃」這句的狀況，也是樁美事啦。
「中文字型支援種類不足」，沒有脈絡、不太確定自己對這句的了解是否正確，姑且視為「轉檔時的軟體無法支援足夠多的中文字型」。這其實問題不大吧？不知道發問者使用哪套軟體，但既然 ePUB 骨子裡橫豎是 XHTML、那「字型支援」就會是顯示媒介的事情、而非轉檔或規格的問題。倘若真是轉檔軟體沒有「用 CSS 設定中文字型」的能力，就花錢改善它吧。
「免費就能用的」字型選擇一直都不多，花錢買就有，硬體製作商或可考慮把這當成賣點。如果可以有股勢力強烈支持下列兩點任一，都是朋友：

要求政府相關的雜七雜八單位一致同意用 Public License 釋出全字庫。SLAT 其實去拜會過兩個相關單位了，相信還有很多單位一定也都試過。我不會說政府沒誠意啥的（他們應該也沒有抱著不放的意思），但我們需要些力量讓這些相關單位「一起」同意這件事，避免責任歸屬不清導致的皮球亂飛。
請需要用的組織起頭、花錢製作一些公用字型，然後用 Public License 釋出。文鼎（似乎也是會員）早先曾釋出部份字體，若有興趣、有些已經不那麼賣的字體或許也可考慮釋出，造福人群。

文字是否以直書顯示，會不會是一個應該要留給讀者決定的問題？若是，那麼只要硬體商支援 CSS3 writing-mode 即可，我們可以用標準順利解決規格問題，那麼使用者便更可擁有切換的能力、而無須另行定義「直書」標籤。又，這應該是顯示媒介要考慮的問題，可以當成賣點做，Lovely Reader 好像就是這樣。在我的想法裡這也是「顯示」的問題，應盡可能與內容（在此例是 ePUB 規格）本身拆開，才能彈性利用。
電子書號標準，若真有必要獨立成為一個標準，猜想國外應該至少有草案了。畢竟如果目前的規格真不夠用、那麼全球都不夠用，可聯合他國一起立一個、盡量避免規格只在自家玩的情形比較好。
註記是否應該跟著 ePUB 一起走？好問題，我沒想過，但有的話真不錯。
至於註記的顯示方式，留給顯示媒介吧，除非現在我們就能窮舉各種顯示設備與介面的可能、不然怎麼訂都是給以後的自己找麻煩。將內容與顯示方式拆開討論，還是比較好的方法。
我的 ePUB Readers 都不能看有 DRM 的東西 orz
「版權保護標準」如果不是 DRM 標準，那想像不到具體是什麼。DRM 是否要有標準？沒想法，但共通標準的話、更容易被集中火力破解就是真的。個人偏頗的意見：DRM 終將要被證明是勞民傷財又吃力不討好的事情，想想怎麼從「限制著作流通來贏取利益」轉往「促使著作流通來贏取利益」不知道會不會比較快，可惜除了廣告之外我也想不到。
「電子書傳輸協定」，想像不到具體是什麼。
「兩岸電子書互通標準」，除了 ePUB 規格本身就處理完的事情之外，想像不到具體是什麼。

格式固定有必要，我愛 ePUB。
詮釋資料的定義部份有必要，雖然這好像不只跟電子書有關。
簡繁互轉個人覺得爆炸難，要到「術語比對」就代表其實還是各走各的，才要比對吧 XD
硬體規格沒想法，不確定讓大家自由發展會不會更好

閱讀體驗

為了進一步了解現況，我其實好像還不錯努力啦。除了真的拿個專用閱讀器來看之外，我試過用下列各種方式盡可能閱讀完一本（夠厚的）電子書，茲列如下：

用電腦液晶螢幕看 PDF 文件：這很多人都有過。心得包括眼睛很酸不舒服、希望有翻頁的動作（不是愚蠢的動畫，只是要可以翻頁而不是連續捲軸）但又要遷就螢幕與字體大小的問題、長文真的看不太下去。
用電腦螢幕看 TXT 文件：也很多人都有，我是看小說。心得包括眼睛很酸不舒服、用螢幕看長文還是黑底白字較舒適、很容易忘記上次看到哪裡、章節分野不明確。
用電腦螢幕、以好讀閱讀軟體看「好讀」文件：大概是最好的體驗。Linux 可以跑真是太棒了、直書可以接受、翻頁方式可以接受、字體大小可以調整真是太棒了。
用電腦螢幕、以 Firefox「ePub Reader」看 ePUB 文件：就跟看網頁一樣，體驗也一樣。我想要可以「翻頁」的閱讀工具（再次強調不是動畫效果）。
用手機、以好讀閱讀軟體、看好讀文件：手指頭常常會擋到字，既然是手持裝置應該還是有點 margin 比較好，其餘同電腦螢幕。我用手機看完三本小說，總閱讀時間大概是時個多小時，這個方式我算看得下去、也不太遇到眼睛疲倦的問題，推測是因為分段閱讀。
用手機瀏覽器看 HTML 長文：捲動而非翻頁、很容易忘記上次看到哪裡。
用 OLPC XO 看 PDF（彩色螢幕模式）：看不太下去，程式太慢、反光問題。
用 OLPC XO 看 PDF（黑白螢幕模式）：除了沒有光線就看不到外，還蠻好的，不過對比比較低有點吃力。

ePUB 的授權資訊

我 Twitter 上有寫過一些：

想了那麼久我承認自己還沒實作，ePUB 書都看好幾本了。

台北市教師研習：Firefox

2010-02-10T10:26:00.001+08:00

「Firefox 也有辦法講到六個小時？」還真的可以，而且我講了兩次。

去年也在台北市教師研習中心講一樣的題目：Firefox 更方便的資料蒐集、整理、分享工具。對我來說 Firefox 最無可匹敵的其實還是在這方面，對 Mozilla 的努力也頗具信心。我狂愛像智慧位址列這類細小、但舉足輕重能改變整個瀏覽習慣的變化，也很喜歡各種加強搜尋能力的小技巧。講義與投影片都請到柏強簡報室去看。

這次最神經病的就是把之前用 OpenOffice 做的講義全部 Google 文件化，其實比想像中麻煩，因為要顧列印版面。網頁仍然無法用傳統列印的思維去想事情，它仍是個「流動」的文件，這或許是我不喜歡用 PDF 思維去想電子書這件事情的原因之一，都從傳統的工作流程去想、就容易卡在很多地方，有的組織應該有能力從「砍掉重練」去想事情。

講課過程中，我說了很多次「這個功能現在大部分瀏覽器都有，大家不習慣 Firefox 的話還是可以試試看。」改良使用體驗的東西互抄是大歡迎，這也是「提供選擇」的精神意涵之一；如果大家都能意識「我們該有更好的網路體驗」，那麼所有瀏覽器就會不斷進步，我想那 Mozilla 就達到它作為非營利組織的目的了。

可惜我整個時間還是沒控得很好，內容塞太滿，最後的「協助翻譯」及「Test Pilot」就沒提到了。下次要改進。

Yesterday

2010-02-03T10:43:00.001+08:00

all my troubles seemed so far away.

「不然出去晃晃好了」，於是他戴上安全帽，我拿了鑰匙，但沒有花很多時間決定要不要往哪裡去。心裡想著「這樣騎會不會一直到華碩去」時，人已經到了；「不然等下去關渡大橋好了」，卻沒有那麼做。我在關渡繞了很大一圈才發現又回到承德路，那旅館已經全部拆掉。而也是厲害，瞬間辨識出某天夜裡淋小雨無目的亂騎的終點，於是旅程繼續。

第一次到新北投站去，原來大名鼎鼎的溫泉會館就在這裡。溫泉博物館今天遊客不少，除了「不好意思（約略同於「借過」）」之外，我還說了句「我幫妳們拍好像比較快」，從致謝的女孩手中拿過相機。難得地、我沒記得怎麼來。警察問我要是否走捷徑，「大路好了，我真的不熟。」

而心情，你怎麼知道什麼時候會停止呢？

Firefox for Maemo, RC2

2010-01-10T08:04:00.000+08:00

Mozilla just released Firefox for Maemo 1.0 RC2, and I post this message with that on whiteg's Nokia N800! It works just fine, except not speedy, and you can install extensions on it!

If you got an Nokia N900, don't forget to try it out. Just go to http://firefox.com/m with your N900 and download the lastest build. Be sure to get the localized version, which include the best search plug-ins set for your region.

混用多種不同授權方式的原始素材

2010-01-08T13:48:00.003+08:00

剛看到小畢在 Twitter/Plurk 上寫了：

Creative Commons 似乎會遇到一個問題.... 當我取材自多個CC授權的作品時，若這些作品的授權條款不一致 (Bob: 中略) 似乎不知道該怎麼處理.....

這邊分三個部份來快速釐清一下觀念：

「用別人的 CC 授權作品來當素材」代表什麼？

因為你本來沒有使用他作品來當素材的權利，所以他採用 CC 授權之後，就表示你「在遵守條約的情況下」可以使用他的作品。當然，「使用方式」可能也是條件的一種，例如要求不得更改、要求不得商業利用等等。

所以一旦你決定要使用這份作品當素材，那麼就得遵守授權的條件；要是無法遵守，就等於沒有獲得授權，也就是不能用。

同條件、不同版本的 CC 授權？

授權條款沒有所謂「升級」這件事情，每個版本的授權條款都是獨立的版本，要「升級」就要重新宣告；又，以 CC 的例子而言，「舊版本」依然有效，這之前提過不少次了。

不過，在 CC 的所有授權條款裡，「相同方式分享」系的條款中特別提到了授權條約版本問題，它是這麼寫的：

您唯有遵守以下各款，方得散布或公開演播改用作品：(i) 本授權條款；(ii) 與本授權條款具有相同授權要素的後續版本；(iii) 與本授權條款具有相同授權要素（的此版本或後續版本）之尚未本地化(unported)或任一司法管轄領域之創用CC公眾授權條款（例如「姓名標示─相同方式分享 3.0 美國」版）；

這代表如果你用了以「姓名標示─相同方式分享 2.0 英國版」釋出的作品當素材，那成品用下列任一條款釋出都 ok：

一模一樣的「姓名標示─相同方式分享 2.0 英國版」
更新版本的「姓名標示─相同方式分享 3.0 英國版」
不同司法領域的「姓名標示─相同方式分享 2.0 台灣版」
不同司法領域、也更新版本的「姓名標示─相同方式分享 3.0 台灣版」

只要其中授權要素相同就行了，這一點是 CC 「相同方式分享」的特色。(需注意不能選用更舊的條約版本就是。)

「CC:姓名標示─非商業性─相同方式分享」跟「CC:姓名標示─相同方式分享」兩種類型的素材混用後？

這其實不用想太多，簡單說就是不能混用，也不能偷吃步地說「那我兩種都用、雙重授權」來處理。「相同方式分享」在這邊又是非常嚴格地規定只有相同（或相容）者可以採用，而在商業性的觀點不同、就會造成此類素材無法混用的問題。

那如果真的很想用怎麼辦呢？授權標章網頁裡每份都有這句話：

若您得到著作權人的同意，上述任何條件都可獲免除。

所以就是回歸原始方式，必須自行取得著作權人同意才行。先前我也曾經為了某個混用不同授權方式的作品，去信請求作者允許我將「姓名標示─相同方式分享」的素材衍生創作後採「姓名標示─非商業性─相同方式分享」方式釋出。

不過小畢在 Plurk 上後來舉的例子，倒有更容易的處理方式：

舉例來說有些作品為了商業考量是CC-BY-NC-SA授權但是如果「我之前的作品」使用CC-BY-SA 那我現在做一份新的作品融合了別人的跟我之前的作品那應該怎麼授權？

用 CC:BY-NC-SA 就對了，因為在著作權沒有轉移的情形下，你自己以前的作品，你本來就有使用的權利，不用考慮 CC:BY-SA 那部份。

2009 年回顧：熱門文章

2010-01-01T03:54:00.000+08:00

這個去年倒是做過了，今年再來一次，也算是給自己一個機會看看過往。以 Google Analytics 的時間為準，本站自 2009/1/1 至 2009/12/31、最多人看的十篇文章依序如下：

RSS 簡單懂：介紹 RSS 的影片，我做了翻譯… 且慢，第一名怎麼跟去年一模一樣啊！維基百科真猛，連結被放上去就是不一樣。不過話說回來，這篇 2007 年 8 月的作品，去年跟今年比較也是掉了 27% 的閱覽次數（我的網誌則是整體而言掉 3%）。
筆記：讓 Ubuntu 長得像 Mac OS X：去年的第三名因為掉得沒有第二名快，所以今年爬上來。個人已經不好此道了，現在正在研究怎麼讓 Windows 7 看起來像 Ubuntu… 這是 2007 年 1 月的作品。
Firefox 套件低調技巧：ScrapBook 篇：也是 2007 年 1 月的作品。這篇比較有趣，它在今年應該不小心被轉貼了一陣子、有不少新的連結來源。不過，原本最大的「客戶」硬是掉了整整 4 成，所以名次下跌一位。
「看援交妹如何賺大錢」：果然越白爛越熱門，本項小跌 7%，上升一名。今年「如何賺大錢」這個關鍵字來源上漲了 38%，不過「西門町援交」居然爬了 210%，有沒有越窮越想亂搞的八卦？又，查「援交理論」來的朋友，是真的想要找什麼理論嗎？ @@
撲克牌遊戲：殺手：也跟著上升一名的是這篇 2007 年 10 月的作品。到目前為止，本篇是唯一小幅上揚者，上漲 1.56%。
Twitter + Firefox 方案一覽：很意外，這篇 2007 年 5 月完成、已經明顯不符時宜的作品還有不少人看，雖然狂跌 52% 仍勉強只滑下兩名。明年應該就看不到它了。
Ubuntu 9.04 倒數中：目前唯一的 2009 新作品，居然是這麼沒內容的東西，證明動態 SEO 還真是可行的玩意 =.=
關於我、關於本站：這篇出現的意義是，本站 2008 年的文章實力超級不足，在 2009 年沒有發揮任何吸引訪客的威力。事實上，往後翻到 24 名才有一篇 2008 年文章出現，好慘，我前年到底都在寫什麼？
顛覆網路 35 天 (4b): 以 @font-face 使用你喜歡的字體：這畢竟是比較吸引技術人的議題，在數篇「顛覆網路 35 天」文章中拔得頭籌。2009 年 6 月的作品，沒能贏過 9.04 倒數的那篇…
Google 協作平台「加入本站」範例：經搜尋關鍵字證明，大家都是找 Google 協作平台範例而不小心跑進來的 orz

大部分都是 2007 年的文章，可能我那年比較有幹勁吧？且剛也說了，我 2008 一定都在混。其他有趣的事情如下：

瀏覽器佔有率：Firefox 維持平盤、仍為本站超過半數訪客使用的瀏覽器，IE 第二但下跌了 20%，剛好也大約是 WebKit 兩兄弟上揚的幅度。雖然連「Mozilla (Suite)」都上揚 6%，但 Opera 你是怎麼回事？居然跌了 6.8%… 有趣的是，如果連 Opera Mini 也加進來，那麼歐家大概也剛好打平 :P
本站仍有 IE5.x 訪客：共 8 次瀏覽，最近的一次在十月。這位仁兄你真的該換瀏覽器了。
Plurk.com 即將成為本站最大連結來源：我絕不諱言，只要認為有趣或必要，我會自推自己的文章。台灣微網誌前兩名的網站加起來剛好等於 Wikipedia 對我的貢獻，明年應該會直接站上第一名吧？
zh-CN 訪客上揚 60%：閱讀的習慣跟台灣的沒什麼差，不過整體訪客數量下跌的情形下 zh-CN 跟 zh-HK 都上揚了，是表示我的站沒被 GFW 擋到嗎？
文章數量持平：今年的網誌篇數與去年相當（少一篇，但沒差啦），大幅集中在 Firefox 3.5 上市時間那段。不過開了才發現原來我 2007 每個月可以寫 20 篇，一月甚至每天寫兩篇 @@ 我不是數字先生啊 orz

My life in 2009

2009-12-31T05:53:00.002+08:00

雖然之前都沒寫過，但前幾天想、今年或許是個值得來個 yearly review 的一年。寫行事曆這件事情一旦養成習慣，回顧時也真的挺方便的。

工作

今年一月到四月，我在法鼓大學籌備處工作了一段時間。那段時間過得還不錯，也藉此機會把一直怕離不開的中研院職務轉為了兼職。雖然後來的離開有點意料外，但對比當時的時機也只能說一切都很巧、在無法負擔的時候解除了負擔。幾個月的時間裡面，我們完成了關於數位公益相關的課程規劃。就不說對學校如何，對自己來說是蠻有幫助、讓我在非營利組織的經營上有時間多思考一點，這大概是在這工作中最大的收穫之一。

因為法鼓大學的職務，所以在中研院創用 CC 計畫這邊自年初起轉為兼職，7 月之後也有新同事來接替我原本的工作。這讓我比較踏實一點，因為你知道、我一直覺得自己在程式這方面的興趣早在大三到了盡頭，接下來不為自己生活所需寫的東西，幾乎可說完全提不起勁。雖然在 CC 相關的數位授權表述資訊這方面，的確是看了不少東西，但對於怎麼實際讓大家得以應用，我想我最好的能力並不在「寫程式、管主機」上。

因此八月起，我的職務有所變動。新的職稱「Developement Manager」是老闆在社群事務與技術研究方面折衷下希望我做的事情，而明年的工作規劃也大部份是我自己提的東西。對於自己提的工作，其實我有點擔心，因為其成果並不容易評估。希望到時不會很後悔就好。關於我的工作規劃，我有稍稍在先前的文章提過一些，歡迎有興趣的商業組織來聊聊。

今年最後這兩個月，我幫中研院內的 myID.tw 辦了一個推廣活動，我對自己的評價是：成果不佳、思慮不周、執行尚可。這說實在是有點殘酷的評論方式，而且「成果」從另一個角度來看其實非常好，但最終不是我自己原先就推測得到的部份、讓我對自己的思慮能力打了不小的折扣。或許這是因為我自己唯一還敢說上兩句的就是思慮吧？因此出現大範圍誤差時，最不能原諒我的，就是我自己。但總之，套句 ilya 的話來說，「你就當做你已經爆炸了。」Anyway，第一次受薪做這類行銷推廣工作，離「技術人」這個錯誤印象遠一點讓我挺開心，希望以後還有機會做這樣的事。

上面看完，不曉得讀者有沒有發現我的 5~10 月是半薪狀態？法鼓的計畫結束後我並沒有很積極找新工作，也不想跟老闆討論在中研院轉回全職的事情 -- 請不要因為看到這句打消你進中研院的念頭，中研院真的是個研究的好地方，大家也都很好，我覺得最不好的是我自己。

但這幾個月也並沒能夠閒著… 雖然跟原先「就休息一陣子吧」的期望差異不小，但在「週休五日」外貌的背後，我接了家教、兩個「不大，但太懶，所以做得半死」的小案子。所以其實還是挺忙的… 說「太懶所以做得半死」好像很矛盾，但如果你知道我就是因為現在還不想做、所以才在打這些文章，大概可以想像得到 Deadline 靠近時沒日沒夜的狀況。

要算工作嗎？社群

這方面的事情雖然不算工作，但差不多也就是工作了。

MozTW 今年比較有進展的東西包括 Foxmosa、GFX.tw 網站開發、連續聚的形式固定（雖然一陣子沒辦了）、MozTW Lab 形式固定等等，也的確把工作（小幅地）分給更多人，還算是部分達到年前希望的「提昇社群成員參與」。其實，MozTW 的事情我一向不太愧咎，畢竟大家都是義工，而過去擔心的、「位子被我佔住、結果真正想幫忙的進不來」的問題，也開始看清楚那只是自己的幻想，而不再感到負擔。做這種義工的協調，總是會感謝很多人，今年感謝第一名應該要頒給 Tim。本人在此聲明：個人認真地認為簡冠庭先生只是經驗不及我，判斷能力我們互有所補、而執行能力上他就高我一截了；在許多工作上，我相信簡先生應該可以是貴公司的得力助手、未來領導，明年他退伍的時候，接洽請早喔！COSCUP 是我今年另一個主力所在，議程組的部分著力不深、不過記錄組應該算做得還不壞？比較開心的是請 Toomore 帶了大家進來玩，讓一大堆 End Users 在 MozTW 的攤位玩就是爽。

軟體自由協會部分，今年終於有點力氣把加入的最大理由「社群贊助機制」做了一些些，目前雖然只能接受五千元以上的捐款、但聊勝於無。接下來要處理的就是更小額的捐款了，不曉得自己這要拖到什麼時候，不過嫌我慢的請記得自己也要出手幫忙，所以就這樣吧。 XD

出國

今年有三次出國的機會，二月時因為 CC 亞洲區會議的關係去了菲律賓，是很好的體驗、也是第一次在「真正的國際會議」上有發表的機會。雖然老師說我講得蠻順，但其實不太好就是了… 重要的是認識很多人，也開始對於別人在做什麼有點概念。我非常期待見識韓國CC大量義工的操作方式，可惜原訂明年在韓國辦的亞洲 CC 會議應該會改成兩年左右辦一次，希望日後還有機會去看看。

第二趟是作為 MozTW 社群的一員，受邀到東京參加 Mozilla Gumi 十周年聚會，並發表社群在台灣的狀況。第二度在國際會議發表演說的機會來得如此迅速，好在這次表現得蠻好，應該可以打 80 分。雖然之前去過日本三次，但東京還是第一回，感覺跟早先的九洲、琉球、北海道差異不小，但或許是更適合一個人的地方，於是…

於是，就跟鐙緯在十一月又去了一次！ XD 這兩次的進步就是我會開始花錢買東西了，雖然買的依然是平價品牌、但對於我這個出國也不會買紀念品的人來說著實是一大進步啊！終於在活了 28 年之後開始對自己的穿著決定要有點意識，如果在街上看到我穿得很差、請提點一下。喜歡日本的一大理由是氣候，或許我應該找個中緯度的地方居住。

最後這一次出國別具意義，因為是第一次實踐「什麼都不規劃、當做放假就好」的花大錢度假法。說不規劃、其實還是有些目標，但可以隨意變動的感覺很不錯，也讓我首度在假期逼近結束時真正出現「好不想回去」的念頭（以往都是「玩得很開心，好累，明天要上學/班囉！」這樣。）我想我以後還是會蠻常這麼做的。

雜事

五月起離開住了一年出頭的新店，搬到了士林。雖然搬來第一天時，就覺得當初選擇這裡的理由之一近乎白痴而有點後悔，但實際住下來以後意外地喜歡，而且巷口的麵包店和豆花店的店員真是可愛（炸）。另外住這裡其實搭公車只要一班就可以到中研院，算蠻方便的，而且符合我「要不就超短程、要不就超長程」的搭車想法。

四月去了趟澎湖教召，做夢也沒想到還會有機會用搭軍艦的方式到澎湖去。說是戰鬥營不為過啦，休息一下也不壞；另外一個附加的好處是又與一些很久不見的朋友碰面，話題少了但感覺默契還在，蠻開心的。今年據說是首年度外離島的教召要去現地演練的，我也實際跟著自己的隊伍前往要防守的地方坐簡單的模擬演練。效果雖然不見得就能如何，但應該比以往紙上談兵好些了。

今年的一大進展是拼命啃東野圭吾的書，到目前中譯版大致看完了六成左右，相關感想與評論都在 Anobii 裡，歡迎大家交流。也因為 Anobii，我發現今年居然有看完近 20 本非關工作的讀物耶！真是太神奇！也多虧遙遠的公車距離、以及那幾天的教召 XD

說到教召，教召結束的當天回台北，就跟前女友分手了（也因此五月搬家），或許是今年最重要的事情，也因此重新獲得一次全盤檢視這個世界的機會。其中比較有趣的，是看著、甚至放縱自己的情緒變化來控制自己。有些意見認為沒有必要被情緒影響，不過說實在、如果其實清楚，那麼放縱不見得就有多壞，至少我現在很清楚怎樣的狀況下自己的確會失常、也確認了一些過去「正向思考」時一直沒去想的事。已經沒辦法用相同的態度生活了，但這就是代價，可以接受。

從 2008 年開始，我又重新進棒球場看比賽了，從國小開始支持的統一獅隊也很爭氣地在這兩年都拿下總冠軍。今年下半年起我進場還算不少，家裡也重新購買了加油棒、汽笛、衣服、帽子等東西，甚至總冠軍戰七場去了五場，人在台北卻參與了台南所有場次（包括史上最長一役），應該算是貢獻度還不錯的球迷吧？總冠軍戰最後一場緯來有清楚地拍到我，觀後感是：「幹，我又胖了。」

我想最近比較覺得生活無味的理由，八成是因為球季結束了 orz

今年進電影院的次數少得可憐，而且從大學畢業以後我就得了自己一個人無法進電影院的病。總計進場看了「天使與魔鬼」、「未來的未來」、「戀夏 500 日」、「福爾摩斯」四部而已，感謝饗樂卡讓我大多時候可以半價看片，不過這張卡絕對是加深我無法獨自觀影之病情的理由之一。在下半年開始發現找不到人一起去看以後，開始覺得有點懷念以前半夜自己跑去「包場」的時期，不過總之就是得了這種病，所以大家週一到週四看電影，可以找我喔！

我不工作然後寫了三個小時回顧，一定會有報應的，一定會。

JeTEDsub 0.4

2009-12-26T05:48:00.003+08:00

可以方便下載 TED Talk 字幕檔的 Jetpack 工具，如果你也有需要、請用。

JeTEDsub Demo from Bob Chao on Vimeo.

跳 Tone 一下討論 CC： TED 的影片跟字幕都是創用CC姓名標示─非商業性─禁止改作授權，我把字幕檔從 JSON 轉為 .sub，算不算種改作呢？就文檔本身而言或許是，不過我想這個授權條款更多只是要用在「翻譯的字句本身」。用程式轉換的方法基本上與智慧無關、任何人轉換都會是一樣的結果，那麼想來是不會被當成「衍生作品」了，不過在 CC 3.0 裡把「衍生作品」放寬為更廣的「改用作品」，這就讓解釋的空間大上非常多。這些多出來的空間，有人稱之為「法律風險」。

風險對每個人來說的意義不見得相同，也曾聽聞有律師建議不要使用創用CC授權過的作品。或許因為如此，商業作品裡看到 CC 作品被再利用的機率還真少（我有看過 PCHome 上面放 CC 授權的照片，nice work!）先前在某次推廣中我提了一下關於風險的事情，立刻引來極大的反應：你有這麼多不確定，那我們為什麼要用、這東西該不會反過來會害人吧？

誠實地說，因為缺乏判例，在法律遊戲的世界裡 CC 確實有不少不確定因子：商業性該如何判斷？改到怎樣才叫做改用作品？組織內部使用算不算散佈、是否該用相同授權條款分享？萬一我用了結果對方反悔怎麼辦？… 諸如此類的。不過我自己其實總很想講一句也很實在的話：

「即便如此，沒有創用CC這種『放話條款』，情況只會更差而已。」

我們生活四周充滿著侵權行為，扣掉刻意為之的那些，其實也有不少根本是誤觸法律。如果你小學也用流行歌曲跳過早操、如果你也曾在簡報裡放別人的照片、如果你在餐廳吃飯時也一邊看著店家接了大喇叭的電視，這些都太可能已經侵權。創用 CC 不會是萬靈丹，硬要求他背負一些東西就有點太過。

很遺憾地，現在你想懂創用 CC 這類授權條款，還是要碰觸一大堆的法律文字；很遺憾地，大部分的時候碰上問題，你還是得找律師。不過如果你是有意識地接觸與了解這些東西（而不是只想著「免費的素材哪裡找」），就已經更進一步了。

只是有感，就不貼 CC Blog 了 :P

Porting JetQRCode from Jetpack to Google Chrome

2009-12-12T23:14:00.002+08:00

(將 Jetpack 套件移植到 Google Chrome — JetQRCode 篇, 點我直接看中文版)

As you may know, Google Chrome browser announced their extension gallery a few days ago. The Google Technology User Group in Taipei hosted a Chrome Hackathon today, I was there and did something insteresting: porting extension between Google Chrome and Jetpack. MozTW is all for "open" (standards, source…) and not for a single product, at least that's the way I doing things.

So here it is, JetQRCode for Google Chrome 0.4, a demo about porting Mozilla Labs Jetpack scripts to Google Chrome.

I've learned a few about the difference between the two:

You have to break everything in Jetpack script, which is in a single file, to several parts, like manifest.json, content_script.js / background.html, options.html, to make things work in Google Chrome.
Jetpack is highly related to jQuery. To make life easier, you may want to insert jQuery as content script.
HttpRequest to different domain is not allowed in content script, do it in background html, and pass the result to content if needed.
You have to create a HTML page for user to set preferences, and storage the values in LocalStorage. (But you can't get the setting values in content script, pass them from background html if needed.) Also, there's only one data type in LocalStorage: string. Be careful if you're trying to use boolean or integer in it.
There's no APIs for context menu in Google Chrome yet, you might need to do the same behaviors in different way.

IMO, since Jetpack is still in early stage, extension APIs in Google Chrome is more complete (though more complex) in many way than Jetpack. Porting things between the two framework is not as easy as I thought before, and need creativity to conquer the difference.

If you are a not-so-good web developer like me, I think Jetpack is easiar to create extensions to solve problems in daily life. But anyway, creating an extension in either Google Chrome or Jetpack is much simpler then in Firefox (without Jetpack), which results more productivity.

(To correct my poor English, drop me a line with patches, thank you. :)

因為我懶得把一樣的話重寫一次了，所以這篇的中英文版大概只有重點一樣、內文會差很多 XD

我原先以為讓 Jetpack 與 Google Chrome 互通套件不算很難，但今天參加 Taipei GTUG 的 Google Chrome Hackathon 時實作一下稍稍有點改觀 —— 的確不難，但是有些東西是比想像中麻煩些。所幸最後仍有斬獲，所以各位親愛的 Google Chrome 使用者、這裡是 JetQRCode for Google Chrome！

拜雙方都遵循網頁標準所賜，其實原理跟很大一部份的程式碼依然相同 (是說我大多都用 jQuery 就是了… 懶惰鬼！)。有些經驗我想還是蠻值得跟大家分享一下，但中文版我想首先講結論：結論是…

Jetpack 真的比較好寫 (XD)，對於像我這種沒有很精的人來說可以輕鬆愉快地達到效果，相對來說 Google Chrome extension 就要考慮比較多架構上的問題 —— 或許是因為得拆成數個檔案吧？有些事情要在哪裡做，得先就權限等問題考量一下。
無論你喜歡哪個，兩個都比原來 Firefox 的套件實作方式輕鬆許多，當然也大勝 Internet Explorer。 (Opera 跟 Safari 沒研究)

好，那麼柏強在這次的遊戲中學到什麼呢？

Google Chrome 的套件，要完成一件事情就算程式碼再簡單也會需要兩個以上的檔案，例如 manifest.json、content_script.js / background.html、options.html 啥的，所以單一檔案的 Jetpack 要移植過去就要好好想一下該怎麼拆程式。
Jetpack 內建 jQuery，很多事情也跟 jQuery 息息相關，所以移植到 Chrome 時、方便起見先把 jQuery 塞進 content script 比較好。
在 Google Chrome 的 content script 裡不能做跨網域 HttpRequest，不過background html 沒問題，所以如果需要的話就在背景做、然後把資訊傳到內容去。
兩者設計哲學中大不同的地方之一是偏好設定，在 Google Chrome 裡你必須自己寫整個 Option 頁面，也要自己把設定值存進 LocalStorage —— 相對自由當然也相對麻煩 (而且從 content page 裡目前還沒辦法直接拿設定值喔！記得從 background html 裡傳。) 這邊我撞到的其中一堵牆是對 LocalStorage 不熟，不知道它什麼都是用字串存，如果要用布林值還是數字的麻煩注意一下。
目前 Google Chrome 裡還沒有調整快捷選單的 API，所以有些效果可能要重新想想使用者可以運用的方法。

以上心得供大家參考，也希望網頁設計師們都可以來玩玩看這兩種比較簡單的套件寫作方式，發揮創意製作出一些好玩的套件。日後有機會再來試試把 Google Chrome 的套件移植回 Jetpack…

更動授權方式為創用 CC 3.0 版

2009-12-11T01:48:00.001+08:00

是的，又要改了。從發佈這篇文章起，除另有標註外，本站文字部份皆採創用 CC 姓名標示—相同方式分享 3.0 台灣版條款授權大眾使用。

由於先前提過的「不可撤回」特性，本站於 2008/12/15 10:01 AM 至 2009/12/11 01:50 AM 的文章亦採創用 CC 姓名標示—相同方式分享 2.5 台灣版條款平行授權，而於 2008/12/15 10:01 AM 前的文章再加採創用 CC 姓名標示—非商業性—相同方式分享 2.5 台灣版條款三重授權。

聽起來很複雜不過也是沒辦法的事情啊… :P

用 Thunderbird 3 玩 Google

2009-12-11T01:26:00.003+08:00

Thunderbird 3 有非常方便的帳號設定功能，只要在一開始的精靈畫面輸入比較知名的電子郵件帳號服務提供商 (例如 Gmail)，就自動幫你把該點該選的通通準備好了。不過呢… 如果只是這樣，那或許你跟我一樣會撞到一些牆，這邊分享一些設定上的經驗，也順便再度介紹即將現身的 Lightning 1.0。

如果你是信件數要用 G 當單位來計算的 Gmail 老用戶，那使用 Thunderbird 3 幫你設定 IMAP 之後可能會遇到幾個問題：

a. IMAP 好像沒用，收不到信？

請到 Gmail 設定的「轉寄和 POP/IMAP」裡確定已經有打開 IMAP 的選項。如果已經開了，或許代表你身處一個會阻擋這類連線的網路環境中 (例如公司…)？

b. 為什麼好像硬碟一直在跑…

有很多原因：

在預設值中，Thunderbird 會把「所有」的信件都收回來電腦裡當個快取 (這快取真大…)，所以如果你是老用戶，想像一下 4G 的信件在空中飄…
由於 Gmail 的特殊 IMAP 實作方式，每一封信都有可能有不同的「分身」出現，例如一封信剛寄到的時候就會同時在「[Gmail] > 所有郵件」以及「收件匣」裡出現；要是設定過自動上標籤的話、還會有更多分身，因此即使信件總量是 4G，實際上要收的可能是 5G 或甚至 8G 的信…
Thunderbird 3 的搜尋功能大躍進 (非常值得一試)，代價是為了製作搜尋索引要耗掉不少硬碟空間。以我的 4.7 G 信件為例 (在 Gmail 裡這樣顯示，實際上因為前一點的關係，可能不止)，整個索引結束後 Thunderbird 個人設定檔資料夾佔去了 18G 的空間 —— 你沒看錯，就是十八基嘎。我後來有做點動作讓整體空間下降到大約 6G (等下會說明)，如果經常需要搜尋信件、或許這是值得的，只是一開始硬碟頻頻亮燈就免不了了…

要跑多久？主要看網路速度而定，有得等了！還好這期間還是可以用 Thunderbird 來收發信，只是「搜尋」無法找到所有信件而已。

c. 我遇到了「Account exceeded bandwidth limits. (Failure) 」訊息，然後無法收信了？

其實這才是我寫這篇的原因，如果你還沒有開始用 Thunderbird 來收 Gmail IMAP 的信件，建議先看完這段。

剛說了 Thunderbird 會把所有信件都下載下來，那很容易在使用不久之後就碰上 Gmail 自己對 IMAP 設的流量限制了。遇到這個問題後，會有數小時到將近一天的時間無法用 IMAP 收信。

這個時候你什麼都不能做，只能回去用 Gmail。

有沒有解法？目前沒有很好的方法，不過我在網路上搜尋到一篇文章提供了一個不錯的意見：有些人 (例如我) 在存取 IMAP 時，並不需要「所有郵件」跟「收件匣」之外的任何資料匣 (也就是標籤)，那為什麼不把他們隱藏起來呢？這樣可以大幅減少信件往來耗費的頻寬，且既然可以用搜尋方式找到任何想找的信件，那「資料匣」的必要性就降低很多了。

在 Gmail 實驗室裡就有「進階 IMAP 控制項」，首先將其啟用：

接著到設定中的「標籤」一頁，我只勾「收件匣」、「寄件備份」、「所有郵件」及「垃圾桶」，其他全部取消。

這麼一來日常使用中與主機之間訊息來往的機會就會稍微減少一點，「可能」也比較不容易撞壁。

請參考 fauzty 對這點的看法，刪除郵件部份我還沒有驗證但他說的應該是對的、資料匣的部份看各人的習慣如何。

d. 我把寄件備份跟垃圾桶那堆也都取消了！

那… 你可能會發現信寄出去時老是卡住，因為本來 Thunderbird 想存放寄件備份的位置被關掉了 XD 刪除郵件倒是還可以用，不過在 Gmail 那邊會多出現「[imap]/刪除的郵件」這種標籤。有兩條路可選：

把垃圾桶跟寄件備份打開
調整 Thunderbird 存放郵件的資料匣

第二種方法要到「編輯 > 帳號設定」 (在 Windows 跟 Mac 上應該是「工具 > 帳號設定」) 去，點選左側面板 Gmail 帳號下的「備份與郵件匣」一項，把 IMAP 中已經隱藏、信件該丟到本機資料匣的東西都選好即可。 (例如下圖中的「草稿」跟「範本」就是存在本機資料匣。)

「垃圾桶」的設定則在「伺服器設定」一項，一樣是看你 IMAP 有沒有把垃圾桶隱藏起來而決定要放到哪兒去。

e. 好，信件沒問題了，可是 Gmail 的連絡人資料不會一起過來…

那… 就用 gContactSync 把它們叫過來吧，裝完以後在「通訊錄」的選單中可以設定啟用，目前要同步的通訊錄名稱請用英文設定。

f. 我想要有 GMail 實驗室裡的「Google 日曆小工具」

那麼你需要的是 Lightning 套件，也就是 Mozilla 行事曆軟體 Sunbird 的「Thunderbird 雙鳥整合版」。安裝後就可以在 Thunderbird 旁顯示接下來幾天的預定行程，加上 Provider for Google Calendar 就可以輕鬆與 Google 日曆同步！

在 Thunderbird 3 裡，Lightning 的行事曆將以分頁的方式呈現，操作起來比以往更直覺些，搭配 Provider for Google Calendar 也支援直接設定以簡訊方式提醒行程。唯一的缺點是目前還沒有給 Thunderbird 3 用的「正式版本」，你得自己安裝 Lightning 的逐日建置版 (Nightly，每天都會更新的超級測試版) 才行，這畢竟還是測試用的、在這邊就不提供連結了，有興趣的可以等 1.0 版正式出爐，屆時應該也會放入由 Sun Microsystem (以及包括小弟在內許多早期貢獻者) 協助完成的中文語系。

JetQRCode: create QRCode with content on web page

2009-12-10T01:20:00.000+08:00

Another Jetpack extension :)

JetQRCode is a Jetpack extension which can generate QRCode. With JetQRCode, you can easily get QRCode of…

(shortened) URL of current tab
selected text

And you can choose…

the output encoding of the QRCode
the image size, from 150px to 500px

Install JetQRCode from Jetpack Gallery. If you don't have Jetpack in your Firefox, Jetpack Gallery will install it first.

For more information on JetQRCode, please check the project page on http://www.bobchao.net/jetqrcode

又見 Jetpack 套件… 我真的愛上它了！JetQRCode 是可以拿來製作 QRCode 的 Jetpack 套件… 不知道 QRCode 是啥？蘋果動新聞全靠它啦！有了 JetQRCode，你可以：

製作目前網頁網址的 QRCode
製作選取文字的 QRCode

接著拿出支援 QRCode 解碼的手機一掃，資訊就跑到手機上囉~

你可以到 Jetpack Gallery 安裝 JetQRCode，關於這個套件的使用方法、未來規劃等等的事項則請參閱 http://www.bobchao.net/jetqrcode。

明年 Jetpack API 完整一點再來辦開發熱鬥會 :) 現在如果你有興趣討論的話，可以參加每週一晚間在生態綠咖啡的 MozTW Lab 台北場，我、小 B、Bryan 都有玩 Jetpack。

昨日主打歌：惜別的海岸

2009-12-08T04:03:00.000+08:00

雖然這一切嚨係　環境來造成

雜談 ccPlus 運作模式

2009-11-02T08:33:00.001+08:00

這篇是下期 CC 電子報的專文 (一刀未剪版)，為了鼓勵集中回應，先貼一下自己的 Blog 以便取得連結 :P

自 iSummit 2008 回來後，筆者撰寫的 Open Business 心得裡提過 ccPlus 這項技術。時過境遷，ccPlus 已經成為 ccREL (為作品以數位方式標示 CC 授權條款的標準規格) 的一部份，當您前往 CC 網站選擇授權條款時若填入「其他授權方式網址」，則產生的程式碼裡就會包含 ccPlus 的資訊。

簡言之，程式碼中的 rel="cc:morePermissions" 相應標籤中，正標示了進一步連絡的網址。如果使用者需要更進一步洽談授權、點選這個網址就對了！事實上，經由按下網頁上的 CC 授權標章前往授權標章的說明網頁時，說明網頁上也會告知訪客該去哪裡洽談更多授權。

授權代理實作方式

ccPlus 的原理十分簡單，商業組織要實作相應的功能也不太難。當創作者為自己的作品標上 ccREL 資訊、並且在其中包含 morePermission 資訊後，支援 ccREL 的瀏覽工具應能直接辨識出授權代理商的連結並提示使用者；在使用者點選授權代理商的連結後，主機端再加以辨識 HTTP 標頭中的 refferer 資訊，得知來源網址、再依據來源網址的原始授權方式決定要提供哪些額外的權利供使用者購買即可。

舉個例子：創作人「小強」以創用 CC 姓名標示—非商業性—相同方式分享條款授權他人使用自己的歌曲，而聽眾「包柏」很喜歡這首歌、並且想用在自己的作品上，但基於種種因素無法遵守這個授權條款，於是他點選小強網頁上的「其他授權方式請點選此處」，連到了授權代理商 morepermission.com 的網頁。morepermission.com 此時因為 HTTP refferer 的資訊得知包柏因小強的歌曲而來，並且從小強的原網頁查明小強採用 CC:BY-NC-SA 條款，因此自動列出下列購物選項供包柏選擇：

除原條款授予之權利外、額外增加「商業使用」的權利：1000 元/單件作品
除原條款授予之權利外、額外允許免去「相同方式分享」的權利：3000 元/單件作品
直接購買一般性商業使用權利 (不需標示姓名、不需相同方式分享)： 20000 元/單件作品

包柏勾選第 1 及第 2 項，並且填寫相關資訊後結帳，便擁有在單件商業作品上利用小強的歌曲、且不需以相同方式分享的權利。每個月都有數十位像包柏這樣的人前來 morepermission.com 購買小強作品的額外權利，而 morepermission.com 則在月底與小強一次回報本月的銷售狀況及結算金額。包柏跟小強都免去了信件往來的等待時間與麻煩，而 morepermission.com 則收取一定比例的服務費。

衍生問題

剛剛的流程看起來還不錯，但就技術面來說、其中會有幾個問題：

1. 包柏要的，是小強網頁上的哪個作品？

當同一個網頁上又有圖、又有文、又有音樂，程式如何判斷 ccREL 所指的東西是什麼？ccREL 可能出現在網頁上的任一處，即便授權代理商能循線回到來源網頁查驗、也無法用電腦程式準確判斷出網頁上的那個部份是授權的標的。

2. morepermission.com 怎麼自動提出購物選項？

最簡單的想法是，原始的授權條款有哪些元素，就提出相對應的「取消」選項。例如本例中原始授權標的物採「姓名標示—非商業性—相同方式分享」授權大眾使用，那麼直接提出「不需姓名標示」、「允許商業利用」、「不需以相同方式分享」作為採購選項似乎便是可行的方式。

不過考慮到原始著作人的意願，那麼事情又有些不同：或許對小強來說，取消「相同方式分享」跟「非商業性」都還好說話，但很堅持必須保留「姓名標示」的權利，此時 morepermission.com 還是必須提出相應的機制來回應著作人意願。

當然，也要考慮到我們並不需要在「more permission」的層面上被 CC 的各項元素綁死，而更可以直接將「一般性的商業使用權利」當成選項之一。選擇此項時，買賣雙方的關係就不是「我已經獲得著作人以 CC 某條款授權、且著作人對我額外免除某些條件」，而是「我已經獲得著作人以一般商業使用權利授權」，則此時就完全不需要看 CC 的條約內容，對於利用人來說或許更為簡便。

3. 如何定價？

取消各種權利時，該怎麼定價？且雖然範例裡「不需相同方式分享」的價碼較「可商業利用」來得高，但不同的著作人可能又有不同的看法。又，依據使用目的不同、定價方式也該有所差異：耗資千萬的電影與巷口的咖啡館要用你的音樂，應該就有不同的計價方法。

這 3 個問題都可以經由著作人與代理商先行約定來解決，也就是說小強在 morepermission.com 上先註冊一個帳號，指定「由這個網址來時、代表著作物是這首歌」、選擇願意有條件除去的授權元素、再分別就各種情形自行給予定價。也或許小強可以指定「某個網址來的著作、一律堅持保留姓名標示元素」、「某些特定網址的著作，一律僅給予『直接購買一般性商業使用權利』的選項」等等。

不過既然要「登記」，那麼又衍生出「如何知道帳號的所有人就是作品所有人」的問題，這個層面其實已經離 CC 所關心的事情有點遠、但又容易被牽扯為 CC 應該解決的問題。筆者認為，無論有沒有 CC、在世界上盜用別人作品自稱作者的事情也本來就存在，那麼原本怎麼解決就怎麼解決、原本難以解決的也不用在這個地方苛求 CC 有所作為。目前來說，服務商及購買者只能相信網頁提供者確實提供了自己擁有著作權的作品。

其他玩法

上面舉的例子是獨立的授權代理商機制，也是筆者認為比較開放的玩法。依據這個作法，使用者可以自由選擇作品的發佈平台及授權代理商，避免被一家公司綁死。

不過，事實上在目前可見的 ccPlus 服務供應商裡，大多都是把著作發表平台 (content hosting) 直接結合金流，還沒有看到開放、接受外部作品一起販售的情形。以 Jamendo 為例，在平台上發表的音樂內含 ccPlus 資訊，但使用者沒辦法選擇授權代理商、而是會直接又連回 Jamendo 的授權網頁。

此外，能夠選擇的授權方式也不若 ccPlus 原先「可以隨選要減少的授權要素」的規劃，而大多是直接就作品要利用的層面來販售商業性使用授權。也以 Jamendo 為例，在選擇好要買的歌曲之後，網站會出現表單要求你描述作品的應用方式，並藉以決定要收多少費用。

這種方式把剛剛提到的作品、購物選項、定價等問題，都直接由該平台幫你決定了。雖然一次解決了很多問題，但相對來講就不那麼自由，且使用者若想藉由多個平台來增加曝光度、也無法選擇統一的授權代理商來簡化收費流程。但不可否認，這樣的實作方式對於服務提供者來講是比較方便、利益也比較高的，因此無怪乎大家都以此種方式實作 ccPlus。

但就算作品發佈平台想兼營金流機制來收一點服務費，無可避免也必須付出相對的營運成本與代價。所以可以想見另一種模式很可能會在不久的將來出現：作品發佈平台提供有限的選擇，讓著作人自三到四家的授權代理商中選擇其一，而發佈平台再與授權代理商分享手續費。這個模式可以讓發佈平台免去增加金流業務的麻煩、且又能讓想合作的授權代理商自行「投標」加入合作伙伴，獲得一定利益，著作人也能因此獲得 (有限的) 選擇自由。若授權代理商增加到一定的數目，這個方式很可能在未來成為主流。

那麼，目前有多少獨立授權代理商？

在筆者有限的資訊裡，答案是零、一家都沒有。

ccPlus 概念推出已經超過兩年，目前實際支援這項技術的獨立授權代理商就是找不到。以全球作為市場範圍來講，這多少應該還是個有利可圖的行業，會造成毫無獨立廠商支援的理由，筆者隨便猜一下：

CC 不紅，ccPlus 更不紅：也就是「這是個解決問題提升利益的好技術，但知道的人不多、實作的人當然更少」。其實這是最好的狀況，問題僅僅在推廣而已，而不是機制本身有問題。
著作發表平台不支援：獨立授權代理商想賺錢，那麼自然希望有足量的著作人使用 ccPlus 技術、且願意指定自己為授權代理。但目前提供著作人發表著作的服務平台、似乎都沒看見能讓你選擇外部授權廠商的設定可填。
雞生蛋蛋生雞：以著作發表平台的角度而言，現在這類授權代理機制還不風行，好像也沒有必要提供支援。上述兩點明顯為雞生蛋、蛋生雞的情境，讓支援 ccPlus 的獨立授權代理商在短期之內只能從自己架主機發表作品的著作人身上賺到服務費，吸引力太小。
也或許，這個市場本來就小得可憐？筆者不這麼認為，但沒有統計數據支持的情形下這必須列為一個可能。

其實應該再加一個「以上皆非」 —— 也或許其實 ccPlus 機制設計上有什麼問題，是我們這些太熟悉 CC 的人沒有注意到的？

無論如何，有更多的後設資料我們就有機會利用機器做更多的事，ccPlus 是後設資料的一種、與其相關的授權機制也有推動的價值。筆者在接下來的半年內將尋訪創作者及既有平台服務商 (包括著作發表平台及線上授權服務平台等)，希望能整理出 ccPlus 機制運作架構建議及目前的狀況分析，期待明年中有機會再與各位分享心得與成果。

如果您想了解更多關於 ccPlus 的資訊，請見 CCTW Wiki: http://wiki.creativecommons.org.tw/CC_Plus

MozCC 在 Jetpack 裡重生：JetCC

2009-10-30T15:46:00.002+08:00

在弄 ccZotero 時，網頁裡後設資料皆經由 ccMetaView (MozCC 的一部份) 擷取而來。ccMetaView 的目標是要能夠抓到各式相關的後設資料格式 (而不論是否與 CC 相關)，這是好事，不過如果就真的只想抓 CC 的後設資料、是否有跟 MozCC 1.0 一樣的簡單套件呢？又，Firefox 的 API 隨著版本演進而變，而就 CC 總部投注在 MozCC 上的資源，顯然不足以隨著版本變動而更新，是否有更能快速修改的東西呢？

之前提過，我最近花比較多時間玩 Jetpack，所以在想到這些後，就把腦筋動到 Jetpack 上。這種單純的架構果然是實作簡單套件的最佳方式，只花了一點點時間、就把這個 Jetpack feature: JetCC 做出來了。

安裝 JetCC 之後，在狀態列上會顯示目前網頁的授權方式，點選之後則會帶你前往授權條款的說明頁面。其實一切就與 MozCC 1.0 差不多，這也是我覺得比較「輕量」的方式。

拜 HTML 5 Selector API 所賜 (在此以 jQuery 處理)，要找到網頁中有沒有「授權條款」相關資訊，只需要簡單一行：

$(doc).find("a[rel~='license']");

接著再取得該元素中的 href 屬性 (也就是授權條款網址)，即可得知該文件採用什麼授權條款，然後顯示相應圖片即可、輕鬆愉快。

在這個小套件裡有幾件事情值得與大家分享：

1. CC Metadata 格式

從古到今，就我所知有三種在網頁裡嵌入 CC 授權資訊的方法，分別是放在註解裡的 RDF、microformat、以及目前的 ccREL 規格。後兩者都可以用剛剛那樣擷取 rel="license" 的方法來察知，不過對 JavaScript 來說、放在註解裡的東西還真是苦手。實作上還是可以分析網頁後自己寫簡要 RDF parser、不過我懶了…

除了註解中的 RDF 之外，XML 中的 RDF 也是個問題。按理說我不需要管到 XML 的部份、但因為 Firefox 的構成介面：XUL 也是種 XML，所以利用 XUL 做的「網頁」 (例如高橋流 XUL) 也可以由 Firefox 開啟，這麼一來支援一下就是理所當然的事情了。不過同上，目前懶得做，願意幫忙的大德快來吧 XD

2. 產生 referer

點選狀態列的 CC 圖示會帶你到該授權條款的說明網頁。其實 CC 的授權條款說明頁面會自動偵測來源網頁是否有其他 ccREL 的資訊 (例如 morePermission、姓名標示資訊等)，並且顯示出來。因此，如果在這邊單純用 jetpack.tabs.open() 來開啟授權條款說明頁的話，在 HTTP request 內並不會送出 referer，那說明網頁也就無法找到來源網頁上的其他資訊。

只要能送出 referer 就能解決此問題，不過 Jetpack 的 API 目前還沒有提供修改 HTTP Request 內容的方法，所以只能靠其他旁門左道來處理了。在你點選狀態列的 JetCC 圖示時，我們偷偷在目前頁面上插入一個按鈕，設定按下後前往授權條款網頁，再用程式模擬按下動作。這樣就暫時繞過了 referer 的問題。

嚴格說來，這個套件的作用相當有限，但有鑑於 Jetpack 這種方式是未來瀏覽器擴充套件架構必走的道路，當成試作品亦有他的價值。程式碼本身相當簡單，我直接宣告進入 Public Domain 了，歡迎大家隨意使用，如果有興趣改成 Google Chrome 可以安裝的擴充套件也不錯 (應該也相當簡單)。

JetWave 0.2 with waves list in your sidebar.

2009-10-30T03:33:00.001+08:00

I just add a feature to JetWave which can show your inbox in Jetpack sidebar. Check the screenshot below:

Also, you can install JetWave from the new Jetpack Gallery, which is still in the alpha stage but usable. Remember to check the "Let me install this unreviewed Jetpack" near the install button.

我為 JetWave 新增了在側邊欄內讀取 Wave 清單的功能 (見上圖)，另外也把 JetWave 丟到 Mozilla 實驗中的 Jetpack Gallery 裡了。如果您要從那邊安裝的話，記得先勾選「Install Jetpack」上方的「Let me install this unreviewed Jetpack」。

JetWave, JetPack feature for Google Wave

2009-10-22T03:07:00.001+08:00

JetWave is a JetPack "feature" for Firefox. Just like Gmail-notifier extensions, JetWave can help you to check your inbox in Google Wave.

For install and usage information, please check the JetWave page.

我最近花蠻多時間玩 JetPack 的。雖然上官覺得 JavaScript 其實不簡單，不過我自己來講、「簡單」代表的是肉腳如我也可以隨便寫出點東西來，我們這種人是不會要求自己太多、或者要把什麼東西寫得太好太複雜的 ;) JetPack (及 Google Chrome 的擴充套件架構) 就蠻適合我們這些平常只碰網頁設計、會點 JavaScript 的人。

JetWave 是簡單的 Google Wave 檢查套件，安裝後會在狀態列上顯示收件匣內的新訊息數目，點擊後則可前往 Google Wave 查看新訊息。除此之外，我也蠻建議會點 JavaScript 的人看一下程式碼 —— 我並不專精於程式設計，但相信看了後可以大概了解用 JetPack 快速寫個符合需求套件 (或說「feature」) 的方法。

安裝或其他資訊，請往此處去。

我接下來想做中職戰況快速檢視的東西，不過今天晚上我要去ㄆㄘㄉ了 :P 所以就跟預定的 JetCPBL 套件說聲明年三月見囉~

Bring CC data to Zotero

2009-10-02T08:01:00.002+08:00

Zotero is a Firefox extension which plays the role of EndNote; it helps you to manage the resources you collected from the web, like research papers or articles. Though there's a "Rights" field for copyright / license metadata, it seems that Zotero cannot recognize CC license data.

Zotero supports COinS, but doesn't save "rft.rights" values from OpenURL (I don't know why.) That means you have to enter every rights information by yourself, or you might have copyright issues when you wanna reuse the data.

Luckily we have MozCC, an extension to recognize hidden metadata in the web page. By the following way, we can make another extension to bring the power of MozCC to Zotero. It actually pretty simple, but I do spend way too much time coding to address these issues:

After 2.4, MozCC is broken into two extension: One for recognize metadata in web page, and another for UI display. Since the separation is still at the early stage of development, I often feel lost when I read the code. :( Well I'm not a good programmer, I knew it from the very beginning.
COinS is totally new for me, and there's only a few example for "rft.rights" on the Internet. This is pretty strange but it's true. Do a search and you'll see. I have to decide if it is the good place to save license data and, if true, in which format. Since I want to solve the multi-licenses issue (see below) in the next step, I save only the license URL at this point.
When there are two (or more) license statements on one page, how do you know which license to follow? Sometimes it means the page is dual-licensed (like Wikipedia, license under both GFDL and CC BY-SA,) but sometimes it means different licenses for different parts on the same page. This could be a problem, and even MozCC doesn't solve this.
Bob is too lazy.

Anyway, I made a simple extension (or, "plugin for Zotero") to try out the possibility. If you wanna give it a try, or even help me to improve it, you can get it from my website.

Remember you have to install MozCC and Zotero first. You can use Zotero 1.x or 2.x beta, and for MozCC, please install the newest version IN THE SANDBOX (2.4.9+) from the Firefox Addons site.

Patches and feedback are welcomed, just leave me a message :)

練習寫英文的分隔線 (喔對了歡迎幫我改作文 orz 請寄信給我)

Zotero 是個 Firefox 的擴充套件，可以用來管理網路文件與你擷取的其他資料，跟 EndNote 的作用非常相近、都是比較偏向學術文件管理的用途。我家老闆希望有個可以管理網路 CC 資源的軟體，這當然是非常棒的東西，但可惜他雖有「授權」欄位、卻認不得 CC 的資料。

我查了一下他支援的 COinS 格式，此格式將 OpenURL 嵌入網頁，規格裡也有 rft.rights 這個欄位，不過 Zotero 不吃… 所以我把腦筋動到 MozCC、一個可以辨識網頁上 CC 資訊的套件上。理論上，可以寫個小程式，讓 Zotero 在儲存資料時「順手」將 MozCC 辨識出來的資訊帶到相對應的欄位裡，完成任務。

程式其實很簡單… 不過我花的時間好像比較多在查資料，包括：

MozCC 2.4.9 開始真的把這套件拆成兩個部份了，一個用來辨識、一個用來顯示。這很棒，也是正確方向，不過目前分割得不是很乾淨，我看程式碼時常迷路 orz 我真的很遜。
COinS 跟 OpenURL 對我來說是新東西，其實我不太敢確認 rft.rights「可以」拿來存授權資料；目前反正是心一橫就上了，而且我有看到有人的使用方式跟我相近。另外，要儲存什麼資訊呢？我一開始有想過像 MP3 的授權欄位一樣，儲存「本文章採用創用CC姓名標示條款授權，請見 {網址}」這類的東西，不過考量到我想解決多重授權(看下一條)等問題，所以目前先單純儲存授權條款網址再說。
網頁上如果出現兩個(以上)的授權聲明，怎麼辨識儲存下來的部份該遵從哪一個條款？是平行授權、還是針對網頁的不同部份授予不同權利呢？這真的有難，MozCC 也沒解決這問題，不過我想試試看有沒有什麼好方法可以處理，以後再說。
我好懶。現在每天看棒球轉播是我唯一的嗜好。

總之總之，我還是做了一個小套件。先裝 Zotero 跟 MozCC 2.4.9+ 再裝這個套件，那麼儲存網頁時如果 MozCC 有偵測到 CC 授權資訊、Zotero 就會把授權條款資訊儲存在「權利」那個欄位內。有興趣的可以試試看，也超歡迎幫忙修改、一起討論的。

我覺得寫得簡單又爛，其實很掙扎要不要丟出來 orz 不過考量到其實我好像沒在怕別人知道我多遜，就丟吧 XD 有興趣幫改或提意見的，請直接留言囉。

Native Personas in Firefox 3.6

2009-09-30T04:47:00.004+08:00

Information and code example are mainly come from Dao's article.

Light-wight theme (aka. native Personas) has landed on trunk. If you are using a recent nightly build of Firefox, just click the image below and press "Allow" on information bar shows up.

Any site can provide themes for visitors, please check the source code in this blog post. If you wanna preview the theme just like what you can with Personas, you have to add the site's URL in Allowed Sites list (the Exceptions… button in Preference > Security,) which is "blog.bobchao.net" in this case.

So how to uninstall the installed themes? Just like what you did from Firefox 1.0, check the Theme Manager in Tools > Add-ons.

練習寫英文的分隔線

Firefox 3.6 最新的 Trunk 已經把原生的「輕量佈景主題」功能 (就是 Personas 啦) 加進去了，如果你剛巧就在使用最近的 nightly，點選下面這張圖片、然後按下訊息列的「允許」試試。

任何網站都可以提供佈景主題給人裝 (設計師福音啊)，程式碼也簡單到炸開、看這篇文的原始碼就行。為了安全起見，如果你也想跟在 getpersonas 一樣、擁有預覽佈景的功能，那得先把該網站加入允許網站清單中 (偏好設定 > 安全裡的「例外網站」給他按下去)。例如你把 blog.bobchao.net 加進去，就可以看到我以後提供的佈景預覽… 所以快加吧 XD

那裝了的佈景怎麼刪掉？就去「工具 > 附加元件」裡的佈景主題刪囉。(BTW，我順手測試一下：用 Zotero 儲存這篇網誌應該可以嵌入 CC 資訊，但不是正規的 ccREL)

CC 發佈「非商業性」認知調查報告

2009-09-16T15:30:00.001+08:00

前言：CC 在台灣時間昨天稍早發佈了「非商業性」認知調查報告，這是大家都很在意的一份研究，所以我利用 Google Translator Toolkit 很快地翻譯了一下 CC 的網誌文章。雖然報告本身不能真的直接拿來「定義非商業行為」，不過可以想見這一份 (以及未來可能的) 研究結果都會一步步反應在未來的 CC 授權條款中，值得有興趣的大家參考。以下翻譯部份原作為 Mike Linksvayer，以創用CC姓名標示3.0條款授權使用：

大約一年前，我們開始研究人們如何理解「非商業性」這個辭彙。這項研究由Andrew W. Mellon 基金會慷慨支持，內容含括深入訪談和兩階段的面談、線上焦點團體及網路問卷調查。最後這些調查的對象是從美國網路使用者隨機抽樣（因資源有限造成的地域限制），並額外包括由此網誌散佈消息所回收的開放問卷（在報告中稱為「CC 之友」）。

今天，我們在此公佈定義非商業性使用的研究報告和原始數據，分別以CC 姓名標示授權條款及CC0公共領域宣告釋出 —— 沒錯，這份與「非商業性」相關的報告，完全可以用於商業目的。請參考今天的新聞稿。

這項研究由Netpop Research執行，並由學者及一個工作小組擔任顧問。工作小組的成員包含數位CC 司法領域專案成員、CC 工作人員、及 CC 董事會成員。

研究結果

在 CC 與「非商業性」相關的授權條款中，皆包括一段「商業性用途」的定義，以此避免相關使用權利授予任何商業目的：

您不得以主要為獲取商業利益或私人金錢報酬的方式…

多數受訪者（含87％的創作者及85％的利用人）表示，這段定義與他們心中的認知「基本相同」（43％的創作者與42％的利用人）或「不太相同，但仍符合」（44％的創作者及43％的利用人）。只有7％的創作者和11％的利用人表示，這段定義與他們心中的認知「不同、且不符合」；而有6％的創作者及 4％的利用人回答「不知道/不確定」。有74％的創作者及77％的利用人認為他們個人的定義與其他人都相同，而只有13％的創作者和11％的利用人在完成問卷後想更改他們自己的定義。

在以 1 代表「肯定為非商業行為」、100 代表「肯定為商業行為」的評分中，創作者與利用人都認為作品與線上廣告結合使用為「商業行為」 (評分分別是84.6及82.6分）。然而，其他更具體的案例，讓我們發現許多情況下要根據脈絡來決定是否為商業行為。例如，創作者和利用人對於「非營利組織在網站上利用了作品，並藉網路廣告賺取足夠費用支持網站運作」這個案例的商業性認知程度，分別給予 59.2 及 71.7分。

同樣的評分方式下，創作者和利用人皆認為利用作品來獲取金錢屬於商業行為（分別評為89.4及91.7分），但針對非營利組織 (或僅為平衡成本) 的相同利用方式則再次給予較低的分數。最後，兩個族群皆認為「個人或私密」的利用方式為「非商業性使用」，不過創作人在這個項目上較利用人略為傾向以商業行為解釋（分別評以 24.3 及 16.0 分）。

在開放問卷調查中，雖然由調查數據難以比較全球「CC 之友」與美國網路抽樣兩者的實際經驗，但兩個族群在某些項目上的評分傾向確實不同。舉例來說，創作人與利用人針對同樣的「非營利組織線上廣告」案例，分別評以 35.7 及 40.3 分，也就是說他們較傾向以非商業行為解釋。全球 CC 之友也認為「個人或私密」使用為非商業行為，分別評以 8.2 和 7.8分；再回顧一次，1 分代表「肯定為非商業行為」、100 分代表「肯定為商業行為」。

更多內容請參考研究報告，也歡迎依據數據自行分析、獲得屬於您自己的結論。

Creative Commons for Mozilla Service Week

2009-09-04T13:39:00.001+08:00

Mozilla Service Week 是 Mozilla 在今年 9 月 14 到 21 日舉辦的全球性活動，提供非營利組織與志工之間的配對、鼓勵大家在這一週奉獻時間心力。雖然很可惜的是台灣找不到人接手籌畫所以沒有參與，但我意外發現這件事情又不小心跟我的工作串了起來。

創用 CC 的美國總部響應 Service Week，號召志工於該周前往 IRC 解答新手疑問。無論你想要發問、或願意幫忙，都可以在那段時間裡於 Freenode 上的 #cc 聊天室找到自己的位子。為了確保一定有人在場能夠回答新手問題，有意願協助的朋友可以前往 CC 的 Wiki 上自願排班，藉以協調人力；當然，也別忘了到 Mozilla Service Week 網頁上登記一下自己的貢獻時數吧。

我本來想也來發起一下中文的 help desk，不過一方面是實在不確定會不會有足夠的志工來協助回答問題、二方面是平常根本也沒多少人寄信到 CC 來發問啊 XD 這回就先跳過了，提醒大家有相關問題還是可以寄信或者直接打來問，也可以在 Twitter、Plurk、Facebook、我的 Blog 上跟我討論喔 :)

這些東西都連在一起的，怎麼能分開呢？

Quotes of the Day -- George Burns

2009-09-04T13:05:00.001+08:00

「只要一杯就能讓我醉倒。問題是，我不記得是第十三杯、還是第十四杯。」

Mozilla Labs: Bespin

2009-09-03T16:29:00.002+08:00

去年十月 Mozilla Labs 推出了「雲端版」的程式碼編輯器 —— Bespin。你可以想成是 Google Docs 的程式碼編輯器版本，讓你能夠以任何 (符合先進規格的) 瀏覽器隨處修改、編寫程式碼。對我這個並不自視為開發者的人來說，剛推出這個專案時只是為了了解一下而試玩一陣子，短評：有趣，但還看不出哪裡有用。昨天因為去 GTUG 時 Gasolin 提起而又把他開出來，士別三日還真是成長得很快啊！

Bespin 的開發原意是要打造開放、可擴充、能提高開發綜效的網際程式編輯環境；另外如同我們對 GFX 的期望一樣，也肩負推廣開放標準的責任。因此，這個專案有幾個目標：

當然是要好用。這包括介面設計、類似 Emacs 的命令列工具等等，當然執行速度上也有一定要求。
既然是網路，當然也要協同作業。因此，你可以將專案分享給其他人即時共同編輯。
要做到開放、可擴充，首先應該自身就應該以符合網際標準的程式開發，讓支援先進標準的瀏覽器 (例如 Google Chrome 等) 也能使用，而不能限制在 Firefox 上；另外，應該要能以 JavaScript 擴充這個編輯器，讓特定需求的使用者用起來更順手，像是 Eclipse 一樣。 (當然更不用說這應該要 OpenSource)

這兩天玩的想法

去年剛開始時玩沒有很大感覺，不過我昨天玩的版本 (0.4.2) 倒是足以讓大眾對這個十分大器的專案備感信心。雖然中文輸入上有先天限制 (他把鍵盤事件都抓走了，無法打中文、只能貼上)，但豐富的自訂能力與方便的命令列還真不簡單。

目前協作功能還在實驗中、預設並未開啟，要試試看的話可以自己動手打開。除了這個功能之外，還有很多、很多設定都藏在 BespinSettings 裡的 Settings 檔案，可以直接編輯、或者用命令列 (Ctrl-J) 型式開啟。
命令列的命令可以自己用 JavaScript 寫，就跟 Ubiquity 一樣。已經有人寫了些東西，我覺得 pastebox 應該可以用來暫時繞過中文輸入問題，但還沒試過。
他可以直接引入公開的 SVN 或 Mercurial 專案，也當然可以執行相對應的各種操作 (co, ci… etc.)。我還沒測試把 MozTW 網站整個 co 過去，因為…
開放給大家玩的主機，單帳號容量限制為 15MB 而已 XD 感覺起來好像少到炸開？但一方面別忘了這還只是剛開始、二方面對大部分的專案程式碼其實也還夠用；另外別忘了這可是個自由軟體專案 (with MPL 1.1)，你可以把程式碼拿回去架在自己團隊的主機上玩啊！

開放

事隔這個專案推出快一年，動手寫這篇的緣故主要還是沒看到有介紹新發展的中文文章。發表初期的文章裡我覺得網路資訊雜誌這篇寫得蠻不錯，不過有一點並不太同意：「讓程式開發人員與 Power User 更離不開 Firefox」。

就算不提這本來就是個跨瀏覽器都能用的專案，我的觀點是，Mozilla (and MozTW) 做的事情並不是為了要讓大家黏住。例如你可以拿 Bespin 回去修改、整合在自己的專案裡 (已經有人對他的 XWiki 動手腳了)，或者想像一下 Google App Engine 裡附上 Bespin 讓開發者在只想小修的時候也有個方便的工具；上面這些整合方法都可以把 Bespin 乃至於 Mozilla 的品牌名稱全部拿掉、僅留簡單 credit，並且弄出完全不同的計劃 (像 WebKit 與 KHTML)。Mozilla 得到什麼？除了所謂的理念推廣或者品牌印象之外，absolute nothing。如果 Mozilla 企圖讓人減少選擇，那麼我們這群支持者會第一個跳出來對幹。

加入吧！

所以總之，如果你對這類工作模式有興趣，也熟悉 JavaScript，或許可以考慮參與這個專案。只要一點點力氣、寫個 command 或許就造福很多人，這是十分輕鬆的貢獻方式。

隨手記：昨天後來有跟另一位先生聊天，他問話的方式我其實不很喜歡 —— 「你們做這個都是為了好玩嗎？會考慮商業價值嗎？」這幾件事情不衝突，我們該接受的挑戰就是如何兼顧。畢竟，你知道資訊流竄的未來，並不是想辦法固守機密就能存活的時代。Copy 太簡單，方法也太多了。

七夕殺傷力最強歌曲

2009-08-29T16:27:00.002+08:00

聊天的時候突然想到來做這個東西好了，立刻就發了 Plurk 讓大家推薦。說是「最強」其實各人定義肯定不同，所以這邊只是整理一下就不做所謂的「排行榜」了，有興趣自虐的可以找來聽 XD。

我現在才要通通看一次，所以可能會刪掉一些資格不符的歌 XD

無交往經驗組

我愛的人愛別人組

要區隔一下：這組是「暗戀對象不愛我」的，如果是因為對方隊狼造所以被甩的請一律前往被甩組。

好朋友
我愛的人
一千萬個理由
Last Dance
你的背包 (個人覺得這應該去其他組或被甩組)
茉莉花
十年 (個人覺得這個應該去其他組)
暗示
GOODBYE MY LOVE
永遠的戀人
~~婚禮的祝福~~ (reject: 應該去被甩組，因為是分手了)
我懷念的
他不愛我

被甩組

其他組

應該會有些特例吧？像是不知不覺就分手了、雖然還沒分但跟分了沒兩樣、曖昧數年還沒正式開始、暗戀但對方是木頭、被劈腿但是打死不分… 啥的，反正通通歸到這裡來。

Ladies and Gentlemen We are Floating in Space
紅豆
越愛越傷心 (找不到影片)
你是我的寶貝
我不會愛
影子 (大概太新了，找不到李玟的版本耶)
多想把你抱住
猜不透

軟杯杯真好，幫我找了好多影片 :P

Put OGV on Internet Archive

2009-08-26T14:55:00.003+08:00

我經常覺得有些選擇的出發點攸關理念，因為所謂「政治正確」的理由而下了決定。就好比因為「開放標準」、「先進技術」等品牌印象上的需求，我會希望 COSCUP 2009 所有演講影片除了傳上好用(但不完全「開放」) 的 YouTube 之外，還可以轉成 OGV 放上 Internet Archive。

這次的 COSCUP 全面採用硬碟式 DV 錄影，錄下來的影片不需要再額外轉為檔案、可以直接處理。在不討論批次轉檔的情形下，Linux 裡的 OggConvert 真的是很直覺方便的轉檔小工具 —— 選、轉、完成，不用花太多腦筋，很適合我這 EndUser。轉檔所需時間要看你的設定，在我的電腦上 250 MB 的影片 (MP4, 720HD, 大約五分鐘) 要花上 12 分鐘左右的時間… 是有點久啦，或許壓縮比調整後會快一點，懶得試了 :P 轉好檔案之後就可以開始上傳。

由於影片較大，我採用 Internet Archive 提供的 FTP 上傳方式。如果你跟我一樣、是採用 OpenID 登入 Internet Archive，此時會發現一個問題：FTP 上傳需要的帳號就是你的 Email，不過密碼呢？Internet Archive 當然不會知道你在 OpenID 服務那裡設定的密碼為何，所以其實他們內部有準備另一組密碼給你，只要前往 Patron Info 裡的「Forgot Password」填上 Email 即可，系統會寄給你這個帳號的密碼 (是一組亂碼)，你就可以用這組帳號和密碼登入 FTP 開始上傳囉！詳細的操作步驟，可以參考別人寫好的圖文教學。

傳好檔案後還要去「Check In」，表單挺複雜、但必填的欄位不多，無論如何填好後你的檔案就會在他提供的網址上出現了。既然已經將 OGV 傳上 Internet Archive，不來試試 HTML 5 的 VIDEO 標籤不是很可惜嗎？ :P

喔喔~ 你的瀏覽器不支援 OGV 原生影片呢！快換瀏覽器吧！ XD (Safari 使用者：請要求你們的瀏覽器開發者加入 OGG 支援！) 這邊先提供 YouTube 上的版本：

下載 OGV 回去看

如果你的瀏覽器還不支援 VIDEO 標籤，這個網頁的寫法會自動提供 YouTube 影片供您觀賞；要是你連 YouTube 都看不了，那就只好提供一個連結讓你下載影片回家看囉！除了 Internet Archive 之外不知道還有哪個免費的影片服務可以支援直連 (HotLink)、可上傳容量又如此無限的，大家還是要支持一下介面難用的 Internet Archive 啊 XD

軟體自由協會代收社群捐款辦法

2009-08-19T22:11:00.004+08:00

我在 COSCUP 宣傳 SLAT 的代收捐款辦法，內容簡介直接看影片前半段吧，代收辦法在此。

COSCUP '09 主持心得

2009-08-18T03:39:00.003+08:00

我在這次 COSCUP 因著 MozTW 的屬性主動接下了「Cloud Computing and Web technology」以及「Promoters」議程，其實準備上還花蠻多時間的。在這邊分享一下我的準備流程，或許可以幫我 Debug：

心怡妹妹的通知函超貼心列上每個講者的 Email，我就寄了信給每個講者。內容就是就自己對講者的認識先哈拉、通知講者我是主持、我會怎麼介紹你、你幾點會到會場測試、是否需要其他協助。由於內容大同小異，GMail Labs 的 Canned responses 幫了不少忙。
除非講者有給我其他補充資料，不然我就是照著講者原先提供給大會的個人介紹來抓句子準備介紹資料了。至於議題部份，有些超出我涉獵範圍的，先稍稍查一下。不用太緊張反正講兩句就過了…
我這次沒有做到的是事先準備問題發問(避免冷場)，不過這次時間都很緊、我自己決定沒有問題就跳過。
我寫了份文件幫助我主持，在聽講同時不斷修改以便符合最新狀況。(其實我是為了發份文件讓大家參考才想到可以來寫這篇 post 的 XD)

我自己是給我的主持表現打了還不錯的分數，但是我是人當然會有盲點 orz 很希望大家能喜歡這樣的主持方式，也或許你根本不記得我？ XD 有什麼回饋都歡迎留言。

也請參考會前寫了但忘了寄給所有講者的 Tips for Hosts (身為議程組要跟大家致歉 orz) BTW 我到現在還不敢檢討身為工作人員的自己 (炸~)

使用、推廣、開發等角色與 GFX

2009-08-13T05:26:00.003+08:00

自由軟體的參與者，依據 COSCUP 的分類法是開發、推廣、使用三個層面(我完全不知道這是誰先提出來的，所以請恕我無法準確姓名標示 :P) 。這三層有些要點：

所有人一定至少是使用者，不使用但參與開發和推廣的難有熱情支撐
推廣者不見得會開發
開發者不見得想推廣
以為自己會開發的推廣者跟以為自己會推廣的開發者都很多

所謂的推廣者，在這邊我想稍微清楚由自己的角度定義一下。「推廣行為」指會直接擴展使用者或貢獻者數目的行為，所以如果只是接 ticket 開發就很明顯不是，而跟左鄰右舍好康倒相報的算是。幾年前 COSCUP 網站上曾提過推廣者是「把軟體包裝成套件」這類的，雖然打包的技術門檻不很高、不過畢竟稍稍有一點，所以我私心還是會推到「兼具些微開發能力的推廣者」或「兼具推廣興趣的開發者」那邊去。

又，之前也提過消費者和使用者的區別，但我這邊先混雜在一起了；如果強要分類的話，我想由於軟體的開發畢竟還是萬事的起源，所以行為無法對開發這件事情有直接或間接貢獻的、或許就可以算是消費者。無論如何這邊先不分，那麼以此三者應該可以繪製成這樣的圖：

既然都被稱為是三隻腳了，理論上三者的關係應該會是彼此互助通力合作的：

不過實際上由於種種因素，我個人的感覺好像是這樣：

這邊看起來好像使用者能做的事情真的很少。以前就提過關於貢獻率的問題，我一直在想：有什麼是單純作為一個使用者可以貢獻的事情？

捐錢贊助自己支持的軟體，此為正解。
跟朋友推荐嗎？那你就變成推廣者了 (恭喜~)

…後來發現自己真的想不太到，這樣要怎麼提高貢獻率呢？要大家多捐錢嗎？ (你捐了嗎？)

我想 GFX 或許就是路徑之一。如同之前所說，我自己是希望「提供更多、更輕鬆並且容易抽身的參與機會，讓人進來先挽起袖子動手碰碰看再說。」除了方便推廣之外，也更提供一個「讓你自己說」的途徑。整個專案從頭到尾，我們都希望把「選你自己的選擇」這個意念傳達給使用者：你不需要在我們站上註冊、用你自己選擇的帳號供應商就好；你不需要侷限於 Firefox 產品頁上的介紹文、選你自己推薦的理由就好。這就是你自己的推薦網頁，你自己可以做決定。當然限於時間人力等因素，我們還沒有辦法做到更高度的自訂，但的確是朝著這個方向前進的。

朝著這個方向前進，也就是說除了勸大家多捐錢之外，我們正試圖讓更多一般使用者也能搖身成為推廣者。

目前 GFX 已經為我們多帶了數百位推廣者進來，這些人裡很多我們早已熟悉、也有很多是先前不認識的，無論如何效應的確有做出來。接下來或許就是要好好考慮幾個方向：

怎麼讓推的人覺得更有意義？成就感更高？
怎麼在加強自訂功能與降低複雜度間取得平衡？
還有什麼 Open 的概念可以幻化為其中的功能、介紹給使用者？

一直記得推廣活動的成功與否要看能帶進多少長期參與者。一切應該會更好吧，我這麼相信著。

用 GFX，告訴別人你為什麼愛火狐！

2009-08-04T18:00:00.000+08:00

那麼為什麼要用 Firefox 呢？我的理由是：

你的理由呢？快到 http://gfx.tw 去設定吧 :)

顛覆網路 35 天：SVG + Video = 滾筒洗衣機！

2009-07-24T17:27:00.000+08:00

這一篇，我們將再度見識混搭網際標準時可以展現的效果，先來看看範例：

View the Demo in Firefox 3.5

這個範例中，我們在 SVG 文件裡塞了個 HTML 5 的 VIDEO 標籤。以下是精簡過的程式碼：

<svg:svg xmlns:svg="http://www.w3.org/2000/svg"
               width="194" height="194">
  <svg:foreignObject x="1" y="1" width="192" height="192">
    <html:video src="tristan3.ogv" ontimeupdate="rotateMePlease()"/>
  </svg:foreignObject>
</svg:svg>

播放鈕什麼的也是用 SVG 做的喔！此外這範例裡也利用了 Firefox 3.5 中的 CSS 套用 SVG 濾鏡功能，如下：

#video {
    filter: url(#filter);
    clip-path: url(#circle);
}

這個 clip-path 特性能為任何元素 (html、svg 等) 定義裁切路徑，可以是任何以 SVG 繪製好的路徑，超強的喔！例如本例裡的 #circle 路徑原始碼如下：

<svg:clipPath id="circle" clipPathUnits="objectBoundingBox">
   <svg:circle cx="0.5" cy="0.5" r="0.5"/>
</svg:clipPath>

而 filter 特性則能定義 SVG 濾鏡，本例裡我們採用的是 feColorMatrix：

<svg:filter id="filter">
  <svg:feColorMatrix values="0.3 0.3 0.3 0 0 0.3 0.3 0.3 0 0 0.3 0.3 0.3 0 0 0 0 0 1 0"/>
</svg:filter>

影片播放後，我們利用 transformation 來讓影片元素旋轉：

function rotateMePlease() {
    // Sure
    if (!video) return;
    video.style.MozTransform='rotate(' + i + 'deg)';
    i += 3;
}

作者 Paul 把所有程式定義在 XHTML 文件中，並且處處使用良好的 XML 語法及名稱空間，不過你可能會想在 HTML 文件中使用一樣的效果。Firefox 3.5 裡可以參照外部 SVG 文件，你就不必把原本的 HTML 整個轉化為 XHTML 了：

.target { clip-path: url(resources.svg#c1); }

從這個範例裡你可以看到混搭 SVG、HTML、VIDEO 及 CSS 的威力，好好玩喔！

顛覆網路 35 天: 色彩校正

2009-07-17T12:48:00.002+08:00

是的我拖稿。

說到色彩校正 (Color Correction) 功能，其實在 Firefox 3 時已經有基本的支援，只是預設是關閉的；Firefox 3.5 裡將校正的速度提升到 Firefox 3 的 5 倍快，也終於預設就開啟這項功能。現在就來看看色彩校正的威力：

不過網路上大部分的照片都沒有色彩校正資訊，所以其實你不見得可以感受得到差別就是。無論如何，多學習一下相關的知識也不壞囉！

所以色彩校正是啥？

如果你花很多時間在照相或影像處理等相關的事務上，那應該知道同樣的色彩在不同的輸出設備 (LCD 螢幕、CRT 螢幕、印表機等等) 上表現可能略有差異。JPG 跟 PNG 檔都支援色彩設定資訊，這些資訊可以幫助 Firefox 依據設備特性而顯示出正確的顏色；除了媒體檔本身之外，顯示設備也有自己的特性。假若某顯示裝置展示紅色的能力較展示藍色更為優秀，那麼這項裝置上的紅色 #ff0000 可能就要設定成 #f40301 才能顯示得跟螢幕一樣。總之這告訴我們，設備跟媒體檔案之間可能要經過兩次轉換才能顯現出正確顏色：一次先依據檔案本身所帶的色彩資訊、第二次則是依據設備的色彩資訊進行轉換。

所以，這關 CSS 什麼事？

網頁設計的世界中常會有需要搭配圖片及 CSS 混合排版的情形，如果你想要在圖片中繪上某個顏色、然後在與其搭配的 CSS 裡也指定一樣的色彩，或許實際出現的情形並無法如你所願 —— 因為 Firefox 裡會讓圖片經過色彩校正程序、但卻不處理 CSS，於是你看到的圖片經過校色之後、看起來跟 CSS 所設定的顏色就不見得相同，以下面這段紫色區塊為例：

在 Firefox 3 裡，你會看到一個紫色的長方形；在 Firefox 3.5 及 Safari 中，你看到的則是一個紫色邊框包覆著另一個紫色長方形 (除非你的系統色彩資訊為 sRGB 模式)。這是因為上方形成長方形的圖片部份經過色彩校正、而 CSS 部份則無。

未來的 Firefox 裡將讓使用者同時為圖片及 CSS 開啟色彩校正功能，這功能現在就可以依照 Mozilla Developer Center 上的說明來試試看，只要將色彩校正切換為「完整色彩管理」模式即可。

圖片格式支援與相關工具

PNG 檔的色彩資訊可以用三種不同方式標註：首先，可以利用 iCCP 區段嵌入 ICC 資訊；第二，可以利用 sRGB 區塊將圖片明確指定為以 sRGB 模式處理；最後，您還可以嵌入 gAMA 及 cHRM 資訊，描述圖片的 gamma 及亮度值等。這三種方式都可以讓 Firefox 利用色彩校正功能調整圖片色彩。

此外，您也可以利用 pngcrush 來移除所有色彩資訊，讓圖檔恢復為未標註的樣子：

pngcrush -rem gAMA -rem cHRM -rem iCCP -rem sRGB infile.png outfile.png

您也還可以利用 TweakPNG 手動刪除這些資訊。

其實低調也不錯

2009-07-09T02:31:00.002+08:00

到時候就是 25 個人分一些有的沒的小禮物，這些是一部份：

據說還有 3 個位子，然後今天 (7/9) 晚間報名截止這樣。

顛覆網路 35 天: HTML 5 版音樂播放器

2009-07-05T17:34:00.001+08:00

很久沒翻譯這系列文章，我發現米嘉也富奸化了… 不過他畢竟是比我維持得更久點，翻譯這類文章真的很考驗毅力的啊，大家要多給義務幫忙翻譯引介資訊的人一點鼓勵。

這篇文章裡討論的是利用 HTML 5 的 audio 標籤與 JavaScript 合作製作一個音樂播放工具，其實 WM 在之前也為 MozTW 製作了一個更炫的、所以害我每次看到這篇都沒什麼毅力翻譯… (藉口藉口！) 反正，先看看完成圖吧！

在 Firefox 3.5 中開啟範例網頁

這個範例還是很有價值的，相較於 WM 的炫爆範例，本例的作者採用了有趣的方式來實作：

<div id="jai">

  <canvas id="jai-transport" width="320" height="20"></canvas>
  <ul class="playlist">

    <li>
      <a href="@F1LT3R - Cryogenic Unrest.ogg">
        F1LT3R - Cryogenic Unrest
      </a>
      <audio src="@F1LT3R - Cryogenic Unrest.ogg"/>.
    <li>

      <a href="@F1LT3R - Ghosts in HyperSpace.ogg">
        F1LT3R - Ghosts in HyperSpace
      </a>
      <audio src="@F1LT3R - Ghosts in HyperSpace.ogg"/>.       
  </ul>    

</div>

原始範例裡的程式碼有包含 Fallback 功能而且比較複雜一點，這裡把程式碼簡化比較容易說明。你發現了嗎？清單中所有音樂項目都只是由 HTML 的列表加上 CSS 樣式展現的，每個項目都與一般 HTML 頁面的連結一樣，可以加入書籤、複製連結位置等等。JavaScript 程式會找出 ID 為jai 之 DIV 標籤中所有的 AUDIO 標籤，接著又以 SVG 加上 JavaScript canvas 的方式繪製出操作介面

用這個方法要加入新樂曲相當方便，且要在任何網站上放入這個播放器也十分容易 —— 定義一個 canvas 與列表就可以了。(相應的 JavaScript 當然要嵌入囉)

附帶一提的是，這個網頁上不但有原作者的說明，連所有的音樂也都是他自己寫的… 這也太猛了吧 XD

Firefox 3.5 台中迷你趴

2009-07-05T16:25:00.000+08:00

依照往例，MozTW 只有在大版本更新的時候會辦 Firefox Party，這次 3.5 推出也不例外。不過一方面有社群成員建議還是辦個交流性的小聚會，另一方面 Mozilla 也有準備紀念品送給各地區的派對活動，所以就讓我們在台中聚會一下吧！

時間： 7/11 14:00-16:30-18:00 (後一半是自由交流時間)
地點：默契咖啡 (台中市中港路二段60-3號)
費用：活動本身免費，低消、餐點等自費 (吃喝大概是 150-200 間)
限額：只有 25 個位子，要報要快喔！

場地有免費網路、插座，歡迎帶筆電來。內容除了分享與交流外，當然也有很多雜七雜八的小禮物會送給參加者。報名及詳細資訊請見報名網頁。

兩小時後，知床大地震！

2009-07-01T14:11:00.002+08:00

你裝 Firefox 3.5 了嗎？如果你是從 Firefox 3.x 甚至 2.x 版跳上來的使用者，想必有感覺到速度上的提昇。因應 Firefox 3.5 的 Codename —— Shiretoko (知床)，Mozilla 這次也準備了有趣的行銷活動「Shiretoko Shock」，邀請各位社群伙伴一起撼動這個世界！

怎麼玩呢？超簡單：只要你在當地時間下午 3:50 分時，上 Twitter、Plurk、Facebook 等地方邀請你的朋友們一起下載 Firefox 就可以囉！以下是一些簡單的範例句：

撼動全世界！現在就下載 Firefox 3.5: http://bit.ly/shiretokoshock-tw #fx35
(我要推這句 | 我要撲這句)

Shock with me！現在就下載 Firefox 3.5: http://bit.ly/shiretokoshock-tw #fx35
(我要推這句 | 我要撲這句)

YouはShock！馬上下載爆強爆快的 Firefox 3.5: http://bit.ly/shiretokoshock-tw #fx35
(我要推這句 | 我要撲這句)

最後一句的梗不曉得有多少人會看懂 (汗) 當然你也可以自己編寫有自我風格的詞句，只要別忘了在最後加上「http://bit.ly/shiretokoshock-tw」的網址及「#fx35」標籤；此外也不必擔心時差問題，只要在自己所屬時區的下午 3:50 「Shock」一下就行了！

從巴西時間起，每個小時都將有一次發生在世界不同時區的 Shiretoko Shock，大家一起製造知床大地震吧！

另外在台灣時間的 7/2 半夜 2:50a 其實還有一次全球的 Super Shock，這個就不邀請大家參加了 XD 夜貓子們自己參考吧 :P

Go home, IE6!

2009-06-24T18:28:00.000+08:00

"Yeah, you always break our coolest toys!"

顛覆網路 35 天 (9): 原生 JSON，更安全、效能更好

2009-06-21T08:18:00.000+08:00

JavaScript Object Notation (JSON)在網站開發的世界裡已經有很多人採用，成為不可或缺的一部份。Firefox 3.5 起以 window.JSON 來原生支援 JSON 格式，本篇 (原文) 將為各位做個相關介紹。

JavaScript 等腳本語言的標準原型 ECMAScript 在第五版時將 JSON 原生支援列入規格，目前 Firefox 3.5 跟 IE8 都支援，而且其他瀏覽器必定也會很快加入支援行列。JSON 原生支援有兩個優點：

安全性提升：單純使用 eval 來解析字串型態陳述式的方法有其安全顧慮，原生 JSON 目前單純解析資料、不呼叫函式來解析物件。
效能提升：這是應該的… 目前其他可以安全解析 JSON 的函式庫，效能都比不上原生支援的瀏覽器。

來看些範例 —— 一個以 HTTP GET 等方法傳回的簡單 JSON API 搜尋結果看起來大概像這樣：

/* 
從主機取回一段搜尋結果的 JSON 資料
*/
 
var data = ' { "responseData":
{"results": [
    {
        "SafeSearch":"true",
        "url":"http://www.arunranga.com/i.jpg",
    },
    {
        "SafeSearch":"false",
  "url":"http://www.badarunranga.com/evil.jpg",
    }
]}}';

您可以用這樣的方式處理資料：

/* 
 取回、操作上一段的 JSON 資料
 如果用支援原生 JSON 的其他函式庫，會更容易一些
*/
 
if (window.JSON) {
    var searchObj = JSON.parse(data);
    for (var i=0; i++; i < searchObj.responseData.results.length) {
        if (searchObj.responseData.results[i].SafeSearch) {
            var img = new Image();
            img.src = searchObj.responseData.results[i].url;
            // ... 在 DOM 中插入圖片...
    }
}

不過，網頁設計師通常並不直接使用 JSON 原生支援，而常用 jQuery 等函式庫自不同網域取回、解析 JSON 資料，這也是 JSON 大展身手的地方。考量到效能問題，有些函式庫已經開始採用瀏覽器的原生 JSON 能力來解析資料。目前 jQurey 與 Dojo 都已支援原生 JSON，所以您使用這些函式庫時一方面在已原生支援 JSON 的瀏覽器上將獲得更好的效能、另一方面在尚未支援的瀏覽器上也可以順利解析 JSON 資料。

授權書及時間提示工具

2009-06-20T15:46:00.000+08:00

我們經常在邀請別人演講時使用許多雜七雜八的文件，像是領據、講者名牌、講者桌牌、影音授權書、時間提示字卡、提示音… 等等東西，不過我發現好像都沒有什麼人分享這類文件，讓大家可以直接改。我這邊先把我使用的時間提示字卡及授權書範本丟出來給大家參考，都是 by-sa。

顛覆網路 35 天 (8a): CSS 3D 效果

2009-06-20T13:18:00.002+08:00

這篇有一個用 Firefox 3.5 新增之 -moz-transform 所製作出來的範例，非常有趣 (強烈建議要看啦)，一例勝千文，看了再說：

View the Demo in Firefox 3.5

當然，-moz-transform 目前還是個 2D 效果的玩意，製作出來的「3D」也是可稱為 2.5D 的視覺效果而已。目前要做到真正的 3D，用這個特性還辦不到。

來看程式碼：首先以 DIV 標籤圍出立方體的三個顯示面：

<div class="cube">
    <div class="face top">
    </div>
    <div class="face left">
    </div>
    <div class="face right">
    </div>
</div>

.cube {
    position: absolute;
}
 
.face {
    position: absolute;
    width: 200px;
    height: 200px;
}

接著把這 3 個 div 都轉為平行四邊形：

.top {
    -moz-transform: rotate(-45deg) skew(15deg, 15deg);
}
 
.left {
    -moz-transform: rotate(15deg) skew(15deg, 15deg);
}
 
.right {
    -moz-transform: rotate(-15deg) skew(-15deg, -15deg);
}

至此，三個方塊已經以平行四邊形的樣子排成正六芒星，接著我們只要調整位置即可。你可以用方程式算出三個面所應該排列的座標點，或者慢慢一步步調整到正確的地方也行。下方的陰影其實就是 top 那一面的位移複製品，只是設定了 opacity: 0.5 的背景色。另一個方塊也是把樣式與標籤直接再複製一份做出來的，並以 translate(600px, 400px) 位移、以 scale(0.5) 將尺寸縮小 50%

方塊中間要填入什麼都行，其中有一面以 HTML5 Video 標籤放入了影片，你可以看到影片也被調整成平行四邊形的樣子 :P

除了 Firefox 3.5 之外，Safari 3.1+ 與 Google Chrome 亦以 -webkit-transform 的型態支援。相關文件可參考 https://developer.mozilla.org/En/CSS/CSS_transform_functions

姓名標示，要標什麼？法律嚴肅版

2009-06-19T15:50:00.001+08:00

之前曾寫過姓名標示，要標什麼？要標哪裡？一文，大概說明我個人看法。其實 CC 授權條款裡面也有明確告訴你要標哪些東西，我們以 3.0 預演版的條文來說明一下。首先是 4. 限制的 (a)：

您必須在您散布或公開演播的每份重製物上，附上本授權條款複本或「統一資源識別符」(Uniform Resource Identifier) …… 保留所有與本授權條款有關的注意事項以及免除保證責任聲明

所以這邊就有兩個：授權條款的複本或 URI (粗略想成是授權條款的網址吧)，與保留授權條款有關的注意事項及免除保證責任聲明 (原來有的請別刪，原來沒的也不用加)。

接著是 4(d)，這邊很多一段段來看：

(i) 若有提供原始著作人姓名（或筆名），則您應提供之，且（或）若原始著作人及（或）授權人，在授權人的著作權聲明、使用條款或藉由其他合理方式指定第三人（例如，贊助機構、出版者、期刊）為姓名標示的對象（「姓名標示對象」），則您應提供該第三人的姓名；

簡單講就是作者指定的名稱，看是本名、筆名或其他單位 (例如贊助商、公司等) 的名稱。

(ii) 本著作名稱；(iii) 在合理實際可行的範圍內，授權人所指定與本著作相關之統一資源識別符，除非該統一資源識別符並非連結至本著作的著作權聲明或與關於本著作之授權資訊；

作品名稱跟作者指定的網址。

在改用作品的情況，則必須註明在改用作品中使用了本著作（例如「原始著作人之本著作的法文譯本」、「依據原始著作人之原著作而改編的電影劇本」等）

如果是改用作品 (修改他人作品而成的新作品)，則要標註使用了哪些東西。不過有鑑於單一改用或彙編著作可能利用了太多作品、會標到天荒地老又耗費資源，這邊有個折衷方法：

在改用作品或彙編之情況，對改用作品或彙編全部有貢獻之作者若使用單一的表彰時，則本項所要求的表彰，最低程度應作為前述表彰之一部分，並至少與其他具有貢獻之作者的表彰方式同等明顯。

意思就是說只要所有被引用的作品標示的方式都一樣明顯的話，可以允許從上面那幾種標示方法裡選一部份使用即可，不需全放。

所以到底要放什麼？

整理一下，如果你只是單純引用、重製散佈別人的著作，那麼記得標上：

原始作品授權條款的複本或授權條款的 URI，以及
作者指定的標示名稱，沒指定就是放他本名或筆名。還有
作品名稱跟授權人指定的網址，沒指定的話可以不放網址。

也就是說，最少會放上授權條款 URI、作品名稱跟作者姓名。

如果這是改用或彙編(編輯)著作，那麼就是依據同樣的原則、把每個用到的作品都標上去。但只要所有用到的作品標示都一樣明顯，則作品名稱、作者姓名、授權人指定的網址這三者可以不用全放。(原著使用的授權條款要標示，不然會很混亂。)

其他可能？

4(a)裡其實有一個特殊的部份：

若您創作彙編，則應在收到任一授權人通知時，於實際可行的範圍內，依其要求移除彙編中，如第4條第(c)項所定對於原始著作人及／或其指定第三人的表彰。若您創作改用作品，則應在收到任一授權人通知時，於實際可行的範圍內，依其要求移除改用作品中，如第4條第(c)項所定對於原始著作人及／或其指定第三人的表彰。

意思就是說，在改用及彙編作品的情況下，原始作品授權人可以要求不要放他的名字 —— 除非已經獲得明示說可以不放，不然還是得先放上去喔！

顛覆網路 35 天 (7b): Firefox 3.5 media query 簡介

2009-06-18T14:54:00.003+08:00

原文出處，篇數太多不曉得怎麼開頭了 orz 反正大家看這系列下來應該都知道我是重點節譯。

現在可以上網看網頁的裝置越來越多，大家對網頁的期待也因裝置限制或功能而有所不同。CSS2 因此加上了媒體類別相關的設定，讓你可以指定某 CSS 宣告適用的裝置，像這樣：

<link rel="stylesheet" media="print" href="print.css">

這樣的確有效解決某些問題，不過網頁設計師要面對的不只是裝置的不同：即便是同一類型的裝置，也有可能有直放、橫擺、螢幕大小、解析度等等各式各樣的問題。Firefox 3.5 開始支援 CSS3 草案的 media query (媒體型態查詢) 機制，提供因應裝置各項特性而套用不同樣式的能力，讓各式裝置可以更適切地套用相應的樣式。以範例網頁來說，如果顯示範圍高大於寬 (直式)，則「all and (orientation:portrait) 成立、套用 portrait.css 樣式：

<link rel="stylesheet" media="all and (orientation:portrait)"
 href="portrait.css">

而如果顯示範圍寬大於高 (橫式)，則套用 landscape.css：

<link rel="stylesheet" media="all and (orientation:landscape)"
 href="landscape.css">

最棒的是，每次螢幕狀況有所轉換時，都會重新計算、套用一次樣式，所以當你以橫式的視窗開啟範例後，不妨慢慢調整視窗大小；一旦高大於寬 (變成直式)，套用的樣式會立即變更。

如果你打開 landscape.css 瞧瞧，會發現其中的某些樣式也採用 media query 來調整。例如網頁文字尺寸預設為 14px，但若顯示範圍寬度至少有 600px，則改用16px 字體顯示：

@media all and (min-width: 600px) {
  body {
    font-size: 16px;
  }
}

倘若顯示範圍再大一點、至少有 700px 寬的話，則採用 20px 的字體尺寸顯示文字：

@media all and (min-width: 700px) {
  body {
    font-size: 20px;
  }
}

還有另一條規則讓 800px 以上寬度的顯示介面擁有更大的字體，不另贅述。總之，當你調整視窗大小，就可以馬上發現變化。有一個不錯的應用點子，是隨著螢幕寬度調整內容欄數 — 越寬的的螢幕，分成越多欄來呈現。

目前 Firefox 3.5、Safari 3、Opera 7 以上的瀏覽器都媒體型態查詢，一般來說新版本瀏覽器是加上更多型態或查詢方式。Firefox 的相關文件請參考 MDC，而 Opera 9.5 的相關說明則在這篇接近最後的地方。目前沒有找到 WebKit 的相關資料。

無論使用者用哪樣的裝置瀏覽你的網站，利用媒體型態查詢功能、可以讓你做出更方便他閱讀的網頁。我的網誌應該會採用相應的技術來製作邊欄，你也試試吧！

顛覆網路 35 天 (7a): 開放影片編碼格式的品質

2009-06-18T01:50:00.003+08:00

這篇主要比較開放影片編碼格式的品質問題，緣起是 Google 的 Chris DiBona 在 WhatWG 郵件群組貼了一篇文章，裡頭提到：

如果 YouTube 要採用 Theora 編碼、還得維持目前的播放品質，那會佔掉全世界大部份的頻寬。

目前關於影片編碼的論戰已經慢慢嘴炮化、缺乏實質的比較，所以 Greg Maxwell 回了他一篇、並放上下列的比較結果。(本篇由原作者授權張貼於顛覆網路 35 天專欄，柏強我只依據往例、節譯重點。)

以下是將同一段影片分別以兩種尺寸編碼、丟上 YouTube 處理後再下載，然後與 Ogg/Theora+Vorbis 比較的情形，各位可以下載觀看以便比對。

~499kbit/sec 比較

YouTube

Download (H.264+AAC; 17MiB)

Ogg/Theora+Vorbis

Download / Watch (Ogg/Theora+Vorbis; 17MiB)

~327kbit/sec 比較

YouTube

Download (H.263+MP3; 12MiB)

Ogg/Theora+Vorbis

Download / Watch (Ogg/Theora+Vorbis; 12MiB)

位元率都分別標示出來了，而 Theora 的版本故意稍稍降一點位元率，以防止略大一些的檔案大小會被懷疑是故意提高品質。要真的公平比較的話，請把音效也考慮進去，光看靜態圖片絕非比較影片品質的好方法。這邊的靜態圖片只是為了方便讀者而做。

製作方法

以下是這四個檔案的完整製作方法：

影片來源是 Blender 基金會以創用 CC 授權的動畫片 Big Buck Bunny，版權無慮。在此使用 media.xiph.org 上下載的無失真 640x360 PNG 與 FLAC 版。
以 ImageMagick 的轉換工具重新取樣成 480x270。
使用 gstreamer 的 jpegenc，設為 quality=100 的 mjpeg + PCM，產出大約 1.5GB、位元率約為 20Mbit/sec 的檔案。
將檔案裁剪至 1G 以便符合 YouTube 的限制，產生 input_mjpeg.avi 檔 (706MiB)。
將檔案上傳到 YouTube，交給它轉換。
下載 YouTube 產出的 FLV 即 H.264 格式檔，工具很多種、在此用的是 keepvid
將原始的 input_mjpeg.avi 以 libtheora 1.1a2 與 Vorbis aoTuv 5.7 產出位元率約當於 499kbit/sec 的檔案，這個數值與 YouTube 產出的檔案相同。
將 input_mjpeg.avi 再重新取樣產出一個 400x226 的檔案。
接下來步驟同上一個檔案，最後再以一樣 libtheora 1.1a2 與 Vorbis aoTuv 5.7 產出位元率約當於 327kbit/sec 的檔案，這個數值與 YouTube 利用 400x226 的影片產出的檔案相同。

Greg Maxwell 的結論

較低品質的兩段影片很難辨出高下，而就算是高一點的品質、YouTube 目前所採用的方式也不見得就高到哪裡去。這樣的品質下四段影片檔必定各有缺點，而取捨就見仁見智。
就以我 (Greg) 的觀點，在 327kbit/sec 的影片 Theora+Vorbis 的格式遠勝過 YouTube 使用的 H.263。遇上聲音更明顯：Vorbis 版可以聽到片頭的蟲鳴、而 YouTube 的檔案中就聽不見了。
高品質的部份，在細細比較後可能大家會比較偏好 H.264 的版本，但差異不很大，大部分的人應該都分不出來。

Greg Maxwell 的信件可以查閱原文。

更高畫質的影片呢？

拜我偷懶到今天才動手看這篇所賜，有另一篇補充的文章可以即時一併翻譯。Maik Merten 為 HD 畫質的影片也做了比較，截圖如下：說實在差異不大，而且 Theora 的仔細看感覺好像還比 H.264 更好 (注意頭髮的地方)。別忘了看看影片來比較喔：

H.264

Theora

所以綜上所述，別嘴炮了，要比較畫質還是實際用眼睛看看吧。

BobChao the Blogger

Firebug 頁籤文字太小的繞路解法

推薦 K24, 我的觀劇亮點

關於社群式管理的心得隨筆

A fox in your pocket - 測試 Firefox 行動版瀏覽器

Aurora 與 Nightly

中文在哪？

回饋

無題

Link Mozilla F1 with Ping.fm

2011 年的第一天，午夜子時你在哪裡？

社群

其他

MozTW 的聖誕禮物？Foxmosa & Firefox 明信片來了！

FAQ

MozTW 是什麼神秘組織，有什麼目的？

是用送的還是要付錢？

你們哪裡有錢印這些？

一人可以拿幾套？

什麼時候開放登記索取？

我還有問題！

生活與工作的雜記，一篇。

在 Aptana 中開啟 JSLint，即時打槍你的 JavaScript

It's official: Firefox 4 Party 延期

Firefox 4 的 HTML5 表單

輸入欄位新型態

輸「出」欄位

輸入欄位的備選清單

輸入元素新屬性

autofocus

placeholder

解構式表單

form 屬性

欄位中的各種表單選項

表單驗證

必填資訊 required

網址 url

電子郵件地址 email

進階驗證 API

新的 CSS 選取符

:required、:optional

:-moz-placeholder

瀏覽器相容性與標準制定

互動素描標記法 v0.1

紀錄片從業人員職業工會 CC 介紹

完美的 404

不要指責

404 必備

聰明點

打錯的網址

搜尋引擎連結過期

站內失效連結

那如果你自己的網站有問題呢？

修正錯誤

相關連結

24 個你可以提昇 Firefox 使用體驗的機會

New Ubuntu, count down!

失敗的 SEO 例子 (update)

嘿，我要走了

社群？

Default Settings of CamStudio For UX Test

Video Options

Cursor Options

Recording

Program Options

立馬加入 W3C 中文 HTML5 討論郵件群組！

2010 CC 亞洲會見聞錄 (3): 社群，結語

「其實我們也不知道為什麼」

給30歲左右人士的實體活動

資金充裕？

實體空間是重要的

有魅力的領導人會加分

世界的自由社群都一樣

結語

2010 CC 亞洲會見聞錄 (2): Open, 以及 CC 司法領域專案會議

Closing Keynote: Open

CC Asia Meeting

2010 CC 亞洲會見聞錄 (1): CC 亞洲會

CC Conference

Sharism

`form` 屬性

必填資訊 `required`

網址 `url`

電子郵件地址 `email`

`:required`、`:optional`

`:-moz-placeholder`