顯示具有 心得 標籤的文章。 顯示所有文章
顯示具有 心得 標籤的文章。 顯示所有文章

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/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/7/6

「我殺了他」,想法、筆記與推斷

三不五時會買一本小說(不然,通常在他處看完便不會再看了),既然買了、又對真兇有一定把握,或許參加一下書商辦的活動也不錯 :P

幾點感想:
  • 「我殺了他」裡的加賀恭一郎還是只出場一下下,不過搭配腦海裡阿部寬的臉,倒不會太不起眼。(但,小說裡的寫法感覺不太到個性呢,好像是哪個刑警都可以的樣子。)
  • 且先不論好不好看(我是盡可能在短時間內看完了),這真的是本奸詐的小說。最後幾章努力讓所有嫌疑犯都有一樣的機會(例如,所有人都有機會持有兇器),過程中的描述有時也故意模糊了主詞。
  • 最後一章給的解說太明顯了。我原先蓋上最後一章時覺得:humm 那如果不用消去法的話難道要輸了嗎?我不想先用消去法,畢竟那大前提就得像暴風雪山莊一樣,「只可能是這裡的人做的」,總覺得刑警在開放空間不能這樣推斷吧?但,解說裡給的提示讓我靈光一閃,對照證物傳遞路徑之後... 靠,果然有個可能的破綻在那邊。再翻了一下前後的相關描述,一切都齊全了。
那麼因為我要參加這個,所以接下來要說明我的推斷(才不會只「三選一」勒),會有雷,也歡迎有看過的來討論討論。(可以跟我借噢,我超貼心的這次把筆記都另外寫 :P)


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/6

COSCUP 2012 - 改變與檢討 (1) 交誼廳、Workshop、接駁車

檢討的部份或許檢討會上可以再補充,先列一些我們嘗試的改變,並提一些個人的看法 -- 如同沒有人能夠代表社群一般,即使作為 COSCUP 2012 的總召,我仍沒有意思在這裡代表整個籌辦團隊發言。以下的紀錄,或可說是分享,但更多其實是為以後的自己記錄。為免富奸上身,寫幾點我就貼一篇,就算真的上身了至少還有產出...

取消交誼廳議程

IMG_0149

除了行政部份「一切從簡、降低負擔」這種與會者看不見的變化之外(之後會討論,不富奸的話),取消交誼廳議程或許是最早決定的改變,源自於 COSCUP 裡有幾年的「交誼廳其實不適合放議程」爭議。去年已經稍有改變,在第二天改以 Unconference 的方式進行而只預排了一天議程,今年我跟議程組長打開始就希望讓交誼廳回到「交誼」性質,讓想休息的人有個地方可以去。

實際狀況裡,或許因為宣傳不力、或者在中研院的場地裡空一間出來隨便大家搞仍是新機制,總之「交誼」的效果似乎不佳。又,今年 COSCUP 很幸運的逃過颱風,而且居然一滴雨也沒下,於是交誼廳當然也不會有以前發生過的積水問題。這倒無損我認為應該尋求別的方式來消化場地總人數的想法。

說「場地總人數」,因為中研院人文館單論座位,其實無論如何是無法容納上千人的會議。取消交誼廳會讓這個問題更嚴重,所以一方面第二天仍有 Unconference,二方面我們需要多一些東西來幫忙消化人,這就是下一項「Workshop」。總地來說,取消交誼廳議程其實並不那麼不可行,以中研院的場地對照單日會眾人數近千人但有兩百左右在會議室外(工作人員、攤位人員)來說,塞一下還是進得去的。

增加 Workshop

COSCUP 2012 Day 2

因應取消交誼廳,我們搬出了另一個很久以前也討論過的東西:Workshop。在以前的討論裡,是希望舉辦 Workshop 將 COSCUP 變成一個三天的研討會:第一天是 Workshop,接著兩天是原本 COSCUP 研討會型式的會議,今年既然是要處理人數問題,那自然就是一起辦。

在原來的規劃上,COSCUP 主辦團隊負責場地,與最基本的電力與網路協助,其他在這三小時裡要搞什麼,就全部交給審核通過的社群搞。某種程度上,你或許也可以把它視為外包給某個社群的議程區段 -- 事實上 JuluOSDev 的方式,就很像理想中的狀況,也確實吸引很多聽眾。不過由於第一次辦,分工上沒討論清楚讓大家忙得團團轉,有了這次的經驗,下次再明白定一下分工(大聲地說出「COSCUP 只負責場地,報到及現場其他工作人員等請自行處理或另外提出需求)應該可以跑得很順。

