2018年4月17日 星期二

成果發表:Storyliner——輕鬆替八卦事件製作互動式懶人包,以囧星人與聯合報願景工程的採訪爭議為例

《Storyliner》範例:囧星聯合爆

下個月要上班,所以最近在惡補 web frontend 的東西,看一堆 ajax 文件後覺得找專案來練習比較紮實,想說那就來順便改版《Guild Wars 2 Inventory》好了。結果規劃架構時,在社交網站上一直被某則網路八卦洗版,然後有天 臉友問我有沒有懶人包...

於是我整理癖就發作啦 ∫OoO∫

Storyliner》 開發期間共八天,企畫三天、程式五天。之所以可以這麼快速,主要是因為類似的 idea 之前已經跑過一次 ux 流程,所以規劃起來不太費力的緣故。

Storyliner 前身:Guild Wars 2 Storyline


二月春節期間,看了這部史詩級的 Guild Wars 2 野生電影:


這是 GW2 資深玩家的集體創作,為了幫助新手看懂劇情,大家集結手上的過季遊戲畫面,剪成超有質感的紀錄片。看完感動之餘也才終於瞭解許多 npc 的對話到底是怎麼回事,然後覺得貴圈真亂,亂到受不了,得好好整理一下才行(握拳)

不少人整理過 GW2 的劇情,除了這個紀錄片外,英文的可參考 這串 Reddit 裡的連結,中文的則有 kopp 貼給我的 這篇巴哈姆特上的文章。由於 GW2 角色繁多、劇情有多重主軸交錯,不管影片懶人包還是圖文懶人包,都難免會看到後面想不起來某個角色到底是誰,或者搞混不同主軸的先後順序。如果懶人包可以追溯特定角色的過去、比對不同主軸的事件順序、同時呈現大量事件節點、必要時才展開細節,應該可以節省許多在長內容中反覆翻找的時間。於是決定寫一個叫《Guild Wars 2 Storyline》的小網頁,把紀錄片裡的劇情做成一目了然的互動式時間軸。

說到互動式時間軸,最眾所周知的莫過於 okfn 的《TimeMapper》,不管是 hychen 的《台南百年文史古地圖》或沃草的《時間軸還原「M503航線」爭議》都是套用它。但 TimeMapper 嚴格來說只是以時間軸做為導覽的 slide show,並沒有我需要的分類跟過濾功能,因此無法直接套用到《Guild Wars 2 Storyline》。那《Guild Wars 2 Storyline》到底該做成什麼樣子呢?要回答這問題,得先搞清楚它所要呈現的內容的本質。

Storyline 的本質:萬事萬物皆是 LOG


身為資料整理強迫症患者,從以前看到人際關係太複雜的電影,都會忍不住想整理劇情,比方說《偷情 Closer》可以整理成這樣:

  1. B男B女 交往
  2. A男A女 結婚
  3. B男 說服 A女 跟自己交往
  4. A女 為了 B男 決定跟 A男 離婚
  5. B女 離開 B男 回去當脫衣舞孃
  6. A男 去光顧 B女 工作的店
  7. A男A女 打離婚砲
  8. A女 回到 A男 身邊
  9. B男 回頭跟 B女 交往
  10. B男B女 甩了

整個看下來,所謂的故事劇情其實就像一份隨時間變化的人物關係圖,也就是說,它的 schema 約等於人物關係圖的欄位加上時間戳記。這類 data model 早有成熟的實做,比方說 facebook 的 activity log,或者資訊系統的 system log。我要做的,則是根據這類資料的輪廓去設計符合懶人包用途的使用介面,就這樣畫了《Guild Wars 2 Storyline》的 user journey 跟 wireframe

話說寫上面這段的時候,一直聯想到 poga 在 coscup 2016 的演講《萬事萬物皆是 LOG》,所以就拿來當這一節的小標了(喂)

總之,由於還沒開始實做《Guild Wars 2 Storyline》就做了《Storyliner》,於是決定之後直接用《Storyliner》來做 GW2 劇情懶人包,《Guild Wars 2 Storyline》就不再繼續開發。

