後台？有就好了嗎？

常常接觸網站管理的朋友應該都對 CMS （內容管理系統 Content Management System）不會太陌生，以目前網路的發展應用來說，架設一個完全靜態、沒有後台上資料的網站真的是非常不 Fashion！

舉凡 Blog、微網誌、論壇、Facebook 都可以算是一種內容管理的系統。如果你的網站沒有程式架構作為基礎的後台，要更新內容、發佈資料也都會變得非常的麻煩。

那麼，後台是有了就好了嗎？

當然不是，好的後台能夠符合操作者、終端使用者的操作習慣，令人方便使用，功能以及使用者介面的設計、配置也都必須因應前台的設計做相對的調整，更要設計出貼近真實使用狀況的「使用者行為路徑（User Interactive Path）」以及良好的統一樣式規範。

今年各家網路龍頭都紛紛推出自己的社群功能，想盡辦法拉攏用戶；這些網站、應用服務幾乎每天都在悄悄的改進他們的介面、流程讓實際的使用者有更好的「體驗」，這都大大的凸顯了管理、使用介面的重要性。

同時，回頭來看看一般機關、企業、甚至是小型網站所選用的後台系統時，卻好像發生了時光倒流；這些以往強調安全性、擴充性良好的後台，操作介面卻都如此的老舊、復古，難道安全性、功能性與美觀、易用性、體驗無法並存嗎？

一個好的後台管理系統，必須兼備許多的條件，從程式架構、資料安全性、運作效能、資訊架構、設計到使用者的體驗缺一不可。

我們最近在開發全新的後台評估會議中，就針對了「後台 / CMS」這個主題做了許多有趣的討論，同事們也都熱烈的攻防許多延伸的議題，在這分享參考：

一般來說，開放源碼的 CMS 平台開發有著「讓越多人使用越好」的考量，因此普遍會有許多一般使用者所用不到或是不需要的欄位；程式架構也是考量龐大使用者而設定，幾乎都是模組化的一體成形；功能操作也由開發人員撰寫程式時就設定完成。

使用者只能按照原有的功能去「適應」，即便使用上有所不便也只能自我安慰的使用下去(用免費的實際上也不能說甚麼了)。開放源碼的 CMS 大多可以透過程式編修而改為使用者所需，但所有架構的成形皆環環相扣且龐雜，若經由修正而達到使用者所需，需要花上長時間了解原始碼的各項功能，並了解修正後各個環節是否會有所衝突；比起從零開始撰寫屬於自己的程式是有可能花上三、五倍的時間。

另外「是否符合需求、操作是否方便、使用穩定性、安全機制」為外掛程式選用的基本考量。由於任何人都可取得開放原始碼，因此有心人士是可輕易地分析弱點，進而入侵網站對於使用者資料庫造成威脅，再者，原始碼的開發者無預警停止更新、新增或是刪除指示元件，使用者必須自己更新升級或是想出其他的解決方案；模組化的軟體，由於組成的細節龐大因此每個元件銜接處都可能會有漏洞可鑽，因此使用開放 CMS 的安全性於這個環節上備受考驗。

所以我們要用獨立開發的 CMS 系統嗎？

完全客製化的CMS 可讓企業掌握各項所需，對內可規畫出專屬企業的界面、操作流程皆可自行決定，結構單純，維護方便。

最重要是系統安全的掌握，客製 CMS 可以架構縝密且完整，雖然可能造成佈署的步驟繁瑣，但安裝建構並不是經常要進行的。而開源碼專案實作的原始碼公開之因讓加密機制安全度降低，例如任何人都可得知資料加密的演算法來進行反解，而當今一般民用普遍的MD5與SHA1演算法都已被證實可反解成不到十個，總有一個會正確的結果。開源碼專案可以直接知道演算法，而客製系統得先從用甚麼演算法開始測試。且為了安裝方便而對一些綁著作業系統的安全機制直接犧牲掉。無法像客製型之封閉 CMS 可達到安全的防禦。雖客製型 CMS 開發時間較長，須花較多時間撰寫程式，若在開發人員有足夠水準的前提下，功能、效能、安全、操作方式都皆能達到較嚴苛的需求。

客製化系統 V.S. 開源碼系統孰優孰劣？

這問題並沒有標準答案，實際上參與開源碼系統開發的人員，程式開發素質都會在一般水準之上。光是模組化的結構如何去適應，並與其他人的程式能相互運行，在軟體工程裡並不容易。所以實際上較為成熟的專案，整體安全性會遠比菜鳥程式設計師要高。但反過來說，頂尖高手開發的客製系統可以用更強固多層的安全機制（開源碼專案的參與人員通常也都是各家軟體公司的菁英，大多也以程式設計師為業），但遇上對於安全性不重視，或是欠缺經驗的程式設計師，那就是災難了。假若，同時有成熟的團隊可以進行開發，也有適當的開源碼專案可以選擇，那會建議以以下幾項原則做C/P 值與邊際效應考量：

開發佈署時間、可維護性、使用者便利性、功能整合性、客製化可能性與程度，以及最重要的───經費成本。

天下沒有完美的系統，但不代表系統應該很醜，或複雜，或難用

然而獨立開發的 CMS 系統卻大多長相醜陋，完全按照功能的架構去製作頁面；例如：公家機關的新聞、消息上稿系統，買賣用的購物商城系統等等，許多都是非常不人性化，僅僅為了功能而存在。

在早年，程式設計師的培訓裡，是根本沒有「使用者經驗」這一項的。基本上都只教育怎麼把功能寫出來，或是說程式設計師已經把絕多的心神放在功能核心上了。但若說某個功能裡包含了一百項作業，可以讓使用者只做一項，其他都給系統做，當然，也可以反過來。若是系統的架構不夠彈性，操作介面就會直接影響到運作的核心。在這種情況下，程式設計師一樣在有限的時間資源內，自然會把使用者能做的事情都丟給使用者去做。

而今，網路服務的龍頭們開始正視使用者經驗，而不只是互動網頁的開發先鋒們孤軍奮戰了。除非是殺手級應用，不然決勝負的關鍵就在使用者經驗。再者，世間也沒有永恆的殺手級應用，因此如何能忽略使用者經驗呢？

因此我們在評估討論獨立開發的 CMS 時，即把使用者流程、設計納入考量的範圍，從一開始的功能、架構就加入使用者最終使用時的「體驗」來當做規格的條件之一。讓「技術程式」以及「設計體驗」並重，這樣才能完整的設計出一套實用、直覺、舒爽的後台管理系統。

【圖片來源：engisystem、amplusmarketing】