顯示具有 Mozilla 標籤的文章。 顯示所有文章
顯示具有 Mozilla 標籤的文章。 顯示所有文章

2015/8/28

Use Firefox OS "lightsaber" on Flame

EN: I'll make a note as a "lightsaber quick install guide" here.

Firefox OS 新的 Add-on 等功能都在 lightsaber 上,要安裝稍微得費點勁,這邊分享一下最速達陣手法:

「不必」自己 build Gecko

EN: You don't have to build the whole gecko from mozilla-central, just use the nightly and it works. Check Updating your Flame and choose the https://ftp.mozilla.org/pub/mozilla.org/b2g/nightly/latest-mozilla-central-flame-kk/ builds.

lightsaber 上面叫你自己從 mozilla-central 重新自建 Gecko,但其實光是要嘗試新東西的話無此必要,只要更新 Flame 到 mozilla-central 的 nightly-build 就好:

https://ftp.mozilla.org/pub/mozilla.org/b2g/nightly/latest-mozilla-central-flame-kk/

如果不知道怎麼升級,請見 Updating your Flame

拿把光劍

EN: then, follow the quick setup section in the README.md of lightsaber, but be sure to remove the "GAIA_DEV_PIXELS_PER_PX=2.25" part.

接著就要把光劍裝上去,其 Readme 裡有最速捷徑

sudo npm install -g bower && sudo npm install -g gulp && sudo npm install -g apm && sudo npm install -g grunt-cli && sudo npm install -g browserify
git clone https://github.com/fxos/lightsaber
cd lightsaber
make install
make sync

我這邊故意少複製了一行,原因有三:

  1. 我在 make sync 時有跳錯誤,如果發生錯誤無論如何就上網查一下,通常都是什麼東西沒裝好。
  2. 這邊有可能會問你要裝哪種 gaia-icon,我反正是挑最新的
  3. 這份 Readme 主要寫給 Z3C 用,如果你好傻好天真地照辦那在 Flame 上就有問題了。

最後一行是真的要把 Gaia 裝上去,作為日用機,我常用的參數是這樣:

  • 要掛 Mozilla 的品牌: MOZILLA_OFFICIAL=1
  • 日用,跳過測試用 App: PRODUCTION=1
  • 跳過啟用導覽與設定: NOFTU=1
  • 開啟 adb 連線除錯: DEVICE_DEBUG=1
  • 開英文跟注音鍵盤: GAIA_KEYBOARD_LAYOUTS=en,zh-Hant-Zhuyin

如果你也要裝中文語系和設定上去,參考小帥提提供的古早資料,將語系抓下來,再以 language.json 指定一下啟用的語系即可。你的最後一行指令可能長得像這樣:

DEVICE_DEBUG=1 PRODUCTION=1 MOZILLA_OFFICIAL=1 GAIA_KEYBOARD_LAYOUTS=en,zh-Hant-Zhuyin LOCALE_BASEDIR=locales/ LOCALES_FILE=locales/l.json make reset-gaia

最後

沒有下一步了,就是這樣喵。雖然手上有 Flame 又不屬於 MoCo 的華人不多,但還是分享一下順便當自己的筆記 -- 我近兩年前寫的 build Firefox OS 筆記,現在還是很好用 :P

2014/3/10

Introducing MozTW Badges - Mozilla 台灣社群徽章系統

Badges
"Badges" by libraryems on Flickr

[English summary]

We, Bob Chao and goescat from Mozilla Taiwan (MozTW) community, are building a badge system to recognize the contribution of Mozilla community members and have fun. This article shows the idea.

Currently we have a basic structure with few badges as samples, and we are invite people (you!) to submit / design more badges with tools, include the (localized) Badge Maker Offline Toolkit provided by Snook.

Here we drafted the design principles of MozTW Badges:

  1. Encouraging people to contribute to Mozilla projects
  2. Set up contributing pathway, helping community members to experience more.
  3. Identify the ability of community members.

... and also 4 categories of badges: Events / Achievements, Roles, Abilities, Contributions.

Community members can design their own badges and submit to the system. Once we make sure that the design fits the principles, we will include it to the system.

You may have heard that Mozilla designed a few badges for community, like this, this, this, and this. But we still need some badges for things that related to local projects -- MozTW Badges fits the needs, and also works as a hub for different projects to showcase / promote their badges.

MozTW Badges is still a prototype, and we are trying to figure out a method to use badge system to encourage people join / enjoy the community. We will keep posting updates on this blog.


小遊戲當道,大家對於各式各樣的「成就」、「徽章」也不至於陌生 -- 你在遊戲中達成了某些條件後,就會「解鎖、被授予」徽章來表彰你的成就,而透過一次次的累積或許還能得到什麼特別的功能、圖片等等。其實說到底,這跟我們小時候可能都拿過的「好寶寶貼紙」或許也有異曲同工之妙,一方面以有形的貼紙獎勵你,二方面也進一步激勵你取得更多貼紙、以換回更好的東西。

