一個以Web 為基礎的新聞供稿實驗系統

全文

(1)一個以 Web 為基礎的新聞供稿實驗系統 A Web-based Experimental System for News Production 何旻哲國立政治大學資訊科學系 g9112@cs.nccu.edu.tw. 李蔡彥國立政治大學資訊科學系 li@nccu.edu.tw. 摘要由於資訊科技的發達，新聞媒體的電子化已成趨勢。而媒體電子化的項目裡，一套能有效提升編採流程效率的供稿系統，是目前具效益且亟待開發的應用。但目前對於供稿系統的研究大部分著重於電子報的部分，並且多數為特定媒體組織所客製化的。本研究以政大大學報的新聞編採流程為例，提出一套能滿足大學報特殊教學目的，並符合平面報紙稿件產製需求的供稿系統設計與實作。我們應用了角色存取控制模式、以新聞中心為主的組織架構及獨立出個人稿件管理區，使得這套供稿系統能具有彈性的權限架構、可適應不同的編採團隊組織且能滿足各項審稿流程之需求。在系統完成後的測試評估中，映證了供稿系統的功能與預期的目標相符，能有效幫助新聞編採流程中的各項工作。關鍵詞：Web 為基礎的新聞稿件產製、稿件自動化、供稿系統、角色存取控制. 一、簡介近年來資訊科技進步及網際網路的發達，許多報社都建置了自己的新聞網站，新聞的發行方式除了原本的平面版本之外，還有網站、電子報甚至以手機傳遞的方式發行。因此希望能將新聞編採流程自動化，方便管理不同的新聞媒材，並節省人力與成本。在新聞編採流程方面，Kerstin Forsberg （2001）定義了新聞產製的過程。從事件的發生、挑選具有新聞價值的事件、分派記者採訪工作、收集相關背景資料、進行採訪、產生各則新聞、到最後的發行，即為一個新聞媒體的採訪週期。我們可將 Forsberg 所提出的新聞產製過程對應到平面報紙的相關工作流程中。如圖一所示，每個採訪周期開始時，由記者提報相關線索，由各版主編召開線索會決定要報導哪些線索，並指派記者進行採訪。記者採訪之後收集不同新聞媒材，完成各則新聞製作，存入資料庫中。再由不同發行平台進行後製作，. 圖一、新聞產製流程. 產生各期新聞，最後召開檢討會，結束當期採訪流程。我們將其中包括記者報線、線索會、記者採訪、新聞產製到存入新聞資料庫等部份，稱之為「內部供稿流程」。政治大學新聞學系為了輔助新聞專業教學，同時提供學生一個模擬實際報業工作的環境，創辦了一份學生實習報紙「大學報」。大學報是一份以平面發行為主的報紙，另外也發行網路版「大學線上」。同時由於大學報除了提供實際報業之模擬環境外，更重要的是其教學目的，因此在組織架構上常常需要調整。孫龍翔（2003）與陳昶任（2003）曾根據大學報的工作流程提出一套稿件自動化系統，雖然這套系統能滿足目前大學報編採流程中大部分的工作需求，但是在使用者權限與組織架構的設計上，無法完全支援大學報在教學目的下所需要的彈性架構（孫龍翔，2003）。本研究以政大大學報為例，針對平面報紙稿件產製流程中的內部供稿部分，提出一套以 Web 為基礎的新聞供稿系統。應用角色存取控制模式的權限架構，及改以新聞中心為主的組織架構，讓供稿系統能隨時適應不同的人員編制；同時透過「個人線索區」與「個人稿件區」的功能，讓供稿系統符合各項審稿流程之需求。我們也針對這個系統的設計，提出了使用者的對功能性及適用性的使用評估報告。本文主要分為七節。第一節簡介供稿系統的需求及本研究之目的與方向；第二節說明與新聞供稿系統相關之背景介紹，以及本研究所應用之角色存取控制模式的相關研究；第三節.

