Category: technology

趁著要飛回去的空檔講一下 Open Government Data Camp 的感想（極短篇）。

我那場運氣不錯，排在第一天的上午，雖然環境很不適合（相當嘈雜）而且非常混亂（有 SXSW 的實戰感覺），但幾乎是全室爆滿，談的就是莫拉克風災的經驗。我把層次再拉高一點到 open data 的「天堂」只會在災難時出現的這個點。因為泰國最近大洪水，所以聽眾很快就抓到我想表達的點。講開放資料的這些團體跟災難防救的那一群有點距離（例如 CrisisMap, Ushahidi），所以我就利用台灣的例子，嘗試把兩個串起來。

由於「莫拉克」的案例實在太特別，所以十分多鐘講完後，陸續有南非、荷蘭、英國、盧森堡、德國、法國、摩爾多瓦和羅馬尼亞的人來攀談並且詢問諸多細節。相當大的比例認為這經驗應該多說一點，所以我答應了 http://www.ejc.net/ 的一位計畫協調人，近日會寫一篇比較長的文章給她，讓這經驗透過歐盟新聞傳播學院的體系再發散一次。

這次順便把青平台基金會和 opendata.tw 廣為「佈達」。不過類似的基金會和計畫在開放資料的領域不在少數，台灣各個城市的體質以及 ICT 環境有這個機會，但目前狀況仍然沒有什麼值得提的。不過至少已經讓歐洲這幾個單位有個印象，了解台灣有組織、計畫和人在弄這個東西，也算是欣慰。

這是第二次在高雄的聚會。

一如往常，心色忐忑的到了高雄軟體園區，帶著老婆和小孩先在旁邊的店面覓食。13:50，到2號樓下等待其他人的到來。只見蔡志浩已在門口閒晃，我上前寒暄兩句。雖在網上認識至少有七年，但從未會首。此行初次照面，實在值得。不久後 Leon 也到，我兩笑說今日搞不好高標就是四人到場。眼見往來行人多半不認，暗自咐道真是選錯日子，三天「國慶」連假，早該出門遊玩。

不一會多人齊來，有兩位是日前在台北 Open Data 講座以及台中 Web Meetup 之友。原來出身高雄者並非少數，只是，有說不出的只是。好巧適逢大日，兩位朋友（Conrad 與富源）帶來婚宴名餅，飽食感添加不少。

4F窗台伴有碼頭美景，我等十多人，分次娓娓道來己身如何。這次僅有三位（包含我）是上次出席成員，其餘皆為高雄本地新識。此情甚好，否則三兩總是難以避免老調重談。此次來者，有產業背景居多。常駐台北而南下者有二，一位學生剛畢業，其餘則是高雄本地工作之朋友。有十年前返回創業的 Leon，也有近期才南下者。

但面臨的產業環境問題，卻不分南北，只是程度大小之分。我對高雄了解不深，頂多是十多年前海軍服役在左營登艦，當地產業結構，則是一概不知。有些困境雖然推想可得，但在 meetup 中諸君侃侃而談中，無論是單純抒發自己公司的經驗（現場有兩位老闆，一位是網路社群，一位是動畫），或是議及產業問題（幾乎每個人都有切身經驗），茶過幾旬，高雄 Web Meetup「忿忿不平」的感受，完全壓過台中場的氣味。

我也無法理解為何如此，可是隱約能感受道，好的契機正在萌芽。至少我等雖然同在資訊（軟體、網路服務）產業打拼，但過往沒有機會認識，也沒有這麼深刻的討論過一個地方的劣勢如何轉化為優勢的想法（例如台北相對於矽谷灣區而言，也是在地）。討論的這些人即使未身經百戰，也都有相當的經驗，願意花點下班的時間，在 Web Meetup 的場合討論、分享，甚至是激盪出在地與網路層面的可能性，這真的很不容易。

尤其是這聚會本來就沒有主題，也不是既有組織動員而來。

我很期待能具體的在高雄開出一個跟 web 有關的 project。或許 Web Meetup 的主題反而不是 Web，而是 Meetup 的火花可以怎麼用 Web 來實驗，例如蔡志浩所提到的 “Service Design” 和高鐵。

也歡迎台中和高雄的各位來 webmeetup.org 走走，這就是網路的聚會。十一月中，希望台南可以成為第三個固定舉辦的城市。

後記：聚會最精采的部份是各種當地的產業情報（苦笑）

本文同部刊載：http://www.opendata.tw/gov-data/cwb/

最近有一則關於氣象局新聞頗值得關注。根據媒體報導，氣象局在天氣預測的部份，即將實行368鄉鎮的預報[1]。預報資料的頻率是鄉鎮市區兩天內每3小時天氣預報，以及7天內每12小時的天氣預報資訊。