「Workshop 主辦人是否具備講師資格」也是一項爭議,我的定義裡是不算:這三小時基本上就是讓接手的社群自己決定要怎麼搞,你可以像 Fire.app 一樣就是一個講師從頭到尾,也可以像 Julu OS 一樣一堆人輪番上陣;或者可以是一個人主講、另一堆人協助與會者動手做,也當然可以就直接作為相互討論特定主題的園地、只有協助秩序的「主持」而沒有講師。由於型式太多樣,我們也不願多做限制,那相對來講就不將「COSCUP 講師」資格賦予講者。我們看到 Julu OS 自己額外做了 T-shirt 鼓勵分享者,是很好的範例。或許下次雖然 Workshop 講者仍不直接賦與 COSCUP 講師相關回饋,但可提供主辦社群定額 VIP 及兩個講者晚宴出席名額,可以平衡一下,也避免「Workshop 講師比較不重要」的誤會 -- 單純是因為定義不同而已。

不過為了確保 Workshop 人數,先前採獨立招生的方式讓我們吃了點苦頭,最後的決定「讓 Workshop 參與者同時擁有 COSCUP 入場資格」也有不少意見。如果再來一次,我想我會選擇回到「讓 Workshop 跟 COSCUP 報名完全脫勾」的想法,並且在市區另開戰場、於周五舉辦。這個想法優劣並存,讓下一屆的人去評估得失吧。以前的 Workshop 討論裡,其實還有「Workshop 就獨立收費」的想法存在過,不過不在這次的考量中,就不多談。

這是我們第一次辦 Workshop,招待不週請多包涵,也歡迎留下你的想法、甚至搶先表達明年當工作人員的意願 :P

取消去程接駁車

很多人以為這次 COSCUP 取消一大堆東西是因為經費不足,其實反而是先為了要節省資源降低負擔,才決定多所限制。這包括設立工作人員員額制度(很神奇吧,想當 COSCUP 志工也會有名額有限的一天...)、取消二籌見面會議改以兩次線上討論取代、降低會前會與檢討會人員餐費等行政項目,也包括取消上午點心、減少便當數(這兩個加起來有不良影響,容後討論),以及這一段要討論的「取消去程接駁車」等影響會眾的事情。

第一班接駁車

COSCUP 從在中研院辦的 2010 年起,首開先例設置了「接駁車」,方便當時只能從捷運南港站來的會眾前往中研院,到後來其他研討會也多有跟進。過去成效不算差,那這次為什麼要取消?原先是我在 PyCon Taiwan 時跟一群在辦研討會的人提到,從南港展覽館到中研院的車超多,似乎沒那麼必要提供接駁車,且我也希望由會眾自己負擔一些費用。小朱提出一個看法:早上真的有點懶得走中研院門口到人文館的那段路,沒來過的人面對這段路也怕迷失。於是大家討論出計程車共乘是個好方法:每個人分 25 塊並不是多大的負擔,不用等太久、滿四人就走的方式也比接駁車好一點,另外我個人奢望能造成一點額外的作用 - 本來開源人們就是要拿出家裡的青菜煮石頭湯,鼓勵共乘讓大家一起坐小黃也增加認識同好的機會。於是,在公開討論區發表取得共識後,決定取消早上到會場的接駁車、改以配套機制鼓勵計程車共乘。

這個作法似乎招來了一些抱怨,不過大致上來說接受度也還不錯。兩天的駐點時間(上午八點起的一個小時)都有約 30 班次小黃前往中研院,保守推估兩天各有 90 人以上搭乘計程車前往會場,我個人覺得下次還可以比照辦理。

那麼晚上的接駁車何以不一併取消?一方面要叫計程車進來人文館並不方便,二方面在夜裡讓不熟悉場地的會眾從人文館走到中研院門口好像也不太保險,有鑑於安全與方便,仍然提供晚間接駁車。是說,大家在第二天結束的時候不太捧場,據說坐不滿一班?或許第二天晚間的接駁車還可以再減少班次避免浪費。