(2) 描述了大學報之新聞編採工作流程，並點出供稿系統所應考慮的問題；第四節針對供稿系統實作上之主要功能做系統分析，並針對第三節所提出的問題提出解決方案；第五節呈現實作之結果與使用者測試評估後的意見；第六節呈現系統建置後的雛形，最後在第七節中討論發展供稿系統之結論與未來發展。. 二、背景與相關研究 (一) 虛擬新聞室在傳播領域的研究中，將新聞產製過程中對於資訊的過濾選擇以及處理稱為「守門」，對於這些過濾、選取資訊的角色，則稱為「守門人」（Gatekeeper）。林頎堯（1999）將新聞室定義為「記者、編輯等新聞工作人員從事資料蒐集、稿件撰寫以及版面編排等新聞產製作業的場所」，其實也就是新聞編採人員進行守門工作的場所（孫龍翔，2003）。許多報業希望藉由電腦的幫助來完成新聞編採的工作，對於這種「透過電腦連網作業，幫助記者完成原先必須在新聞室內之工作，使可能分散於不同地點的新聞守門人，彷彿在同一個辦公地點工作一般。」的行為，林頎堯（1999）將之定義為「虛擬新聞室」，新聞供稿系統也就屬於一種虛擬新聞室。. 圖二、角色存取控制圖（Park，2001）角色存取控制（Role-Based Access Control，RBAC）從 1970 年代被提出來，主要概念為不直接將權限賦予使用者，而是在中間創造一個「角色」，每個角色被賦予一個到多個權限，然後讓使用者來扮演一個或多個角色。 NIST 將角色存取模式歸納為四種模式（Sandhu，2000）： 1.. 僅實作「權限賦予」（Permission Assignment）及「角色賦予」（User Assignment）兩種功能。 2.. 不過孫龍翔（2003）認為，電子報與傳統平面報在產製稿件的工作流程仍有其差異。電子報著重於對新聞即時性的需求；而傳統平面報紙則重視守門程序的觀念。針對平面報的供稿需求，孫龍翔（2003）與陳昶任（2003）同樣以大學報為例，提出一套能符合平面報供稿流程的稿件產製流程自動化系統。 (三) 角色權限控制為了建立一套能適應彈性組織架構的供稿系統，需要完善的權限管理機制來幫助我們達到這個目的。由於傳統的權限控制在維護上的成本很高，因此許多不同的權限管理模式被提出來。角色存取控制模式即為其中之一，主要功能為減少管理存取權的成本與複雜度，同時能適用於大型組織（曾俊豪，2000）。. 階層式角色存取控制：除了單層式具有的功能之外，實作了角色的階層式架構（Role Hierarchy），使角色除了能被賦予權限外，還能被賦予其他角色。角色的權限為其被賦予的權限與其被賦予角色權限之聯集。. (二) 供稿系統對於供稿系統，Henrik Fagrell（2000）以廣播電台的新聞採訪為例，建構了 FieldWise 系統。這套系統著重於透過行動裝置，來幫助常常需要在外面採訪新聞的記者們收集相關背景資訊；並加強分散於各地的記者間的互動與合作。林頎堯（1999）也以交清電子報為例，建構了以電子報編採流程為主的「虛擬新聞室」。. 單層式角色存取控制：. 3.. 條件限制式角色存取控制：除階層式具有的功能之外，可以對角色賦予的動作加上條件限制（CONSTRAINTS），以符合組織運作上的實際情形。. 4.. 對稱式角色存取控制：除了條件限制式具有的功能之外，也能針對權限賦予的動作加上條件限制。. (四) 其他相關研究除了有關稿件產製流程的研究之外，稿件產生之後的新聞資料儲存格式也同樣受到重視；而發展「新聞內容標記」，是強化新聞內容資料儲存的重要途徑（陳百齡，2002）。國際報業電訊委員會（International Press Telecommunications Council ， IPTC ）提出了 NewsML、NITF、PRISM 等多項規格，並已經在國際報業間被廣泛運用。. 三、大學報工作流程.