換個方向,其實這些徽章 / 貼紙同時可以拿來證明了你有某些能力、參與過某些事件等等。有很多平台也已經支援這樣的系統來鼓勵使用者多多參與,例如大家可能都聽過的 Foursquare,甚至紅到讓粉絲成立 Foursquare 的徽章網站

The MozTW Badges

近期,我跟社群成員 goescat 正在設計一套給 MozTW(Mozilla 台灣社群)使用的徽章系統 -- 姑且先稱為 MozTW Badges。這套徽章系統希望可以在許多層面幫上社群成員,包括:

  • 讓各種社群成員表彰彼此的貢獻,鼓勵大家發展各種能力
  • 知道誰確實對什麼東西有其(已獲驗證的)能力與經驗,藉此協助社群成員分析我們自己的優缺點,或是尋找幫手
  • 更重要的是:蒐集獎勵徽章本來就是件有趣的事情,看技客們滿載貼紙的筆電外殼就知道了 :P

許多技客的筆電外殼,貼滿花花綠綠的貼紙,表達自己的屬性

Structure

在設計這套徽章系統的架構時,我們先考量了社群對於徽章形態與作用會有哪些需求。

目前草稿如下:

作用與形態

徽章的設計目的應該要照顧這些要點:

  • 鼓勵參與貢獻:絕大部分的徽章設計,都將以此為依歸。
  • 鼓勵精進自我能力:借由徽章本身的鼓勵性質,鼓勵社群成員自我挑戰、獲取經驗
  • 識別社群成員能力:徽章先天會有「分類」的性質,以此也能識別整體社群的能力,以強補弱

而進一步區分為四類:

  • 獎勵參與各種事件:這個十分常見,例如參與當季的連續聚等等。這類徽章拿了以後終身不會過期,主要其實也是有趣與紀念使用。
  • 特定身份識別:例如在地化經理、社群聯繫人、Mozilla 校園大使、Webmaker 輔導員等等特定身份。這類的徽章或許能被取消,無論是「到期」或是借由其他方式取回。以這類徽章當作身分證明,或許不見得容易被人接受,但至少我們可以創造視覺印象上圖片與身份的對應。
  • 證明擁有特定能力:或許是因為上了什麼課程,或提出什麼證據,我們可以證明該社群成員具有特定能力,並頒發這類徽章。
  • 獎勵特定領域貢獻:證明擁有特定能力的徽章或許不見得適合由社群以分散決策的方式發送,因此在這個部分我們另外也加上更實際對 Mozilla 有幫助的獎勵特定領域貢獻徽章。而這樣的徽章應該是用來表彰貢獻經驗的,因此會隨著貢獻量升級。以此,我們更強調要把會的技能拿出來用,而不只是學了就好。

這張圖展示了上述的分類與要點:

分散式設計

徽章畢竟還是會有「發放機構」的問題,為了嘗試保有社群的分散式風格,我們一方面將鼓勵大家設計自己關心領域的徽章(例如,Ernest 或許會想設計 SUMO 的貢獻徽章),二方面也歡迎提名應該獲得徽章的夥伴。

此外為了在具備分散式特色的同時也保持一定的外觀統一識別,我們規劃了一些簡單的要點提供大家參考:

  • 形狀:目前我們建議依據徽章類別調整徽章的形狀
    • 五角星:單一事件
    • 六角星:證明擁有特定能力
    • 八角星:獎勵特定領域貢獻
  • 色彩:建議同一群的徽章採用相同色系,或可用深淺不同來說明等級
  • 標記數字:有些情況也可以用標示數字的方法來明確說明徽章等級,可以用加註圓框數字的方式處理。
  • 單一事件、角色識別兩類其實不用太拘束,可以盡情發揮無妨,但需盡可能追求簡單扼要,例如避免在徽章上塞太多文字 -- 那樣反而也無法一眼識別出是哪個活動。

舉例來說,這是給所有第一次參加 Mozilla 台灣社群相關活動夥伴的「Hello Foxmosa」徽章,屬於單一事件形態,採用五角星:

另外針對對外推廣 Mozilla 相關事宜的演講者,則有「摩力講師」徽章,獎勵這方面的貢獻。

若演講次數多,則將另外頒發「明星講師」徽章,以顏色區別其不同

上述的徽章名稱都是暫時取的,圖案僅供調理參考、實際內容物參見標示。或許出外演講超過二十次的夥伴我們應該給個「現實扭曲力場」徽章也說不定 :P

為了兼顧分散與集中的優點,MozTW Badges 也應該有個網站集中宣導各種社群成員可獲得的徽章。我大概規劃了個草稿,可見此圖檔,有機會再另外撰文描述。

