跳到主要內容

避免落入預期解法的死胡同


買錯票

某天我要去台北，卻發現自己前一天起迄站買反，買成台北 —> 台南，但是搭車前才發現，詢問服務台人員，只得到回覆說發車前 30 分之前才能退票，自己也依稀記得規定是如此，因此只好認栽，誰叫自己買票沒看清楚，趕緊自己去重買一張到台北的車票。後來老婆提醒我也許可以換票，再至服務台詢問，服務小姐說若是錯過班車，可以當天的票搭乘較晚班次的自由座，但是我給她看我的票是早上出發，卻要搭晚上的車，我就解釋是因為我買錯票，她猶豫了一下，竟然說了一個聽起來可以幫我換票的說詞（我忘了他確切的用詞），我雖然感到驚訝但是我已經買了到台北的票，只能說來不及了，她就建議我仍然採用換搭自由座的方法。

預期解法 - 退票

這件事我也犯了一個跟某些客戶常犯的錯誤，就是「沒有提供背景資訊」，或說「預期解法」。我心理預期我的問題的解法只有「退票」，因此我只問了特定的「退票」事宜，發現不能用「退票」解決，就以為沒有解法了。如果我能第一時間提供比較完整的背景資訊（也就是買錯票的狀況）給服務台，因為服務小姐擁有較完整的解決方案，她可以從我的背景資訊中，更清楚我的需求，進而幫我想到其他解法。

破除方法 - 主動探詢

當然服務是雙方的，如果服務台小姐可以在我第一次詢問時，就更主動探詢更多的背景資訊，她也就有機會促使我講出原本的問題，並從中找出其他解法，最終就提供了一個更好的服務體驗。

回到原始問題

在 ZK 技術支援上，有時客戶問到一個特定的功能可否做到某個效果，問題很簡短，也沒有交代需求或應用情境。如果該功能確實可以達到該效果，我通常會簡短肯定回覆，只是確認或補充說明。如果無法做到，或是該功能跟客戶預期的效果沒有什麼關聯，我會在信末提說：「如果你能告訴我們你的應用情境，也許我們能找到其他解法」。因為我推測這位客戶已經落入「預期解法」的思維，他已經認定這個特定的功能就是解法，如果不能做到他的要求，就是不能解。我問的那句話就會促使客戶描述原本的應用情境，我可以據此去找到另外的替代方案或更好的解法。
標籤：

留言

張貼留言

這個網誌中的熱門文章

innerHTML 的安全風險

問題 若你要實作一個使用者輸入的功能，並把輸入的內容顯示在網頁上時，應避免把使用者輸入的值直接指定給某個 element 的 innerHTML 。因為若是使用者輸入包含 HTML、JavaScript， innerHTML 就會解析並執行： var userInput = '<img src="javascript:alert("XSS")">' element . innerHTML = userInput ; 因此可能 user A 的惡意輸入，會被系統顯示到 user B 的畫面上，進而執行特定成程式碼而造成 XSS 攻擊 。 解法 一般會先想到 encode HTML，但是如果只是要顯示文字，將使用者輸入值指定給 textContent 會更簡單，無需 encode，該值會被當成純文字處理，並不會執行 javascript。 var userInput = '<img src="javascript:alert("XSS")">' element . textContent = userInput ;
張貼留言
閱讀完整內容

XMind使用心得

使用FreeMind有好一段時間，不過畫面單調一直是我不滿意之處。 XMind在畫面上好看很多，節點形狀樣式、分支線樣式有多樣選擇，也可以匯入FreeMind的檔案。 類似Excel般，工作頁活頁的概念也很不錯，可以將多個相關的心智圖存在一起。 可以某個分支為中心來檢視的功能也很令人激賞，完全符合心智圖那種可見樹、可見林的特性。 不過使用上有幾項缺點: 1.不能設定節點的預設文字大小。 預設應該是10點字，太小了，但是「喜好設定」內沒有地方可以修改，需要每次自己加大字型，很麻煩。 2.沒有加大字型的動作可以設定快速鍵。 我喜歡不只是用顏色，還有用字型的大小來凸顯主幹、分支的差別，不能快速的增大、縮小字型很不便。
2 則留言
閱讀完整內容

ZK 教學 - 使用 MVC 或 MVVM?

不管是現在剛開始接觸 ZK 或是用過一陣子的人都可能會遇到的問題是到底要用 MVC 或 MVVM 的方式開發。從 ZK 8 之後又把 MVVM 的能力更佳的擴展，所以 MVVM 會是一個功能更強的開發方式。但 MVC 在使用上比較直覺，仍有其優勢，所以我想決定性的因素會比較是 開發者的偏好 及 專案的特性 。你可參考下面的比較來決定哪種方式比較適合你。 優勢比較 MVVM ViewModel 較不易受畫面變動影響。 因為 ViewModel 沒有變數直接指向 ZK 元件，因此若是畫面上有元件更改，ViewModel 一般不需要修改 ViewModel 較易於在不同頁面中重用。 因為 ViewModel 只包含資料跟業務邏輯，若是不同頁面需要的資料跟業務邏輯相同，就可以重用同一個 ViewModel 例如 A 頁面按按鈕執行搜尋，B 頁面點選單執行同樣的搜尋，則可以重用同一個 ViewModel 中的 command，只是兩個頁面 data binding 寫在不同的元件上。 畫面較易於重用（易於模組化）。 透過 shadow component 跟 template 機制，可以將一段頁面的片段做成可以接受傳入參數 套用 Responsive Design 的成本較低。 通常需要針對不同裝置設計不同版面，但是顯示的資料內容大同小異，因此 ViewModel 多半可以重用 易於套用美工所設計的畫面，或是網路上現成的元件。 易於整合第三方 javascript library 或 widget。 因為 ZK 8 提供了一個可以讓你透過 javascript 去呼叫 ViewModel 中的 command (client side binding) 的方式來跟後端溝通 ViewModel 的可測試性較好。 因為 ViewModel 不需要繼承特定類別跟實作特定介面，可以輕易地執行單元測試 MVC 操控元件方式直覺好學、易懂。 MVVM 控制元件較不直接，需要了解 zk framework data binding 的行為 可以完全使用元件所提供的所有 API。 仍有極少部分 ZK 元件行為沒辦法用 MVVM 控制。例如產生 Messagebox , Listbox.renderAll() , Popup.o...
張貼留言
閱讀完整內容