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

2015/6/2

KKTIX / Google Spreadsheet / Mac OS dashboard 快速製作

COSCUP 2015 Workshop 採用 KKTIX 報名,場次不少,我們自然也挺關心每個場次的報名狀況(關係到我們是否要針對特定族群再加以宣傳)。由於每場的 KKTIX 活動頁面都選用同樣的佈景主題,也都公開顯示報名狀況,於是即使沒有提供 API,也可以很容易用 Google Spreadsheet 的 ImportXML 函式快速製作出綜合每個場次報名狀況的一覽表。

ImportXML 可以接兩個參數:

  1. 要讀入的 XML 網址
  2. XLink query,用以指明需要顯示的資料

以迅速爆滿、由 d3js.tw 成員慕約帶來的「第一次自幹 Open Data SimCity 就上手」為例,其網址為 http://coscup2015.kktix.cc/events/opendata-simcity ,而查閱原始碼可知,記載人數的 node 為「<span class="info-count">」的內容,於是 XLink 就可寫作 //span[@class='info-count'] 。

那麼只要在 Google Spreadsheet 的某個儲存格打入下列公式:

=IMPORTXML("http://coscup2015.kktix.cc/events/opendata-simcity", "//span[@class='info-count']")

就會讀入現有的報名人數及總名額,接著再用一些文字操作的函式,也就能順利把數字部分都讀出來。於是只要搭配一點點變化,就可以做出這樣的表格:

另外再做點美化,發布為 HTML 後,就成了人人可看的狀態一覽表:

其實若要自己看,也不盡然得發布為 HTML,但發布後搭配 Mac OS 的 Safari 「在 Dashboard 裡打開的功能」,那就能把這個頁面變成方便查閱的 Dashboard 小工具了:

Google Spreadsheet 還有另外提供 ImportHTML 這類的函式,但主要是用來讀取表格;如果像這種只要取幾個節點或一份清單的狀況,有鑒於 HTML 也是一種 XML,Google Spreadsheet 可以正確讀入沒有問題,還是 ImportXML 會方便點。

不免俗也是要廣告一下:COSCUP 2015 Workshop結合 15 個社群傾力演出,陣容堅強內容充實,絕大部份為免費參加。歡迎大家一起來唷 :)

2015/5/8

Lightning Talk in MozTW Lab

摩茲連續聚 第六集

我們今天在 MozTW Lab 嘗試做了 25 分鐘的 Lightning Talk,效果不錯。

「有 Talk」這件事其實與 MozTW Lab 原本的設計理念不太一致:本來,MozTW Lab 就是個「來我家寫程式」的活動,大家應該來做自己的事情就好,而有事情可以互相幫忙。不過有些理由,讓我覺得這樣的分享時間或有必要:

  • 現在每週 MozTW Lab 都有超過 20 位參與者(到我寫這段文字的 22:11 為止,在場仍有 17 位社群成員各自忙著,Simply Amazing),大家卻不見得瞭解對方在做什麼,甚至也叫不出名字,這讓「有事情可以互相幫忙」的機會降低了不少。
  • 我們的連續聚幾百年沒辦了,大家彼此少了很多可以快速介紹一些 Web 相關議題的機會。
  • 我還是希望來參加 Lab 的夥伴能有機會更認識 Mozilla 的各種專案與想法

於是上週在 Telegram 上喊了下,本週也順利做了第一次實驗。主要設計概念是:

  • 不能變成活動主題
  • 時間不能太長 - 目前設定每次 Lab 花至多 30 分鐘時間分享,因為絕大部分時間應該還是要讓大家來做事。
  • 試行彈性時間:不一定每場剛好 5 分鐘,超時會催場,但不會強制拔插頭。
  • 鼓勵大家分享最近在做的事情

稟持這樣的想法,第一集閃電秀就在今天熱鬧演出了!這一集的內容有:

  • 某齧齒動物跟大家分享了報社的兩三事,恕我不能講更多...
  • 新朋友 Ross Ziegler 與大家相見歡
  • Irvin 介紹了最近的熱門議題:Facebook Zero 與網路中立性
  • 則介紹了一下最近 Webmaker.org 的動態

