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

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/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/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/12/5

Firefox 附加元件:用 Markdown Here 在 Blogger 上發文

因為公司的系統常用 markdown,在這幾個月裡我也開始慢慢熟悉語法,就想找些方法以後用 markdown 寫 Blog。我之前大多使用 HTML 編寫,大致的缺點就是比較慢… 改用 markdown 應該會快很多,至少有點 tag 潔癖的情況下,用 markdown 似乎可以確保出來的語法整潔?
不過由於自己的 blog 在 Blogger,多少也有改點佈景,實在有點懶得搬家到別的地方,於是開始找「能在 Blogger 上寫 markdown」的方法。目前大部份的教學文件都要你轉個方向走,例如:
  • 先用 markdown 編輯器寫、轉成 HTML、再把 HTML 貼上來:想也知道我不可能選這個啊…
  • 利用其他有整合好的編輯器,把「轉成 HTML 在貼」的工作盡可能自動化:缺點是 Blogger 上的一些文章設定沒那麼方便,變成寫好要再回來調整,且不一定有辦法上傳圖片…
後 來找到這個 Firefox 附加元件 — Markdown Here,似乎還 不錯,他其實只是把 Rich Text Editor 裡的 markdown 純文字轉換為 HTML 內容,但這樣便讓相容性提高了許多 — 理論上可以相容任何 Rich Text Editor 網站。
目前試用有些缺點:
  1. 為了在 HTML 跟 Markdown 之間互轉,它在產出的 HTML 碼裡會塞一些有點醜的原始碼編碼… 外觀看不到,但看 Code 很醜,且重點是大幅增加了頁面所需的 data
  2. 另外它預設會添加很多 style… 這個要去設定裡把它的 Style 全部清掉。其實這個設定原意也是讓頁面更漂亮,但遇到你自己本來就會加 CSS 的 Blog 時,還是全拿掉吧…
或許用一用會決定要來自己改他的 code,但無論如何有興趣的朋友可以試試看 :)

下載 Markdown Here

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/8/2

COSCUP 2013,我會在哪? Day 1

以下是我(如果有空聽的話)在 COSCUP 2013 的預定行程表,先寫第一天的:

Open Data Initiatives for Taiwan、座談會:Open Data 面面觀

前面三場其實你也不得不做如此選擇,因為是全場聯播;但,即使撇開「全場聯播」這件事情不理,這三場還是很有吸引力的。

做 Open Data 的夥伴,相信一定很想有機會直接面對在政府裡的負責人,而前 Google 亞太營運總監、現在在行政院負責協調跨部會科技業務的政務委員張善政先生,無疑是最佳人選之一。這也是 COSCUP 幾年來少見,直接邀請政府單位相關業務負責人前來演講的狀況,全因 Open Data 這個議題中,政府機構的資料釋出是最被關注的一環。

第二場則是議程組絞盡腦汁開出來的好菜,也是 COSCUP 在第二屆的「開放組織新人秀」之後難得又有的座談會形式議程。除了張政委之外,有雲端翟神翟本喬,Open Content 推動者莊庭瑞老師,以及戰力超群的「零時政府」高天師 clkao,主持人更是 COSCUP 前任總召葉平。個人是很有興趣聽聽他們針對 Open Data 能激起怎樣的火花。

開源硬體有什麼意義? / What does it mean to open-source hardware?

我很少說自己覺得崇拜誰。若有的話,翟神非常可能是其中一個,且講題我也蠻有興趣的,就它了。

如果爆滿,我可能會去「Hello! NFC!」瞭解一下這個玩意。

教會改用 OpenOffice.org 的經驗

作為推廣者,對於導入有興趣,應該也是很正常的 :) 實例分享最是難得,我想聽聽他們怎麼做。
滿了的話,我可能會去「純自由軟體的虛擬偶像歌手實作」,Paul 的議程應該很有趣吧哈哈哈!

當設計遇上opensource,人人都可以是設計師

這段有點難選 orz,我自己也算是非正規設計師,且一直很想在 COSCUP 裡多放點非技術人員的 Open Source 觀點,所以就選這個。