在地關懷

事實上 Mozilla 也正在規劃給整體社群使用的徽章,目前已經有幾個兼具紀念與實驗性質的作品,大致也都落在前述的分類中,舉幾個例:


Peter 獲得的 webdev - 50 pull requests merged 徽章

MozTW Badges 與之不同之處,為專注於台灣社群的相關事務。事實上個人也覺得各個子團體(按地區、語言、能力等等區分皆可)應該都要有一套不會與 Mozilla 的徽章系統打架的徽章系統,以便處理例如「協助在地化網站架設」、「協助在地專案規劃」等等從全球角度比較難兼顧的部分。

而既然 Mozilla 在 2014 年的目標之一是推廣 Open Badges(可視為為了徽章跨平台通用性,而制定的一套徽章後設資料,以及相關發送、展示、驗證機制),我想今年對於徽章的設計與規劃只會多不會少,有些全球通用的徽章點子也應該送往相關人員處。

發送徽章

在目前的實驗期間我們將先採用 https://badges.mozilla.org/ 這個平台發送徽章。其實還有很多徽章發送平台我們還需要繼續測試,例如 Mozilla 剛推出的 BadgeKit。歡迎跟我們一起研究適合的發送平台。


Mozilla 甫推出的 BadgeKit,目前還在 Private Beta 中

下一步

這篇文章只先描述我們的基本想法,接下來還有很多事情可以做,也歡迎大家協助:

  • 參與實驗:試著取得第一個 MozTW 徽章:只要在 MozTW 相關活動中與任一個已經擁有「Hello Foxmosa」徽章的夥伴見面,就可以請他提名你取得這個徽章 :D 我們也會不斷在這個 blog 更新相關的新實驗。
  • 參與規劃:歡迎到社群討論群組針對這個想法發言規劃。
  • 一起設計:把握前述原則後,歡迎提供新的徽章設計。您可以下載由 Snook 提供、已經翻譯為中文的「徽章設計離線工具包」來用,記得真正的關鍵是最後一張表格,要把徽章相關條件都設計出來。接著歡迎到社群討論群組發表您的設計,我們可以在那邊進一步討論。
  • 設計網站:在測試階段過後,我們需要夥伴幫忙把網站規劃詳細設計、實作出來,意者也請到社群討論群組寄個信喊聲一下

當然,若你看完這篇文章有什麼想法,能夠在下面留言與我們交流,那就更好了!期待可以聽到你的意見 :)

Special Thanks: Peter Chen (English editing.)

2014/1/4

我習慣的 bug report 格式

由於自己是從 Mozilla 開始接觸相關事務的,很多習慣大致都由在 Mozilla 的生活養成。簡要分享自己回報軟體問題的步驟。

關鍵問題:「在什麼樣的情境下,引發了與預期有所出入的結果?」

1. 情境

  • 作業系統、搭配軟體等
  • 誘發錯誤結果的步驟,術語稱之為 reproduce steps,這會需要回報者自己多試幾次確定步驟正確。寫作上的重點是儘量用很難操作錯誤的表達方式,例如「開啟新分頁」或許不如「按下 Cmd/Ctrl - T,開啟新分頁」 -- 或許,其他開啟新分頁的方法本來就不會引發一樣的錯誤。

2. 預期

  • 本來應該發生什麼事的描述,其實不會很難寫。
  • 如果有其他可以供參考的資料,例如別的同類軟體產生的正確結果截圖等,則又更佳。

3. 結果

  • 做完上述步驟後,實際發生的結果
  • 有畫面截圖或者其它可證明/說明結果的報表(例如 log 檔),則又更佳。

其他

  • 出現機率:有些事情可能不是每次都會出現,但出現機率高到讓你覺得不容忽視。這時可註記之,一方面這是重要資訊,很可能代表還有隱藏的線索尚未發現;二方面,也是要避免看這份回報的人自己試一次沒問題就打回票了。
  • 標題簡要清楚:這跟寫信一樣,就不多提。

由於 Mozilla 的 Bugzilla 平常需要應付很多新手回報問題,所以上面的要點已經被做成了制式表單(如圖,我另外標了數字可對照之),另外也有一篇文章教使用者如何回報問題,可參考之。(雖然看不懂那篇英文的人,或許也無法獨立、不需協助地回報問題,但有人想翻譯還是大歡迎的。)

所以我自己的慣用格式如下:

## Steps:

1. reproduce
2. steps
3. here

## Expect

(expectation after the steps above)

## Result

(actual result)

## Notes

(other notes)

其他事項會列在 Notes 處,而有時自我判斷無關作業系統與搭配軟體版本的就省略之(有時會判斷錯就是,屆時還是得花上一次來回)。因著「簡要分享」的想法,有些例如「重要性」什麼的就且不提。比我能寫得好的大有人在,只是分享一下習慣。

