運用 Poka-yoke 機制, 使用自動完成輸入框
若是進行廣域搜索的用戶, 要考慮到資料的侷限性. 可研究 Google Suggest
信賴那些行之有效的標準
介面越簡單, 交互的瞬間就越美好.
若是進行廣域搜索的用戶, 要考慮到資料的侷限性. 可研究 Google Suggest
信賴那些行之有效的標準
介面越簡單, 交互的瞬間就越美好.
- 1月 08 週五 201015:57
[筆記] 瞬間之美 -- 搜索
- 1月 08 週五 201008:17
[筆記] 瞬間之美 -- 指引用戶
創建通道, 帶領瀏覽者去我們要他去的地方。
對於用戶來說, 關鍵在於能否在網站上保持方向感, 能否得到所需的訊息, 以及能否完成他要做的事情.
清楚的導航結構不僅有助於用戶了解網站可以做什麼, 還能知道如何去做.
設計中的每件事都很重要, 外觀, 佈局, 導航結構, 表達個性的元素, 乃至顏色與字型.
對於用戶來說, 關鍵在於能否在網站上保持方向感, 能否得到所需的訊息, 以及能否完成他要做的事情.
清楚的導航結構不僅有助於用戶了解網站可以做什麼, 還能知道如何去做.
設計中的每件事都很重要, 外觀, 佈局, 導航結構, 表達個性的元素, 乃至顏色與字型.
- 1月 07 週四 201013:03
[筆記] 瞬間之美 -- 學習
好的文字可以解釋開發者的用意; 不好的文字則會把用戶搞的頭昏腦脹, 被迫靠猜測決定, 這很可能會使他們犯下錯誤.
人們在使用我們的產品時, 他們所知道的一切都來自於我們所告訴他們的東西. 因此, 我們的職責是給出正確的訊息, 而且要僅可能簡明清楚.
哪怕是簡單的動詞+名詞, 或者是開門見山的幾句話. 而當文字無法達到目的實, 我們可以通過其他方式來解決問題.
開門見山
人們在使用我們的產品時, 他們所知道的一切都來自於我們所告訴他們的東西. 因此, 我們的職責是給出正確的訊息, 而且要僅可能簡明清楚.
哪怕是簡單的動詞+名詞, 或者是開門見山的幾句話. 而當文字無法達到目的實, 我們可以通過其他方式來解決問題.
開門見山
- 1月 07 週四 201009:50
[需求] 分析問題與機會
SA 不是 User 講什麼他就寫什麼. 應該要再深入的問幾個問題以了解 User 講的有沒有矛盾的地方。
否則用這樣的使用者需求寫出來的解決方案, "有好也不完全"。
筆者提供幾個問題來協助您快速發掘使用者的需要,
使用者在現況遇到怎樣的問題 ?
這些問題對使用者造成什麼影響 ?
使用者認為可能的原因是什麼 ?
使用者希望如何改善 ?
使用者認為這樣的改善可以增進哪方面的效率 ? 如何證明有改善 ?
誰可以執行這樣的作業? 是否需要誰的允許才可執行? 這作業(或資料)和哪個單位有關係 ?
最後重要的是，確定『系統的改進目標』為何？
否則用這樣的使用者需求寫出來的解決方案, "有好也不完全"。
筆者提供幾個問題來協助您快速發掘使用者的需要,
使用者在現況遇到怎樣的問題 ?
這些問題對使用者造成什麼影響 ?
使用者認為可能的原因是什麼 ?
使用者希望如何改善 ?
使用者認為這樣的改善可以增進哪方面的效率 ? 如何證明有改善 ?
誰可以執行這樣的作業? 是否需要誰的允許才可執行? 這作業(或資料)和哪個單位有關係 ?
最後重要的是，確定『系統的改進目標』為何？
- 1月 06 週三 201022:29
[需求] 需求分析的定義
引用 <<維基百科>>
在系統工程及軟體工程中，需求分析指的是在建立一個新的或改變一個現存的使用者作業時確定新系統(複數)的目的、範圍、定義和功能時所要做的所有工作(不一定是系統的工作, 也有可能是流程工作)。需求分析是軟體工程中的一個關鍵過程。在這個過程中，系統分析員必須確定顧客的需要。只有在確定了這些需要後他們才能夠分析和尋求合適的解決方法。
在軟體工程的歷史中，很長時間裏人們一直認為需求分析是整個軟體工程中最簡單的一個步驟，但在過去十年中越來越多的人認識到它是整個過程中最關鍵的一個過程。假如在需求分析時分析者們未能正確地認識到顧客的需要的話，那麼最後的軟體實際上不可能達到顧客的需要，或者軟體無法在規定的時間裏完工(為什麼呢? 因為改來改去)。
主要困難
在系統工程及軟體工程中，需求分析指的是在建立一個新的或改變一個現存的使用者作業時確定新系統(複數)的目的、範圍、定義和功能時所要做的所有工作(不一定是系統的工作, 也有可能是流程工作)。需求分析是軟體工程中的一個關鍵過程。在這個過程中，系統分析員必須確定顧客的需要。只有在確定了這些需要後他們才能夠分析和尋求合適的解決方法。
在軟體工程的歷史中，很長時間裏人們一直認為需求分析是整個軟體工程中最簡單的一個步驟，但在過去十年中越來越多的人認識到它是整個過程中最關鍵的一個過程。假如在需求分析時分析者們未能正確地認識到顧客的需要的話，那麼最後的軟體實際上不可能達到顧客的需要，或者軟體無法在規定的時間裏完工(為什麼呢? 因為改來改去)。
主要困難
- 1月 05 週二 201021:59
你是 Me too 嗎?
老闆說要做什麼.
老闆說怎麼做.
你想做什麼.
你想要怎麼做.
老闆說怎麼做.
你想做什麼.
你想要怎麼做.
- 1月 05 週二 201021:45
回顧2009
2009 沒什麼可以拿來講的專案.
倒是讀了不少書
讓事情發生
金字塔原理 I, II
Domain Driven Design
POJO In Action
教練
倒是讀了不少書
讓事情發生
金字塔原理 I, II
Domain Driven Design
POJO In Action
教練
- 1月 05 週二 201013:25
[心得] MVC 歷史
你或許有聽過 MVC, 也或許您正在使用 MVC. 但您知道 MVC 的歷史嗎 ?
- 1月 05 週二 201012:13
[設計] Domain Driven Design - 應用規格
一個領域不是只在一間公司, 一個領域可以有許多公司在競爭. 例如, LCD 在台灣就有 4, 5 間公司. LCD 這個領域有不一樣嗎? 當然都一樣.
不同的是, 製程方式, 管理方式.
在設計 LCD 工廠的 Shop Flow Control 時, 若使用 Domain Driven Design 心法, 應該怎樣進行設計呢?
Application
不同的是, 製程方式, 管理方式.
在設計 LCD 工廠的 Shop Flow Control 時, 若使用 Domain Driven Design 心法, 應該怎樣進行設計呢?
Application
- 1月 02 週六 201016:42
[審查] Code Review 實務
Code Review 是不是多餘的?
如果你是汲汲於賺錢的老闆, 應該覺得這幹麻做, 浪費時間.
如果你跟我一樣是個程式小工, 那麼請跟我一起重視這件事情. 透過這個活動讓我們養成一種正確的習慣.
CodeReview 不用是一群人在房間裡盯著一支程式在指指點點. Review 若讓人覺得沮喪, 最終將淪為形式; Review 應當要讓人覺得有進步, 高興, 可以為其他人的學習典範.