它擊敗了「經驗分享:用 Javascript 實作注音輸入法」「Good Rice: A Real-Life Example of Linked Open Data」,以及 MozTW 有參與的「座談會:找人來了後怎麼辦?開源專案的志工經營分享,以Mozilla、Wikipedia、與OpenStreetMap為例」

便利專案管理的輔助制度:貢獻者契約

這邊也有點難選,不過看了一下描述後,還蠻想聽聽冬梅姐對貢獻者契約的整理。

不過如果我腿很酸,也可能坐在原地聽另一個也有興趣的「以pure data製作中文歌唱合成器」,或者看上一場的情況留在「座談會:找人來了後怎麼辦?」

HTML5专业图像处理开源引擎-AlloyImage

對於中國的公司怎麼發展、釋出 Open Source 軟體很有興趣,所以大概不只是去聽 AlloyImage 介紹吧 :P 另外也很有興趣的是「App on Server: NAS 上的 App 開發與商業模式」,或者「How the KDE community ticks」

撥開法律服務的黑色迷霧

這一節也好難選 orz 最後選了看起來像是行政上實務經驗分享的這個議程。同時間考慮的有「Live Coding」(一直很想學 Pure Data 相關的東西),且其實推薦大家可以參考「Mozilla Webmaker 教育專案」

中国大陆开源社区的发展与现状

這一節也是好難選 orz orz
  • 「Listening me! 福利請聽」看起來很有趣,也想聽聽實務分享;
  • 半個(或者說三分之一個好了?)前端工程師的我,對「一小時 RWD 就上手」當然有興趣;
  • 我有玩 Open Street Map,也希望瞭解「自製簡易實景調查(街景)車」呀... 
不過,想想之後最難有機會面對面的或許是對岸的社群,那就去聽聽看他們怎麼玩好了。

Open Data in D3JS - 以零時政府為例

最近比較有在玩圖,所以應該會去聽聽看人家怎麼用 D3JS 來展示數據,另一個也很有興趣的是「Build your own Trello within 200 Lines of Code」

大陆地区网络状况简介

這個議程禁止錄影錄音,太機車,那就沒什麼好說了啊。爆滿的話我應該會去「從『小』投入立體打印」聽聽經驗分享。













2013/7/13

Now you see me, now you don't



UX Build 開始調整關閉鈕的空間,目前的設計是分頁超過一定數量後會隱藏關閉鈕... 還可以,視覺上是簡潔了點,但沒有非常喜歡就是(個人比較偏好要固定出現關閉鈕,畢竟 Firefox 的分頁有最小寬度、不必像 Chrome 一樣為了避免誤按而藏起來)。

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 而來的權力。

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

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

2013/1/30

[免費課程] 網站分析入門 - 給 FLOSS 志工社群網站管理員的網站分析

Today's latte, Google Analytics.

tl;dr: 2013/2/16 一整天,有免費的網站分析課程,歡迎報名。(請先參考本文最後面的報名資格)


我一直覺得網站分析很重要,但直到進入網路行銷公司之前,倒沒有很認真去看待這門學問。MozTW 早早就裝了 Google Analytics,也設定了追蹤下載量的程式,然後呢?我們知道每個月都有很多人上 moztw.org 下載  Firefox,所以呢?

「網站分析」在從前對我們而言,似乎就是網站的心電圖 - 放上去、會動,那我的網站沒問題,完工!

不過代誌不是我想的那麼簡單,深入探究才發現,網站分析其實可以提供一些問題的答案或線索,作為輔助調整網站的利器:

  • 幫助你精確思考網站的目的,以及「勝利條件」
  • 訪客進入你的網站,到底想做什麼?
  • 網站中的哪一頁,對於達成目標最有價值?
  • 又,哪些頁面可能有問題,需要調整?
  • 你的網站該前進 mobile 了嗎?
  • 放在別人網站的連結,到底有沒有用?