(3) 圖三、大學報工作流程. 大學報是一份由政治大學新聞學系所創辦的一份學生實習報，以大學生角度出發，主要為報導大學生活的相關資訊，由學生獨立作業，模擬報社實際運作，並於每週五出報。大學報每星期的工作流程如圖三所示，從前一週星期四開始，記者在早上十點之前，將以 MS-Word 格式儲存的線索單利用 FTP 的方式上傳至伺服器上；主編與總編依據線索單召開線索會與主編會討論要報導哪些線索。記者採訪之後，在出報當週星期一將稿件以純文字檔格式儲存並利用 FTP 方式上傳至伺服器上；主編到伺服器上將稿件下載回個人電腦並列印出來進行審稿與改稿作業，方便閱讀以及與總編和記者開會時討論使用。同時編輯室的編輯也到 FTP 伺服器上下載記者稿件的純文字檔，利用編採實驗室中個人電腦上的 Quark press 桌上排版軟體進行文字的編排組版。最後在星期四出報，並於星期五舉行檢討會，結束當期大學報工作流程。. (二) 新聞中心模式在此模式下，總編負責管理多個新聞中心與一個編輯中心。新聞中心分別指派正副採訪主任各一名。記者所撰寫的稿件屬於新聞中心，再由新聞中心供稿給其下所屬各版。編輯中心主任則負責帶領編輯群分組進行各新聞中心內稿件的編輯工作。初步分析大學報的工作流程，我們得到如圖五的供稿系統使用案例圖。記者與主編透過線索流程及稿件流程來進行報線與採訪作業，在採訪過程中，也利用討論區的功能交流對於各則新聞的意見；系統管理員透過管理系統來管理使用者權限、討論區及設定大學報各期的期數資訊。圖六為稿件流程的使用案例圖與稿件活動圖，由於線索與稿件之流程類似，我們只呈現稿件之審稿流程。. 由於大學報是一份學生實習報紙，除了模擬一般報社的運作之外，仍有其教學目的；因此編採團隊組織可能會因為每年的教學目的不同而有所變更，如圖四，主要可以分為以下兩種模式： (一) 版面模式由總編輯管理新聞中心，在新聞中心下設八個版。分別指派一名主編來管理屬於該版的記者與編輯，記者所撰寫的稿件出現在自己所屬的版。對編採團隊組織來說，皆是以「版」為單位來進行採訪路線的分配與記者及編輯的管理。. 圖四、大學報編採團隊組織圖 (a)版面模式 (b)新聞中心模式.

