基於參與者模式建構具擴充性的電腦輔助協同創作工具 - 政大學術集成

全文

(1)國立政治大學數位內容碩士學位學程 Master's Program in Digital Content and Technologies National Chengchi University. 碩士論文 Master's Thesis. 基於參與者模式建構具擴充性的電腦輔助協同創作政治. 立. 工具. 大. ‧ 國. 學. Construction of a Scalable Computer Supported Cooperative Art Tool. Nat. er. io. sit. y. ‧. Based on Actor Model. al. n. v i n 指導教授：廖峻鋒助理教授 Ch engchi U 陶亞倫教授. 研究生：黃晨翔. 中華民國一百零七年六月 June 2018. DOI:10.6814/THE.NCCU.DCT.004.2018.B02.

(2) 摘要共同圖形編輯系統是一種群組軟體，同時也是電腦輔助協同工作系統的一類，這類系統常使用於多人會議討論的應用情境。近年來由於物聯網及數位互動藝術的興起，出現了許多基於類似技術的多人互動作品。然而，共同圖形編輯系統都無法避免一個固有難題，也就是多人同時編修同一份文件時的同步控制問題。以共同創作數位互動藝術的情境在例，在創作期間，複數參與者會同時對同一個區段進行修改，可能造成錯誤的結果。在傳統解決方案中，使用鎖、信號等方式予以控制，然隨著專案的規模增. 政治大. 加，程式設計的邏輯複雜度也隨之上升，使得開發門檻高出許多。本研究提出將參與. 立. 者模式應用於共同圖形編輯系統，開發一輔助函式庫工具，除了解決同步控制問題，. ‧ 國. 學. 藉由將後端服務以固定規格的 Actor 包裝，根據服務內容不同將其分為兩大類，對功. ‧. 能進行歸納，使創作者使用工具時更容易進行管理。研究的評估針對數名受測者做質. sit. y. Nat. 性分析，供函式庫予具一定程式開發經驗的受測者進行實際操作與訪談，以了解此研. n. al. er. io. 究的實質成效。研究成果有效降低了共同圖形編輯系統的開發門檻，提供給數位互動. i n U. v. 藝術創作者更為直覺並具有擴充彈性的電腦輔助協同創作工具。. Ch. engchi. 關鍵字：電腦輔助協同創作、共同圖形編輯系統，參與者模式. ii. DOI:10.6814/THE.NCCU.DCT.004.2018.B02.

(3) Abstract Collaborative Graphics Editing Systems (CGES) is a kind of groupware and is also a category of Computer Supported Cooperative Work (CSCW) systems. CGES has been widely used to realize multi-person on-line conferences. Recently, the emergence of IoT and digital interactive art has brought about a lot of applications of CGES to the creation of multi-user collaborative and interactive artworks. However, CGES usually faces concurrency control problems, which mean, there can be errors when multiple users modify data located at the same place. Classical approaches to deal with this issue are locks and semaphores.. 政治大. Nevertheless, the difficulty of development and complexity of the programs increase when. 立. the size of code expands. In this research, we combine the concept of Actor Model with. ‧ 國. 學. CGES, provide a ready-made library to support the development of interactive arts with CGES. By wrapping the back-end service with actors, and dividing them into two categories. ‧. according to the contents, not only solving concurrency control problem but facilitating the. y. Nat. sit. management of the toolkit. Finally, we use the qualitative experiment to assess the. n. al. er. io. achievement of the research. According to the evaluation results, we conclude that this work. i n U. v. can lower the threshold of development of CGES, and provide a more scalable, flexible. Ch. computer supported cooperative art tool.. engchi. Keywords: Computer Supported Cooperative Work, Collaborative Graphics Editing Systems, Actor Model. iii. DOI:10.6814/THE.NCCU.DCT.004.2018.B02.

(4) 目錄第一章緒論 .............................................................................................................................. 1 1.1 研究背景 ....................................................................................................................................... 1 1.2 研究動機 ....................................................................................................................................... 3 1.3 研究目標 ....................................................................................................................................... 5. 第二章文獻探討 ...................................................................................................................... 8 2.1 參與者模式 ................................................................................................................................... 8 2.2 共同圖形編輯系統 ..................................................................................................................... 10 2.2.1 鎖：Ensemble....................................................................................................................... 10 2.2.2 序列化：LICRA .................................................................................................................. 12. 政治大 2.3 數位協同創作與共同編輯系統 ................................................................................................. 17 立 2.2.3 多版本控制：Grace ............................................................................................................. 14 2.2.4 混合式方案 .......................................................................................................................... 15. ‧ 國. 學. 第三章研究方法 .................................................................................................................... 20 3.1 延續傳遞風格與非同步程式設計 ............................................................................................. 20. ‧. 3.2 以參與者模式包裝後端服務 ..................................................................................................... 21 3.3 校內展覽 ..................................................................................................................................... 29. y. Nat. sit. 第四章實驗與評估 ................................................................................................................ 31. al. er. io. 4.1 評估流程及方法 ......................................................................................................................... 31. n. 4.2 評估方法 ..................................................................................................................................... 34. Ch. i n U. v. 4.3 評估結果分析 ............................................................................................................................. 35. engchi. 第五章結論與未來工作 ........................................................................................................ 39 5.1 研究貢獻 ..................................................................................................................................... 39 5.2 未來工作 ..................................................................................................................................... 40. 參考文獻 ................................................................................................................................. 41. iv. DOI:10.6814/THE.NCCU.DCT.004.2018.B02.

(5) 圖目錄圖 1.1 ＂Spell on the City＂展出現場 ................................................................................................... 3 圖 2.1 Actor 與信箱關聯示意圖 ............................................................................................................ 9 圖 2.2 Ensemble 工作區域 .................................................................................................................... 11 圖 2.3 GRACE 其中一個使用者視窗 .................................................................................................. 15 圖 2.4 HIVE 創作介面 .......................................................................................................................... 17 圖 2.5 Abyss 互動成像 ......................................................................................................................... 18 圖 2.6 CrowdPainting 計畫實施頁面 ................................................................................................... 19 圖 3.1 難以閱讀的多層函式架構被匿稱為回調地獄 ........................................................................ 21 圖 3.2 後端資料處理架構圖 ................................................................................................................ 22 圖 3.3 Actor Model 實作架構示意圖 ................................................................................................... 24 圖 3.4 以參與者模式包裝過後的編輯函式 ....................................................................................... 25 圖 3.5 使用者頁面範例 ........................................................................................................................ 26 圖 3.6 系統運行循序圖 ........................................................................................................................ 26 圖 3.7 系統運行流程 ............................................................................................................................ 29 圖 3.8 於校內展展出共同創作工具應用範例 .................................................................................... 30. 立. 政治大. ‧ 國. 學. ‧. 圖 4.1 實驗過程側拍 ............................................................................................................................ 32 圖 4.2 受測者數量與找出易用性問題之比例 .................................................................................... 34 圖 4.3 受測者實驗時間 ........................................................................................................................ 35 圖 4.4 實驗中參與者模式的啟動步驟 ................................................................................................ 36. n. er. io. sit. y. Nat. al. Ch. engchi. v. i n U. v. DOI:10.6814/THE.NCCU.DCT.004.2018.B02.

(6) 表目錄表 1.1 Johansen CSCW Matrix ............................................................................................................... 1 表 4.1 流程之評估項目與預估時間 .................................................................................................... 33 表 4.2 受測者基本資料 ........................................................................................................................ 35. 立. 政治大. ‧. ‧ 國. 學. n. er. io. sit. y. Nat. al. Ch. engchi. vi. i n U. v. DOI:10.6814/THE.NCCU.DCT.004.2018.B02.

