剛剛 (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 門市，再一次的給它吼~ 還是不能點選耶！！ 拜託啦，這樣再幾次也會讓如我這樣的忠實客戶給落跑不再去光顧了。如果，嗯，相關單位對該功能還是不知道該如何設計與實現的好，歡迎來找我們聊聊吧，不是只有唸唸空談而已，如何提供具體的解決方案，這點倒是還瞭解的。
Hello TB:
下來訂書時來給它試試看。 !^^
今天上博客來購物
發現電子地圖已經有所更新
整個設計就很Friendly
比之前的好用很多
7-11還是有所改進的
Hi Trek:
還真希望他們能讓系統更穩定…
HI：
5/1PIC又發生主機異常的狀況，點選7-11電子地圖後，出現「處理 URL 時伺服器發生錯誤，請連絡您的系統管理員。」的錯誤訊息
Hi Andy:
這個問題我也聽說過，不過那倒是另外一個安全性的設計議題了。 🙂
博客來的客戶資料也有被外洩的問題了！上星期我一個同事接到詐騙，今天是我接到，我們的電話、訂單資料都外流了；詐騙電話知道我們正確的買書日期及書名，說是訂購單選成分期付款，要退費再用分期….等等；看來博客來和統一前一波的人事異動，還真造成不少的問題 ~
Hi Dii:
yes, 其實這個小功能是還好，就是端賴需求來決定即可。
推Kenming Wang所說,將已選過的門市儲存在使用者Profile,
其實多做個: “加入常用門市” 功能也不會在server端多什麼麻煩,
使用者用起來還比較快速簡便
Hi Richard:
我們(HSDc) 在研討會曾介紹過此應用，甚至現在我們在輔導企業客戶，也是運用這樣的技術。可以參考我們研討會的簡報資料。 ^^
Hi Hachi:
1. 我還是比較認為他們並沒有把已選過的 7-11 門市狀態儲存至個人的 profile 內，應該是 cookie。不過倒是如何做，都可以接受(以前者的作法可能比較好)。
2.不是很慢，是當掉，樓下那位 Trek 有回答。 🙂
我把對 “該介面使用” 的不滿意感受給表達出來，有許多網友，可能會有與我同樣的感覺，當然也有如您覺得可以接受的程度，這其實都 OK 的，最後當然還是博客來他們自己需要去評估與調查諸多用戶的習慣與接受情形，我這篇不滿意的表達，充其量也是讓他們參考而已，而若能做得介面更友善，多少也是讀者們的受惠吧。
Hi ty & Trek:
其實說真的，實在沒那麼 “複雜” 耶，我現在其實只是針對 “選擇 7-11 門市” 這個小功能而論，其實不會牽扯到什麼 “EC 的整合” 這類事情。說真的，目前這種狀況是 “把簡單的事情複雜化” 🙂
Hi
據我了解，3/5那天統一資訊有部server出了問題，導致門市一直重選，這是個案，當天所有透過7-11門市取貨的EC廠商都會出現這個狀況，不單只是博客來。
統一資訊的電子地圖已經上線多年，使用介面的確不太便利，今年有提出改版計劃，EC廠商也都會與之接軌。
Hi文中提到的虛擬DB(MemoryDB) 是什麼東東?可以介紹一下嗎?
博客來我常消費的網路書局之一，不過我從沒遇過你的問題耶。
1.上次選過的門市會被記錄，似乎不是記在cookie，因為我電腦當機時，常常其他網頁的cookie都死光了，博客來的門市紀錄都還在呀。
2.就在剛才我特地到博客來隨便選本書快速結帳(當然最後沒買)，然後重選門市，連到7-11電子地圖，大約5-6秒鐘就出來了，切換縣市也不到2秒，不清楚你說的很慢是什麼意思？我用的是2M/256的ADSL。
題外話，連網頁我最難以忍受的是Yahoo的blog，每次CPU loading都100%，整台電腦都卡卡的，聽說密技是在網頁上按右鍵，選”內容”，等dialog朓出後按”取消”，就正常了，不過並不是每次都成功。
Hi Kenming ,
要說的詳細點話就多了。(勾起我的回憶)
1.整合的部分，前端網頁確實不是重點。事實上利用網頁互傳參數也不是很好的方法。
整合的重點的確在於後端系統。包括:
(1)訂單資料資料傳遞。訂單確認後，EC網站需將訂單資料以XML形式送至統一資訊。
(2000年已經是用XML互傳，還算小先進。還記得統一資訊那邊是Microsoft 作系統整合的部分。)
(2)送貨資料傳遞。EC 網站確定要送貨至 7-11 門市。要將送貨資料送至統一資訊再送至物流中心。以方便物流中心盤點貨品。
(3)EC網站產生並列印特殊條碼。條碼單要連同貨品送至物流中心。(就是每次取貨的時候，店員刷的那張單)。當然物流中心也要刷刷刷再跟EC網站送來的送貨資料比對確定貨物都有送到物流中心。到了物流中心，統一就可以保證隔日中午前送達門市了(配送系統其實在當時已經很不錯了。)
(4)顧客取貨後，資料傳回。統一資訊 –> EC 網站。確認顧客已取走貨物。(不然EC網站就會一直發email或是簡訊給客戶，提醒你要趕快去拿。)
(5)例外處理：若客戶未取走貨物，退回貨物的資料處理。
回到原本的問題。
統一資訊為何要使用”網頁互傳參數”的方法，並將網頁放在自家的網站上，我認為有兩個原因:
(1)為了確定送貨門市的資料可以即時並”正確”的讓EC網站取得。直接自己做網頁抓自己的DB最快了。
(2)”網頁互傳參數”的方法確實很簡單。EC網站不用太費力就可以”連結”起來。
(叫每家EC網站再作自己的”門市選擇”網頁，然後從統一資訊”常常”(至少每天一次吧)更新7-11門市的資料，EC網站(就是我們苦命工程師)也是會抱怨的)
不過平心而論，若要真的把格主和我都在抱怨的這個流程做好，其實讓EC網站自己做我覺得會最好。這樣可以做得到在購物流程上就把門市選好而不必再跳出視窗去作門市選擇)
2.但是真正的問題在於
(1) 選擇門市的流程有好多頁，EC網站的客戶在選的時候覺得繁複。
(2) 常常統一資訊的伺服器一當或一爆量，所有EC網站的客戶都不能選擇門市了(或選的時候邊寫部落格邊選:-)。
要最快速的解決抱怨的方式就是
(1) 改善使用者介面。(AJAX 是一解，尤其是針對這種多層式選項應該不錯用。)
(2) 另外就是網頁效能的改善。那又包括網頁程式，網頁或資料庫伺服器調校，甚至可能談到硬體的擴充了。
問題還是在於統一資訊有無心或(或大家要說統一或7-11。一個集團的，誰主導我就不了了)肯不肯去改善了~
以上是一些回憶和淺見。
落落長講了一堆 看的人辛苦了~
很高興遇到近鄰又能有機會發表一下自己的經驗。
有機會再和格主多討教交流。
感謝~
TY
所以Kenming適合住在書局旁邊(還要那種大書局)
這樣比較方便:D
我現在中午或者下班都會走個10公尺的路到書局翻翻在回家:XD 方便又快速
Hello helenna:
所以啊，我是忍了好幾年才 “不吐不快” 耶。 !^^
平常還勉強可以忍受，但是當我碰到訂書一直卡在哪裡，情緒就爆發出來了。
Hello TY:
這個…. 那實在不算是整合喔。 其實 {取得 7-11 門市} 目的僅是取得哪一個門市的資訊，如此而已。
還有，透過 Ajax 是可以更豐富動態網頁的互動效果，不過，這仍是需與後端(Ap Server) 的互動，我比較重視這。 !^^
呵呵
關於這7-11介面
我好像沒感覺那麼明顯耶^^”
好巧~我也住興南路附近,常選的門市是7-11 的東南門市。以我的使用經驗而言，博客來的系統經常是無法儲存我上次選過的7-11 門市資料，因此每次購書都必須要經過”門市選擇”這個冗長的過程。也曾向博客來反映過，但並沒有得到任何的回應。
我早年(2000 年)參與開發的購物網站也與7-11的門市取貨流程做過系統上的整合，這些年來的確在購物流程的網頁上沒有太多的改進。其實現在如果透過AJAX，可以讓輕易選擇的流程集中在一頁完成，在效能沒有太大的差別，而且也並不難改。重點在於7-11是否重視並投入人力去重寫重測了。另外，真的覺得博客來該好好檢查一下為何沒有存好會員上次的門市資料，我想大部分的會員都會有一定的慣性在某個門市取貨，真的不需要每次都去選的。難道只有我們住中和的比較倒楣?!資料都存不住? 每次都需要碰到這種折磨人的流程~
Hello Neo:
no,no~ 我只單論那個 {7-11 取貨門市} 這個小功能案例討論而已喔。 無論是 博客來 or 統一，這類粗陋的介面早該檢討改進囉。
7-11 在行銷的反應這麼快又好，但是怎麼在 IT 這邊的反應如此遲鈍呢？
我來提供一點不同的聲音。
基本上博客來在7-11這一段是非戰之罪，因為博客來介接的是 7-11 取貨付款的系統，而這些並不是博客來做的。
大家有興趣也可以到 Zakka、Lativ 這些也有 7-11 取貨付款的購物網站去看看，他們在 7-11 取貨付款的使用介面跟流程也都跟博客來一樣。
至於這個系統流程不止消費者用的不方便，其它簽約的網路商家跟系統整合廠商也都可以聽到怨聲載道的聲音，真的只有不長進可以形容。
Hi john:
> 博客來會紀錄之前使用過的門市資料，不需要每次重選吧！
我還沒提到，現在每次瀏覽網站，又再再重新登入一次呢。另，我經常還是需要重新選擇門市，其實並沒有被選擇起來存在資料庫(應該是 cookie 的方式儲存吧)。
博客來會紀錄之前使用過的門市資料，不需要每次重選吧！
不過話說回來，博客來除了速度、價格外，服務真的是很差，曾經發過email抱怨，只把責任都推到7-11門市身上，唉。
現在如果其他網購價格跟它一樣，都優先找別家。
Hi fox:
用戶的不滿是他們進步的動力，希望他們能改善。 ^^
深有同感，上次也不過訂兩本書，卡在7-11那卡好久，然後莫名其妙的連折價券提供的折價20元也不見了…超怒= =
Hello Eric：
我是覺得， 企業不應與 IT 分開的耶，兩者是一體兩面而已的。真正的源頭，還是在企業主本身的。 !^^
不進步的是企業的IT
並不是博客來本身
所以,應該檢討的是統一資訊(該集團的IT)的態度
那個態度經不是258萬可以形容的,而是123456789萬,^^