那,下週呢?下週就看你的了,現在就上網預約報名吧!戰神表示下週會希望能夠開直播,請關注 MozTW 的粉絲頁以獲得進一步消息囉!

2015/4/21

Google Tag Manager 新版學習札記

先前稍微玩了一下 Google Tag Manager 但一直沒有正式放到網站上(主要是... 沒有人有時間再去研究,還有一堆 GA 調整的票掛在那邊沒時間做啊啊啊啊),但因為某顆布丁說要有光就有了光,於是我這星期又重新把沈寂數個月的「研究轉換到 GTM」那張票挖出來。

快速分享一些東西,或許能幫上跟我狀況 / 程度差不多的人。

這篇文:

  • 不是教學,是快速概覽:我是站在「如果是我的話,看了以後可以省一些摸索時間」來寫的,而介面選項在哪裡什麼的,自己摸吧 XD
  • 不是去技術文:GTM 本身雖然沒有限制是開發人員才能使用,但會不會 JavaScript 影響規劃時能用的把戲,我直接以小會一點 js 的角度來看

那就開始囉!

改名

如果你用過舊版的,有些名詞換了,個人認為是更好懂:

  • Rules 改稱為 Trigger
  • Macro 改稱 Variable

改名這種事情,其實對初學者來說超級重要的,因為在求助時,找到的文件可能都還是舊版。

概念

基本流程如下

  1. 新增 Container,就是... 意義上可以歸類的一組東西
  2. 請開發人員將 Container 產生的 GTM 程式碼放上網站。理想上無論你以後怎麼改設定,這就是少數幾次真的會動到網站程式碼的時候了。
  3. 在 Container 中可以新增各種 Tag,可以想為「要做的事」
  4. 每個 Tag 可以藉由多種 Trigger「觸發」
  5. 另外 Trigger 跟 Tag 中可以藉由各種 Variable 來設定雜七雜八的東西
  6. 設定完畢後,可以用 Preview / Debug 來測試
  7. 測試沒問題就發佈,相關設定就會直接套用到網站上
  8. 若以後有要改什麼,就從 Step 3 再走一遍,而開發人員理想上不用更動什麼程式碼

舉例:「使用者在進入這一頁點選『喝我喝我』按鈕後,就告訴 GA 這人在進來多久以後才按這個鈕」,這句話裡:

  • Tag 是「就告訴 GA 這人在進來多久以後才按這個鈕」
    • 其中「進來多久」很可能是 Variable
  • Trigger 是使用者「點選『喝我喝我』按鈕」

Tag 與 Trigger

Tag 的設定不盡相同。簡單的狀況:以設定「讀入此頁時,就在 GA 中記上一筆 pageview」這樣的事情來說,只要新增一個 GA 的 Tag、選擇 Pageview、並且設定在 All page 觸發就結束了。

但複雜的話就很複雜:一樣以 GA 為例,你有「一大堆」的欄位可以指定要傳送怎樣的資訊給 GA,舉凡 UserID、Enhanced eCommerce data 等等都可以(也必須)在這裡設定。這部分有必要搭配相關的開發文件來查閱該怎麼傳。

每個 Tag 都可以指定讓很多種 Trigger 觸發,這裡會是聯集,也就是說如果你設定了 3 個 Trigger,那只要符合 3 個中的任一種情形,都會觸發此 Tag。若想用「交集」,也就是要符合所有條件才會動,那設定上得自己兜成一個 Trigger(單一 Trigger 內的各條件是交集),或者另外新增 Exception。

舉例:我們希望在使用者登入的情況下(這裡有個 Variable 可以得知使用者是否登入),點擊某頁 A 上的某個連結 B 會觸發 Tag。有兩類設定方式:

  1. 在一個 Trigger 裡,設定在 A 頁啟用 Link Click 追蹤,並僅在使用者已登入點擊 B 連結時觸發
  2. 或者,也可以設定某個 Trigger 是在 A 頁啟用 Link Click 追蹤,並僅在點擊 B 連結時觸發。此時該 Tag 還要記得另外新增一個若使用者未登入則不觸發此 Tag 的 Exception

兩種方式主要看規劃,講簡潔好維護當然是 1,但或許某些時候還是會想用 2。