(7) 第一章、緒論. 1.1 研究背景電腦輔助的協同工作（Computer Supported Cooperative Work，CSCW）一詞，最早於 1984 年由 Irene Greif 和 Paul Cashman 提出 [1]。其中群組軟體（Groupware），即指多位使用者共同使用的應用程式：例如早期便出現的電子郵件、BBS 論壇，至現今因網路通訊技術發展而隨之出現的即時通訊、語音通. 政治大. 話等等，皆屬於群組軟體的一種型式。. 立. 根據 Johansen 於 1988 年提出的 CSCW 分類矩陣 [2]，這些應用程式及產品. ‧ 國. 學. 大多屬於同時異地、異時異地兩類。而近年來隨著物聯網的崛起及智慧行動裝. ‧. 置的普及，共同編輯系統（ Collaborative editing system）亦開始出現。共同編輯. Nat. sit. y. 系統是 CSCW 領域中一個分支，讓多個使用者能夠一起編輯一份文件，或者共. n. al. er. io. 同繪製一份圖畫，又分成即時與非即時兩大類。雖然共同編輯系統並不拘於時. Ch. i n U. v. 地限制，此篇研究中將針對現場共同編輯進行討論，此類型系統位於分類矩陣. engchi. 中的同時同地或異時同地，例如：Tivolli 共同白板 [3]、電子會議室等等。. 近年來隨著數位科技的興盛，亦拓寬了新媒體藝術（New media art）的視野。新媒體藝術泛指利用現代科技與新媒體呈現的作品形式，因此亦有人認為「數位藝術」一詞與其內容更加切合。此概念囊括了許多不同的領域，互動藝術亦屬其中分支之一。. 1. DOI:10.6814/THE.NCCU.DCT.004.2018.B02.

(8) 表 1.1 Johansen CSCW Matrix. 同時. 同地. 異地. 面對面互動. 遠端互動. ● 數位會議室. ● 遠端桌面共享. ● 公共投影牆. ● 線上會議. ● 單螢幕群組軟體（Single Display Groupware）異時. 執行中任務. 溝通與協調. ● 小組討論室. 立. ● 專案管理. 政治 ●大電子郵件 ● 版本控管. ‧ 國. ● 群組行事曆. 學. ● 輪值群組軟體（ Shift Work Groupware）. ‧ sit. y. Nat. 與一般傳統的藝術作品只由作品本身構成不同，互動藝術強調為三種元素. n. al. er. io. 組成：觀眾、裝置、內容。「視聽者」在作品「完成的現場」被轉換成「參與. i n U. v. 者」，而藝術家將作品的完成交給參與者（但此權力仍有一定的規則及限制，並. Ch. engchi. 非全權交出）[5]；這類互動作品比起傳統藝術更加強調觀眾的參與。例如第七屆韓國首爾國際媒體藝術雙年展，由 Zune Lee 及 Kenny Kyungmi Kim 兩位藝術家創作的作品＂Spell on the City＂[6]：參與者經由社群軟體推特發表推文，經過自然語言處理對推文進行情感分析，得到該推文的情緒種類後與相對應的繪文字配對，將繪文字傳至會場周遭外圍的投影牆上，繪文字會隨著新的推文增加而進行更新；若以前述矩陣進行分類，此作品即是典型「同時同地」中的公共投影牆，裝置在會場設置完成時並不是作品的最終形態，等到觀眾（參與者）. 2. DOI:10.6814/THE.NCCU.DCT.004.2018.B02.

(9) 與裝置進行互動，將各個使用者的心情繪文字打到投影牆上後才能算是「作品完成的現場」。. 立. 政治大. ‧. ‧ 國. 1.2 研究動機. 學. 圖 1.1 ＂Spell on the City＂展出現場 [6]. 與傳統藝術相較單純的媒材相比，互動藝術牽涉到許多跨領域的知識，然. y. Nat. io. sit. 而並非所有創作者都具有跨領域的技術背景，對於並非多人團隊的獨立創作者. er. 而言，創作門檻相對高出許多。若能使用現成的工具進行開發及創作，能節省. al. n. v i n Ch 許多時間與精力。隨著近年的智慧手機普及，應用智慧行動裝置進行多對一螢 engchi U 幕（或裝置）的互動方式也越來越多，例如上述提到的 ”Spell on the City“ 即為其中應用的一種。若在實作這類型的作品時能結合既有的共同編輯系統，將能省去從頭開始撰寫程式碼的步驟，達到事半功倍的效果。. 以在互動作品較常見的共同圖形即時編輯系統為例，參與者通常經由各自的裝置，而非在同一台裝置上對圖形畫布進行作業。由於即時性的緣故，會衍生出集中訪問的狀況[8]，意即在作業期間，複數參與者會對同一個變數進行接. 3. DOI:10.6814/THE.NCCU.DCT.004.2018.B02.

(10) 收與修改，造成結果的錯誤。包括遺失更新問題（Lost update problem），即不同使用者交錯存取同一筆資料；未委任相依（Dirty Reads），指使用者已經送出更新指令，但資料尚未收到更新指令，而第二位使用者存取到舊資料造成的錯誤等，統稱為同步控制問題（Concurrency control problem）。為了應對此狀況，目前常見的解決方案大致分成以下三種類型[7]： 1. 鎖（Lock）：只有使用者鎖定並編輯不同的物件時才能同時編輯。此方法仍有缺點，例如由於請求及獲得鎖定狀態皆需要消耗資源，因此可能會. 政治大. 出現回應具延遲性等等問題。E.g., Ensemble[9]。. 立. 2. 序列（Serialiasation）：確保所做改變會依循序列的順序進行，當操作之. ‧ 國. 學. 間遇到衝突時則只保留最後一個操作的行為。E.g., Group Design[10]。. ‧. 3. 多版本（Multiversioning）：多版本的共同圖形編輯系統實現所有的行為，. Nat. sit. y. 並試圖呈現所有的改變，然而這類型的做法在圖形使用者介面的呈現上. n. al. er. io. 會有一些困難，例如該如何選擇顯示的版本等等狀況。E.g., GRACE[11]、 TIVOLI[3]。. Ch. engchi. i n U. v. 雖然共同圖形編輯系統已有許多版本與種類，但據所知範圍內，截至目前為止仍未有專為互動藝術所設計的工具框架或者函式庫供創作者使用，且上述解決方案的傳統實作過程往往會牽涉到複雜的鎖或執行緒等等的使用，使用上並不那麼直覺，加上隨著專案的規模增加，其設計的邏輯複雜度也會隨之上升，使得學習門檻高出不少。. 4. DOI:10.6814/THE.NCCU.DCT.004.2018.B02.

(11) 1.3 研究目標本研究使用 JavaScript 語言搭配參與者模式（Actor model），開發輔助進行多人互動功能的框架。參與者模式是一種平行運算的模型，於 1973 年由 Carl Hewitt, Peter Bishop, Richard Steiger[12] 三人提出。相對於物件導向程式設計（Object-oriented programming）中＂Everything is an Object＂的概念，參與者模式提倡＂Everything is an Actor＂。比起傳統同步問題選擇用鎖或多執行緒的方式處理共享資源衝突，在參與者模式中選擇將狀. 政治大. 態及行為被封裝在各個輕量化的元件，也就是 Actor 之中。每個 Actor 有三個必. 立. 要條件，分別是. ‧ 國. 學. ‧運算（Pprocessing）：每個 Actor 個別能進行運算。. sit. Nat. ‧溝通（Communication）要能跟其他 Actor 溝通。. y. ‧. ‧儲存（Storage）：必須要能儲存資料。. n. al. er. io. 不僅從根本解決了資料共享的衝突困擾、迴避了競爭條件（Race condition）. i n U. v. 等等問題，在使用上也比傳統資料鎖更加直覺易懂，對於開發者而言理解門檻. Ch. 降低許多。. engchi. 此研究預期達成的目標主要有下列三點： 1. 協助使用者加速開發流程一般的多人互動作品開發流程中，除了應用功能之外，尚需要處理底層通訊的部分，藉由進行功能的封裝與模組化，令使用者在開發相關功能時更為. 5. DOI:10.6814/THE.NCCU.DCT.004.2018.B02.