這三項基本上結果都還算可接受,或甚至可以說是好的。下一篇再來談有不良影響的「點心減量」 + 「便當限量」... 不富奸的話。

2012/9/5

我使用的 3 種網站框線圖、原型工具比較

工具有好有壞,不過到一個地步後,比的常只是適用時機跟熟悉程度。抱持這個信念,我經常試用不同的網站框線圖(Wireframe)及原型(Prototype)工具,以下整理此時此刻還算熟悉的三種 – MS PowerPoint、Adobe Fireworks、Balsamiq Mockups,並從個人角度予以比較。其實我自己還用過 FlairBuilder、Axure RP,當然還有手打 HTML,不過這其實是篇躺在草稿匣裡超過一年的文章,且讓我先中斷拖搞吧。

要繼續看下去之前,有些背景資訊還是先聲明一下,這應該有助於讀者判斷我的論點有多少參考價值:

  • 我曾經服務於知世安索帕,處理使用體驗事宜。個人負責的部分,會需要製作原型的時機,大多是為了要說明或實驗某種互動情形,而專為那些小範圍設計的互動原型。
  • MozTW 的網頁,我大多都參與製作過程,也經常是類似於企劃的腳色,目前 Mozilla Taiwan 的網頁我也有參與。
  • 本文寫作時,我還沒什麼機會為大網站製作原型,大致都是活動站或甚至單頁。偶而有時會製作小程式軟體的。後來有機會製作某大網站的框線圖與使用性測試用的原型,此時 Axure 那類有 Template 的工具會有點用,但為了其他人作業方便我還是用了 PowerPoint。
  • 如果是自己要用的框線圖跟原型,我大多不在意顏色,偶爾會需要強調些什麼就是了。
  • 我常切換於 Linux、Windows、Mac 之間,三邊都能用的軟體在我心目中會大加分。

那麼就開始吧:

Microsoft PowerPoint

PowerPoint 是我大學時期的好朋友,十分熟悉。組合動畫部分我小有心得,應該可以把「以具象動畫解釋抽象意涵」寫為專長,也以製作多媒體簡報為名做過幾個案子。PowerPoint 的優點是在微軟的努力荼毒之下,每個人多少都會用(精不精另當別論),也就是說這是個蠻適合多人輪流編修的工具。

image

  • 本文撰寫時最新版:2010 (Windows)
  • 價格:包含在 Microsoft Office 中,商用版定價約一萬元,不過你公司八成已經有買授權 :)

但也就是如此了。一般的狀況下蠻 ok,不過 PowerPoint (以及 Word)都為了「一頁看得完」的模式設計,對於經常一頁望不完的網頁來講是個阻礙思考的石頭。又,雖然有動畫功能,且結合多頁仍然可以做出還蠻不錯的互動效果幫助說明,不過它的本意畢竟不在此,除卻滑鼠點擊之外的行為都有點麻煩。由於兩邊不討好,還有其他選擇的情形下,無論是畫純框線圖,或者製作互動原型,PowerPoint 不是我的首選。

那為什麼之前會用呢?因為還要跟沒有其他選擇的人一起畫 XD 又,有時就是得把做出來的東西整理到投影片上,那麼這樣可以就地編修,也還算是個額外加分的優點。不過 2007 改介面之後畫圖變得有點麻煩,不知道能不能把繪圖物件單獨拉出來變成面板,這有點阻礙我的思考速度 :/

如果你也需要用 PowerPoint 來畫框線圖或簡單的原型,可以考慮下載這兩個元件範本來用:

當然,作為自由軟體的支持者,不免要提一下 OpenOffice.org 這個免費、功能也不錯的辦公軟體。在繪製框線圖及簡單原型的部分,我覺得 OO.o 的 Impress 與 PowerPoint 大致是一樣可用,如果你是個體戶想省點錢,OO.o 夠了。不過 OO.o Impress 的動畫部分,雖然已經支援了 PowerPoint 2000 以後的所有特效,但編排介面說實在很差就是。

Adobe Fireworks

Macromedia 惠我良多,最愛的軟體是 Dreamweaver 與 Fireworks,也曾獲邀參加 Close Beta 測試。由於在 Fireworks 8 以前一直是愛用者,熟練度算也蠻不錯。

