2010年11月21日 星期日

網站定位對使用性的影響

前陣子讀《Don't make me think》提到, 網站設計的最高原則就是 --- 別讓使用者思考如何用, 這意味著網站頁面必須有明確的進入點, 頁面上任何元件都要能自我解讀。所以, 複雜的產品通常不是好主意。

今天剛好看到YUI3設計中的激進和妥協裡的評論提到:
前端開發這個行業的產生時間本來就很短,相比傳統的企業級的應用軟件開發是相當的初級的,本質原因是因為web開發的複雜程度遠不如ERP,我在實習的時候參加過一些ERP的開發,光一個訂單管理的小模塊所需要的報表就有成百上千個……我們可以說J2EE艱辛慘淡,但絕不會死,而且會在更加專業和尖端的企業開發中有著更加旺盛的生命力。
因此框架一定是在業務複雜到一定程度後的必然選擇,這是無可迴避的。 問題是,web產品的使用者不是受過良好培訓的業務員、不是企業管理者、不是操作員和工程師,而是千千萬萬傻乎乎的初等網民,網民水平不提升,我們甚至不敢做出太複雜的產品,那麼……
讓我有這樣的想法, 公司內部用的網站是個工具, 公司不用擔心使用者看不懂怎麼用而拒絕使用, 公司可以藉由「教育使用者」而大幅減少網站設計的難度和開發時間。另一個相似的例子是, 網站只是協助服務的工具, 使用者不會因網站難用而拒用這個服務。比方說年代售票難用到爆炸, 但若只有這個購票方式時, 也只好繼續使用。而年代售票唯一要確定的事, 是線上刷卡這段有做好, 不能算錯帳。只要這點沒出包, 那怕大刺刺地寫著「請等個數十秒」的訊息, 使用者也得乖乖等待。

但若網站本身就是核心服務, 像是相簿、Blog、書籤、搜尋、入口網站這類服務, 就要仔細分析和改進使用性。這算是從另一個角度來解讀網站使用性的重要程度吧, 世上沒有絕對重要的事, 什麼事都要看情況決定。

1 則留言:

在 Fedora 下裝 id-utils

Fedora 似乎因為執行檔撞名,而沒有提供 id-utils 的套件 ,但這是使用 gj 的必要套件,只好自己編。從官網抓好 tarball ,解開來編譯 (./configure && make)就是了。 但編譯後會遇到錯誤: ./stdio.h:10...