在開放資料的各種討論，氣象和交通資訊通常是最常被提及的資料類型。不只是因為這兩者所產出的資料，幾乎是所有民眾每日生活所需，而且由於資料本身的變異以及更新頻率相當的頻繁，在資料應用的方式以遊戲規則方面，也有不少的發展。

對於一般民眾而言，這是件好事。例如我們可以拜訪 www.cwb.gov.tw 檢索旅遊地區隔日或是未來幾日的天氣預報，好比在台北的萬華區，最近的氣候狀況和南港區其實差異頗大。以往在網站上只能看到整個台北市的天氣預報，現在預報區域縮小，透過專業的氣象人員所產生的天氣預報（詮釋），參考價值應能得到有效提升。

不過所謂某個地區的「天氣資料」以往並不是不存在，但民眾無法順利取得。原因不少，但我猜想，主要是氣象局並沒有義務或政策依據必須提供民眾透過網站使用氣象預報資料（或產品）。在「發展鄉鎮逐時天氣預報系統計畫」的資料內我們可以看到，雖然這是民國99到100年中央氣象局主要的施政計畫之一[2]，但預報資料要怎麼在網站上呈現，或是如何提供應用程式開發者一個合理的接取規則，顯然不在整體的考量範圍之內[3]。我們看到的反而是資訊服務被放在「加強氣象服務與推廣氣象防災教育宣導」的章節，而且這也不是一朝一夕的狀況。

這不單是氣象局本身的問題，更進一步來看，這幾乎是所有擁有大量資料的政府機關的問題。就算退幾步來看，不要求提供以開發者為導向的資料接取服務，即便是一般民眾要檢閱現有的氣象資料產品，達到氣象局所謂「推廣」的目的，可是，氣象局的網站在親和度（accessibility）卻一直是詬病的指標之一。網頁充滿了未經全盤思考卻硬把資訊塞放在首頁的毛病，網頁資訊區塊成為高階長官在螢幕上「指指點點」的受害者。相對之下，日本的 www.tenki.jp 就清爽許多。

試想，氣象資訊的數量之多，異質性高，但又必須整合為在效能、審美、人力、內部流程以及預算等各方面都符合要求的網站，誰說網站在開放資料各種討論當中，不是一門具體而且頗難的學問？

在政策和預算都無視網路已經是最主要資訊服務管道的此時，氣象局的網站氣象產品，也只是這些因素的果實罷了。網站服務既不是主要的業務，提供這項業務也需要相當的成本。若是民間的開發者[5]想自行運用氣象站資料開發天氣的應用程式，也只能透過迂迴的方式達成[6]。各相關者對於氣象局網站（資料）的諸多抱怨，其來有自。

欣聞最近又有不少以「雲端」為名的聯盟競相成立，但在刻意忽略國家級氣象和交通資料服務的狀況下，雲端要算什麼[7]，我認為大概只有行事（或形式、形勢）的算計層次而已。

[1] http://www2.cna.com.tw/ShowNews/WebNews_Detail.aspx?Type=FirstNews&ID=201109300017

[2] http://lis.ly.gov.tw/npl/report/991103/1.pdf

[3] http://www.cwb.gov.tw/V6/about/Strategic_Plan.htm

[4] http://zh.wikisource.org/zh-hant/交通部中央氣象局附屬測站組織通則

[5] http://zonble.github.com/twweather/

[6] http://pweb.cwb.gov.tw/phpBB2/viewtopic.php?t=1721&sid=fb68d5d24ba3daf14379428a6dd21ef0

[7] http://www.ncp.org.tw/vanilla/vj-attachment/2011/04/attach112.pdf

今天是 Web Meetup 的第三場，也是台中的第二場。聽起來這活動似乎很頻繁，但事實上第一場也只是兩週前的事情而已。每週在台灣的各個城市奔跑，美其名為 Web Meetup，是網聚，是新訊息的交流，也是重新和久未聯絡的朋友們敘舊的時刻。但真正的目的是什麼？ 最後的結果會是什麼？

我的初衷在前兩天寫道 [1]，今天再次來到台中。出席率百分之百，多了些不一樣的面孔，而來自加拿大的 Adam（@foodjing），也因為在活動的前一刻看到了目前在資策會任職的 James（@jameshilltaiwan）的訊息，直接跑來了 Mojo。

能交換心得的東西不在少數，看到這活動願意出席的朋友，動機也不太相同，背景更是大異其趣。不過有個可能的共通點就是，願意撥出生活和工作中閒暇的時間，看看新的事物，認識新的人。 +Kang-min Liu 在新竹，說要來台中買麵包。 +Jedi Lin 在彰化，其他人主要在台中，而我在台北，帶著老婆和小孩四處遊玩。