Storyliner 開發過程:React、Semantic UI


實做的部分蠻千篇一律的,一樣先 用 Notability 跟 apple pencil 手繪整理概念,再 用 google spreadsheet 整理資料,最後 用 React 寫程式 然後 deploy 到 github pages 上。

由於是純前端應用,沒有資料庫、也不提供登入,因此跟《Hackfoldr 2.0》《Guild Wars 2 Inventory》《Debater》一樣用最陽春的方式產生客製化的使用體驗,也就是把資料來源寫在網址裡面、同時用 local storage 儲存瀏覽過的網址、最後在介面上替這些歷史網址做一個選單。

中間大部分的時間,主要花在閱讀囧星人跟聯合報事件的資料,還有來來回回調整資料欄位跟網頁介面。其中最困難的部分,莫過於為了展示小編註解的重要性,拼命想梗寫圍觀筆記~後來有臉友說圍觀筆記比劇情本身還好看,真是不枉費我的一番苦心 XD

程式面最大的收穫大概就是人生中第一次用 fetch() 吧 XD 然後學會用 HTTP header 裡面的 Content-Type 來過濾來源資料,對 ajax 的實務面有稍微熟悉一些,算是有達到原本做練習的目的... (謎之音:練習 ajax 根本不用寫一整個產品好嗎 '_>`)

Storyliner 與 Debater:網路八卦姊妹花


同樣是為了整理八卦而開發,《Storyliner》可說是《Debater》的姊妹作,只是兩者處理的問題分屬公眾討論的不同階段。

Debater》是整理各方對某個案情的論述,《Storyliner》則是整理案情本身,臨床上,可以先用《Storyliner》釐清案發過程,讓評論者可以基於相同的事實基礎上發展論述,接著再用《Debater》整理論述的內容。

為了方便整理時間表,《Storyliner》的資料來源使用 csv 格式;為了方便整理長篇論述,《Debater》的資料來源使用 markdown 格式。在編輯工作上,做《Storyliner》的資料會比做《Debater》的資料輕鬆許多,因為做好前者只需要收集事實後忠實呈現,做好後者則需要通盤理解各方論述,才能設計出適合該議題的標籤樹。

Storyliner 潛在應用:政策發展、政商關係演進、歷史公案


做完《Storyliner》後在社交網站分享了範例頁面《囧星聯合爆》,原本沒在 follow 事件的臉友說覺得整理得很清楚,我想產品的目標算是有達到吧?也就是說,這樣的資料 schema 跟介面呈現方式,對 log 型態的內容來說,算是合適的。

那麼還有哪些內容是 log 形式、可能適合用《Storyliner》的方式整理跟呈現呢?目前想到的有政策發(ㄈㄢ)展(ㄆㄢˊ)的歷程,以及政商人物關係的演化歷程,或者歷史公案如二戰後盟軍成員 ROC 代管台澎領地結果演變成黨國殖民體制的歷程等。不過上述內容都比網路八卦複雜,真要整理的話,也許會需要擴充資料欄位就是了——

程式碼是 open source 的,歡迎有志之士接手往這些方向發展,或者等我下次失業的時候再來試著整理看看 lol

產品資訊


名稱:Storyliner
描述:The Interactive Gossip Viewer
授權:MIT

程式碼 / Source code
範例頁面 / Sample page
範例資料 / Sample data
發佈日誌 / Release note
開發手札(推特) / Dev log (Twitter)
開發手札(臉書) / Dev log (Facebook)

後記


時光飛逝,眼看著四月只剩下兩個禮拜,原本還想做另一個產品《CC License Chooser》、完成某 勞基法 x 中小企業講座心得文、還有編 婷宇論文的主題曲,不過看來上班前的這段時間能處理好接案的事情跟惡補技術知識應該就要偷笑了,其他支線劇情就先放下吧 www

希望這次全職可以至少撐過三個月啊... (抖)