2013/10/6

Mozilla Summit 2013: Where am I (Day 3)

[en] The final day of Mozilla Summit 2013! Again I'm sharing my schedule for your reference.

The Location and Facilitators information are all for Santa Clara, please check the full agenda of Sunday. It could be your final chance to stop and say hi this year :P.

繼昨天,這是我明天的選課單。地點時間以 Santa Clara 為主,中文是我自己的 Comments,各議程詳細資訊請見 Summit Wiki

13:15-14:30

很難選,所以我後補多選一個。

Distributed Leadership and decision making

Mozilla 的運作模式中很多部分都需要分散決策,事實上這也是其所認同的核心價值之一(跟程式開發一樣,分不同模組、由不同人開發並決定怎麼做事)。這當然會有很多麻煩,這堂會討論大大小小麻煩的地方,並討論解決方案。

(備選)Ideas into Action: Next steps for me and my team

蔣登登同學主持。內容是討論專案規劃,以讓 Summit 中產生的點子持續推動下去。

(備選)Designing your project for participation

如何讓設計的專案能為眾人參與?推薦覺得事情都要在自己手上完成的人參加,雖然會這樣想的人大概也不會參加 orz

15:00-16:15

Brainstorming on Future Local MozHackSpaces

最近對 HackSpace 的構成與營運方式很有興趣,希望去跟大家多聊聊。

(備選)Community-driven Web Compatibility

  • Grand Ballroom Salon CD
  • TBD

似乎是要去動手做的題目,我猜應該是針對行動網站的技術宣教事宜吧?

我對其他 Sessions 的想法

The Future of Comms Reps: 現在的 Comms Reps 可以去,提一些可行不可行的事情比較好。(特別是區域內有公司營運的這個、那個,還有另一個以及又一個地區。)

Call to Developers: Ask a localizer: 多國語系程式開發其實有很多意想不到的眉角,有興趣的可以去聽聽。

Economic Justice, Mozilla, and the Trans Pacific Partnership: 其實是很深的題目,也值得討論。有哲學系的朋友嗎?

The Role of Commercial L10n at Mozilla: 看得懂會有什麼問題,而不只是說「請人做比較穩/快」的話,請試著貢獻你的想法。

Effectively communicating your contribution at Mozilla: 推薦學生社群成員參加,讓履歷更漂亮。

2013/10/5

Mozilla Summit 2013: Where am I (Day 2)

[en] I'll be at these sessions during the afternoon of Day 2 in Mozilla Summit 2013, just FYI. The Location and Facilitators information are all for Santa Clara, please check the full agenda of Saturday. Welcome to stop and say hi.

繼昨天,這是我明天的選課單。地點時間以 Santa Clara 為主,中文是我自己的 Comments,各議程詳細資訊請見 Summit Wiki

Practicing Open

為了產出「a new FAQ guide on "How to work open at Mozilla"」文件的討論會,我應該去分享些什麼。

Mozilla 的新員工似乎許多(特別是非工程師)都不知道這個組織是什麼玩意,這似乎有點麻煩;另外在當前合作廠商變多、且產業與以前瀏覽器不同的情況下,應該發展一些仍然可以稱得上「Open」的訊息流通方式。

是說這場的主持人今年四月剛進 Mozilla,然後還是作行銷呀。(這不是說她就一定不了解就是,我只是突然有點抖,但也許她其實超 Open。)


備選:Defining and Packaging a Mozilla Core experience for onboarding

編寫新成員的入門課程 -- Just kidding,不過意思應該沒有差太遠。與前面差別是一個給員工、一個給志工。社群成員有興趣的話,我還挺希望有人去。

Imagining a Mozilla-Wide Open Badges System + OBI 101

Open Badges 相關的討論,我一直都算蠻有興趣的。


備選:Level Up with Firefox Student Ambassadors!

校園大使相關的,如果 OpenBadges 那場很不堪我才會去。

對於其他場的 Comments

首先昨天的 Firefox OS 2014 居然真的是討論場!我錯了,先致歉。

其他:

Building a Framework to enable Mozilla to effectively communicate across our community: 看說明是有點興趣,且在布魯塞爾是 Gerv 主持。不過本時段太多軌只好連備選都排不上。

Developing empathy for your users: 未看先猜公司會有一部分人去聽,所以等著聽她們描述就好。

Designing for our users not ourselves: 感覺是 UCD 入門班。

Strategies of industry players and competing effectively: 如果參與的一群人平常有在關心,應該是個不錯的 session。

Understanding web developers: For developer engagement.

How do we scale up our innovation capacity?: 未看先猜可能會有點發散。

Developing an Open Badge Eco-system: 蠻有興趣的,但重點是 Santa Clara 沒有這場 orz