(12) 直覺化，不必再耗費太多心力於底層邏輯的撰寫與設計，而能藉由呼叫既有函式進行製作。 2. 便於維護及易理解的程式碼如前述所提到，在開發即時的共同圖形編輯系統時，常因共享變數而出現同步問題（Concurrency problem），而參與者模式將狀態與行為皆封裝在各個 Actor 中，除了簡化了同步問題處理的複雜度之外，分明的狀態隸屬相較於傳統方案也更加直覺並容易理解，減低開發過程及後續維護的負擔。 3. 彈性的應用發展. 立. 政治大. 函式庫提供基礎的功能，然而既有功能並不一定能滿足所有使用者的需. ‧ 國. 學. 求，此時彈性的架構設計便顯得重要。由於參與者模式本身的特性，包括原則. ‧. 上並不共用狀態，具有優秀的可擴展性（Scability）等等，開發者需要擴展其他. Nat. n. al. er. io. sit. y. 功能時相對來得容易許多。. i n U. v. 函式庫具備兩種層級的 Actor，上層稱為 Server Actor，下層是 User Actor；. Ch. engchi. Server Actor 建立之後，可根據指令創建隸屬自己的 User Actor，User Actor 可進行一些運算或行為之後，將結果傳送至 Server Actor 或其他 User Actor 的 Mailbox，Server / User Actor 接收之後對訊息進行處理，並根據結果指定下一封訊息的處理方式。以一個共同白板創作系統為例：一個空間內前方有張大白板（Server Actor），數名參與者各持數位裝置（User Actor）例如智慧型手機，在自己的裝置上進行圖片繪製（User Actor 內進行的運算處理），繪製完成後可將. 6. DOI:10.6814/THE.NCCU.DCT.004.2018.B02.

(13) 圖片推送至前方白板上，或是將其推送給其他參與者再進行修改，最終所有圖案皆被推送至前方白板，完成一幅共同創作。. 本研究的評估部份將讓數名使用者基於本研究的實作原型進行開發，並對過程與結果進質性分析，換句話說，本研究將藉由提供函式庫給予具一定程式開發經驗的使用者進行簡易實作與訪談，了解此研究是否有達到上述預期目標、理想與實際上的差異及優劣之處，進一步得出結論與未來發展。. 立. 政治大. ‧. ‧ 國. 學. n. er. io. sit. y. Nat. al. Ch. engchi. 7. i n U. v. DOI:10.6814/THE.NCCU.DCT.004.2018.B02.

(14) 第二章、文獻探討. 本章節將針對參與者模式做進一步的介紹，與共同圖形編輯系統傳統處理同步控制問題的方式進行分析與比較，並對數個案例進行適用性質探討。. 2.1 參與者模式[20] 上一章節尾末有對參與者模式進行簡易的說明，在此節將做進一步的介紹。 . 政治大參與者模式是一種可進行平行運算的基礎模型，常被應用於同步運算框架立. ‧ 國. 學. 或者系統的實作上，例如程式語言 Erlang、Scala，開發框架工具 Akka。與同步問題的傳統處理方式不同，參與者模式將狀態及行為封裝在各個 Actor 中。. ‧. io. sit. Nat. 資料與狀態、有能力與其他 Actor 溝通。. y. 每個 Actor 有三個必要條件：每個 Actor 都能各自進行運算的工作、能各自儲存. er. 由於在參與者模式中強調各個 Actor 的不相依性，Actor 不可直接分享自己. al. n. v i n Ch 的狀態，例如傳遞包含自己內部狀態的參考或者指針等等行為都是被禁止的。 engchi U 因此有效地防止了變數或狀態的共享時容易產生的同步控制問題。在物件導向程式設計中，有呼叫物件方法的作法，而參與者模式中也有類似的概念：每個 Actor 皆配備自己的信箱（Mailbox），藉由訊息（Message）傳遞至其他 Actor （或自己本身）的信箱地址，以調用包裝於 Actor 中的方法；當收到訊息時，訊息不會立即被處理，而是待該 Actor 使用中的資源釋出後，才一封封執行存放於信箱中的訊息。. 8. DOI:10.6814/THE.NCCU.DCT.004.2018.B02.

(15) 圖 2.1 Actor 與信箱關聯示意圖. 政治大. 當 Actor 收到訊息時，可採取以下三種行動：. 立. 學. ‧ 國. ‧創造更多 Actor. ‧向其他已知的 Actor 發送訊息. sit. y. Nat. . ‧. ‧指定如何處理下一條訊息. n. al. er. io. 首先，Actor 有創造其他 Actor 的能力，而在創建 Actor 時這些 Actor 可得. i n U. v. 知彼此的信箱位址；換言之，若分屬於不同群的 Actor，則無法直接傳送訊息至. Ch. engchi. 對方信箱，這種狀況則需要另外分配一個擔任接收者的 Actor 處理訊息。第二點，向其他已知的 Actor 發送訊息，更精確而言是對其他已知的信箱位址發送訊息。字面上並不難理解，此處需要強調的是發送者只專注於對位址發送訊息，並不負責訊息中途是否丟失；若需要額外的安全機制開發者可另外安排，例如令接收者回傳是否收到的訊息，但確保訊息安全抵達這件事情原則上並不在發送者的業務範圍內。. 9. DOI:10.6814/THE.NCCU.DCT.004.2018.B02.

(16) 第三點指定下一條抵達的訊息處理方式，這代表了 Actor 具有不確定性（Indeterminacy）[13]，意即依據收到的訊息不同，可隨時更動 Actor 的行為，這為整體參與者模式帶來了可調整性，在應對各種情境有更彈性的選擇——例如錯誤容忍度的提升：參與者模式並非不允許整個系統裡出現一點錯誤，在某個 Actor 出現問題時，可通知創建它／它創建的 Actor 以進行問題的修復或其他處理。. 政治大. 另外，參與者模式的訊息傳遞採用非同步（ asynchronously ）的方式傳送，. 立. 意即發送的時間點先後並不代表該訊息實際被讀取執行的時間順序，因此可依. ‧ 國. 學. 據時間或條件需求安排訊息的優先執行緒。. ‧ sit. y. Nat. 2.2 共同圖形編輯系統. n. al. er. io. 在前一章介紹過目前傳統上實作共同圖形編輯系統可大致分成三種類型：. i n U. v. 鎖（Lock）、序列化（Serialiasation）、多版本（Multiversioning），以下將分別對. Ch. engchi. 以這三種方式實作的系統案例進行介紹與優缺點討論。. 2.2.1 鎖：Ensemble [9] Ensemble 是一個使用鎖為基礎運作原則的共同圖形編輯器，由 NewmanWolfe, Webb 及 Montes 於 1992 年提出。藉由限制不同用戶存取畫布的權限達到迴避同步控制問題的結果。首先編輯器分配給每個使用者固定範圍的編輯區域，以游標移動可改變該區域的位置，各個用戶可對畫布進行比例放大縮小，而當. 10. DOI:10.6814/THE.NCCU.DCT.004.2018.B02.

(17) 編輯區域重疊時，系統會進行序列化的權限分配——換言之，同一塊編輯區域同時間只允許一個使用者進行輸入。. 此共同編輯系統提供使用者兩個視窗，其一個是用戶私人工作區域，另一個視窗是最終成像的顯示區域。一般圖形編輯的方式可分成像素導向（Pixeloriented）或者物件導向（Object-oriented），前者將繪製的圖形像素與畫布直接結合，根據畫布的區域位置進行編輯，依照使用者們繪製的先後順序進行圖像. 政治大. 的更動；而後者將每個繪製的圖形以物件的形式進行編輯，意即圖形之間是以. 立. 獨立的方式存在，可針對不同圖形物件進行編輯，當使用者們編輯同一個物件. ‧ 國. 學. 時才會發生存取的衝突，需要另行處理這部分的問題——Ensemble 在此選擇使. n. al. er. io. sit. y. Nat. 的部分。. ‧. 用物件導向式的編輯方式，搭配一個負責判斷所有編輯事件的 GM 以處理衝突. Ch. engchi. i n U. v. 圖 2.2 Ensemble 工作區域. 11. DOI:10.6814/THE.NCCU.DCT.004.2018.B02.

