常常接觸網站管理的朋友應該都對 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 時,即把使用者流程、設計納入考量的範圍,從一開始的功能、架構就加入使用者最終使用時的「體驗」來當做規格的條件之一。讓「技術程式」以及「設計體驗」並重,這樣才能完整的設計出一套實用、直覺、舒爽的後台管理系統。

【圖片來源:engisystemamplusmarketing

 

  • David Chuang

    應該要先釐清「管理後台」所擔負的責任,「管理後台」應該是讓網站經營者能夠容易且無痛的操作各項網站前台元素所需的功能管理。

    文中所謂公家機關的新聞上稿系統、購物商城的管理系統;雖達不到美觀或甚至是文中所形容的醜陋,但卻是穩定的系統。

    我認為「管理後台」不應以「使用者經驗」作為訴求,而應以「穩定清楚」作為主要的任務。許多網站經營者並不若我們為重度網路使用者,甚至通常都是由平常的職員們推選貌似對電腦較為熟悉的人員兼任。過多的AJAX特效或是美觀到嚇人的UI,對於這些管理人員並沒有幫助。

    「我每天都要看有沒有訂單,可不可以獨立把這個功能放到我一下就可以看到的地方?」「可以把字放大嗎?我有老花看不清楚」「為什麼我用IE6看起來跟你們給我的畫面不太一樣?」相信曾經執行過公家機關或是中小企業網站的同仁都會遇到這樣的需求,但,這卻是他們最基本要求。

    業主對於「管理後台」的「使用者經驗」的要求絕對遠遠低於前台的華麗,「管理後台」的安全性也不應該以是否為開放源碼的CMS為評斷標準;「管理後台」可以不public,可以設定使之內部人員或固定ip方可連接;假設放在public可以讓眾人去測試登入,怎麼說也都不安全是吧。

    http://blog.phimedia.tv/wp-admin/

    • 其實文章還有要說的是「前後台的界線已經越來越模糊了」如果管理、操作介面不重要的話,那為什麼大家要選擇較好的網站、工具呢?

      • 訪客

        前後台的確已經越來越模糊,很多的服務都已經是「後台」、「用戶編輯區(小後台)」、「前台」的概念。

    • Topias Tsui

      「讓網站經營者能夠容易且無痛的操作各項網站前台元素所需的功能管理」
      我的看法是,這就是極其重要的使用者經驗。而且,並不會遠遠低於前台的使用。

      • 訪客

        的確是,「容易」才是最難的。而且通常很樸實

  • 羅智華

    這問題並沒有標準答案

    • 訪客

      所以才列出了幾個考量點囉

  • 訪客

    您好,所謂的「穩定清楚」,其實也是使用者經驗的一部分。我想我們都同意,一套系統絕對以安全穩定優先,但這不代表使用者經驗該被犧牲。我們以比較淺的程式面看,從Web1.0到Ajax時代。的確,平添許多隱憂,但這些並非不可防禦。所以原罪應該不是在Ajax身上。而是因為諸多理由,解決以上隱憂也是其中之一,而把優使性給犧牲了。

    另外關於開源碼的安全問題,我有提到,就程式架構方面,它通常比較安全。但,就系統架構上,因為簡化安裝流程與公開加密演算法的關係,而讓可利用系統綁定或是加密的安全性大幅降低。當然,這可以改,只是改了之後不曉得有多少外掛會受波及(通常用開源碼專案的用戶,都會使用外掛),就更別說未來的更新版本能否相容。

    以一個開發人員來講,必須假想人都是邪惡的,無論是駭客、一般使用者甚至是自家員工。以IP或是VPN限制,基本上防君子不防小人,另外若這是個公開服務(例如你就是個架站系統的業者),做這些限制基本上服務就不用營運了。安全是個牽扯極多方面的議題,我們這次主要聚焦在於您進行開發,或選用開源碼程式,通常都是基於某個理由(例如某個外掛十分好用,或某個功能真的沒開源碼可用)。而在這個理由之下,再去談其延伸的安全問題。

    您可採用其中一方,或是混搭性的進行改造,但沒有一支程式能永保安全(有時會是編譯器、伺服服務或是一些離奇的可能性),勢必要持續的升級,而這升級好不好做,甚至能不能做,在開源碼世界會不會變成您得自行維護的分支,這都是需要考量的。