Exception 其實也是一種 Trigger,你可以想成「如果符合這個 Trigger 的條件,我就不觸發」。正所謂敵不動我不動,敵一動我亂動(此句意味不明。)

當然一個 Trigger 也可以觸發兩個以上的 Tag。

Variable

記得先進 Variable 把一些預設的 Built-In Variables 開起來,例如我開了 Page 跟 Click 的大部分。

這些做啥用?例如 Click Element 可以作為 Trigger 的條件,讓你做到「如果點選了 DIV.triggerme 底下的 A 元素,就觸發這個 Tag」,以此類推。

Variable 有許多類型,我覺得比較有用的東西例如:

  • Constant: 常數(固定值),例如 GAID 會用在很多 Tag 上,先拉出來做常數設定好。一個重點是在這邊設定好以後就會變成各欄位的下拉選單。
  • Custom JavaScript: 大概是變化最多最厲害的一種,可以用 JavaScript 抓/拼出各種想要的值交給 GTM。
    • 一行看熱鬧: function(){ return {{Click Element}}.getElementsByClassName("text")[0].getAttribute("data-event-label"); }
    • 其中 {{Click Element}} 是 Variable 的引用方式
    • GTM 高人 Zorro 曾指點,其實 GTM 內建 jQuery,所以不見得要像我那樣用原生 DOM API 抓東西。但... 我就習慣了... 然後沒有公開說支援的東西我也會擔心不告而別壞光光 :/
  • Data Layer Variable: 網頁上送來的 Data Layer 資訊要從這裡轉成變數給其他人用
  • Lookup Table: 如果你會 JavaScript 的話差不多就是 Switch ... Case 的精簡版,需求簡單又懶得寫程式時是蠻方便

Preview / Debug

GTM 內建的除錯工具,啟用後在瀏覽網頁時下半部會分割視窗顯示,平常測試起來會比用瀏覽器內建的 developer console 方便非常多。主要功能是查閱各種狀態(網頁載入、DOM 完備、網頁讀完、各種點擊事件)下:

  • 到底哪些 Tag 被觸發了
    • 以及,送出了什麼資訊
    • 而如果沒被觸發又因為哪些條件沒滿足(這個非常好用)
  • 各自訂變數值

由於他會把各狀態當下的所有數值記錄下來,所以你也可以在十幾個事件之後才回頭查第三次 click 觸發了什麼東西。下圖代表在剛載入的時機點由於網頁 URL 不符規則,於是沒有觸發。

Preview 時的 GTM 設定只有你才看得到,或者你也可以分享給其他特定人。總之,即使在 production 上測試也是沒問題的。

其他筆記

  • 瀏覽器相容性:寫 Custom JavaScript 要注意瀏覽器相容性,畢竟這段 js 碼是真的會在瀏覽器上跑。
  • 由於 GTM 的設計,只要你會寫 JavaScript 就幾乎可以不靠開發人員調整網頁,就能自幹所有的變數(例如,自己爬最終訂單畫面來解析出訂單內容資料)。
    • 不過基礎 Metadata 我會仍然傾向商請網站開發人員送 Data Layer 過來,以免網頁結構有些許更動時讓 GTM 死在路邊。
  • 閱讀文件後我認為 GTM for iOS / Android App 實際作用倒沒有像網站上那麼大,開發人員仍然得自己送出幾乎所有的事件(App 沒有 DOM 可以抓啊...),差異點是:
    1. 有些設定過的 Data Layer 值可以直接重複使用
    2. 可以在軟體發佈以後才透過 GTM 改一些設定值

小結

網站分析師善用 GTM 的話可以省很多「等開發人員有空」的時間,有什麼要調整的東西時開發人員也比較不會覺得很煩。站在「網站企劃分析人員多少都得懂點網頁技術」的角度上,是蠻推薦每個人都可以學學。不過相較 GA 已經深入行銷人的領域、在用詞與操作上幾乎只要懂網路基本原理就可以用,GTM 就還是很技術人的工具。

當然,即使你完全不會寫 JavaScript,也還是可以用 GTM 快樂做些事情、不用等 RD 幫你處理,但會寫 JavaScript 的情況下,用起來根本不是同個級別的。無論如何,Google 提供不少範例,或可作為一個入口。