雖然我確實比較不喜歡換成 Adobe 品牌後的各項老 Macromedia 軟體,不過從 CS2 之後開始不用 Fireworks,卻不是因為情感上的理由,純粹因為當時我就轉用 Linux 了,而 Fireworks 8 用 Wine 跑得很順。事實上 gfx.tw 的 mockups 就是用 Fireworks 8+Wine+Linux 畫的。

Adobe Fireworks CS4 Beta

  • 本文填寫時最新版:Fireworks CS6
  • 價格:大概台幣 14000 元,愈來愈貴了!

Fireworks 在我心中還是繪圖工具更多一些,不過產品策略上近期確實越來越轉往原型製作了。既然原本是網頁用的繪圖工具,超連結什麼的它當然有顧好,甚至也可以打簡單的 HTML 區塊進去。很早就有多頁概念的它,簡易的互動原型不成問題,而一直以來也有雄厚的擴充套件作為後援、讓你更方便地加上網頁相關的物件。

缺點是你會很容易往視覺的方向想,畢竟它本來是繪圖軟體嘛,東加一點西加一點,定力不足一下子就迷失了 XD 又,因為後來發現 Balsamiq Mockups 實在爆炸快,如果不是必然得要測試視覺的狀況,就不會用 Fireworks -- 連光碟都忘了丟哪裡去了…

據說近期 Fireworks 新增了很多方便製作原型的東西,如果你本來就需要用這套軟體修圖,可以考慮採用,我自己是沒在用了。

Balsamiq Mockups

掀起手繪風框線圖熱潮的 Balsamiq Mockups,一開始用只是覺得實在太可愛,後來倒是發現它很努力地往「讓你更方便快速地說明」這個方向前進。

image

它的功能很簡單:框線圖。由於架構在 Adobe AIR 上,所以 Linux、Mac OS X 以及 Windows 都可以用,且檔案格式開放所以也有一些程式支援匯出入,例如 iPad 上的 iMockup、FlairBuilder 等等。

相較於其他這邊介紹的工具,它很貼心地在你滑鼠移到某物件上時,就自動在旁邊顯示相關的屬性面板。雖然其他工具多少會用工具列來讓你方便調整,但「在旁邊」和「在上面」是差很多的。另外,豐富的預設物件集,涵蓋網頁上的基本物件及一些常見的組合效果(例如分頁、地圖等),輔以可愛的手繪風,這些都讓 Balsamiq Mockups 在編輯上順暢又愉快。就我個人來講,畫框線圖用 Balsamiq Mockups 是最愉快的

互動能力部分,基本上近乎零。你可以為物件設定點選的連結,不過就只能是這樣而已。如果要做互動原型,可以考慮搭配 Napkee 做後天調整,但 Napkee(我也有授權顆顆)不是很好用… 所以我僅拿來畫框線圖而已。

由於它採一個檔案就是一頁的方式,或許不適合頁面數量太多的網站 -- 管他的我也用不到 XD

使用這套軟體的朋友可以多逛逛 mockupstogo.net,上面有很多別人已經畫好的東西可以直接載來用。


之後有機會再來補上 FlairBuilder、Axure RP Pro 及手寫 HTML 的狀況,其實我真正還想討論多人共編時的狀況 (這會需要考慮團隊成員全體的軟體使用能力,以及元件重複使用的可能性),但,以後再說吧。

2010/8/25

Default Settings of CamStudio For UX Test

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.

2010/3/31

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

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

關於電子書標準進度報告

  • 對於最後選擇 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 書都看好幾本了。

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

雜談 ccPlus 運作模式

這篇是下期 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 條款,因此自動列出下列購物選項供包柏選擇:

  1. 除原條款授予之權利外、額外增加「商業使用」的權利:1000 元/單件作品
  2. 除原條款授予之權利外、額外允許免去「相同方式分享」的權利:3000 元/單件作品
  3. 直接購買一般性商業使用權利 (不需標示姓名、不需相同方式分享): 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 概念推出已經超過兩年,目前實際支援這項技術的獨立授權代理商就是找不到。以全球作為市場範圍來講,這多少應該還是個有利可圖的行業,會造成毫無獨立廠商支援的理由,筆者隨便猜一下:

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

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

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

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

2009/10/30

MozCC 在 Jetpack 裡重生:JetCC

在弄 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 可以安裝的擴充套件也不錯 (應該也相當簡單)。