Contributing with just the browser: 如果主持得好,應該是有趣的討論會。未看先猜是從 L20N 的想法作為起點發想的,今天彼得大帝跟我說他們做了個類似 Facebook、只要添加特殊標記就可通用的網站翻譯工具。

2013/10/4

Mozilla Summit 2013:Where am I (Day 1)

[en] I'll be at these sessions, just FYI. The Location and Facilitators information are all for Santa Clara, please check the full agenda of Friday. Welcome to stop and say hi.

以下是我的選課指南,給眾人參考。地點跟 Facilitators 都是 Santa Clara 的場次,而後面中文是我自己的 Comment。完整資訊請參考 Wiki

正取選擇

下午 1:00-2:15 及 2:45-4:00 可以任選兩堂:

Building a Web Literate World

無論你想、或不想讓小孩學電腦程式,先問,如果出發點不是為了「競爭力」呢?

我自己是很吃 Webmaker 專案提出來的這一套:教你一點邏輯,一點 Web 的編輯方式,只是因為那(即將)就是生活技能之一,就如拿筆書寫、操作微波爐。沒有人想計較你寫字好看與否,傳遞表意即可;沒有人想計較你操作微波爐多快,有東西可以吃即可。

希望接下來對 Mozilla Foundation 的專案更深入接觸。

What does "Mozillian" mean?

跟社群自我定位有關,做社群的人心裡都應該認真想一次這件事情。來去看看別人想些什麼,提供意見。

備選 (aka If something goes wrong...)

Ecosystems in our Image

有興趣的地方:應該會討論到,在當前的 App Marketplace 世界裡,Mozilla 要有怎樣的表現,才不至隨波逐流,而能把理念化為機制,實際產生影響?

對於其他 Session 的想法 (Few comments on other session)

The Web We Want: Could be a good topic for discussion, but I can hardly image how deep we can go in a 75 mins session.

Firefox OS in 2014 and Beyond: 1) Luckly I'm familiar with the development team, and the public information should be enough (or it's not Mozilla.) and 2) I think it will not be a "discussing session," IMPOV.

Privacy, Security, and Data: Pragmatic Innovations for Users and the Web: Looks nice when relate to UX, not sure if we will have some prototype or anything as an outcome.

2013/6/22

Firefox 的新界面 Australis,分頁部分

已經開始有些媒體針對這個新的界面撰寫報導,事實上現在你也可以透過 UX Build 玩玩看。大家一眼就會看見的是分頁,我想順道就針對分頁的更動列出幾個自己覺得重要的事情:

弧線

Australis 的線條大概是目前瀏覽器裡最「弧」的一個(剛巧 Firefox 也是最「狐」的瀏覽器 -- 冷!)
上:Australis (in UX Build)   下:Google Chrome
 以我所知,有幾項設計理由:
  • Firefox 在各版本間開始追求的、一致的設計語言:柔軟、友善,很多稜稜角角的東西都改成圓弧狀了。這樣的風格早已在 Firefox for Android 上呈現,現在桌機版只是(終於要)跟上而已。
  • 速度感:不要問我這是硬扯的還是真的,反正有張投影片是在描述,這樣的弧線有跑車似的流線型感覺... 好啦是有流線啦,有沒有反映到感覺上,我就不知道了。
好看嗎?難看嗎?我覺得看久倒是意外的順眼,當初 Thunderbird 剛換上這個主題時個人讚譽有加,Firefox 換上多少有點不習慣(TB 跟 Fx 開的分頁數目有巨大差異),但使用 UX build 一陣子之後,我是還蠻喜歡的。

強調當前分頁

目前的設計加強「目前分頁」的存在感。一方面拜弧線所賜,相較於舊的設計確實更有「從網址工具列長出來、是一體的」的感覺;二方面,此設計削弱了背景分頁的存在感,除去框線使其融入標題列中。

有人覺得這會造成背景分頁較難辨識與瞄準,我是還好;但無論如何,帶來的好處倒是顯而易見,整個瀏覽器的分頁列確實變得更乾淨、更不打擾 -- 不打擾是 UI 設計上大家都想追求的東西,很高興 Firefox UX Team 不僅僅用砍掉元素的方式來整理標題列,在色彩、線條的設計上也投下心力。(例如,除了背景分頁框線不見之外,你有注意到兩個相鄰背景分頁之間變成直線嗎?)

其他

一定爆炸多人覺得這根本抄 Chrome,且不論每個瀏覽器都有上一頁下一頁、每個電話都有掛斷的鍵,我就舉幾個在分頁列部分跟 Chrome 一樣或不一樣的地方:
  • 標題列不見了,有人討厭有人喜歡,我是喜歡的那一派(我之前一直比較喜歡 Chrome 在這部分的設計,精簡)
  • 每個分頁的關閉鈕還在:雖然實際上用到的機會不大,相較於 Chrome 的背景分頁沒有關閉鈕,我比較喜歡讓它一直存在。
  • Chrome 分頁太多時基本悲劇,還好 Australis 仍然保留這部分的堅持:


又,PTT 上莫名其妙有很多人覺得這樣的設計會浪費空間 -- 怎麼會?東西都要搭配各種環境一起看的,且讓這些截圖告訴你:



 

其實 Australis 的一大要點是凸顯「自訂」這件事情,此處的體現大抵藏在那個真的從 Chrome 來的 Menu 選單中。之後有機會再分享我的看法。

如果你有興趣要瞭解 Australis,可以參考 Wiki 上的設計文件及當時用來展示的草稿圖

聲明

大概有人會覺得上面這些偏好單純因為我很少用 Chrome,事實上我不但每種瀏覽器都用(是啊,我想多瞭解),在過去半年也都用 Chrome 當主力瀏覽器。青菜蘿蔔各有所好,如果我剛巧就是喜歡某個多些,別覺得我太偏袒哪 :)

2013/2/1

菁英政治

Open Source 界不願承認的九件事一文中,引一段有意思的:

More often, though, it is heavily qualified. In many projects, documentation writers or artists are less influential than programmers. Often, who you know can influence whether your contributions are accepted as much as the actually quality of your work.

Similarly, the famous are more likely to influence decision-making than the rank and file, regardless of what they have done recently. People like Mark Shuttleworth or corporations like Google can buy their way to influence. Community projects can find their governing bodies dominated by their corporate sponsors, as has usually been the case with Fedora. Although meritocracy is the ideal, it is almost never the sole practice.

不敢說自己看得很多,不過以上大部份都正確。很久以前,我記得聽人說過 Open Source 的環境是菁英政治而非純然民主;Mitchell Baker 也曾說過 Mozilla 的文化上應該是 Earned authority;或說我自己在關於社群式管理的心得隨筆也描述過在程式碼上貢獻與應允者間的關係往來。

「打碼的最大」是這類社群的常見現象,我們也經常低估文件、繪圖者的貢獻程度。這有點像一間公司獨尊業務的作法,只有有「營收產出」的能拿到最豐碩的果實,而忽略其他人在輔助支援上的努力。這點應該是我們致力改善的,如果都像 TonyQ 一樣把視覺設計視為心中的神或許不壞 :P

有名的人也確實比較有影響力,不過這沒什麼不好。以瞎透舞姿先生來說,他的「有名」其來有自,必然也經過了許多努力而生 -- 生下來就有名的人不多見,在這個社群內更不太發生,而無論他做了什麼、也都會對他後續的影響力產生影響。又,在每個環境裡的「有名」,也不見得會能夠被帶到另一個環境裡。如果在商普界知名的 Mr. xxxxx 們來談 Open Source,我們應該會請他講中文。因此這份「有名」事實上也是 earned authority 的代表,而我們也不愛單純由 given 而來的權力。

至於贊助商主宰,嗯,慣於用資源而非道理來控制人的群體充斥我們周圍,我自己仍然會記得即使是這些人也仍是「社群」的一份子,也代表著部份的聲音,應獲得一定尊重(說到底資源的贊助也屬於一種貢獻啊);又,不喜歡原也不必勉強,你總可以選擇自己不被那些勢力左右,就開個分支或離開吧。

是以,我還是抱持樂觀的態度看這些缺失。會向著更好的地方去,中途的曲折只是必然要來的墊背。

2012/9/3

如何用 Thunderbird 上 Mozilla 聊天室

本文為個人著作,「我的人生都是虛構的,與實際的人物、團體沒有任何關係」。

雖然 Thunderbird 眼看即將停止開發進入維護看守模式,不過頭已經洗下去的部分當然還是會完成。跟著上個月底 Firefox 15 所推出的 Thunderbird 15 還是有新功能,包括 Filelink 加上了 UbuntuOne 這個雲端檔案服務,另外就是本文重點:線上聊天功能。

本來 Thunderbird 的遠景就是要向「訊息整合」邁進,比照 Outlook、Gmail 般把線上聊天功能整合進來也算合理至極。不過與前兩者不同,Mozilla 到底沒有自己的即時訊息服務可以整而合之,那麼要加上那些聊天服務?不必煩惱,能加的都加進來就對了!於是乎,新版 Thunderbird 可以一口氣整合 Google Talk(與其他 XMPP 服務)、Facebook、Twitter,以及文後要介紹的 IRC 聊天室。除了 Twitter 我用起來很不習慣之外,其他都算還不錯,以下為各位快速說明一下怎麼用 Thunderbird 上 irc://irc.mozilla.org/#mozilla-taiwan:

  1. 當然你要先裝好最新版的 Thunderbird,並且設定好郵件帳號啥的。我忘了不設郵件帳號能不能上聊天室,不過如果你裝 Thunderbird 卻只是要上聊天室,那有點浪費,建議你找別的 IRC 聊天室工具
  2. 首先請到 Tools > Account Settings... 開啟帳號設定視窗
  3. 點選帳號設定視窗右下角的 Account Action 鈕,選擇 Add Chat Account...
  4. 在跳出的視窗中選擇 IRC,按 Next
  5. 在 Username 輸入你想使用的聊天帳號名稱,Server 請輸入 irc.mozilla.org,按 Next
  6. 接著是 Password,如果你從未在 Mozilla 的 IRC 聊天室中註冊帳號,那可以先按 Next 跳過
  7. Local Alias 只是帳號的暱稱,用處不大不輸入也沒關係;點開 IRC Options,把 Port 改成 6697,並且勾選 Use SSL,接著按 Next,再按個 Finish 結束這個回合設定。