(4) 編輯. 記者. 記者. 新聞中心主任. 新增稿件. 稿件流程. 討論區. 提交稿件. 刪除稿件. 線索流程. 閱讀稿件. 新聞中心主任. <<extend>>. <<include>>. 稿件分版. 審核稿件. 管理稿件. 再加強 <<extend>>. 系統管理員. 編輯. <<extend>>. <<extend>>. 不錄取轉至其他新聞中心. 管理使用者權限. 管理討論區. 設定期數. (from 系統管理). (from 系統管理). (from 系統管理). 錄取. （a）. 圖六、供稿系統使用案例圖. 記者. 新聞中心主任. 供稿系統. 新增稿件. 四、系統設計基於前節所述，供稿系統除了一般虛擬新聞室所須具備的功能之外，還要能符合平面報紙的供稿流程與守門觀念；同時要基於大學報的教學目的，這套供稿系統必須能適應不同的組織架構模式。圖七為本系統的網站架構圖及使用案例圖；系統主要可分成「系統區」、「記者區」、「主編區」、「系統管理區」等四個主要區塊。系統區主要功能為訊息交換的場所，包含系統公告、各項討論交流園地、以及放置參考資料等。記者可以在記者區中使用個人稿件管理來新增當期稿件，並且在稿件區中查看當期其他記者所採訪的稿件，線索流程亦同。主編則利用主編區中的功能進行線索、稿件的審核動作，並且利用稿件區中之討論區功能與記者交換意見。最後系統管理員可以在系統管理區中進行各項管理工作。本章將針對供稿系統的幾個比較重要的功能說明系統設計上如何解決各項問題。 (一) 權限架構在供稿系統的權限設計上，為了要有較具彈性的權限管理機制，我們採用了角色存取控制模式作為權限架構的基礎。以大學報而言，組織中的角色較為單純，且彼此之間少有權限上的衝突，因此我們僅實作單層式角色控制模式。圖八為使用者類別圖，每個使用者為多個角色的集合，而每個角色亦為多個權限的集合。此外，為了權限判斷方便，使用者另外維護一份權限集合，此權限集合為所有賦予使用者角色的權限之聯集。圖九為使用者登入系統時之流程圖，由於角色及權限等資料並不會常常變動，因此我們. 暫存. 刪除稿件. 提交稿件. 審理中. 再加強. 審核稿件. 不錄取. 錄取. 系統歸檔. （b）圖五、（a）稿件流程使用案例圖（b）稿件活動圖在供稿系統啟始時即將角色、權限等資訊放入 Role Manager 中管理。使用者登入時，系統會先到資料庫取得使用者將關資訊，並依據使用者所擁有的角色向 Role Manager 取得該角色所賦予的權限，將之加入使用者的本身的權限集合，隨後存入 Permission Pool 中。當使用的功能必須檢查權限時，則直接到 Permission Pool 中取得使用者的權限集合，檢查是否擁有適當的權限。 (二) 編採組織架構本文之前曾提及，大學報的編採組織可以採用兩種模式：版面模式與新聞中心模式。因此在組織架構的部分，必須考慮能適應雙層或者多層架構。這部分我們提出兩種可能的解決方案。第一種為雙層式架構，每個新聞中心都是由一個或多個版面所構成，而稿件及線索可以屬於一個新聞中心或者一個版面，雙層式架構能支援版面模式或新聞中心模式的編採組織架構；第二種則為多層式架構模型。我們定義一個「組織」能包含零個到多個子組織；而記.

(5) user 1. 1. 1..n. role. permissionSet 1. 1. 1..n. permission. 圖八、使用者類別圖（a）設定使用者角色稿件流程. 權限管理. 管理角色權限. (from 系統管理). (from 系統管理). <<extend>> <<extend>>. 討論區. 使用者. 管理系統. <<extend>>. 設定期數 (from 系統管理). <<extend>>. <<extend>>. <<extend>>. 圖九、使用者登入流程圖線索流程. 管理討論區 (from 系統管理). 管理新聞中心 (from 系統管理). 管理版面 (from 系統管理). （b）圖七、 (a)供稿系統網站架構圖, 系統使用案例圖. (b)供稿. 者可以發表線索或稿件到這些組織中。在多層式架構模型中，無論將來組織如何調整，都能夠馬上配合調整，但是相對地在設定上也較為複雜。在系統分析時的訪談過程中，我們了解大學報不會出現三層以上的編採組織架構，且必須考慮將來的系統管理者不具資訊背景，太複雜的設定方式反而會增加系統管理者的負擔，因此在供稿系統中我們採用雙層式的組織架構。在雙層式的架構中，記者所發表的線索與稿件都屬於新聞中心，再由新聞中心主任將線索或稿件分版；如果新聞中心內只有一個版，則系統會自動將線索、稿件分至該版。因此在新聞中心模式下，我們只需要設立四個新聞中心，各對應兩個版；而在版面模式下，則設立八個新聞中心，各自對應一個版面，即能同時支援兩種不同組織架構模式。. 的稿件之情形。因此我們設計了「個人稿件管理」的功能。在個人稿件管理中，記者可以查閱並修改、管理所有自己所發表的稿件。因此不論記者的稿件被轉至任何新聞中心，仍然可以繼續採訪的工作，而不會被權限所限制。當主編認為有兩位記者所提交的稿件內容相近時，則可能採取併稿的方式，由兩位記者共同採訪同一則新聞。由於目前稿件只能屬於一個記者，因此在併稿時，主編會指定其中一人當主筆人，由主筆人以新增線索的方式來進行採訪的工作，而共同採訪之記者姓名則以附加在內文之中作紀錄。. 五、系統實作新聞供稿系統是以 Java JDK 1.4.2 為開發環境，使用者端的頁面呈現與邏輯使用 HTML 與 JavaScript 語言，後端則採用 Java Servlet、 JSP、Java Bean 搭配之 MVC 架構。網頁伺服器採用 Apache Tomcat 4.1，搭配 MySQL 資料庫。. (三) 審稿機制. 本節以下將介紹新聞產製的審稿流程，概要介紹供稿系統的主要功能。由於線索與稿件的審稿流程極其相似，我們將只以線索的審稿流程為例說明。. 由於稿件區中的稿件是以新聞中心當索引作為分類的依據，當記者的稿件被轉至其他新聞中心後，如果該記者不具備被轉入之新聞中心之記者權限，就會發生記者無法編輯自己發表. 圖十為供稿系統登入畫面，使用者輸入自己所屬的記者證號、密碼，並選擇欲登入的報刊期數之後，登入系統。登入之後會顯示所登入期數之相關資訊，包含線索與稿件的遲交期.