2009/9/3

Mozilla Labs: Bespin

去年十月 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/8/18

COSCUP '09 主持心得

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

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

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

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

2009/8/13

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

自由軟體的參與者,依據 COSCUP 的分類法是開發、推廣、使用三個層面(我完全不知道這是誰先提出來的,所以請恕我無法準確姓名標示 :P) 。這三層有些要點:

  • 所有人一定至少是使用者,不使用但參與開發和推廣的難有熱情支撐
  • 推廣者不見得會開發
  • 開發者不見得想推廣
  • 以為自己會開發的推廣者跟以為自己會推廣的開發者都很多

所謂的推廣者,在這邊我想稍微清楚由自己的角度定義一下。「推廣行為」指會直接擴展使用者或貢獻者數目的行為,所以如果只是接 ticket 開發就很明顯不是,而跟左鄰右舍好康倒相報的算是。幾年前 COSCUP 網站上曾提過推廣者是「把軟體包裝成套件」這類的,雖然打包的技術門檻不很高、不過畢竟稍稍有一點,所以我私心還是會推到「兼具些微開發能力的推廣者」或「兼具推廣興趣的開發者」那邊去。

又,之前也提過消費者和使用者的區別,但我這邊先混雜在一起了;如果強要分類的話,我想由於軟體的開發畢竟還是萬事的起源,所以行為無法對開發這件事情有直接或間接貢獻的、或許就可以算是消費者。無論如何這邊先不分,那麼以此三者應該可以繪製成這樣的圖:

既然都被稱為是三隻腳了,理論上三者的關係應該會是彼此互助通力合作的:

不過實際上由於種種因素,我個人的感覺好像是這樣:

這邊看起來好像使用者能做的事情真的很少。以前就提過關於貢獻率的問題,我一直在想:有什麼是單純作為一個使用者可以貢獻的事情?

  • 捐錢贊助自己支持的軟體,此為正解。
  • 跟朋友推荐嗎?那你就變成推廣者了 (恭喜~)

…後來發現自己真的想不太到,這樣要怎麼提高貢獻率呢?要大家多捐錢嗎? (你捐了嗎?)

我想 GFX 或許就是路徑之一。如同之前所說,我自己是希望「提供更多、更輕鬆並且容易抽身的參與機會,讓人進來先挽起袖子動手碰碰看再說。」除了方便推廣之外,也更提供一個「讓你自己說」的途徑。整個專案從頭到尾,我們都希望把「選你自己的選擇」這個意念傳達給使用者:你不需要在我們站上註冊、用你自己選擇的帳號供應商就好;你不需要侷限於 Firefox 產品頁上的介紹文、選你自己推薦的理由就好。這就是你自己的推薦網頁,你自己可以做決定。當然限於時間人力等因素,我們還沒有辦法做到更高度的自訂,但的確是朝著這個方向前進的。

朝著這個方向前進,也就是說除了勸大家多捐錢之外,我們正試圖讓更多一般使用者也能搖身成為推廣者。

目前 GFX 已經為我們多帶了數百位推廣者進來,這些人裡很多我們早已熟悉、也有很多是先前不認識的,無論如何效應的確有做出來。接下來或許就是要好好考慮幾個方向:

  • 怎麼讓推的人覺得更有意義?成就感更高?
  • 怎麼在加強自訂功能與降低複雜度間取得平衡?
  • 還有什麼 Open 的概念可以幻化為其中的功能、介紹給使用者?

一直記得推廣活動的成功與否要看能帶進多少長期參與者。一切應該會更好吧,我這麼相信著。

2009/3/26

該怎麼定義 MozTW 社群?

早上寫的信,整理如下、表達一下我的看法:你怎麼定義誰是 MozTW 社群、或不是?我個人是傾向不定義。或者先換個角度,社群成員應該會有哪些行為?你可以

  • 單純因為支持網際標準而推荐別人使用 Firefox
  • 設計一些好看的海報協助宣傳
  • 從社會運動角度、寫支持網際自由的文章,為他人提供思考的衝擊
  • 在討論區上為新手解答疑惑、或者就寫教學文件降低進入門檻
  • 協助辦活動,協助募款
  • 提供行銷企劃方案
  • 提出網路使用行為的分析報告,協助大家改良網路體驗
  • 或者,最單純最單純地,你使用 Firefox,讓各大網站設計師有遵循標準的理由 (或說壓力)。