這麼一來你已經設定好了主機,預設中也會自動幫你連上線。接著要加入 #mozilla-taiwan 這個聊天室:

  1. 前面那堆步驟做完後,你的郵件工具列中會出現 Chat 按鈕,點選後會開一個新的聊天分頁,請切換過去。
  2. 點選聊天工具列上的 Join Chat,並且在跳出來的視窗中確定自己選的是 irc.mozilla.org,再於 Channel 中輸入 #mozilla-taiwan (井號也要輸入),按下 OK
  3. Conversations 側邊欄會出現 #mozilla-taiwan,點選後就會開啟聊天模式,可以跟大家打個招呼 :D
  4. 有興趣的話可以再回 Account Settings 找到 irc.mozilla.org,並且在 Auto-Joined Channels 欄位裡打上 #mozilla-taiwan,那這樣每次開啟 Thunderbird 時就會幫你連線且加入該頻道。

在 IRC 的世界裡,沒有註冊帳號的人可能會跟別人「撞名」。玩一陣子之後有興趣的話,可以考慮跟 NickServ 註冊帳號,把自己專屬的暱稱佔起來。相關資訊請自己搜尋 Google :P 如果你覺得本文都是字有點難以下嚥,可以參考 Thunderbird Support 的相關文章,有圖解 -- 當然,如果你還願意幫忙把那篇文章翻譯為中文,那就更好。

2012/4/7

P2PU.org 共同學習的好平台

很久沒寫了,為了做作業來介紹一下最近在看的東西:p2pu.org

P2PU.org screenshot

P2PU.org 是個鼓勵共同學習的網站,上面有老師、有同學,屬於非同步式的遠距教學。任何人都可以教,教學內容可以設定為「課程」、「挑戰」等。例如,我這篇文章其實是在做圖中「#1 Introduce Yourself」的第二個作業,要寫篇文章說明自己為什麼要學習這個課程,以及其他與自己相關的兩三事。

主要還是跟 Mozilla 有關的事情。Mozilla 基金會在去年有「以線上徽章做為學習證明」的構想,並推出了「Open Badges」這個專案,產出一套開放、分散架構的徽章後設資料組(OBI)及徽章收集、顯示機制。在構想 gfx.tw 時,我曾發想在個人推薦頁面顯示徽章(或者「Achievements」,近來的遊戲都很喜歡玩這套)來做為社群認證機制的想法,例如協助辦理實體或線上活動給個徽章、在討論區上回答問題給個徽章等等。目前 Mozilla 的「Mozillians.org」平台加上 Open Badges 剛好就是這些想法的體現(當然,我應該沒影響了什麼,只是所見略同而已)。Open Badges 跟 P2PU 合作,讓在 P2PU 上面學習的夥伴可以獲得依這套規格所製作的徽章,同時也獲得一個很好的 show case。

在 P2PU 上獲得徽章的方式,大致都是「秀出你的能力」:你參加了某個課程之後,可能會有一些作業,在做完以後將作品送到 P2PU,並描述你學到了什麼,就可以請同學來幫忙評分。每個徽章所需要的條件不盡相同,常見的是「至少兩位同學,給你平均 3 分以上的評價,來證實你具有某種能力」這類的。所有的評價以及評語都是公開可查驗的,而系統判斷條件通過後就會自動發給你徽章。如果有同學需要人幫忙評分,系統會在課程網頁上提示,你可以給同學一點評語、建議、想法。

除了這種實力驗證式的徽章之外,就如同遊戲一般,有些徽章需要的是特殊條件而非「證明實力」的。例如,你可以主動給同學「打招呼」徽章(不需要任何理由,就是打招呼),或者如果同學覺得你對大家的學習很有幫助,也可以給你「好同學」徽章等等。

Open Badges 是個還在起步階段的有趣專案,而 P2PU 的模式我也很喜歡,希望這兩者後續都有不錯的發展。

BTW,Mozilla 基金會真的有很多有趣的東西,志在改善現況者可以多看看

2011/10/24

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

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

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

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

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

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

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

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

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

