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

剛剛 (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 門市,再一次的給它吼~ 還是不能點選耶!! 拜託啦,這樣再幾次也會讓如我這樣的忠實客戶給落跑不再去光顧了。如果,嗯,相關單位對該功能還是不知道該如何設計與實現的好,歡迎來找我們聊聊吧,不是只有唸唸空談而已,如何提供具體的解決方案,這點倒是還瞭解的。