在 Mozilla 這樣的專案裡,貢獻的方式千奇百怪,若要限定一個範圍才叫作「社群成員」,不免排除其他方式、排除其他可能。面對他人的詢問,我經常用這樣的回答:「廣義來說、有用 Firefox 就是社群成員;狹義的話,就是經常參與:討論、分享、協助辦活動等等。」其實,這依然刻意避免定下範圍。之前在近期碎念裡提過的,「之所以老回答不出來『社群有多少人』,正是因為不想忽視、貶低任何一點支持的力量」,是依循這般信念寫下的。

MozTW 本來就是個在網路上的社群,是或不是 —— 你覺得是就是,不是就不是。這說法很詐,不過實情確實是如此。

但正如你我一樣、社群成員可以有各自的思考,這部份是獨立的。那麼我們怎麼知道社群的意識是什麼?事實上,這不是以人、而是以事為主聚集的群體,而對事情的看法即便是一個人也能有眾多面向:你擁護 Open Source 不見得要擁護 Free Software,但至少這兩件事情都是「自由」這個理念的面向之一,是以、我至少可以說這個社群是熱愛網路、熱愛自由的,也因此形成所謂的社群。

或許最好的公約數是「熱愛網路自由」,並由任何角度參與 MozTW。這些就是社群,社群就是我們。

那麼誰是所謂的「Official」呢?或者、「Official」這個概念在這類的社群裡面,該怎麼變化?目前來說,我的職稱是因為實際需要而定下的 (記者看不懂「社群成員」這四個字,有時也很難解釋),而通常正式發言時我也只敢說「我的想法是」而避免用「我們的想法是」來企圖代表社群。不過無論如何,實質上我可以控制主機、實質上我對專案的參與比較積極、實質上別人乃至於 Mozilla 基金會要找台灣的時候會找到我 (以及 MozTW.org),那麼我只能力求自己反應社群意識、然後就依據自我判斷行事了。我是不是官方的一份子?不是也是、是也不是。

或許等到哪天我開公司來養 MozTW 的時候,這個問題會比較好解答 XD

2009/3/8

Firefox 3.1 改了版號,之後呢?

「Firefox 3.1 八成會更名為 3.5」,這是我前幾天看到會議記錄裡註記「考慮要改」之後的感想。昨天很快地看到 mozilla.dev.planning 上已經提出了各項配套,看來就是要改了。為關心的大眾先摘要一下接下來的進展:

  • Firefox 3.1 Beta 3 還是照原訂計劃,依這個名字出
  • 接下來就是 Firefox 3.5 Beta 4 了
  • 原先在 Trunk 裡的 3.2a1pre 接著會改名為 3.6a1pre,不過不代表接著會用 3.6 這個名字出
  • 改名 3.5 大致上不會影響 (已經拖延的) 釋出日期,也不一定會再加新功能。唯有在該功能在 tinderbox/trunk 已經都做完了、不會拖延日期的情況下,才會放進 3.5

其他部份的詳情可以看 Mozilla Wiki,接下來整理一下前天在 Twitter 上跟大家的對談、及我的想法。

導致 3.1 b3 拖延的罪魁禍首之一是提升 JavaScript 速度的新引擎 Trackmonkey,曾經也有提出過是否要砍掉 TM 然後先推出 3.1;隨後,亦有人提議是否將 3.1 更名為 3.5。

我自己是支持保留 TM、改稱 3.5 的,不過這比較是推廣上的考量:首先、使用者的確已經在期待下一版能夠「快很多」,那麼雖然已經改了一些效能問題、但 TM 不進來是不會快「很多」的,可以參考 CNET 最近的測試報告,便知有沒有 TM 的差距;另外,這一版裡加上的各項 CSS 修正搭配 HTML 5 Video/Audio 元素、Tracemonkey、隱密模式等等的其中任何一項,都已經足夠作為一個 0.1 版,這樣一推出我想使用者會預期下一個 0.1 也要有這麼大幅度的改良,這樣壓力也太大了、並且其實一點都不符合 release often 的構想;最後,Firefox 4.0 T-shirt 樣式我已經想好了,不想等到 202x 年才能用啊 XD