有打算下個月或下下個月在摩茲工寮弄個簡單的 GTM 分享,有興趣的下面留言一下吧。

2014/5/5

菜鳥 Maker,之前

是一種連菜鳥都還稱不上的狀態。

黑熊用講歷史的姿態,告訴我臺北有哪些地方可以買:

  • 昌吉街,螺絲
  • 景西街,木料
  • 太原路,塑膠製品(泡棉那種都是)

陳飛說他們都去大學美術社買卡碘西德。黑熊補充:或許熟一些後,可以去找招牌廣告行買人家比較零的,便宜多。

卡碘西德先買 6 才 / 2 尺來試玩。那檯裁紙機的 plugin 不支援 Mac 了,但還有另外一套軟體可能支援,還沒試 - 因為週末,美術社都休息。

關於木工。鴻旗覺得手作木工需要保留那樣的味道,就是要不整齊啊!

蜂巢板應該是個意外貴的素材;代木是均質的東西;角鋼很便宜,合板也很便宜(意外地超級便宜),廁所門版是超級便宜的白板。

至於什麼時候才要升級成菜鳥?想做的事情實在太多了,義鴻說就慢慢來吧,我說,就是把這件事情放著讓它慢慢來了,才會拖了半年多啊~

就跟我永遠沒學的吉他一樣,於是大概就不會再去北海道了。

2014/5/1

5/12,一起參與 Mozilla Webmaker 的線上培訓課程

Mozilla 的資訊教育專案 Webmaker 即將在 5/12 啟動培訓課程,歡迎對於 Web 教育有興趣的夥伴一起參加,也邀請對此專案有興趣的朋友加入 Webmaker 台灣社群討論區,共同討論 Webmaker 在台灣推廣的計劃與活動。

本次 Webmaker 培訓課程(Webmaker Training)學習體驗著重在相互連結,與其他對傳播數位與 Web 素養的熱情夥伴交流互動。只有與大家互動,這次的學習體驗才算得上成功; Webmaker 培訓課程就是要你與他人合作,而不只是埋頭讀書而已。
Webmaker 培訓課程共有四個單元,可以看作是不同的課程、幫助大家更了解 Webmaker 專案背後的理論Webmaker 提供的工具教學資訊參與式學習之道、以及以開放方式協同合作所需的技術及社交技巧。

每個單元將由 Webmaker 及線上同儕學習平台 P2PU 共同主持。課程為期一週,但歡樂將無盡延續。您可以自行決定參與程度,或者只接收有興趣的單元訊息。自己的 Webmaker 培訓課程,自己打造!

實時參與

  1. 每週都將開設標以 #teachtheweb 的 Twitter Chat
  2. 每週也會舉辦 HOMAGO 直播,其錄影事後將於 YouTube 留存
  3. 每週舉辦的 TeachTheWeb 社群會議也將有大段時間討論當週內容與概念

Webmaker 培訓課程

「探索」單元 - 5/12-5/18

了解 Webmaker 計劃背後的理論框架及教學法。本單元將協助您了解 Web 生態體系,以及開放網路的重要性。

「打造」單元 - 5/19-5/25

發展富含 Web 素養內涵及創作技法,並與其他如歷史、生物等主題結合的開放教育資源。我們將在本單元學習創作教育素材,既切題、又自由,且方便他人再利用或重組。

「引導」單元 - 5/26-6/1

由理論進入實務,我們將在本單元學習及開放、參與式學習技術,用以在課堂上、工作坊或街頭活動中傳授數位/Web 素養相關技能。

「連結」單元 - 6/2-6/8

與在地社群及全球 Webmaker 社群連結,讓您的作品威力再加倍!本單元中我們將學習如何建立關係,以便更為提升您的作品影響力。

歡迎在這裡報名,並且選擇您想要參加的單元 :D

在地社群

對 Webmaker 有興趣嗎?請加入台灣 Webmaker 社群的討論區,預計將於培訓課程期間順勢舉辦讀書會,歡迎對於 Web 教育有興趣的朋友們一同參與。


(本文由 Bob 編譯自 http://www.zythepsary.com/techie/webmaker-training-starts-may-12th/ ,並添增部分在地內容與介紹。)

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.)