(6) 第二部分為記者區，主要功能包括個人線索管理、線索區（如圖十一）、個人稿件管理及稿件區。記者可以利用個人線索管理區新增線索，並提交新聞中心主任。另外，也可以利用線索區查閱當期所有已錄取的線索資訊；新聞中心主任也可以利用線索區列印新聞規劃單。. 圖十、系統登入畫面. 主編區之主要功能為線索管理與稿件管理，新聞中心主任可以利用線索管理功能來審核記者所提交之線索。圖十二為線索內容管理畫面，新聞中心主任可以利用線索內容管理，將記者的線索轉至其他新聞中心，或者對自己新聞中心的線索進行分版的動作；而總編輯也利用線索內容管理挑選當期的頭版稿件。圖十三為系統管理區的功能畫面，系統管理者可以在這邊處理新聞中心管理、版面管理、報別管理、討論區管理、使用者管理及角色管理。我們可以從使用者管理畫面中看到，系統並沒有直接設定使用者的權限，而是賦予使用者所扮演的角色，再由角色管理中設定每個角色擁有的權限。. 圖十一、線索區畫面. 在角色管理方面，我們將權限分成三個主要部分。第一部分屬於靜態的權限，大部分為功能方面的管理權限。第二部分則設定角色對於每個新聞中心所擁有的權限，第三部分則設定角色對於每個討論區看板的權限。第二及第三部分屬於動態權限，這邊的權限會隨著新聞中心和討論區的變動而有所調整。. 六、系統測試評估. 圖十二、線索管理畫面. 在供稿系統完成之後，我們邀請了 23 位修讀新聞系「數位媒體製作」課程的同學來參與測試評估的工作，這些同學大部分都有參與過大學報或了解大學報的編採流程，因此評估的結果具有一定的代表性。測試評估的流程為先由該課程助教示範供稿系統功能與操作流程；之後由同學分配扮演記者與新聞中心主任等角色，實際模擬採訪流程。受測同學完成系統各項功能操作後，填寫測試評估問卷，進行統計。在測試評估問卷中，我們分別就系統功能、使用者介面及使用者認知與態度進行調查，調查結果如下： (一) 系統功能. 圖十三、角色管理畫面限、截止日期等等。而畫面左方則依系統主要功能分為四種選單：系統區、記者區、主編區與系統管理區。系統區的主要功能為讓記者們互動交流用的公告及討論區，顯示系統與期數相關資訊，及使用者登出。. 系統功能主要是評估供稿系統是否能符合大學報新聞產製流程中的工作需求。表一為系統評估之結果統計，對於「線索區的功能是否符合記者報線的工作需求」與「稿件區功能是否符合報社交稿與核稿的工作需求」方面，大部分的同學都表示同意。由於部分同學並未參與大學報以新聞中心模式的新聞產製流程.