我們可以說一開始把 3.1 塞這麼多東西就是錯誤 (這是我的理由),不過現在改 3.5 我是支持的,以推廣的角度。

alicekey 提到覺得 Mozilla 不嚴謹,並以 Ubuntu 為例、希望可以定期出。對我來說,以 Ubuntu 當標準是絕不認同的啊,這很主觀地因為 8.10 給我的回憶太可怕,從來沒有在灌上後這麼期待半年後新版快到來的 XD。這邊不是要認同「軟體業拖延是常態」 (雖然的確是),但一開始的規劃太龐大是錯誤、改版號在我的觀點來講卻不是。那就是個版號而已,鬆比緊好,大家可以過得比較輕鬆愉快一點。

最後感想:任何對 Mozilla 開發進度認真的人都應該考慮訂閱 planning 這個 mailing list,然後在需要的時候發聲。這是你的軟體,而且你有權可以影響的時候,為何不呢?

2009/3/3

什麼很大?整理我的想法

剛跟 @pirrer 在 Twitter 上討論了一下某遊戲廣告的事情,我覺得還是整理一下自己的想法好了,140 字真的不是很好討論 (好啦,我文言文能力低落)。

緣起是這一句,我的想法是:其實我很懷疑這些討論能帶來什麼實質助益耶 — 也就是,如果那廣告的目的是促進「產品本身的銷售」,我嚴重懷疑成效如何。我也看那廣告兩三次,但我就是不會去玩 (然後我問周遭的人,還沒有碰過有玩的,這樣本數大概是十五左右吧,還不夠大就是)。

pirrer 看的角度則是比較相信這的確造成了來訪人數增加 (而可推論進入遊戲試玩人數增加),接著的問題是遊戲本身夠不夠吸引人,這就跟廣告本身無關。即是,他認為這個廣告是成功的。 (@pirrer: 可以這麼解釋你的意思嗎?)

關於這點正是我最懷疑的地方,其實我覺得網路商 (當然也不只是網路商) 有很多迷思,例如未被證明效果、只是跟風的行銷手法等等 —— 我知道本來就很難判斷某次行銷活動的確切效果,不過這麼講好了: 利用網路宣傳的效果、我猜想是被大部份行銷入門者過份高估的。諸如此類的迷思,我覺得很多。

來訪人數的確實增加了嗎?或許吧。真的讓比較多人進來玩了嗎?好吧這的確要看遊戲了,不過促使我懷疑的一個角度是:看到那樣的廣告,你會不會覺得自己玩了就好像白痴被爛手法騙進來一樣? XD

無論如何,看到該廠商下一個廣告我想就很明白了。

2009/2/11

YouTube + SlideShare

我經常在簡報時播放 YouTube 上抓下來的影片,一方面比較生動、二方面也比較省力。一般來說,在簡報結束後我都將投影片放到 SlideShare 上面提供大家閱覽、下載,不過會遇到一個問題:影片無法隨著投影片播放,也就只會剩下「Video」這個說明頁、看的人也不曉得我放的是哪段影片。

不過現在方便許多了,因為 SlideShare 新增了添加 YouTube 影片的功能。只要輸入 YouTube 影片網址、選擇要放在第幾張投影片後就行了。用在我上次為了資訊志工所做的 Web 2.0 投影片裡更可以看到效果:

Web 2.0
View more presentations from Bob Chao. (tags: 2.0 web)

每份投影片最多安插五段影片,對我來說大致上是夠了。不過,要選擇插入的投影片時只看得到「放在第 n 張之後」這樣的選項,有時實在記不太起來想放的是第幾張啊… 我現在是開雙分頁來相互對照,不過希望以後可以解決這個問題。

2009/1/24

雜記

這其實牽扯很多事情,我不願意向自己的思緒裡挖得太深、畢竟速記才是我的目的:

  • 公共關係
  • 訊息的完整正確性,在這個訊息四散快速流動的世界裡,是否仍是不可妥協? (我私心認為完全可以妥協 —— 長期看來是不能妥協的,但應該允許「部份」事實逐次流出,進而構成「完整」)
  • 怎樣的參與是參與?哪些方式的參與才能真正達到目的?若無法定義這個,你就沒資格說我的參與不是參與,而我嚴重懷疑是否能定義。「廣義來說,使用 Firefox 等軟體的,都可以算是社群成員。」
  • 或者,用利害關係人的概念更清楚些:即便是反對你的人,散佈反對訊息的同時都等於正對這個話題提出貢獻。
  • 如果我們,「網路原生種」的我們,的確必須連線才能發揮最強威力,那麼為何定要離線?這不可以是「沒有網路我什麼都做不成」的藉口,但同時要檢視「該離線」的言論,你只需問他五個「為何?」

