第二次除黴會議紀錄(已結束)

編輯歷史

時間 作者 版本
2017-07-03 05:54 – 05:54 (unknown) r0 – r1
顯示 diff
+ 第二次除黴會議紀錄(已結束)
+ 此文件路徑:全民除黴計畫hackfoldr / 會議紀錄 / 這裡
+
+ 會議資訊
+ 會議名稱:第二次除黴會議
+ 時間:2014/06/28 13:30~17:30
+ 地點:伯朗咖啡科大店,大包廂一半。 簡評:環保頗吵,人多結帳慢,不考慮再去
+ 與會者:大嘴、呂沛宸、佑丞、Wilber、S5Y、Michael ,共6位 (3位新成員)
+
+
+ *<一>會議紀錄摘要 (匯整中)
+ *會前小談
+ Michael : 加入新聞小幫手的動機(18個月之前的遠因)是因為日本臺灣留學生殺人事件中媒體過於誇張的報導行徑。目前專注於新聞小幫手專案的新聞分析及組織化、目標國際化的可能性上。
+
+ *超濃縮自我介紹 (僅列一下新朋友)
+ Michael:新聞小幫手資料整理與新聞分析者
+ 大嘴:主要新聞來源是PTT,主流媒體的新聞管道已經看都不想看了
+ S5Y:因為ETC的事件對媒體問題感受也滿深的
+
+ *舊進度追蹤 → 檢討
+ *建立聯絡名單資料庫 → 還沒填的快填吧
+ *開始建立媒體識讀資料庫 → 佑丞再去找低年級學妹借,用途:app會有識讀文章、網站會有完整資料
+ *初期需主動找新聞評論,因此開始蒐集各大報頭板新聞的網路版內容(以 Word 存在 Google Drive 資料夾內,每日一個新資料夾) 可搭配其他計畫的爬新聞技術自動化,先取消人工紀錄了,抱歉><
+ *技術後端開始嘗試建立新聞資料庫
+ *建立新聞歸納分類標準 (計畫目標訂定以網路媒體為主,但初期會先挑選平面媒體也有的新聞,增加除黴傳播效益)
+ *不理會原有媒體的分類,採用複數標籤形式,半自動半手動分類
+ *繼續於專頁及八卦板經營及招募人才,需要人力請自行到徵才pad填上
+ *App UI 設計討論
+ *表現區塊已大致確定,需再優化,Wilber已做出基本框架
+
+
+ *<二>新進度討論&小結 (匯整中)
+ *沒有參與會議的朋友有意見仍可提出
+
+ 2.1.評價系統
+ * 新聞發黴級別要再思考一下怎麼產生,以及各級代表意義
+ *優先處理事項,釐清目前確定的計算機制與簡易流程圖,寫成文件方便其他人了解「評分的脈絡」。(接觸媒體界的人就需要先拿出這個東西來說)
+ *找評論員的部分,先建立出一套好用的創新評價系統,能在拉人時直接DEMO給對方看,或許比較好打破既有認為要找專家寫評論就是要像投書一樣很長一篇
+
+ 2.2.市場調查
+ *需界定問題範圍(紙本、網路媒體) → 目標對象
+ *考慮做出可信樣本數的人力成本
+ *如果已有相關調查,說不定就可省下來,要再麻煩佑丞或郁芳有空查一下,目前我查過的資料只有 2013臺灣民眾媒體評鑑大調查與十年回顧 (不過佑丞好像不太相信這個XD)
+ *備註:趕8月份設計出問卷、收集到問卷,可能性很低,Michael建議先用簡單的評分結構代替,之後再改成正式的。
+ *推薦用IPA分析法,簡單好用
+ *重要-表現程度分析法~Importance- Performance Analysis,IPA(上)
+ *重要-表現程度分析法~Importance- Performance Analysis,IPA(下)
+
+ 2.3.App部份
+ UI設計修正
+ *媒體業者的名字要放大
+ *使用者蒐尋議題時,資料的顯示方式
+ *數據使用的代稱可以誇大一點,如打臉指數之類的,不要只放數字
+ *新聞發黴級別要再思考一下怎麼產生,以及分級意義
+
+ APP名字:仍以「除黴新聞」or「除媒新聞」為產品名,較中性也能表達,不建議開放投票 by 佑丞
+ *建議更完整討論再決定,品牌名稱及字面形象直接影響使用意願和第一印象,佑丞說的沒有錯,中性是使用者對媒體的潛在希望,也是反映自身的行為形象。不過如果能在不影響中性的情況下提高刺激度也是可以考慮的。
+ *在初期吸引年輕族群能使用的策略上,可以和效率、速食文化、等元素搭上邊,可產生如「快評新聞」之類的名字。
+
+ 2.4.後台與程式部份
+ *Michael有租虛擬主機願意借我們用(需先評估可不可行)
+ *資料庫系統使用 Mongo http://zh.wikipedia.org/wiki/MongoDB
+ *有後台人力資料管理需求所以需要一個介面
+ *大嘴推薦 Meteor ,參考 Meteor 初體驗
+ *主要是針對DDP的部份,建置起來後可以提供給所有網站前端甚至是手機APP使用,而不用花時間寫一堆資料API。
+ *http://meteorhacks.com/introduction-to-ddp.html
+ *不然就是用json (?)
+
+ 2.5.接收訊息者的觀點(也就是APP使用著)
+ *只看到排在最上面是最爛的新聞,沒有吸引力,還不如有「看好戲」的機制讓人有動力「看別人犯錯細節」的「見獵心喜」,促進使用者人數。
+ *新聞訊息要有「組織化」的功能(像組織圖),讓接收者知道各項新聞訊息是怎樣子的一個脈絡,屬於正面意義。(完全是編輯台人工處裡)
+ *是指能在新聞內文標明出像5W(何人、何事、何地、為何、...) 這樣的脈絡嗎?
+ *差不多是這樣子,開會時我舉例是編輯小組事後整理主題的架構,再來分類,所以變成半機器半人工程序。
+
+ 2.6.雜項
+ *因為兩位工程師加入,Wilber就專心做資料庫部分,app轉由S5Y幫忙,大嘴待Wilber那邊OK後幫忙寫後台管理功能。
+ *先手機版,再Web版。
+ *建議先畫出一些重要的流程圖或UML,方便長期管理,也方便非程式背景的新聞界人士理解系統機制。
+
+
+ *<三>進度時程訂定 (包含規畫、技術、推廣、活動等行程,沒寫到就自填)
+ *第一個框框是確認自己的任務,第二個是等完成後再勾。
+
+ *06/30END NewsDiff的創作者詢問(Michael主動給)
+ *完成,說明狀況:已經給 Wilber NewsDiff 開發者資訊
+ *正在  Wilber 評估 Michael 現在正在用的虛擬主機可不可以使用
+ *完成,說明狀況:感謝麥克的幫助, 不過依我現在的系統需求, 是需要vps, 一台完全給我操作的虛擬主機, 這部分, 我決定先在aws辦一個app4am虛擬主機, 一年免費, 不過有流量限制
+ *07/06 佑丞詢問市調問題並回覆,可找郁芳協助(如進行到問卷題目設計時CC給Michael一份)
+ *完成,說明狀況:
+ *07/06 整理好新版的評價機制流程
+ *完成,說明狀況:
+ *07/08 此日前,聯絡佳欣討論有關記者朋友的合作招募方式
+ *完成,說明狀況:
+ *07/10 UI設計修正 (最好在資料庫建好前完成) (會找阡瑜協助)
+ *完成,說明狀況:
+ *07/12 此日前,和梅君約訪,目前日期未定
+ *完成,說明狀況:
+ *07/12 資料庫建立 (約需兩週) - Wilber Chao
+ *完成,說明狀況:
+ *07/13 開始,大嘴在Wilber建好資料庫後開始做後台管理介面 (先求可用就行)
+ *完成,說明狀況:
+
+ 持續和其他計畫交流並考慮合作空間
+ 下次開會時間
+ *暫定8/02 ,籌備文件於 http://hackfoldr.org/app4am/aoKbmAeNTUO