(7) 實際運作，因此在「系統是否符合新聞中心的設計」部分僅有 61%的同學表示同意，而有 26%的同學認為普通，4%的同學不同意，另外 9%的同學表示沒有意見；討論區則是系統功能中同學們比較不能適應的，在這方面將會列入系統修改實的考量。在新聞審稿的流程中，主編與記者間的互動是很重要的一環，有同學建議能查詢線上的記者名單，加強彼此間的聯繫。而記者採訪時常需要收集相關資料，因此也有同學建議能增加搜尋過期的線索與稿件的功能。表一、系統功能評估結果統計非常同同意意線索區功能是否符合需求稿件區功能是否符合需求系統是否符合新聞中心設計對討論區設計是否感到滿意. 普通. 不同意. 非常不同意. 不知道. 0% 78% 17% 4% 0% 0% 0% 78% 9% 13% 0% 0% 0% 61% 26% 4% 0% 9%. 想要的功能對系統的回應速度感到滿意系統操作很容易學習再次操作時能夠輕易上手系統經常出錯，讓人困擾. 13% 78%. 9%. 0%. 0% 0%. 13% 78%. 9%. 0%. 0% 0%. 17% 65% 17%. 0%. 0% 0%. 0%. (三) 使用者認知與態度使用者認知與態度主要是探知使用者對於供稿系統的觀點，確認同學們使用供稿系統的意願（詳見表三）。大多數的同學認為供稿系統能夠提升編採流程時的效率，但是仍然有些傳統新聞室的人工處理流程是無法完全被虛擬的供稿系統所取代的。尤其大學報除了普通的出版之外，還兼具了教學的目的，主編常常需要和記者們溝通，指導記者們如何採訪與稿件寫作等等。在溝通的觀點下，透過網頁導覽的供稿系統無法與面對面的直接溝通更方便，不過幾乎所有的同學都不排斥使用供稿系統。表三、使用者認知與態度評估結果統計. 4% 43% 43% 4% 4% 0%. 非常同意. (二) 使用者介面使用者介面主要讓同學評估供稿系統是否有友善的人機操作介面，表二為使用者介面評估結果統計。由於供稿系統的介面設計是採用網路上開放原始碼之套件做系統版面編排，大部分同學對於使用者介面感到滿意。但也因為該套件並不是專供新聞稿件產製流程所使用，因此在功能圖示上無法清楚表示各項功能的意涵，這點是造成比較多同學困擾的地方。多數同學認為重新設計一套能符合供稿系統功能說明的圖示，也有部分同學認為不同的功能區域間應該採用不同色調作為區分。表二、使用者介面評估結果統計非常不不同不同知非常同意同意普通意意道對系統版面配置感到滿意 4% 87% 4% 4% 對系統色調、字型感到滿意 13% 48% 30% 9% 可以清楚了解圖示的意涵 0% 30% 22% 43% 對系統的點選操作模式感到滿意 0% 48% 52% 0% 系統的分類結構非常清楚 4% 70% 22% 4% 很快就能找到 4% 48% 30% 17%. 0% 0% 0% 0% 4% 0%. 0% 0% 0% 0% 0% 0%. 4% 30% 52% 13% 0%. 系統有效縮短我在編輯室的時間系統有效縮短我的工作時數供稿系統在新聞處理上更有彈性許多傳統流程不適合用機器取代我比較喜歡面對面改稿以系統取代面對面改稿缺乏人情味傳統新聞室控制手段不適用於網路供稿系統與實體新聞室經驗相同我並不害怕使用這套系統. 同意. 普通. 不同意. 非常不同意. 不知道. 13% 70% 9% 0% 0% 9% 9% 61% 22% 4% 0% 4% 0% 87% 4% 9% 0% 0% 9% 48% 30% 4% 0% 9% 17% 30% 35% 4% 0% 13% 14% 27% 50% 0% 0% 9% 4% 22% 35% 22% 4% 13% 0% 9% 22% 48% 9% 13% 13% 78% 9% 0% 0% 0%. 七、結論與未來發展本研究針對大學報的新聞稿件產製流程做出系統分析，並且實際建置了一套內部供稿系統的雛型。這套供稿系統能夠符合平面報紙對於新聞守門的嚴謹態度，另外也兼顧了報社包括分版、併稿等審稿機制。對於大學報特殊.