FLOSS 的志工夥伴平常看很多技術性文件、上開發軟體的課程,不過「網站分析」甚少落入我們的眼簾。趁著與公司 GG 閒在家的機會,這次我與 OSSF 合作,開設「給 FLOSS 志工社群網站管理員的網站分析」入門課程,希望在提升社群網站品質部份有點小小貢獻。

我們將以 Google Analytics 為工具,課程內容預定包括:

  • 設定 Google Analytics、埋設基本追蹤碼
  • 重新思考網站目標,定義網站目標
  • 重要數據與報表說明,如 Visits vs. Pageview、Bounce、Conversion、Traffic source 等等
  • 區隔,與進階區隔
  • 自訂報表、Dashboard
  • 自動信件通知設定
  • 設計多網站分析結構
  • 權限設定
  • 其他我突然覺得很重要的東西(炸)

小弟在 FLOSS 社群裡從來不(也無法)以技術能力走天下,因此可以想見這門課程不需要太深的技術能力,適合推薦你社群中熱心幫忙、但非技術人的夥伴參加。所有需要的科技知識(Cookies、Referral、Domain & Sub-domain、基礎 RegExp...),我都會試圖在課程裡解釋。

感謝 OSSF 鼎力支援,這樣的課程將完全免費 -- 當然,市場上也有其他網站分析的課程,而為了讓該給 FLOSS 社群的資源能妥善利用,我針對報名者資格做了點限制:

Update: 我們應該還有名額讓不符下列條件的朋友報名,所以無論如何還是歡迎填個資料。

  1. 參與者應該擁有任一 FLOSS 志工社群網站的管理權限
    • 網站需與 FLOSS 志工社群相關,開放規格的語言(Python、JavaScript)亦可、研討會 ok
    • 如果您是拿薪水來協助管理 FLOSS 志工社群網站,那請找坊間的課程來上。我個人推薦喬后的課,作為我在知世的好同事,她在網站分析這門學問上也更專業。
  2. 或者,任何擁有條件 1 資格的人,願意幫你背書、按你的要求調整網站
  3. 又或者,你已經擁有任一 FLOSS 志工社群網站的 Google Analytics(或其他分析工具)的管理權限
  4. 場地沒有電腦,歡迎自備上網設備
    • 非 100% 必要,但有實際看會比較好
    • 又,用手機會看得爆炸辛苦,建議至少是平板,筆電還是最好的

如果你符合這樣的條件,歡迎填寫這份表單,我們在確定後會發給你 OSSF 報名 VIP 碼協助你報名。

填寫報名申請表

願力無邊但名額有限,所以有興趣的夥伴馬上報名吧 :D 隨附我在 WebConf 2013 講的「網站分析?我小時候以為自己會」簡報,供參考。

2013/1/25

關於 COSCUP 參與人員的雜記

前幾天聽說,有人覺得我在 COSCUP 就是不斷把 MozTW 的人帶進去。

這確實是我 2010 以前在做的事情,畢竟 MozTW 很多(絕大部分吧,哈)核心成員都不是技術人員,他們能對 Open Source 世界最好的貢獻,其中一項就是在這些不需要技術底的領域服務。不過至少我突然很好奇:那麼幾年以來,掛上 MozTW 名稱的決策參與者有多少,有怎樣的變化?最重要是,我有沒有偏袒什麼?

先定義「決策參與者」,雖然 COSCUP 一直都把絕大部分的決策攤給全體工作人員出意見,但我會傾向覺得所有「組長」職、場務組的「小組長」職,以及議程委員會的成員屬於研討會裡比較該先計算的決策參與者。做事的人最大,而組長一般也是最勞心的;議程委員會會決定整體議程的走向,不可說不重要。雖然一定漏了很多因素,但這樣的想法應該還算可以接受。

由於手上沒有組員資料,先算組長吧;網站上只有 2011、2012 的組長資料,我連同今年的一起計算後,比例大概是 30.7%、20% 及今年的 33%,我每年都減少 1~2 個組的決定讓比例比較高一點,不過去年倒是只有 20%(意外地少,我自己是沒注意)。