2010/9/22

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

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

  1. 升級時,將未經使用者明確授權即安裝的第三方附加元件(Plug-ins or so)停用,主要影響啟動效能。有點類似 IE9 Beta 啟動時提醒你某個附加元件太拖累的東西,但另外也在意「不經使用者授權即自行安裝」的元件(如 Skype、Norton 軟體、Java 等)。
  2. 自動清理重複的附加元件,又是 Java,似乎 Microsoft DRM 也會重複灌版本號碼不同、但只是升級而已的套件。這應該是沒有好好指定套件 ID 的緣故。
  3. Windows 下視窗最大化時,分頁與標題列同置一行,就像 Google Chrome 一樣,增加瀏覽空間。這好像有人在試了。
  4. 在 Windows 上啟動時,螢幕繪製的狀況比 Fx 3.6 慘
  5. 更聰明的網址自動補完。有人動手了。
  6. 即便是 HTTPS 的網站,當掉後也要能自動復原。似乎是政策問題多過實做。
  7. 合併停止與重新讀取鈕後,不應使停止鈕出現「停用」狀態

    萬一頁面讀得很慢,使用者想按下「停止」鈕的時候會發生兩種狀況:

    • 順利停止網頁讀取,或是
    • 網頁在按下前的一瞬間已經讀取完畢、按鈕變成「重新讀取」,所以使用者按到的是「重新讀取」鈕、暴怒。

    為了防止這種情形發生,目前的作法是在網頁讀取完畢後仍暫時顯示「停止」鈕、但採停用狀態以防止誤觸。雖然實際上對網頁讀取速度沒有影響,但多那半秒的「停止」模樣可能會讓使用者以為網頁讀取變慢了。

    又,你覺得 Firefox「抄」其他瀏覽器嗎?這個 Bug 有 Google Chrome 的開發者上去分享 Chrome 設計的理由 XD 且不論「原創」所指為何,請搞清楚在這個世界裡的共創理念。(這個 bug 有人動手了)

  8. 網址列中,網域部份加重顯示,其實我記得以前 Firefox 曾經有過測試版是如此作用的,但沒加到最後版本的原因不明。有人動手了。
  9. 強化拖曳分頁時的視覺提示,MozTW 討論區之前有人提過,目前沒人動手,我也很想要這個功能 :/
  10. 減弱搜尋欄圖示的干擾,或者更準確點描述問題:「那個區域現在已經有星星、RSS icon、重讀、停止等各種顏色的圖示會出現,搜尋引擎的圖示則是另一種本身就五顏六色的干擾源」。不過個人覺得,現在 Fx 的搜尋欄已經是各家有此功能的瀏覽器中最好的一種了(我尤其不喜歡 Safari 的方式,原因同 Comment 5),接下來可以走的方向應該就只有與位址列合併了吧?
  11. 在選單中增加縮放控制的介面元素,類似 Google Chrome 現在的作法。討論中,我不是很喜歡 Google Chrome 7 dev 實做選單中多重控制項的方法,尤其 keyboard inaccessible、and no tooltips 這些小細節。
  12. 「應用程式分頁」中的外部連結,應該開在新分頁裡。可以來討論「什麼叫做外部連結」 XD
  13. 應用程式分頁隱藏瀏覽工具列等元素。好處:很多 Web 應用程式確實不需要瀏覽器內建的導覽列。 壞處:但,有的需要啊!又,「外部連結」的 Bug 裡有人提到,這會讓辨識釣魚網站變得比較困難。應該是不用期待 Firefox 4 會有這個。
  14. 多重選取分頁,又一個邁向提姆所謂「Firefox OS」的東西?

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

2010/4/1

Why so serious?

有兩件跟 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 年第一季網路現況統計

昨天(或說不久前)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/2/10

台北市教師研習:Firefox

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

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

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

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

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

2010/1/10

Firefox for Maemo, RC2

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.

2009/12/12

Porting JetQRCode from Jetpack to Google Chrome

(將 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:

  1. 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.
  2. Jetpack is highly related to jQuery. To make life easier, you may want to insert jQuery as content script.
  3. HttpRequest to different domain is not allowed in content script, do it in background html, and pass the result to content if needed.
  4. 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.
  5. 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 就是了… 懶惰鬼!)。有些經驗我想還是蠻值得跟大家分享一下,但中文版我想首先講結論:結論是…

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

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

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

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

2009/12/11

用 Thunderbird 3 玩 Google

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]/刪除的郵件」這種標籤。有兩條路可選:

  1. 把垃圾桶跟寄件備份打開
  2. 調整 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 (以及包括小弟在內許多早期貢獻者) 協助完成的中文語系。

2009/9/30

Native Personas in Firefox 3.6

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)

2009/9/4

Creative Commons for Mozilla Service Week

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

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

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

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