(18) 在使用者指定物件欲進行編輯時，GM 將會依照提交請求的先後順序決定哪些使用者對此物件擁有存取權，對其他無權進行更動的使用者下鎖定（Lock）的指令，直到當前的使用者釋出手上的權限（結束編輯）為止。此種方法的缺點在於，當操作指令產生時，必須花費等待發送請求至 GM 的往返時間，以及等待執行授權的時間，依據連線環境不同，訊息的往返速度可能會造成系統的延遲，Ensemble 雖然允許無衝突的操作立即執行而無需等待. 政治大. GM 批准，當操作出現需要優先序判定的狀況時此問題仍舊無法完全解決。. 學. ‧ 國. 立 2.2.2 序列化：LICRA [15]. ‧. 與上述 Ensemble 不同， LICRA （ Lock-free Interactive Concurrency. sit. y. Nat. Resolution）不使用鎖、全域共享變數或者時脈，而是制定一個同步控制協議，. n. al. er. io. 利用生成操作及語義的操作轉換機制之間的相依性來實現其目標——讓複數使. i n U. v. 用者可同時與一塊工作區域進行訪問與互動，並改善共同編輯系統的響應時間，. Ch. engchi. 以達到在群組軟體立即反映共同編輯畫面的結果。. 此篇研究主張群組共同編輯系統應具備以下條件：・互動性（Interactivity）：使用者送出訊息的時間與系統回應時間不能間隔太長，以得到自然的互動體驗。・動態成員（Dynamic membership）：系統運行期間，所有使用者應該能自由進入及離開，而不會造成錯誤或衝突。. 12. DOI:10.6814/THE.NCCU.DCT.004.2018.B02.

(19) ・資料可用性（Data availability）：當出現需求時，使用者擁有能自由對資料進行訪問動作的權限。・資料一致性（Data consistency）：所有使用者所見共同編輯區域應為相同。・因果關聯（Causality）：當使用者要編輯另一位使用者在編輯中的物件時，應待當前編輯完成才能做修改。. 政治大. LICRA 在使用者對工作區域進行存取或更動時，將其作為一個事件對每個. 立. 使用者進行廣播，這個事件訊息裡除了編輯的操作內容外，還包含了時間戳記，. ‧ 國. 學. 所有的更動都將依照時間戳記依序執行，只有當序列中不存在其他排隊等待執. ‧. 行的事件時，才允許不用查看時間戳記直接無序執行事件。. sit. y. Nat. n. al. er. io. 除此之外，LICRA 尚針對操作的數量進行簡化的討論，以增進整體系統效. i n U. v. 能：在共同編輯的情境中，有些同樣屬性的操作處於同一等候序列時，可由時. Ch. engchi. 間戳記最晚的事件直接覆蓋掉其餘事件，例如填色，若序列中存在「填入紅色」的指令事件，後來另一位使用者又新增了「填入綠色」的指令，此時可直接以「填入綠色的指令」覆蓋其他所有的填色事件；但亦有部份同屬性的操作是不可覆蓋的，例如「將圖形放大兩倍」、「將圖形縮小 0.25 倍」，這類的事件雖然也屬於同屬性的指令，但其間屬於相對關係，便不能以時間戳記最晚的事件覆蓋其他。這些操作的簡化倚賴於開發者的人為判定，指令的行為須為獨立而不具有相依性的狀況，才能適用此方法。. 13. DOI:10.6814/THE.NCCU.DCT.004.2018.B02.

(20) 而 LICRA 最大的問題是沒辦法做到動態成員該項要求，由於系統運行期間需要維持同樣數量的成員數量，因此介於編輯期間使用者不能任意加入或離開系統。. 2.2.3 多版本控制：GRACE[11] GRACE 是物件導向式圖片共同編輯系統，採用保存多版本的方式，以進一步迴避同步控制問題：首先在本地端創建各自的編輯版本，當複數操作指令對. 政治大. 最終成像產生衝突時，可將應用這些操作命令後的成像皆保存下來供使用者進. 立. 行決策。除此之外，一如 LICRA 提出了簡化操作的方式，GRACE 也針對這點. ‧ 國. 學. 進行了更詳細的分類與討論。. ‧. 在此類多版本控制的物件導向圖形編輯系統中，為了識別物件，需要有以. sit. y. Nat. 下特性：. n. al. er. io. ・唯一性（uniqueness）：一個版本中所儲存的物件必須具有唯一辨識屬. Ch. i n U. v. 性。以確保在編輯時物件之間不會互相干擾影響，為各自獨立而不相依。. engchi. ‧可追溯性（traceability）：一個物件編輯後產生的多版本必須可用屬性追踪，此舉是為了在編輯物件後仍可根據標籤屬性查看所有編輯後的結果。・一致性（consistency）：不同備份版本的同一物件的須具有相同的屬性標籤，使得之後的操作指令亦可應用至其他版本上的同一物件。. 14. DOI:10.6814/THE.NCCU.DCT.004.2018.B02.

(21) 圖 2.3 GRACE 其中一個使用者視窗. 立. 政治大. 與前面兩種預防同步控制問題產生的方法不同，GRACE 提出的多版本管理. ‧ 國. 學. 允許操作間的衝突發生，藉由在本地端備份所有的編輯版本，因應所有的編輯. ‧. 操作。此種方式的優點是無時間延遲問題（皆在本地端編輯），保存在操作產生. sit. y. Nat. 衝突前的工作狀況。. n. al. er. io. 然而除了備份所有版本需耗費額外資源外，此類多版本控制的編輯方式在介面. i n U. v. 設計上並不容易清楚呈現給使用者，容易讓使用者在所有備份版本中進行選擇. Ch. engchi. 時產生困惑，甚至決策上的錯誤。. 2.2.4 混合式方案除了上面三種作法外，亦有研究使用混合式解決方案，例如 Sandy Citro、 Jim McGovern 及 Caspar Ryan 等人結合了以上既存方式，提出一管理衝突的演算法[19]。. 15. DOI:10.6814/THE.NCCU.DCT.004.2018.B02.

(22) 當複數使用者同時修改同一個目標時會發生衝突問題，在此研究中將衝突分成非獨占性及獨佔性兩種，可同時存在時為非獨占性，當不能同時執行時（後來會覆蓋先到）的稱為獨佔性衝突。無論屬於何種衝突形式，皆需對產生衝突之目標進行鎖定，以免產生更多問題。鎖可放置在單一物件上或者該物件之屬性級別，具體狀況取決於程式的設定。對於非獨占性衝突，將所使用者們執行的操作轉化成一序列，將決策權交. 政治大. 給使用者，藉由選擇保留目前操作、撤銷上一步，或是執行新操作，以修正問. 立. 題。而獨佔性衝突不能以序列化，選擇以多版本控制的方式處理，每個使用者. ‧ 國. 學. 所做的改變將在不同的版本檔案中實作。然而視狀況不同，系統可能會誤以多. ‧. 版本控制的方式處理非獨占性衝突。. sit. y. Nat. n. al. er. io. 以上為圖像共同編輯系統中常見的處理同步控制問題的方式，各具備優勢. i n U. v. 的同時也尚有改善空間，傳統的鎖與序列化兩種方法，其本質上並沒有解決多. Ch. engchi. 人同時直接對共同變數做存取的狀況：鎖的操作方式犧牲了使用者的即時體驗感（需要等待當前使用者編輯結束）、序列化則需要考慮在相對操作指令出現時是否會衍生出與預期中不同的結果；多版本則是在圖形介面的呈現上會遇到一些困難，無論對使用者或是開發者都並不是那麼友善，最後的混合式方案仍有其瑕疵存在，例如使用者仍需花費心力進行人工決策，或是系統在部分情況下會判斷錯誤等等。. 16. DOI:10.6814/THE.NCCU.DCT.004.2018.B02.

(23) 2.3 數位協同創作與共同編輯系統本節將以過去數個數位協同創作的互動作品為例，進一步討論與共同編輯系統結合的可能性。 “HIVE” 是由 Jon Montenegro 於 2015 年提出的一項數位協同創作[14]：多名使用者同時編輯一塊工作區域，工作區域上分佈著圓圈排成的矩形，藉由使用者點擊矩形隨機填入顏色或改變樣式，以形成一幅簡易的圖畫。以目前此作品於線上的展示狀況來看，使用者之於其他使用者為未知狀態，意. 治政大即每個參與者皆不曉得此時線上有多少人，或者正在哪個位置執行什麼動作，立 ‧. ‧ 國. 學. 因此產生出來也為不可預測的最終結果。. n. er. io. sit. y. Nat. al. Ch. engchi. i n U. v. 圖 2.4 HIVE 創作介面 Jon Montenegro 的另一項創作“Abyss”[16]亦有異曲同工之妙，觀眾（也就是參與者）使用手機掃描 QR code 之後，會將參與者的手持裝置導向一幅全黑的畫面，藉由對面板進行點擊的動作會在該畫面產生漣漪，而這些參與者造成的漣漪會一起顯示在螢幕之上，形成一幅被打亂水面般的影像。. 17. DOI:10.6814/THE.NCCU.DCT.004.2018.B02.