好像不算太偏袒,但倒是意外發現一個問題:「名字後面不掛社群品牌」的組長比例,前年是 30.77%、去年是 60%、今年估計應該是 40%(我也不會掛),這樣的比例似乎有點讓人擔心。我的疑惑是,這些不掛社群品牌的人,是因為認同 Open Source 所以來辦活動,還是單純因為喜歡辦活動的氛圍所以參加?

希望是因為認同,不然 COSCUP 的演變就是專業研討會活動公司了,這樣不好。

看可以來做點什麼。

2012/9/29

HTTPS 的 referrer 狀況筆記

很快筆記一下,周三去聽喬后演講時,她講了個我從前不知道的事:HTTPS 的網站連向 HTTP 網站時,瀏覽器不會送 referrer。以目前大部份網站都沒用 SSL 的情況來說,這會讓分析時高估直接流量(自以為有很多人加入書籤?XD)、且可能低估某些來源的威力。剛巧又有人貼了 Search Engine Land 的文章,說 iOS 6 因為預設搜尋引擎與 Firefox 相同,都轉往 SSL Search,所以就不送 referrer 了。如此推算,被低估的部份就變成自然搜尋,但這是網站健康程度的指標之一,雖然重要性就看個人,但若有需求該怎麼解決?

那就測試一下吧!Dropbox 的空間可以用 SSL 存取,所以我做了個簡單的網頁來顯示 referrer,想等 Google 去索引此網頁後再來測試搜尋。但,後來想到更快的方法:Facebook 也是 HTTPS 吧?那就從 Facebook 去連這個檔案就好。
好,所以事實證明,若 HTTPS 網站轉進另一個 HTTPS 網站時,還是會送 referrer。所以,如果想避開這種狀況帶來的影響,讓自己的網站也採用 HTTPS 就好了。花錢能解決的事情都是簡單,接下來的問題只在值不值得花。

不過現在大部份網站並不採用 HTTPS,那按理說會造成一部份的自然搜尋來源蒸發現象。但以我可以看到分析資料的網站而言,在 Firefox 預設改用 SSL Search 後,這種事情卻沒有發生,難道這代表 Firefox 的使用量已經低到無法撼動任何東西了嗎? XD

這倒也不是。其實 Facebook 等網站或許因為廣告等需求,就算你用 HTTPS 連,他的 proxy link 仍採用 HTTP 未加密連線。也就是說
  1. 你使用 HTTPS 來連 Facebook,並點擊一個看到的對外連結
  2. 這個對外連結會先跳到 HTTP 連線的 proxy link:以我的測試網站來說,就是 http://www.facebook.com/l.php?u=https%3A%2F%2Fdl.dropbox.com%2Fu%2F3280872%2Freferrer.htm&h=YAQH98kqz
  3. 這樣正式連過去另一個站的時候,對方無論是否採 HTTPS 連線,仍可收到來自 facebook.com 的 referrer
實際上 Google 也是如此,即使你採用 SSL Search,按照 Search Engine Land 的方法到 whatismyreferer 測試,對方也能正確顯示你從 Google 來。因為 Google 也用 proxy link 當跳板,然後這張跳板也刻意僅用 HTTP 連線。這是 Firefox 採用 SSL Search後,在數據上沒有造成任何影響的原因。

最後一個問題 - 那為什麼 iOS6 採用 SSL Search 後,搜尋上會造成這種影響?從剛剛的各種線索推算,答案就簡單了:因為 Google 行動版的行為不同。Google 行動版雖然也用 proxy link 來計算點擊數,但這個 proxy link 卻採用 HTTPS 連線,所以瀏覽器發現連線對象是 HTTP 網站時,也就很快樂地把  referrer 擋下來了。你可以用 Firefox for Android 搜尋 whatismyreferer 後,長按搜尋結果連結來證實此點。

喔,這樣才是置入性行銷啊 :)

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/11/8

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

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

頁籤文字小到無法辨識的 Firebug

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

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


  5. 重新啟動 Firefox

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

2011/10/24

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

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

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

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

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

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

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

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

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