這次聚會總共有十位朋友，場地已經容納不下。

型態雖然隨意，但台中畢竟不若台北，人移動的成本相對而言還是相當高的。組織化的 meetup 是好是壞，該不該很有系統的辦個東南西北每週跑的活動，我也還不知道。

今天 web 談的不多，但聽到幾位不同背景的朋友講述自己產業怎麼切過來 web 的經驗，我很好奇，因為 web 除了是你我的生活的主要空間之外，在工作的範圍裡，也是慢慢不得已必須要面對的課題。對於專注在這產業稍微早一點進場的我們而言，有些社群和商業情勢的脈絡，再也清晰不過。但這事本來就是相對，早進場不一定比較有辦法，只是剛好，或是碰過而已（例如 +吟遊詩人安可 提到的 Wikipedia）。幾輪談話下來，曾有傳產經驗並負責實際業務的其中兩位朋友 +chuyi huang +I-Ting Ni ），切入的點就很不一樣，值得細細咀嚼。

我想聽的更多，即使是同一位 +ET Blue ，兩次對於她所從事的產業，都有不一樣的理悟。人生百態， +CQD the Good 說自己是竹科的逃兵。竹科？聽起來很近又很遠，台灣的話題總是會逃不出這個科學園區。 +Alan Lu 不知道為什麼，隨時敲著鍵盤，掛著神祕的微笑。

下次預計 10.14（五）同時段在東海書苑舉辦。我知道，還有 wiki 頁面要處理好，這也是身為一個拈花惹草的角色必須肩負的 to do item。活動訊息，容後發佈。另外也要先畫個押，以後我所知道的最新訊息，只會在 Web Meetup 分享。這應該算是彌補今天 web 濃度不足的懺悔動作。

[1] https://blog.schee.info/2011/09/29/web-meetup-3/

後記：通常「移動」就沒辦法 consolidate，會失去很多，不過我覺得這樣反而更好。

昨晚在幾封信的回覆中想著 data-driven organization（由資料驅動的組織？）的時候，下意識中浮現了前幾份工作的經驗 － 有淒離失敗的片段，也有快意成功的突破。一個組織的競爭優勢是否有機會建立在資料驅動的模式上（例如 eBay, Walmart），我嘴巴畫個樣子，應該不難推敲。

比如說，某個組織（不特定是商業還是公益）的雇員分為三個階層，分別是高階經營、中階管理以及初階營運單位。高階經營的主管在決定事情時，多半以直覺出發，要不然就是模式（pattern）。中階主管則是科層（bureaucracy）和混沌（chaos），初階則是流程（flow）以及公司規定。

這跟 data-driven organization 的關係是什麼？我覺得在輔導（？）或是誘惑組織進行深度內化的資訊改造前，應該要搞清楚這三個層面的人員是怎麼「決定」要做事情的。

當然這也可以應用到政府機關以及開放資料（open data）。

待續。

九月份下旬的五場活動之後，十月份上旬比較確定的活動行程是：

• 10/5（三）從群眾外包（Crowdsourcing）到資料民主化探討公民參與，台南
• 10/8（六）Web Meetup #4, 高雄
• 10/14（五）Web Meetup #5, 台中（原聚會地點租約到期，9月30日活動再討論）
• 10/15（六）Web Meetup #6, 宜蘭（6minut.es 會在當日公開）

歡迎舊雨新知繼續捧場。回鄉從喝咖啡（或茶、或豆花）開始，我想是最沒有負擔的了。:)

• 9/16（五）Web Meetup #1, 台灣台中
• 9/24（六）Web Meetup #2, 台灣高雄
• 9/29（四）Opendata.tw 座談 #2, 台灣台北
• 9/30（五）公路總局局本部座談，台灣台北
• 9/30（五）Web Meetup #3，台灣台中

歡迎舊雨新知捧場。

6minut.es 是一個網路節目。還有很多製作的細節要處理，這些細節大致可以分為：

1. 準備（企劃）：腳本、評論主題、網站候選、訪談人候選等。

2. 製作（錄製和剪輯）：背景、燈光、錄音、錄影、音源控制、視訊切換、網路視訊和錄製、背景噪音抑制、錄製軟體。影音後製是很大的項目，這一部分我沒經驗，所以會花點時間慢慢學習。

3. 網路（播放）等：專用網站製作、視訊托管服務、音檔托管服務、視訊轉檔、播送通路、社會媒體通路、專用信箱、網站監控服務等。

4. 其他：例如電系（電源）、網路通訊、儲存系統、本計畫所屬的公司註冊、網路捐款帳號和流程串接、裝置固定系統（如螢幕支架）、主播儀容化妝… 等。