(24) 這兩項作品皆使觀眾跳脫單純「觀賞」的角色，使其成為創作者的一部份，可視為共同編輯系統的一種變體。. 立. 政治大. er. io. sit. y. ‧. ‧ 國. 學. Nat. 圖 2.5 Abyss 互動成像. 而點陣式共同圖像創作，例如 CrowdPainting 實驗計畫，此網站計畫以多人於線. al. n. v i n Ch 上繪製畫布的一部分，完成史上最大的共同合作繪畫。使用者在註冊及登錄後， engchi U 可於系統分配的指定空白位置進行作畫；與前兩者不同，使用者無法對其他參與者的作畫區域進行干涉的動作，但在區域作畫完成後申請新的畫布，只要是分配給自己的區域都可更動修改。. 18. DOI:10.6814/THE.NCCU.DCT.004.2018.B02.

(25) 政治大. 圖 2.6 CrowdPainting 計畫實施頁面. 立. 除此之外尚有許多數位協同創作的互動作品，在此不再一一列舉，但可從中注. ‧ 國. 學. 意到，大多數的創作者在製作這類型的互動作品時，會選擇使用 JavaScript 做為. ‧. 主要開發語言；以及這些互動作品的功能，無疑能夠以一般共同編輯系統的概. sit. y. Nat. 念作為為基礎模板，進一步進行開發及調整後成形。. io. n. al. er. 下一章節將敘述本研究結合參與者模式與數位協同創作方法，以及實作範例。. Ch. engchi. 19. i n U. v. DOI:10.6814/THE.NCCU.DCT.004.2018.B02.

(26) 第三章研究方法. 有鑑於現今許多互動裝置及作品皆採用 JavaScript 開發，JavaScript 易與多媒體及網頁結合的特性誘使許多開發人員投入，擁有豐富的工具套件；考量到在許多從事互動作品製作的開發者之間的語言普及度、共同編輯功能中圖形繪製的便捷等等因素，本研究選用 JavaScript 作為開發語言進行實作。. 政治大了避免阻塞，發展出使用呼調（Callback）的非同步程式設計方式，而這種撰寫立. 由於 JavaScript 的運行環境以瀏覽器為主，因此設計成單執行緒的程式語言，為. ‧ 國. 學. 方式又發展出延續傳遞風格，此種程式撰寫方式視專案複雜度的不同，對開發者而言可能衍生出其他困難，將在下一節進一步進行介紹。. ‧ y. Nat. er. io. al. sit. 3.1 延續傳遞風格與非同步程式設計. v. n. 延續傳遞風格（Continuation-passing style），簡稱 CPS，與直接風格（Direct. Ch. engchi. i n U. style）直接回傳函數計算結果值不同，延續傳遞風格選擇將計算完成的結果直接傳送入下一個要進行計算的函式。相較於其他程式語言 JavaScript 更為頻繁地使用 CPS 程設方法，除了因為 JavaScript 本身即具備高階函式（High order function）的特性外，還有其只具備單執行緒的執行方式：卻在多人連線處理大量 I/O 時仍需維持不阻塞的執行效率，因此需要可以確保非同步回調的程設方法。. 20. DOI:10.6814/THE.NCCU.DCT.004.2018.B02.

(27) 關於同步／非同步程式設計，「同步」意即在程式執行時依照撰寫的順序——由上至下依序，上方的執行完畢才會執行下方的功能，大部分的程式都以這種方式執行。但對於單執行緒而言，在遇到需要較長時間的動作時這種執行方式會造成堵塞，進一步影響執行的效率；此時藉由非同步程式設計可迴避這種狀況，也就是將造成堵塞的動作先置入佇列，經過一段時間後再回調執行。然而 CPS 也為開發者帶來了其他問題：隨著專案規模及複雜度的上升，在進行異步回調的規劃與組織也愈發困難、程式的維護性及可除錯性亦會降低許多，. 政治大. 加上匿名函式的存在，可能導致更複雜的狀況，甚至出現回調地獄（Callback. 立. hell）現象。. ‧. ‧ 國. 學 er. io. sit. y. Nat. al. n. v i n Ch 圖 3.1 難以閱讀的多層函式架構被匿稱為回調地獄 engchi U 因此如何迴避同步控制問題、簡化延續傳遞風格以兼顧方便開發者的維護性與閱讀性為研究中關注的重點。. 3.2 以參與者模式包裝後端服務在前兩章所提到，參與者模式的結合為本研究提出的解決方案，藉由將後端函式功能包裝成 Actor 架構，增加程式的可閱讀性，並藉此解決同步控制問題。. 21. DOI:10.6814/THE.NCCU.DCT.004.2018.B02.

(28) 首先，將 Actor 分為兩種類，分別是位階最高用來控制 Whiteboard 頁面的 aWB∈AWB，以及隸屬其下的協作者 auser∈Auser。. 前者負責最終圖像的展示與合成，在一組共同編輯群組中只會存在一個 aEWB，若存在多組共同編輯群組，彼此欲進行交流或資料的溝通，也應該經由此 aEWB 進行處理，此研究暫只討論單一共同編輯群組的，即僅存在一個 E 的狀況。建立 aEWB 之後，可由 aEWB 建立可同時存在複數的 AEuser ，其中 AEuser={u1,. 政治大. u2...un}，負責處理所屬使用者前端送達的資料，並依需求將其交給其他 Actor，圖 3-2 為架構示意圖。. 立. ‧. ‧ 國. 學. n. er. io. sit. y. Nat. al. Ch. engchi. i n U. v. 圖 3.2 後端資料處理架構圖. 22. DOI:10.6814/THE.NCCU.DCT.004.2018.B02.

(29) 𝑊𝐵 ∈ 𝐴!" ——（1） 𝑢 ≡ {𝑢! , 𝑢! . . . 𝑢! } ∈ 𝐴!"#$ ——（2）. 上兩式指將展示頁面以 WB 表示，WB 於後端的訊息處理交由 AWB 負責；同時存在的複數使用者，在此統一以 u 表示，與其對應的 Actor 類型統稱為 Auser。由此討論，我們可正式定義一個共同編輯群組 E 為一個 tuple：E = <aEWB, AEuser>，其中 AEuser={u1, u2...un}為參考 E 的協作 actors，uk∈ 𝛶，𝛶為所有 actors 的集合。. 立. 政治大. 根據參與者模式中的規則定義，以上這些 Actor 皆需要經由一個代理者 m∈M，. ‧ 國. 學. 在參與者模式中稱為信箱（Mailbox），以佇列的方式經手傳入的訊息 𝑀。. ‧. 此信箱佇列中的訊息 𝑀 不一定以 FIFO 的順序進行處理，可依使用者個別需求. Nat. sit. n. al. er. io. 步定義為：. y. 進行設置觸發條件，或者等候時間的調整，以非同步執行的方式運作。可進一. Ch. 𝛶 = 𝑀×𝐵. i n U. ——（3）. engchi. v. 𝑀 = {𝑚! , . . . , 𝑚! }, 𝐵 = {𝑏! , . . . , 𝑏! } ——（4）. 其中𝛶 意即所有的 Actors，而 M 代表信箱地址，B 代表本身內建的邏輯行為。此研究在實作的部分，由於每個 Actor 的基本規格與構成皆為一致，因此使用抽象工廠模式（Abstract Factory Pattern）包裝參與者模式，以一個 Actor（即行為及邏輯內容）配備一個信箱的方式輸出：AE 𝑢𝑠𝑒𝑟𝑘 = (mk, bk)，因此我們可將其表示為 AEuser = {u1, …, un} = {(m1, b1), (m2, b2), …, (mn, bn)}，同理 AEWB = (mWB, bWB)。. 23. DOI:10.6814/THE.NCCU.DCT.004.2018.B02.