2008/12/18

隱藏發佈後之 Google 試算表的某些資料

這篇是我寫在 HappyMobs Wiki 上的文件,歡迎到那邊協助補完


用 Google 表格 (Form) 做網際連署等表單時,常會遇到以下需求:

  1. 最好可以即時公佈有哪些人已經參與連署
  2. 最好可以隱藏一些隱私欄位 (例如 email、電話等)

很可惜,需求 2 目前沒有很好的解法,至少現在是這樣。

解決方案

目前沒有很好的解法,但還是可以用笨方法解。以下是幾種笨方法、及其副作用的介紹。

For programmer: 或許這可以利用伺服端程式藉著 API 存取 Google 試算表後再顯示出來,但目前似乎並沒有人寫這玩意。如果你有寫了、或是有找到這類解決方案,歡迎協助編輯這份說明

Google 試算表裡的「隱藏欄」

副作用:對會 HTML 的人來說等於沒隱藏。

最簡單、也最不推薦的方法,便是先在 Google 試算表裡選取某欄、然後按滑鼠右鍵選擇「隱藏欄」,接著再發布。但這種方法只是把該欄位在視覺上隱藏起來,其發布的網頁原始碼中仍含有那些隱私資訊,對於 會用 HTML 的人來說等於沒有藏。因此,真正私密的資料不建議用這種方法。

發佈「影文件」

副作用:需要人工手動進行,耗時、無法動態即時更新。

說穿了就是把資料內容「複製」到另一份試算表,刪去隱私資料後再發佈那份「影文件」,這樣可以確保發佈後的東西安全。

以下假設有一試算表 A 需要發佈並隱藏其中的隱私資料,將複製的步驟說明如下:

  1. 開啟試算表 A
  2. 點選 Google 文件介面中的「檔案>建立副本」,副本試算表的名稱請自訂 (在此以「B」為例)。
  3. 刪除試算表 B 中的隱私欄位
  4. 發佈試算表 B,並以試算表 B 的發佈網址為公佈名單網址。

如果你是想分享(而非發佈為 HTML) 給其他使用者,記得你刪除的資料依然會在「檔案>修訂版本資訊」裡出現,所以變成是要先在試算表 A 裡刪除敏感資料、複製出試算表 B 後,再行復原試算表 A 剛才刪除的資料。進行這樣的動作之前,請先取消試算表 A 的「表單>接受回應」,待資料復原後才打開。

日後要更新時有兩種方案可選:

同試算表、新版本
  1. 開啟試算表 A
  2. 點選 Google 文件介面中的「檔案>匯出> xls」,這樣你會下載一個 MS Excel 檔案,在此例為 A.xls
  3. 以硬碟上的軟體 (MS Office 或 OpenOffice 皆可) 開啟 A.xls,刪去敏感資訊後存檔
  4. 回到 Google 文件,開啟試算表 B
  5. 點選 Google 文件介面中的「檔案>上傳新版本」,接著選取硬碟上的 A.xls 上傳

這麼做的優點是發佈的名單網址 (試算表 B 的發佈網址) 不會變動,缺點是需要硬碟暫存、不方便在公用電腦等地使用。步驟 3 也可以先省略、待步驟 4 與 5 都做完後再直接用 Google 文件編輯,但若要這麼做請記得先取消「有變更時自動重新發佈」,免得把還沒刪除敏感資料的版本送出去。

新試算表

非常簡單,只要按著原來複製出試算表 B 的步驟再從試算表 A 衍生出試算表 C、試算表 D 等等徒子徒孫就可以了。缺點是發佈名單的位置會經常更動 (因為你每次更新的時候真正發佈的試算表都不一樣)。

其他連署方案

由於隱藏 Google 文件表單資料中的隱私資訊如此麻煩,若您真的很需要即時、方便的連署功能,建議採用 Zoho Creator 等其他連署方案,不要用 Google 文件。