目前除了錄影的部份還是單機之外，其他配置都走雙機以上（包含錄音、螢幕、電腦、燈光…）。錄影摸熟了我再來進行雙機的配置處理。

目的並不是要模仿台灣的「電子媒體」這個具有壓迫性的譬喻（metaphor）來製作新聞，我也對於「公民新聞」這事的興趣不高。只是看著電子媒體每天以低於國小畢業生邏輯訓練的水準在製播新聞主題，我就相當納悶為什麼沒有任何帶狀的網路節目，是可以列入我每天收視的選擇。

計畫開展的原則類似2002年在開始寫 blog 一樣，先求有，再求好。數位匯流的局勢註定了傳統的流程不一定能順利的轉換媒體空間，發揮影響力。而影音設備的數位化，也讓製播和遞送的成本遠低於傳統的電子媒體需求。

當然門檻還是有的，例如製播網路節目的初始成本支出可能就是 blog 媒體的五到八倍。比如說寫 blog 文章所需要的一台筆記型電腦不超過一千塊美金，那麼製作網路節目的成本就是五千塊美金起跳。一般網路用慣的朋友可能會認為影音的製播不需要投注這樣規模的初始成本，但事實上影音製播的專業，即使轉換為數位也是有一定的門檻，若是對製播的節目稍微有點要求，那麼實際的作法比想像中要麻煩很多。

順道一提，我認為目前台灣諸多以公益或學術型態存在所進行「網路新聞」計畫，都太偏向於文字導向。胡元輝在日前所提到的「優質新聞調查報導媒合網站」 http://goo.gl/zrebl 以調查報導網站 http://www.propublica.org 為學習的對象，可能也是偏向文字居多。我比較訝異的是區區的新台幣一百八十萬竟然會募不到？可是台灣還算富裕，想用網路來做電子媒體的人也不少，到底是什麼原因讓這些文字型的媒體人活的這麼苦？

這計畫叫做 6minut.es，算是工作之餘進行的半年度公益計畫。目前準備了閒錢約一萬美金來試試看，希望在九月開播後可以玩三個月。我會把所有的配置、流程和經驗都完全公開，希望能貫徹 open data 的理念。

當然最主要的原因是好玩，而且是具有公共性質的好玩。

我在 APNG Camp 的 keynote 資料，時間是香港時間2月22日10:00。我放一份過來。也會在台北的這場活動先分享部份心得。

The “Guanxi” of dot Gov: A preliminary survey on public data and government websites across APAC

Speaker: TH Schee, Fertta Communications, Taipei, Taiwan

Abstract: Much discussion has been centered around the digitization, release models, security and privacy of public data after Whitehouse’s Open Government Initiatives launched in 2009. Different approaches were adapted, whether be it top-down endeavor by governments, grass-root effort from NGOs or clandestine operation of online groups, the cornucopia of public data will be the web, or the website in a more tangible form. Demanding of public data in APAC region for effective communication and operation based on sound data source, both in private and public sectors, has never been more emphasized in this radical changing environment. By identifying formidable “Guanxi” of government websites and published data, we will first witness interesting homogeneity and heterogeneity of underlining relationships in policy, data, content, mechanism, and leaked intention of stakeholders. In a region that the man often binds data into official websites, the presentation could be a handy compendium to all future Gov 2.0 projects.

今天花十分鐘和某團隊討論前的手稿。主要針對營運人員在處理垂直型小型網路服務的具體作為，進行一次初步標準化作業項目的探討。敏感處我已經先移除。

電子報

• 安排電子報發送
• 編輯電子報內容
• 定期分析統計數據
• 不定期執行改善建議計畫

會員

• 經營站內會員，例如會員中心資料進行調閱、分析、整理
• 針對站內客服問題進行匯整、分析、處理、簽結等
• 定期製作會員成長狀況報表
• 不定期提出會員成長計畫
• 不定期蒐集本站具有影響力之會員名單，並建立資料庫，供後續連繫和運用

PV/Visits

• 購買和分析 ARO 數據
• 長期經營站外 SEO
• 定期製作 Google Analytics 統計報表並提出改善建議
• 執行根據統計數據所得出之改善計畫

社群媒體

• 建立社群媒體操作政策與流程
• 定期使用 Google Analytics 統計社群媒體之操作表現
• 透過社群媒體搜集使用者對於樂多品牌、頻道改善之建議

頻道經營

• 定期執行首頁內容更新
• 定期檢查首頁或相關頁面連結是否正確
• 不定期檢查服務功能性問題 (functional)，並回報入 Redmine

廣告

• 定期檢查廣告輪播狀況
• 定期檢查廣告入稿內容品質
• 定期檢查各廣告版面表現並產生報表供營運參考

團隊

• 使用 yammer.com 培養團隊交換新訊息之默契