(30) 學圖 3.3 Actor Model 實作架構示意圖. Nat. io. sit. y. ‧. ‧ 國. 立. 政治大. er. 就包裝函式而言，若採用一般的物件導向程式設計方法也能達到類似的呈現，. al. n. v i n 然而傳統物件導向的設計方式在解決同步控制問題上，需依賴鎖定機制處理可 Ch engchi U 能出現的衝突及問題。簡單的鎖定機制並不難實現，然而隨著專案的規模增加其實現邏輯也會變得愈加複雜，而參與者模式透過狀態各自持有的方式克服了此困難，因此不需要鎖定機制協助處理同步問題。在此研究中我們以此概念實作了簡易的共同圖片編輯工具，前後端的資料溝通以 Socket.io 進行，在進行程式撰寫時，aEWB 部分的編輯目為安排各 AEuser 的宣告，在使用者頁面開啟時為該頁面綁定 AEuser，並決定允許接收並處理哪些訊息；而 AEuser 內部則包涵了訊息的內容，也就是邏輯本身。. 24. DOI:10.6814/THE.NCCU.DCT.004.2018.B02.

(31) 圖 3.4 以參與者模式包裝過後的編輯函式. 政治大. 圖 3.4 為一 AWB 類型的 Actor 實作（以下簡稱𝑎!" ），其行為 bWB 產生一封訊息 aWB. 立. ，內容是生產一個 u，以下簡稱為 𝑎𝑢1 。首先使用 init() 宣告 𝑎𝑢1 ，此動作. 學. ‧ 國. 𝑀!. 將藉由 Factory 建構起一個本身包涵邏輯函式的 Actor 及專屬於它的信箱，確定. ‧. 成功後 𝑎𝑢1 即可向 WB 與 𝑢! 寄送訊息，也就是 sendToWB() 及 sendToUser2()，. sit. y. Nat. 詳細功能邏輯比照於 𝑎!" 撰寫於 𝑎𝑢1 中，以此類推可撰寫其他訊息𝑀! 。. io. al. er. 此撰寫方法看似一般物件導向程式中呼叫物件的方式，但不同之處在於這封訊. v. n. 息並非直接寄送給 Actor 本身處理，而是經由信箱排序後才交予 Actor 執行；但. Ch. engchi. i n U. 開發者在使用此函式庫時不需理解背後的訊息交換細節，函式庫提供基本的功能，開發者只需要呼叫，或者依照模式概念根據需求撰寫功能邏輯部分的訊息內容，並設定發送時機即可。. 25. DOI:10.6814/THE.NCCU.DCT.004.2018.B02.

(32) 圖 3.5 使用者頁面範例. 立. 政治大. 在前端的部分，可分為展示頁面及使用者頁面。展示頁面對應後端的 𝑎!" ，僅. ‧ 國. 學. 負責接收使用者繪製完成的圖形資訊；而在使用者頁面中提供了基礎的圖形繪. io. sit. y. Nat. n. al. er. 選項。. ‧. 製功能，以及將畫布傳送的至其他頁面（包含展示頁或者其他使用者畫布）的. Ch. engchi. i n U. v. 圖 3.6 系統運行循序圖. 26. DOI:10.6814/THE.NCCU.DCT.004.2018.B02.

(33) 首先展示頁面啟動的當下，會在後端服務中建構一個 𝑎!" ，並將辨識 ID 與當下畫布狀態一齊傳送至屬於 𝑎!" 的信箱 𝑀!" ，經由佇列處理後保存至 𝑎!" 之中，其後若他人（使用者）需要更改這些狀態，皆不能直接存取值，而是經由發送要求至信箱，依序進行處理。展示頁面設置好之後即能開啟使用者頁面，其數量或上限可依照開發者的預設需求進行更動及設定；當使用者頁面連線至伺服器時比照展示頁面，將自己的 ID 及畫布狀態經由信箱傳送至自己的 auser 中並予以保存。以下 Pseudocode 為 AWB 的行為定義：. 立. 政治大. if WB is opened then. ‧ 國. 學. def 𝑎!" , 𝑎!" ∈ 𝐴!" [case operation of. ‧. 𝑀! : 𝑎!! (status of un). sit. y. Nat. end case]. er. io. if operation = 𝑀! ∧ (𝑠𝑡𝑎𝑡𝑢𝑠 𝑜𝑓 𝑢! ) ≠ NIL then become link. n. a. be ablel to Caccess data from 𝑎!! n. fi. hengchi U. iv. end def. 不同於唯一的 AWB ，鑑於使用者數量的變化 Auser 可能存在複數，然而其預設行為並不會有太大的差異，以下為 Pseudocode Auser 的行為概念：. 27. DOI:10.6814/THE.NCCU.DCT.004.2018.B02.

(34) if un is opened then def 𝑎! (status of un), ∀𝑎!"#$ ∈ 𝐴!"#$ [case operation of 𝑀!" ：𝑎!" 𝑀!! ：𝑎!! (status of un) end case] if operation = 𝑀!" then send some messages to 𝑎!" fi. 政治大 send some messages to 𝑎 立. if operation = 𝑀!! ∧ (status of un) ≠ NIL then !!. 學. end def. ‧. ‧ 國. fi. 作畫期間畫布狀態預設不會即時更新至後端伺服器，而是在選擇將圖形傳輸至. Nat. sit. y. 其他頁面時，才會以 Base64/PNG 的編碼方式送至後端進行處理，方便使用者之. n. al. er. io. 間互相交換作圖，而頁面之間的判定以各自的所屬 ID 辨識。. Ch. engchi. 28. i n U. v. DOI:10.6814/THE.NCCU.DCT.004.2018.B02.

(35) 立. 政治大. ‧. ‧ 國. 學. n 3.3 校內展覽. 圖 3.7 系統運行流程. Ch. engchi. er. io. sit. y. Nat. al. i n U. v. 完成共同創作工具之應用範例後，於校內展覽中展出此創作輔助工具及應用範例。向參觀者以口頭介紹參與者模式及工具函式庫之使用方式，並提供範例情境予參觀者進行體驗活動。. •. 展覽時間：2018 年 6 月 15 日. •. 展覽地點：國立政治大學大仁樓 104. 29. DOI:10.6814/THE.NCCU.DCT.004.2018.B02.

(36) 展覽內容：參觀者可使用現場提供的電腦設備，或以自己的智慧型手機掃描張貼的 QR code 後進入個別使用者頁面，點選螢幕後可進行圖形繪製。繪製完成後可將圖形傳送至現場其他參觀者的所屬頁面進行互動作畫，或是將其傳送至展示屏幕上進行最終合成，完成一幅共同創作。. 立. 政治大. 學 ‧. ‧ 國 io. sit. y. Nat. n. al. er. •. Ch. engchi. i n U. v. 圖 3.8 於校內展展出共同創作工具應用範例. 30. DOI:10.6814/THE.NCCU.DCT.004.2018.B02.

(37) 第四章實驗與評估 4.1 評估流程及方法由於本研究的目標在於協助開發者加速開發流程，了解實際的使用狀況是否有改善是很重要的一環。因此本研究決定使用質性研究中的「易用性測試」（Usability Testing）為評估方法。根據國際標準組織定義，易用性泛指在指定情境條件下使用時，產品的容易理解程度、易學習程度和使用者的滿意度。易. 政治大. 用性測試一般分成兩種：形成型測試（ Formative Testing ）與總結型測試. 立. （Summative Testing）。兩者差異主要在於實施測試的時間點，形成型測試通常. ‧ 國. 學. 實施在產品完成之前，目的是取得實際使用的結果數據，作為產品改善的參考. ‧. 方向；總結型測試則是在產品完成之後實施測驗，除了受測者的回饋意見外，. sit. y. Nat. 也會將不同但類似性質的產品測試結果一同進行比較與分析。本研究目的為增. n. al. er. io. 進創作開發者之開發效率，藉由形成型的易用性測試可評估實際使用之問題所. i n U. v. 在，以及未來改進方向。研究測試中除了提供後端工具函式庫外，也會提供基. Ch. engchi. 礎前端頁面功能，以減少測試所需花費時間。在搭配架構圖簡單介紹參與者模式之後，將說明函式庫的使用目的及方法，接著受測者將依照文件指示獨立完成下列幾個目標，包括：・理解函式庫架構。・建構一個共同圖形編輯工具。・對功能進行一項擴增，如使用者人數上限變化、增加 Actor 保存屬性等。. 31. DOI:10.6814/THE.NCCU.DCT.004.2018.B02.

