實在難以忍受的網路購書流程

2008/03/05| 閱覽人次：18,770| 28 則留言

剛剛 (03/05 PM23:10) 左右，要向「博客來」網購書籍，點選購物車快速結帳(我發現到，名不其實，根本沒有快速)，光是要選個 {7-11 取貨門市}，點選了好幾次，網頁就一直在那邊轉著，沒有啥回應。吼，已經忍受他們不理想的購物介面好久了，此時實在不吐不快！

我應該算是他們多年來的忠實用戶了，現在買書，幾乎都是在該網站買書的，主要原因可不是方便，而是便宜。對我而言，只要書比外面實體書店便宜、取貨快速(這點博客來被統一集團併購後，透過該物流的確非常迅速)、再來就是買書時簡單乾脆，也就是購書的流程能越簡單越好 (喔，還有啦，最起碼基本資料也不應該被外洩的)。

其它諸如搜尋系統之類的，是另一回事，我主要最不滿意的，就是那個「選擇 7-11」的功能。吼~ 如此差勁的設計，幾年來還是沒有任何長進！！ 我知道他們的作法肯定是把所有的 7-11 店家，以及全台灣省鄉鎮縣市給全部塞到網頁這邊來了，大概就是利用 JavaScript 之類的動態網頁技巧把它給實現功能。介面要作得好，這其實設計與實作並不困難，從需求面來看，舉個例，我就打個 “興南”，就會列出 興字開頭的店家、或是興南路等都可以，簡單的說，我可以利用很隨性的打上幾個關鍵字來搜尋門市，就可以篩選列出店家。我只是列出其中之一的作法，其實要能設計更便利的介面方法肯定有很多種，任何一種我看都會比現在你要透過選擇框，先選哪一個縣市，再選路名來得好。吼(再來一次吼聲)~，我們家中和，每次我要選到那個興南路，總是要用滑鼠拉著捲軸找好久，每次拉我總是嘴裡碎碎唸，什麼時代啦，還有這種介面啊。

我曾經寫過一篇：「Javascript 是爛東西？」，其實要提醒軟體設計人員，不要以為有些資料的取得方式是很固定，不容易變動，且可能資料量不大，所以乾脆先一次給全塞到最前端的網頁來，再透過具有動態效果如 Javascript 的網頁語言來操作存取，就是所有的動作都是在網頁(已經與 Server 無關)給全做掉了。在網頁塞了許多不必要的資料，或是讓網頁這邊處理企業邏輯等，這都不是好的設計方式。

無論如何，像這種大型的購物網站，是屬於交易型的系統，也就是稱之為 OLTP(On-Line Transaction Processing)的企業系統，除了在現實上，效能與穩定是必然的要求外，其實在設計上是蠻重視 UI 與在後端系統 (後端系統我比較偏稱之為 Application Server，而不僅是 Web Server)的互動過程，也就是需要向系統動態要求取得或處理資訊，這是一種屬於對話互動式的設計作法。所以當以 {選擇 7-11 取貨門市} 這個案例來說，使用者 (UI)會需要與後端 AP Server 一到多次(可能會有兩三次吧)的互動，才會取得最後的結果，反而這樣的方式在操作過程中，會比較順暢且簡潔。

我估其他們不這麼做的原因應該是考量到了效能 (performance)，其實這真的也蠻好解的，我再強調，是與後端 AP Server 互動，並不是每一次都要連到資料庫操作的。由於資料量實在不大，台灣全省鄉鎮縣市 加上好幾千家的 7-11，在記憶體也不會佔用多少。所以也可以利用如 “虛擬DB”，也可稱之為 MemoryDB 的設計方法來達成的，是絕對可以兼顧效能與彈性的，沒有問題的。

結果我這篇文章寫了一個小時，再去點選那個 7-11 門市，再一次的給它吼~ 還是不能點選耶！！ 拜託啦，這樣再幾次也會讓如我這樣的忠實客戶給落跑不再去光顧了。如果，嗯，相關單位對該功能還是不知道該如何設計與實現的好，歡迎來找我們聊聊吧，不是只有唸唸空談而已，如何提供具體的解決方案，這點倒是還瞭解的。