(8) 的教學目的，這套供稿系統也能適應不同組織架構模式。. 1999. [2]. 陳百齡,“讓電腦也能辨識新聞：新聞內容標記問題初探”, 中華傳播學會 2002 年會論文, 2002.. [3]. 陳昶任,“跨平台整合之新聞流程管理系統”, 國立交通大學資訊科學系碩士論文 , 六月, 2003.. [4]. 曾俊豪,“以角色為基礎作網頁伺服器的存取控制之系統設計與實作”, 國立台灣大學資訊工程研究所碩士論文, 2000.. 目前的供稿系統仍是以文字記者為主軸，新聞照片、圖表則是以附加檔案的形式跟著文字稿件的審稿流程。未來應該特別針對新聞照片的部分，設計適合攝影記者的編採流程，並能與文字記者撰寫之稿件連結整合，才能夠保持整則新聞資訊的完整。在內部供稿系統趨於完善之後，就能繼續發展外部供稿系統，能夠將內部供稿系統中的新聞，依據不同的需求，提供適合的資訊給多種平台（如平面版的大學報、網路版的大學線上，甚至電子報、手機網站等不同形式的新聞媒體）。. [5]. 孫龍翔,“稿件產製流程自動化系統的設計與實作－大學報供稿系統”, 國立政治大學新聞研究所碩士論文, 2003.. [6]. H. Fagrell, K. Forsberg, and J. Sanneblad, “FieldWise: A Mobile Knowledge Manage-ment Architecture,” in Proceedings of CSCW’00, December 2-6, 2000.. [7]. K. Forsberg, “Mobile Newsmaking”, Licentiate Thesis, Department of Informatics, Göteborg University, Sweden, December, 2001.. 以電腦輔助的觀點來看，供稿系統也有許多有趣的議題值得繼續探討。包括記者撰寫稿件時，如何正確有效地幫助記者下關鍵字；在採訪過程中，有沒有更好的方法能幫記者收集相關資訊；如何幫助主編與記者在審稿與改稿階段的溝通，有沒有更好的互動機制等等，都是供稿系統未來的發展目標。. [8]. J.S. Park, R.S. Sandhu and G.J Ahn “Role-Based Access Control on the Web”, ACM Transactions on Information and System Security, Vol.4, No.1, February, 2001.. [9]. R.S. Sandhu, Edward J. Coyne, Hal L. Feinstein, and C. E. Youman, “Role-Based Ac-cess Control Model,” IEEE Computer, Vol.29, Number 2, February 1996.. 八、參考文獻. [10]. R.S. Sandhu, D. Ferraiolo, and R. Kuhn, “The NIST Model for Role-Based Access Con-trol: Towards A Unified Standard,” in Proceedings of ACM Workshop on RBAC, July 2000.. 測試評估的結果顯示，供稿系統大致上都夠符合實際採訪的需求，多數使用者也認為採用供稿系統能夠幫助記者提升編採過程中的效率。不過還是有些需要面對面溝通的部分是無法完全由供稿系統取代：在這部分，供稿系統只能當作是一種輔助的工具。同時也顯示了供稿系統在一些幫助記者間或主編與記者間的互動功能上，包含討論區的使用介面都還有加強之處。. [1]. 林頎堯,“電子報虛擬新聞室 Intranet 網路系統雛型建構－以交清電子報為例”, 國立交通大學傳播研究所碩士論文, 六月,.

(9)