(38) 評估過程可分為兩大部分：觀察法及半結構式訪談。於測試過程中，提供 MacBookPro”13 為測試設備。首先研究方將向受測者簡要說明實驗流程，接著介紹共同編輯工具、參與者模式的原理，以及本研究提出之開發輔助工具。說明結束後受測者將開啟本次的實驗專案並進行工具函式庫的導入，專案中提供前端測試檔案以利受測者直接使用，接著輔以說明文件建構起一簡易共同圖形編輯系統，並對預設之使用者人數上限進行更動。過程中將紀錄完成任務目標所需的完成時間，以及受測者開發時所遇到的困. 政治大. 難及疑問點，觀察函式庫的使用狀況狀況、是否能夠在短時間內迅速上手......等. 立. 等狀況。此階段評估旨在記錄受測者實際使用本研究提供之工具的操作狀況。. ‧. ‧ 國. 學. n. er. io. sit. y. Nat. al. Ch. engchi. i n U. v. 圖 4.1 實驗過程側拍. 32. DOI:10.6814/THE.NCCU.DCT.004.2018.B02.

(39) 完成上列目標後將對受測者進行結構式的訪談，以訪談問卷的方式回答關鍵問題，主要包括：・函式庫的使用與架構是否直覺並容易理解？・是否容易對功能進行擴增或者編修？・參與者模式對整體架構的理解及開發是否有所助益？・使用此函式庫是否對加速開發共同圖片編輯工具有所幫助？・開發過程中遇到哪些問題？請列舉並說明之。. 政治大. 此外，受測者可在此階段進一步提出對此工具的問題及看法，藉此評估本研. 立. 表 4.1 流程之評估項目與預估時間. y. sit. 預估時間. n. al. er. io 說明實驗流程. ‧. 測試流程. Nat. 評估項目. 學. ‧ 國. 究的目標成效，以錄音方式全程紀錄。. Ch. engchi. i n U. v 3 分鐘. 介紹工具函式庫. 10 分鐘. 導入專案. 2 分鐘. 任務一：建構簡易共同圖形編輯工具. （進行時間紀錄）. 任務二：進行功能擴增－增加可上線使用者人數. （進行時間紀錄）. 33. DOI:10.6814/THE.NCCU.DCT.004.2018.B02.

(40) 4.2 評估對象一般產品的完成過程中，將反覆進行數次形成型測試進行改善，於形成型測試的階段，比起受測人數，更重視人員的背景條件。最後產品改良完成後，再進行海量統計的總結型測試。根據 Nielsen Norman Group 在 2000 年曾提出，作為產品的改善參考的形成型測試，每次只需要約五個符合特定條件需求的受測者便能找出 85% 的易用性問題，以比例而言是最符合成本效益的數字[18]。在此次實驗中，徵求了五位符合需求條件、具備程式開發經驗的受測人員進行評估。. 立. 政治大. ‧. ‧ 國. 學 er. io. sit. y. Nat. 圖 4.2 受測者數量與找出易用性問題之比例（圖片來源：https://www.nngroup.com/）. n. al. Ch. engchi. i n U. v. 研究目標希望無論使用者技術上的程度為何，都能迅速地學會函式庫的使用方式，在短時間內開發出相關的互動創作。在評估過程中，我們徵求了五位平時有在進行程式設計，並具備 node.js 後端服務開發經驗的受測者，三位男性、兩位女性，年齡層集中在 23 至 26 歲之間。依照程式開發經驗多寡及熟悉度，由淺至深分成初學者、中、高三個等級，並調查受測者是否具備開發共同編輯系統之經驗。. 34. DOI:10.6814/THE.NCCU.DCT.004.2018.B02.

(41) 表 4.2 受測者基本資料受測者. 年齡. 性別. 教育程度. 程式開發經驗. 是否有開發共同編輯系統之相關經驗. A. 25. 男. 學士. 初學者. 否. B. 24. 男. 碩士. 中級. 否. C. 23. 男. 碩士. 初學者. 是. D. 26. 女. 碩士. 初學者. 否. E. 26. 女. 碩士. 立. 否. ‧ 國. 學. 4.3 評估結果分析. 高級政治大. 經過測試實驗我們可從記錄中得知，使用者完成實驗目標的所需時間總和皆在. ‧. 四十分鐘以內。其中最長的時間總和為 38 分 16 秒，程式開發經驗為初學者；. y. Nat. er. io. sit. 最短時間為 16 分 37 秒，程式開發經驗較豐富，為高級者類別。而第一項任務：建構一簡易共同圖形編輯工具，五位受測者的完成時間皆在十分鐘以內。. n. al. Ch. engchi. i n U. v. 圖 4.3 受測者實驗時間. 35. DOI:10.6814/THE.NCCU.DCT.004.2018.B02.

(42) 參與者模式欲順利啟動的步驟包含 (1) 創造一 Actor 閉包並為其命名 (2) 於 Actor 內部依照格式需求撰寫訊息內容 (3) 於適當的時機使用 init() 初始化 Actor (4) 根據所需時機或條件啟動該 Actor 的內部訊息。. 立. 政治大. ‧. ‧ 國. 學 sit. y. Nat. n. al. er. io. 圖 4.4 實驗中參與者模式的啟動步驟. Ch. engchi. i n U. v. 在前半的實作階段我們觀察到，有三位受測者在定義完訊息內容後，會宣告 Actor 本身，卻忘記進行訊息的啟動步驟。我們推測與此次實驗內容設計並無太複雜的邏輯需求有關，使用者不需考慮太多宣告與啟動時機的問題，最後一步驟便顯得較不直覺。另外，在實驗流程中我們發現，具備共同編輯系統開發經驗的受測者，與開發經驗為高級的受測者，於理解問題與工具性質上的速度明顯高於其他受測者。於訪談中得知前者在共同編輯系統的開發上遭遇過同步控. 36. DOI:10.6814/THE.NCCU.DCT.004.2018.B02.

(43) 制問題的處理難題，而後者亦俱備處理同步控制問題及非同步程式設計的豐富經驗。受測者於訪談階段以五等第制的方式評分關鍵性問題，並發表過程中遇到的難處及意見，經歸納後評估結果如下：. 1. 輔助開發工具的使用及架構直覺並容易理解。此項評分平均為 4 分，經過流程中的輔助開發工具介紹步驟後，使用者. 政治大. 皆認為此工具的使用方式及架構直覺且容易理解。其中兩位受測者 B 與 D 認為，. 立. 宣告 Actor 內部行為及訊息的方式略嫌複雜，希望有更簡明的方式進行宣告及啟. ‧ 國. 學. 動呼叫，尚有改進空間；受測者 A 表示，經過說明後相當簡單易懂，但若在缺. ‧. 乏口頭說明的狀況下，對於初學者而言使用的門檻難度會提升，可能會需要更. n. al. er. io. sit. y. Nat. 長的思考時間，建議在文件中更詳盡地介紹參與者模式的運作方式。. 2. 容易對功能進行擴增或編修。. Ch. engchi. i n U. v. 此項評分平均為 3.8 分，多數受測者者認為輔助開發工具容易對共同編輯系統的功能進行編修，包括將其應用於互動裝置作品上；其中兩位受測者表示希望能有將輔助開發工具與各種感應器連結的嘗試機會。受測者 B 認為由於宣告 Actor 內部行為及訊息方式的複雜性，在有其他中介軟體可供選擇的狀況下，可能會影響將工具應用於 IOT 相關互動裝置的使用意願。. 37. DOI:10.6814/THE.NCCU.DCT.004.2018.B02.

