上一篇簡單地介紹了研討會開放原始碼管理系統Open Conference System (以下簡稱OCS)，這篇我想來介紹一下我修改的地方。這次要介紹的是外表上的介面、翻譯、以及報名功能。另外還有OCS主要功能的投稿與審查功能，則留到下次再介紹。
(more...)由於最近幫空大社科系的2016社會變遷與當代議題研討會在架設研討會網站，所以找了網路上馳名已久的PKG系列系統之一的Open Conference System (我把它翻譯成「研討會開放原始碼管理系統」，以下簡稱OCS)。我把它拿回來進行大幅度的改造，並公開在GitHub上 (請到此下載)。。以下我想針對這個系統做個簡介。
很多人應該都有這個疑問，為什麼不要用普通的CMS，中文叫做內容管理系統(Content Management System)，像是Joomla、Drupal，或甚至是WordPress (儘管它是用來寫Blog用的，但很多的時候被人用做CMS)。
但是普通的CMS很難支援研討會複雜的處理流程。舉例來說，研討會會有摘要與全文兩階段投稿、多人匿名審查、審查意見與作者修正後再上傳檔案、以及審查結果公告等功能。我們必須對CMS做大量的修改、調整，才能讓它的處理流程支援研討會。因此，與其花費大量時間去將一個CMS調整成能夠支援研討會的系統，不如一開始就找一個能為研討會設計的系統，也就是本篇所介紹的OCS。
然而，我先把另一個很重要的問題說在前面：這些複雜的研討會流程，為什麼不要用email來處理就好了？這個問題問的非常好，這是一種人們對於資訊系統的迷思。
事實上，用email很好。主要的理由在於他是大家熟悉的工具，我們幾乎不需要額外的學習成本就能夠使用email。第二個理由是如果研討會規模不大，那麼信件來往勢必數量上也不會多，用email來管理就很足夠了。
那為什麼不要用email呢？這是因為人們會希望追求更省力的工作流程，但是往往卻忽略了學習成本這個問題。一個資訊系統「可以用」，與「好用」，這兩者之間的距離是用新臺幣來計算。而像是OCS這種開放原始碼的系統，只能夠稱得上可以用，但是距離一般人們心目中的好用，換句話說，就是客製化，則是相當困難的事情。
儘管如此，我還是為OCS做了相當大幅度的調整。不過先讓我們看一下OCS有什麼功能好了。
以下介紹來自於OCS的首頁：
OCS是一個開放自由的網頁發佈工具，專門用來建立學術研討會。OCS的特色如下：
為了研討會處理流程而設計的OCS相當的複雜。就使用角色來說，OCS裡面㑹可能會有以下七種角色(role)：
每一種角色可以使用的功能都不一樣，例如會議主席不能夠修改整個系統的網站標題，只有系統管理者可以進行這項動作。審查者可以為稿件提出接受/修改/拒絕的意見，但只有會議主席或是主題主席可以決定這個論文的最終結果。
多種不同的角色與複雜的流程造成OCS的高度複雜性。這對許多只是想要架一個「簡單網站」的學者來說，簡直是無法想像的程度。
這麼複雜的流程有辦法簡化嗎？老實說，如果要辦一個大型研討會，那就的確是要如此複雜的分工。我目前先做一些小功能來連結前台顯示內容與後台的設定欄位：有筆的圖示按鈕。在使用者擁有相對應的權限時，系統會在公告、議程等我修改過的位置上顯示這個按鈕，點選後就能夠直接跳掉相對應的後台欄位中。這個應急之道是給那些懶得去後台翻設定的使用者使用，但相對於OCS的高度複雜來說，只是杯水車薪。
OCS並不是單純的CMS，其中一個特色就是對於灰色文獻(gray literature)問題的處理。什麼是灰色文獻呢？灰色文獻的意思是指在資訊傳播過程中所存在但難以被搜尋、取得的資訊。研討會上發表的論文就是一種很常見的灰色文獻。
大部分研討會上發表的論文並沒有正式出版。常見的情況中，研討會的會議論文集(proceeding)並不會像一般書籍一樣作成一本書、申請ISBN、遵照法定送存規定一樣地送往國家圖書館保存，而通常只是將研討會中所發表的論文作成一本會議手冊──有些研討會手冊裡面甚至連全文都沒有、只有投影片──然後只有參與研討會的與會者才拿得到。這樣的結果造成雖然有研討會論文的存在，但是一般人卻只能知道有這篇文章發表在研討會中，卻難以得到文章的內文，這就是灰色文獻的問題。
OCS不僅只是研討會網站，它本身也是資料典藏系統，可以讓其他人輕易取得在OCS上發佈的論文。從設定上可以看到，它提供了OAI-PMH的資料交換功能，可以作為資料提供者(data provider)讓其他資料獲取者(data harvester)來取得資料，像是PKP另一個系統Open Harvester Systems。同時它也可以為發佈的論文加上數位物件識別碼DOI (Digital Object Idenifier System)，方便學術論文的引用與取得。
然而現在學術傳播環境中，研討會論文是否要公開的這個問題，其實並沒有定論。有些研討會並不是難以負擔出版成本而不將會議論文出版，而是遵照作者的意願而不公開作者在研討會發表的論文。有人可能會覺得奇怪：如果發表的論文不出版的話，那豈不是違反學術傳播的目的了嗎？這是因為許多作者會在研討會跟期刊上發表同一主題的論文，而通常研討會上只是初步的成果、期刊則會是較完整的內容。為了避免期刊的主編或審查者搜尋到作者之前發表的研討會論文而造成一稿多投的誤解，所以許多作者寧願選擇在研討會不公開他的論文，而是在期刊上刊出較完整的結果。當然，我不否認也會有真的是一稿多投：研討會跟期刊的內容幾乎一樣的問題，但這不是本文的重點。
回到OCS來看，它試圖解決灰色文獻問題的方式是否能為現在學術研討㑹所接受，我想仍需要一段時間來觀察。但我能夠確定的是，在處理OCS的如何公開論文之前，光是OCS複雜的設定就已經讓一堆不懂資訊系統的學者舉白旗投降了吧。
如果你也想要來架設OCS看看的話，可以從我的GitHub上取得我目前修改的進度：
秉持著開放原始碼的精神，既然從開放原始碼的系統取得了OCS，我當然也很樂意與大家分享我作的系統。但是必須事先聲明的是，這是一個不完整的系統。因為我是一邊安裝一邊修改，直到最後才順利讓它勉強可以運作。我並沒有要讓它做到可以讓人從無到有地順利架設，只要能夠支援現在研討會運作就好了。
另一方面，我的OCS目前僅支援線上全文審查的功能，還沒有去修改它的摘要/全文二階段審查功能。這可能是要到年中的時候才會去處理的問題，現在就先擱著了。
總之，歡迎大家拿取我修改過的程式碼來作進一步開發，有問題歡迎底下提問，或是用GitHub的Issues功能提問都可以。接下來幾篇我想跟大家聊聊我這個OCS改了什麼東西，慢慢來寫吧。
(more...)這篇是給想要整合ORCID的系統採用的方案。除了以ORCID建議的方式來設計OAuth登入功能，我還用bookmarklet來製作信任託管授權功能。
現在很多系統都想要整合ORCID，但是大部分系統的整合方式都只是提供一個輸入框，要作者自行註冊再自己複製ORCID編號。可是現在已經是OAuth的時代，我們可以採用ORCID建議的三方登入來建置登入按鈕。
有注意到上面這張圖裡面顯示的「布丁布丁吃什麼？」要求取得登入訊息的資訊嗎？這個方法很簡單，不必動到任何伺服器端的程式碼，只要用JavaScript在前端執行就能夠搞定。
以下介紹如果在尚未登入ORCID，也沒有註冊ORCID的情況下使用此方案的過程。
這個方案是為了整合既有的系統。系統通常會有Email的輸入框，也會有ORCID ID的輸入框。
如果有加入布丁式ORCID整合方案，就會變成上面的樣子。
按下「建立或連接ORCID ID」會跳出要求ORCID登入畫面。你也可以在該畫面的「Don't have an ORCID iD? Register.」切換成註冊畫面。
登入成功之後，該視窗會關閉，然後原本的視窗中會抓到登入之後的ORCID ID。
接下來我們要加入信任託管的授權。
請照著下面的指示，把「授權政大」(這個按鈕的字可以自訂)拖曳到書籤列。
書籤多了一個「授權政大」了。
然後按下「開啟設定頁面」按鈕。
開啟了ORCID的帳號管理頁面。
點下書籤列上的「授權政大」按鈕。
接下來會跳出一個對話框，因為授權需要密碼，請輸入您ORCID的密碼。
授權成功，會跳出即將關閉視窗的訊息。
這樣就授權完成了。擁有授權的一方就可以用信任託管的方式幫忙建置ORCID的資料，做法請看我之前寫的「以機構身份管理其他研究者的著作：ORCID的信任託管功能」。
接下來我要來說明如何安裝布丁式ORCID整合方案。這是給網頁工程師看得部分，如果你看不懂，那也別在意。
首先，我們會有一個系統表單網頁的網址，此例中的網址為「http://your-server/form.html」(會在後面用到)，以及該網頁的原始HTML碼。例如：
<input type="text" name="email" value="" />
<input type="text" name="orcid_id" /> 然後我們要底下加入以下程式碼：
<script type="text/javascript" src="https://googledrive.com/host/0B3_qgRmbvvZ1RmhGYmVFeTExblU"></script>
<script type="text/javascript">
ORCID_puli_utils.init({
inputs: {
email: "[name='email']",
orcid_id: "[name='orcid_id']"
},
app: {
client_id: "APP-xxxxxxxxxxxxxxxx",
client_secret: "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx",
redirect_uri: "http://your-server/form.html",
},
employment: {
orcid: "0000-0002-5496-8565",
disambiguated_id: 32787,
source_id: 34913,
keyword: "National Chengchi University",
},
message: {
connect_button: "建立或連接ORCID ID",
bookmarklet: "授權政大",
bookmarklet_usage: "請拖曳上面授權按鈕到書籤列<br /><img src='https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEh9IFr0Z9Qu-JIR3vi2UFkfW5mZdy9WgzKo1FIl7qU6nuoze36JOmBxutZ0eiOcjnzrSUduGXpWoAXiU5qoJvkDd56Abts2y91UFFcOjw5apmyUy4GwFskZ-LF4LY5oZPgu3npi_Q/' style='border:1px gray solid' />",
open_account: "開啟設定頁面",
open_bookmarket: "請點選授權按鈕。<br /><img src='https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjLbMa53HgWhdm1Lq4mOD-SRzkMmF55D6SwTOiBKR3MPqq2L0pgxK9T6jtuiZgJxwas2tXY3Sj52HIXcxw5qvA5O58JhwBZ2gwzatVJ18iETssbgtYrvty7bZ6GlHAP9jFbS93wJg/' style='border:1px gray solid' />",
input_password: "請輸入您的密碼 <br /><img src='https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhtNZ37lCN_qWYT5TUjW8ul6VsiDJx5_cxv4yY7CNOqc_OLboP_TsSNiDgXbNR7EHYnq7QmtLlxOYLpW7no-JNQjfcHyfPz8UBmac1A_MWVFoUK-e511ryaXnd5uP_2lIDy5KtUww/' style='border:1px gray solid' />",
prompt_hint: "請輸入您的密碼",
prompt_error: "密碼錯誤，請再次輸入您的密碼",
alert_success: "授權成功，視窗即將關閉。",
delegated: "已經授權"
}
});
</script> 這邊總共有3處參數需要設定，我用顏色標示，各別是綠色的信任託管對象、藍色的Public API設定、紅色的機構資訊、紫色的授權按鈕。這些資料取得的方式不一，以下一一說明：
首先，我們先要有一個代表機構的公用ORCID帳號。這個帳號就算不是ORCID的機構會員也無所謂，用一般的方式免費註冊一個ORCID的帳號就可以了。
註冊之後，你就會獲得一個ORCID ID。我註冊了一個測試用的ORCID帳號，ORCID ID就是「0000-0002-5496-8565」。
接下來我們要設定供網站登入用的Public API。這邊要設定三個參數： 1. client_id、2. client_secret、3. redirect_uri。這三個參數都必須在ORCID網站上的開發者工具裡面設定。
點下開發者工具頁面中間的「Register for the free ORCID public API」。
確認接受條款。
然後設定你的網站資訊，包括網站名稱(Name of your application)、網站網址(Your website URL)、網站介紹(Description of your application)、返回網址(Redirect URIs)。比較需要說明的是返回網址，請設定系統表單網頁的網址，此例就是「http://your-server/form.html」。然後按下右下角的磁片按鈕來儲存。
儲存之後會回到原本的開發者工具頁面，按下「Show Details」來顯示詳細訊息。
這邊可以找到Public API所需要的三項參數。在Redirect URIs裡面找到返回網址redirect_uri參數；在Client ID找到client_id參數，開頭會是「APP-」；在Client secret可以找到client_secret參數。(一般是不能公開這個參數)
這樣子Public API所需要的參數就設定完了。
接下來是機構資訊的設定。這邊有三個參數要設定，以政大為例：
1. disambiguated_id: 32787
2. source_id: 34913
3. keyword: “National Chengchi University”，這一項可以自行設定。
機構的disambiguated_id跟source_id是比較難以取得的參數，以下說明如何使用Google Chrome瀏覽器來取得機構的這兩種參數。
首先我們要進入到你自己的ORCID頁面，然後在Employment裡面進入「+ Add employment」裡面的「+ Add manually」。
同時開啟Google Chrome的偵錯面板，切換到Network分頁。
在Institution/employer中輸入資訊時，就會自動帶出機構的資料。找到我們目標的機構，例如國立政治大學就是「National Chengchi University」。
點下「National Chengchi University」的時候，注意Network分頁讀取資料的網址，有個「32787?_=1437762980098」，其中32787就是disambiguated_id。
新增機構之後，Network分頁中會讀取一個叫做「affiliation.json」的檔案。點進去看該檔案的細節。
在Request Payload裡面找到disambiguatedAffiliationSourceId: “34913”，其中34913就是 source_id。
雖然過程有點麻煩，但這樣子就設定完機構的參數了。
最後是「授權政大」的按鈕。這個按鈕可以任意修改文字訊息。事實上，message裡面的資料都可以任意修改，不會影響布丁式ORCID整合方案的運作。但是修改時必須遵照JSON的格式就是了。
布丁式ORCID整合方案終歸來說只是一種暫時使用的權宜之計，特別適合不想要花錢買一個系統來管理ORCID（因為ORCID網頁本身就很好操作了，實際上不太需要額外買一個系統來管理）、也不想要花錢加入機構會員（因為機構會員的Member API一樣要額外的系統才能運作）的機構。
ORCID是一個稱職的OAuth系統，可說是學術界的Google Account一樣。可是它作為著作目錄權威檔的角色來說，本身有很多問題在，詳細可以看我之前寫的「令人意外！ORCID目前並沒有自動跟資料庫同步」。對於ORCID，除了註冊帳號之外，目前似乎並沒有深入建置資料的必要性就是了。
(more...)這一篇是為編碼結果與序列分析工具之間的資料轉換工具。因為我們通常都是用Google試算表或是Excel類型的工具來做編碼，可是序列分析工具卻輸入需要一連串的文字，因此我製作一個轉換工具來介接兩者。
我寫了一個線上計算Cohen Kappa係數的工具。本文簡單介紹編碼者間一致性信度與操作教學。
William M.K. Trochim這張圖傳神地描繪出編碼者間一致性的問題。兩位編碼者(coder)，或著說是觀察者(observer) (註1)，在分析與觀察同一件物品或現象時，兩個人的觀點可能會不太一樣。
註1：因為現在觀察大多是交給機器錄影或錄音，較無觀察偏見的問題。主要會受到人為影響的部分則是分析這些錄影與訪談的資料，而分析質性資料將之給與概念化標籤的方法稱之為「編碼」，進行編碼的研究者也就是「編碼者」。
如果兩人編碼結果相差很大，那表示研究者的分析方式不夠客觀、帶有嚴重偏頗。如果兩人編碼結果相同，那表示這是一個很穩定、具有足夠信度、可以重複使用的編碼方法。
因此現在的研究方法中會要求質性編碼要以兩位以上研究者來進行編碼，並利用統計來計算編碼者之間的一致性信度。
依據資料類型的不同，一致性信度有很多種計算方式。在此介紹的是適用於名義尺度資料類型的Cohen Kappa係數計算方法。名義尺度的意思是資料編碼本身只是一個「代號」，代號與代號之間並沒有順序、間隔、比例的關係。Cohen Kappa係數只看有多少個編碼，兩個人之間的編碼相符的比例為何。由於Cohen Kappa排除了編碼者亂填的隨機性，因此比單純的相符百分比還來得可信。
Kappa係數介於-1 ~ 1之間。一般來說，能達到0.8以上是很棒的結果，但通常達到0.6~0.8就可以發表了。至於0.6以下，則是建議你們兩位編碼者再討論一下編碼方法，有更多共識之後再來重編一次吧。
| Kappa係數 | 一致性程度 |
| < 0.4 | 差 |
| 0.4 ~ 0.6 | 一般 |
| 0.6 ~ 0.8 | 好 |
| > 0.8 | 極佳 |
我做了CKEditor的插件Recordmp3js，這是以HTML5的新功能為基礎，建構在Recordmp3js專案上實作的插件。以下介紹這個套件的功能。
I developed a CKEditor pluing: Recordmp3js. This is based on HTML5 audio function and Recordmp3js project. You can use Recordmp3js plugin to record voice in CKEditor. This article introduce Recordmp3js and some development memo.
recordmp3js的特色如下：
安裝說明請看專案的README。
安裝好之後會看到一個麥克風的圖示
開啟視窗之後，要先按瀏覽器的「允許」麥克風。
然後主要操作介面才能正常啟用。左邊是錄音的按鈕，右邊是音量的顯示器，未開始錄音時是以單色顯示。讓我們按下錄音按鈕。
開始錄音。你可以看到限制錄音時間，右邊的音量顯示器變成彩色了。
停止錄音之後，要等待系統轉檔與上傳。大致上錄音1分鐘就需要1分鐘轉檔。
轉檔完成，下面會出現音樂播放界面。按下音樂下載圖示則可以下載錄音檔MP3
按下「確定」之後，就可以在編輯器內插入<audio>標籤了。
其實前一篇開發的PHP File Host專案是為了保存這篇的錄音檔而開發，規劃上是最後才實作。不過真的摸到Recordmp3js之後，才發現原來保存二進位MP3檔案的方式竟然是用Base64編碼！
Base64編碼是一種將二進位檔案以字串的方式編碼的方法。一般HTML網頁是以純文字的方式保存，因此網頁上面的圖片、聲音檔案等二進位資料通常是另外儲存，再以<img>、<audio>標籤嵌入到HTML網頁中。可是這個動作是撰寫HTML網頁初學者的第一個難關：為什麼網頁跟圖片要分開儲存？這也造成了複製網頁檔案的困難，不能只有複製HTML網頁檔案本身，還得複製相關使用的二進位圖片檔案。
Base64編碼可以讓圖片以字串的方式保存在HTML網頁中，而不需要額外保存一個檔案。我以前也介紹過以Base64編碼保存圖片這件事情。在寫這個Recordmp3js插件時，也因為覺得還要另外找地方插入麥克風圖示很麻煩，所以直接用Base64編碼的圖片來插入。可是我還真沒想到原來Recordmp3js的MP3聲音檔案也是用Base64來儲存！
以前只是單純地使用Base64編碼的檔案，但是到這時候我才意識到Base64的麻煩之處。一般是使用file類型表單欄位來上傳檔案，例如：
<input type=”file” name=”file” />
但是由於Base64編碼是字串資料形態，所以用普通的text類型表單欄位來遞交：
<input type=”text” name=”file” />
這兩者的name雖然都是file，但是對伺服器來說卻是不一樣的。在PHP當中前者是要用$_FILES[“file”]來取用、後者是要用$_POST[“file”]。此外，由於Base64編碼並沒有指定檔案名稱，所以還需要用另一個text欄位來傳送檔案名稱。
而即使Base64編碼是字串形式，也不能用JSONP的方式來做跨網域傳輸。因為JSONP實際上是將資料輸入在網址上，而Base64編碼的結果通常很容易超過網址的2083字元限制。
這造成我得改寫PHP File Host的檔案接收方式，又花了我一番功夫。到最後索性乾脆讓Recordmp3js預設使用Base64編碼來儲存，讓PHP File Host變成選擇性支援。雖然這會造成插入CKEditor的資料變得超級長，但不需要額外架設伺服器保存MP3檔案這點還是蠻容易讓人使用的。
一開始研究HTML5錄音功能時，最讓我困擾的地方在於HTML5預設的錄音結果是WAVE格式。WAVE是沒有壓縮的聲音檔案，因此聲音檔案的大小非常大，讓我難以直接使用HTML5的錄音功能來儲存錄音檔案。
本來還在考慮是否要在PHP File Host加上檔案轉檔功能，在上傳檔案之後轉檔成MP3或amr格式。可是後來意外發現Recordmp3js居然在Recorderjs專案之上加上了MP3轉檔libmp3lame.js的功能，讓MP3轉檔的工作直接就在客戶端瀏覽器上完成。這真的是太方便了。
當然，對很多網頁開發者來說，這是風險很高的事情。因為客戶端使用的瀏覽器跟電腦效能不一，因此完全不能寄望IE6或是在行動裝置上的瀏覽器能夠正常執行。我剛剛拿了Android的Chrome跟Firefox來玩玩看，的確是無法開啟。
不過我的應用場景比較特殊，我可以要求使用者以Chrome或Firefox來使用我的系統，這個顧慮就暫時不在我的考量之中。
這也讓我想到是否可能用更有效率的amr格式來為語音聲音檔案編碼，赫然發現GitHub上的確有amr.js專案，真是厲害。然而選用編碼格式也要顧慮到瀏覽器的支援，根據w3schools.com的HTLM5 Audio介紹，<audio>標籤只支援MP3、Wav跟Ogg格式，大部分瀏覽器都支援MP3，除了Opera。支援細節如下：
| Browser | MP3 | Wav | Ogg |
|---|---|---|---|
| Internet Explorer | YES | NO | NO |
| Chrome | YES | YES | YES |
| Firefox | YES | YES | YES |
| Safari | YES | YES | NO |
| Opera | NO | YES | YES |
Recorderjs將HTML5的錄音元件包裝的非常好用，但是實際上使用之前，還是需要經過非常多的設定。你可以看看Recordmp3js的範例網頁程式碼，JavaScript設定那邊就一長串了，一開始研究的時候還真讓人感到困擾。Recordermp3js也具備了錄音完成之後上傳的功能，可是這功能卻寫死在Recordmp3js檔案裡面，而非開放設定的功能，讓我到最後還跑到Recordmp3js裡面去研究，也花了不少功夫。
在研究的過程中，越來越覺得audio真是有趣的應用。藉由結合多個音訊來源，我們可以動態控制各種聲音播放，就可以自行製作各種樂器。Web Audio Demos展示了很多聲音的應用，Web Audio Vocoder是其中一種強調混音的功能，這激起了很多不同應用的可能性。而我則是參考了AudioRecorer華麗的音量顯示器，做到Recordmp3js當中，讓錄音介面感覺漂亮一點。
使用HTML5錄音跟MP3轉檔時，Recordmp3js都使用到了HTML5新元件Worker。一般來說，這個Worker必須是獨立的JavaScript程式碼，而且受限於同網域下執行的安全性問題。在跨網域應用中，這是一個很大的門檻。
但是我參考使用web workers這篇文章的說明，撰寫了worker_manger.js，將worker要執行的程式碼事先插入到目標網頁中，然後在以該網頁上的worker程式碼作為worker物件執行，就能夠保持在同網域執行的限制，迴避跨網域的問題。
雖然這個小功能我只用了很短的時間來做，但其實應該對很多人來說是很重要的功能吧？有機會再來正式發佈好了。
使用HTML5錄音元件的另一個重點在於「允許」錄音檔案的事件。實際上啟用Recordmp3js的時候，跟HTML5元件宣告我要使用麥克風的時候，不是所有的瀏覽器就會跳出提示問你要不要啟用麥克風。
Firefox會在使用時直接跳出是否允許啟用，一個網頁只會問一次，Chrome有些版本也是如此。但是我電腦的Chrome卻不會在Recordmp3js載入時跳出來詢問，而是要離開網頁、再回到網頁時才會詢問。我索性加入一個<iframe>標籤，讓網頁觸發讀取事件，好讓Chrome問我要不要允許使用麥克風。但是離開網頁又回來時，Chrome還是會問我要不要允許麥克風，還好這動作也只要問一次而已。
很多使用者應該會忘記做「允許」麥克風這個動作。Chrome跟Firefox的介面都不太容易讓人理解，我可以預期這個動作應該是最讓人感到困擾的地方吧。
至於播放介面，我就直接使用HTML5的<audio>標籤。雖然<audio>標籤提供了播放/暫停、時間、播放進度條、聲音控制等功能，但是各個瀏覽器上<audio>長得都不太一樣，因此網路上大多建議是自行重寫<audio>的操作介面。但想到這個<audio>是要插入到CKEditor當中使用，寫得太複雜也不利於編輯。所以我還是選用最基本的<audio>標籤來顯示。
最後來講講CKEditor插件的開發。
一開始我是看为CKEditor在线编辑器增加一个自定义插件這篇，一步一步來實際操作看看。但是做到最後並沒有如期地做出可以用的CKEditor插件。我也去翻了CKEditor的Plugin教學跟它的API，但後來還是覺得乾脆直接複製既有的Plugin開始做起好了，所以就打開被壓縮的程式碼來看，直接從可以運作的功能中找尋我需要的程式片段。
雖然並不是什麼正規的學習方式，但這樣也在一片混亂中寫完了這個插件。有多混亂呢，看看插件的程式碼就知道了orz
總之最後還是完成了，也發佈到CKEditor的Add-on頁面去，也算是對這份研究有個交待啦！
話說回來，一開始會全部都重頭製作的原因就是因為在CKEditor與TinyMCE上找不到這種錄音的插件。現在我可以用這種方式來製作錄音插件的話，那其實像是webcam拍照與錄影等各種應用應該都沒問題才是。有機會再來研究看看吧。
(more...)
Comments