設計模式的對話：什麼是最好的溝通方式模式 ？ 第一部分。
2006年10月11日，1:46 PM由比爾斯科特|在“ 設計“ | 3評論在2006年的春天，一個十分熟悉設計模式資源的組織和發展集團的設計師討論設計模式在現實世界中的當前和未來的作用。 我們談到有關定義和記錄模式，上下文通信所需的模式應如何應用，如何才能開發一種設計語言，以及如何不同的模式列出了可以銜接。 我們回答第一個問題是“什麼是設計模式？”你可以找到在這個會話線程盧克Wroblewski的博客 。
最近提出一個後續問題，並 Jenifer是第一次在談話中。 本週晚些時候，我們會聽到盧克 Wroblewski的回應。
問：什麼是最好的方式來溝通模式？
Jenifer Tidwell
交互設計師 /軟件開發人員，The MathWorks公司
作者設計的用戶界面
館長， UI模式和技術
模式通信的設計思路，從一個設計師到另一個。 從這個簡單的事實，與其說是別人如下 - 例子的重要性，需要一個精闢的“問題”或“使用時”的說法，和嚴格的格式和形式邏輯的相對次要。
不同的人學習不同的方式。 有些人會明白詳細的文字說明，在UI模式，但設計者往往是視覺化 - 實際上可能會發現許多精心選擇的例子陣列更多的價值。 許多讀者告訴我，他們的“最喜歡的方面設計的用戶界面“的插圖。 這些讀者獲得從所示的例子格局的本質，並找到他們作為一個對自己的工作來源書啟發。 （此外，我不相信的良好格局，甚至可以沒有書面的例子，你有地面之前，寫，其餘的在現有的，現實世界中使用的格局。）
說到例子開始，我發現一個新的模式出現三個關鍵的見解：
- 承認，你見過一個技術或“工作”的想法，在多個地方或上下文。
- 理解為什麼它的工作原理。 一個堅實的理解認知和平面設計理論提供幫助，即使“為什麼”，有時也不外乎“它只是公約。”
- 洞察時，在適當的時機使用模式，當它不。
這最後一個，我覺得，是迄今為止最困難的三個 - 它需要細緻，周到的設計判斷，以達到非顯而易見性的建議。 它太容易出現同義反复。 “問題：你需要一個上下文菜單。 解決方案：使用上下文菜單“的還難，但更為有用，這樣說：”問題：你需要向用戶展示了一個短，項目相關的選擇的動態列表，但你不能用了很多它的屏幕空間。“是的，它的承諾。 編寫這樣的建議違背了許多設計師，誰（可以理解）傾向於信任比規則更直觀的判斷糧食，但它真的有助於知識淵博的讀者少得多。
最後，一個字有關格式。 模式社區內，已經給予了很多關注的模式格式 - 他們應該有哪些部分被命名為哪些部分，等我發現它的事項低於我們認為，只要基本答案是有。 （我使用這些：什麼，使用時，為什麼，怎麼樣，和例子。）請記住，你寫一個人的觀眾這種模式。 它需要是可讀的，和太多的部分 - 或太多術語，誰可以解釋什麼是“部隊”是指？ - 為讀者更難破譯你想說什麼。
你不寫代碼，要么。 或正式規範，或一個組件目錄。 個人覺得您可能是有益的工作，在你的模式非常精確的邏輯，但我保證大多數讀者不會在意。 這也意味著，我不認為，我寫他們的UI模式，有多大價值設計自動化或代碼生成。 但是，這又是另一回事。
所有這一切說，每一個信息架構師知道多個內容提供商採用一致的格式價值！ 我們的模式作家都去的格式和結構變化的試驗，但現在會發生什麼誰想要搜尋或交叉引用所有我們的模式，以饗讀者呢？ 好了，現在我們有一個問題！ 這是我們需要解決在不久的將來，但我認為某種格式的演變是要找到最好的答案。
- Jenifer
分享和擴展： 書籤del.icio.us | Digg它！ | 書籤交易！
3評論
抱歉，評論形式此時關閉。
YUI庫在Twitter
翻譯
最近的帖子
檔案：
- 2012年1月 （5）
- 2011年12月 （7）
- 2011年11月 （12）
- 2011年10月 （4）
- 2011年9月 （9）
- 2011年8月 （6）
- 2011年7月 （7）
- 2011年6月 （8）
- 2011年5月 （6）
- 2011年4月 （10）
- 2011年3月 （8）
- 2011年2月 （5）
- 2011年1月 （10）
- 2010年12月 （24）
- 2010年11月 （21）
- 10月2010 （11 ）
- 2010年9月 （17）
- 2010年8月 （18）
- 2010年7月 （8）
- 2010年6月 （11）
- 2010年5月 （11）
- 2010年4月 （22）
- 2010年3月 （22）
- 2010年2月 （16）
- 2010年1月 （8）
- 2009年12月 （9）
- 2009年11月 （29）
- 2009年10月 （14）
- 2009年9月 （12）
- 2009年8月 （4）
- 2009年7月 （5）
- 2009年6月 （7）
- 2009年5月 （7）
- 2009年4月 （7）
- 2009年3月 （15）
- 2009年2月 （10）
- 2009年1月 （7）
- 2008年12月 （11）
- 2008年11月 （12）
- 2008年10月 （16）
- 2008年9月 （4）
- 2008年8月 （9）
- 2008年7月 （12）
- 2008年6月 （11）
- 2008年5月 （12）
- 2008年4月 （11）
- 2008年3月 （7）
- 2008年2月 （10）
- 2008年1月 （6）
- 2007年12月 （12）
- 2007年11月 （6）
- 2007年10月 （5）
- 2007年9月 （8）
- 2007年8月 （6）
- 2007年7月 （3）
- 2007年6月 （7）
- 2007年5月 （12）
- 2007年4月 （8）
- 2007年3月 （7）
- 2007年2月 （7）
- 2007年1月 （8）
- 2006年12月 （5）
- 2006年11月 （6）
- 2006年10月 （11）
- 2006年9月 （4）
- 2006年8月 （5）
- 2006年7月 （2）
- 2006年6月 （3）
- 2006年5月 （7）
- 2006年4月 （2）
- 2006年3月 （1）
- 2006年2月 （14）
評論政策
我們鼓勵的意見，對博客上的對話有助於。 請注意，在我們的判斷，雅虎可能刪除的意見，如果他們的話題，不恰當的，或以其他方式違反了我們的服務條款。
成為一個 Yahoo!
你是一個有才華的工程師，產品經理，或設計師尋找自己沉浸在一個充滿創意和樂趣的環境呢？ 然後來找到一個與我們的工作。
元：
Jenifer，
目前，我讀你的書，我愛你與它採取的方法。 我覺得它是非常方便和仍然鼓舞人心。 這樣，我可以更容易地與同事分享，以及。
我發現，往往是有關何時使用模式的最好的見解和比較模式（如響應披露VS反應使）。 對於我來說，這凸顯了另一種溝通模式的重要途徑：收集盡可能完整，允許進行比較。
評論由邁克爾麵包車Ouwerkerk - 2006年10月11日，日＃
謝謝你，邁克爾！ 完整性好點 - 如果一個模式語言是過大，或解決方案，是不是那麼好，那麼它變得不太實用。 但你在像這樣的比較權利，使模式更為有用。 這是我將牢記對未來的東西。
評論Jenifer - 2006年10月13日，日＃
這可能是早產（因為它是唯一的後續會議的第一部分），但我想知道disuccion參與者模式加入處理屬性的想法認為呢？
我解釋的想法（“設計過程中的屬性添加模式，擴展模式的重點包括設計中”）於去年八月，在我的博客：
添加設計過程中，屬性模式
http://www.peterboersma.com/blog/2006/08/adding-design-process-attributes-to.html
任何參與者（或讀者！）照顧中方對此有何評論？
彼得Boersma評論- 2006年10月16 日 ，＃