(44) 3. 參與者模式對於整體的架構理解及開發有正面的助益。此項評分平均為 4.2 分，各種開發程度的受測者皆認為參與者模式有助於明確地理解各個頁面的資料管理架構及連結關係。其中給予最低 3 分的受測者 D 表示，在毫無基礎背景知識的狀況下，對於參與者模式的運作較難在短時間內完整理解。經過討論後，對此我們推定與 Actor 宣告內部訊息的方式略嫌繁瑣有關，使得受測者在進行各項細部調整及設定時較容易受到混肴。. 政治大. 4. 使用此開發工具有助於加速共同編輯系統的開發。. 立. 此項評分為 4.8 分，所有的受測者一致肯定此輔助開發工具有助於加速共. ‧ 國. 學. 同編輯系統的開發，對於沒有共同編輯系統開發經驗的開發者十分友善，藉由. ‧. 輔助工具提供的方法，能夠在短時間內架構起一共同編輯系統，而不用從零開. y. sit. n. al. er. io. 開發上。. Nat. 始從頭摸索，大幅降低了開發門檻的高度，能夠花更多心力於其他功能應用的. Ch. engchi. 38. i n U. v. DOI:10.6814/THE.NCCU.DCT.004.2018.B02.

(45) 第五章結論與未來工作. 5.1 研究貢獻綜合前述章節，傳統在進行共同圖形編輯系統的開發時，同步控制問題的處理容易趨近複雜化；而將共同圖形編輯系統的概念應用於互動藝術裝置上時，對於創作者而言，如何處理同步控制問題往往會成為最大的難題之一。此研究藉. 政治大. 由以參與者模式進行後端服務的包裝，提供創作者一輔助開發工具以達成下列. 立. 目標，包括：. ‧ 國. 學. 1. 協助使用者加速開發流程 2. 便於維護及易理解的程式碼. ‧. 3. 彈性的應用發展. y. Nat. er. io. sit. 首先，輔助開發工具中提供將功能包裝好的訊息交換函式功能，即使創作者不諳內部邏輯原理，也能藉由呼叫模組化功能進行功能的製作，開發時更為. al. n. v i n Ch 直覺，不需必再耗費心力於底層邏輯的撰寫與設計，可縮短協助創作者縮短開 engchi U 發流程。其二，參與者模式將狀態及行為封裝於各個 Actor 之中，根據其行為及目的之差異可分為兩大類：控制展示頁面／控制使用者頁面兩種。除了參與者模式可簡化同步問題處理複雜程度的優勢外，藉由功能的差異歸納 Actor 種類這點，使得狀態隸屬相較於傳統方案更加分明，對於創作者而言也相對直覺，提升開發效率及後續維護的品質。. 39. DOI:10.6814/THE.NCCU.DCT.004.2018.B02.

(46) 最後，由於此函式庫以 JavaScript 撰寫，易與多媒體及網頁結合，並擁有豐富的相關工具套件；因此除了本研究的共同創作系統外，創作者也可藉由對函式庫中 Actor 的行為進行增加或改寫，將函式庫應用於其他形式的多人互動藝術作品上。. 5.2 未來發展綜合實驗中受測者的訪談結果及其他使用者的回饋之後，我們歸納出未來研究之發展及改進方向如下：. 學. ‧ 國. 立. 政治大. 1. 簡化 Actor 內部的行為及訊息的宣告方式. ‧. 在實驗過程中，受測者皆對參與者模式之於共同編輯系統抱持正面的態. sit. y. Nat. 度，而同時我們收到許多回饋，多數意見提出關於 Actor 的部署有些複雜，需要. n. al. er. io. 的設定時間較為冗長與瑣碎。當一個 Actor 的內部行為或訊息種類越趨多樣化時，. i n U. v. 管理的難度亦會與之上升。若能藉由將宣告的方式加以簡化，以利開發及管理，提升工具的易用性。. Ch. engchi. 2. 增加互動裝置常使用的感應器預設收發訊息方法鑑於許多現今互動裝置時常與各種感應器進行結合，進行多樣互動方式的開發，未來可規劃增加不同種類訊息的預設收發方法，幫助使用者減少創作過程所花費之心力與時間，也增廣此工具的適用範圍。. 40. DOI:10.6814/THE.NCCU.DCT.004.2018.B02.

(47) 參考文獻 [1]. Grudin, J. (1994). Computer-supported cooperative work: Its history and participation. IEEE Computer 27(5): 19-26.. [2]. Karen D. Grant. Dimensions of Collaborative Work.. [3]. ER Pedersen. Tivoli: an electronic whiteboard for informal workgroup meetings.. 政治大 Factors in Computing Systems Pages 391-398 立. CHI '93 Proceedings of the INTERACT '93 and CHI '93 Conference on Human. ‧ 國. 學. [4]. JH Oh, CK Shi. Categorisation of Audience Relationship between Action and. ‧. Visualisation in Interactive Art Installations. 2013 17th International Conference. sit. al. er. io. v. Linda Candy & Sam Ferguson. Interactive Experience in the Digital Age:. n. [5]. y. Nat. on Information Visualisation.. Ch. Evaluating New Art Practice.. engchi. i n U. [6]. http://studiobottles.net/projects/nhm/spell-on-the-city?ckattempt=1. [7]. Claudia-Lavinia Ignat, Moira C. Norrie. Grouping in collaborative graphical editors. CSCW '04 Proceedings of the 2004 ACM conference on Computer supported cooperative work Pages 447-456. [8]. C.A. EllisS.J. Gibbs Concurrency Control in Groupware Systems. 41. DOI:10.6814/THE.NCCU.DCT.004.2018.B02.

(48) [9]. Newman-Wolfe, R.E., Webb M., and Montes, M. Implicit locking in the Ensemble concurrent object-oriented graphics editor. Proc. of the CSCW’92, New York, 1992, 265-272.. [10]. Karsenty, A., and Beaudouin-Lafon, M. An algorithm for distributed groupware applications. Proc. of the 13th Intl. Conf. on Distributed Computing Systems, May 1993, 195-202.. [11]. 政治大. Sun, C. and Chen, D. Consistency Maintenance in Real-Time Collaborative. 立. Graphics Editing Systems. ACM Trans. on Computer-Human Interaction, vol.9,. ‧ 國. 學. no.1, March 2002, 1-41.. ‧. [12]. Carl Hewitt Peter Bishop Richard Steiger.A universal modular ACTOR. y. Nat. n. er. io. al. sit. formalism for artificial intelligence.. i n U. v. [13]. Agha,G A. Actors: A model of concurrent computation in distributed systems.. [14]. Jon Montenegro. Hive. http://www.jonjon.tv/clients/hive-interactive-art/. [15]. Kanwati, R. LICRA: a replicated-data management algorithm for distributed. Ch. engchi. synchronous groupware application. Parallel Computing, 22, 1992, 1733-1746. [16]. Jon Montenegro. Abyss. http://www.jonjon.tv/clients/abyss-interactive-art/. [17]. Crowd Painting. http://www.crowdpainting.com/. 42. DOI:10.6814/THE.NCCU.DCT.004.2018.B02.

(49) [18]. JAKOB. NIELSEN.. Why. You. Only. Need. to. Test. with. 5. Users?. https://www.nngroup.com/articles/why-you-only-need-to-test-with-5-users/. [19]. Sandy Citro, Jim McGovern, Caspar Ryan. Conflict Management for Real-Time Collaborative Editing in Mobile Replicated Architectures. ACSC '07 Proceedings of the thirtieth Australasian conference on Computer science - Volume 62 Pages 115-124.. 立. S. Tilkov, "Vaughn Vernon on Reactive Programming with the Actor Model," in. 學. ‧ 國. [20]. 政治大. IEEE Software, vol. 33, no. 3, pp. 109-112, May-June 2016.. ‧. [21]. Jason Stewart, Benjamin B. Bederson, Allison Druin. Single Display Groupware:. y. Nat. sit. A Model for Co-present Collaboration. CHI '99 Proceedings of the SIGCHI. n. al. er. io. conference on Human Factors in Computing SystemsPages 286-293. [22]. Ch. engchi. i n U. v. Carl Gutwin, Saul Greenberg & Mark Roseman. Workspace awareness in realtime distributed groupware frame. HCI '96 Proceedings of HCI on People and Computers XI Pages 281-298. [23]. Saul Greenberg, Stephen Hayne, Roy Rada. Groupware for Real-Time Drawing. Designer's Guide. 43. DOI:10.6814/THE.NCCU.DCT.004.2018.B02.

(50)