今天是一整個sprint的最後一天，因為一些原因，能Demo的story少的可憐，雖然App的首次啟動時間從13秒減到3秒得到不少掌聲，但身為開發者，說好的story『漏溝』這麼多，確實有點說不過去，所以下午的自省會議大家也很充分地自省，希望能讓團隊下次sprint能更好。接著是下午的另一個重頭戲，App開發好一陣子了，也發現UI的體驗開始有些不一致，因此在很久前的自省會議提到希望能列一些App內的UI pattern，用來補強story中對於UI的描述，並讓體驗趨於一致，有位成員和美術團隊花了相當長的時間整理既有的UI，算是一種反向工程吧！不過整理完還是要跟開發者確認一下，所以有了這個會議。
在這會議召開的前幾天，我們開發團隊內部也對於pattern這個字有熱烈的討論過，顯然，不是每位都對pattern有相同的解釋或定義，所以開會的第一時間我就發言問了一下，這次UI pattern的定義是什麼？好吧！產品經理果然很嘴砲(感覺，我禮拜一上班會被打)，他覺得用什麼字不重要，重要是會開完後有沒有共識，只要有共識，就算不叫UI pattern也沒關係。好吧！會議就在熱烈的討論中(嗯~我知道我問很多問題，但我絕不是在刁難，別瞪我XD)，慢慢釐清了一些東西，老實說，我確實有想把討論中的東西導向我所知道的pattern。
回到家把n年前看完的《Designing Interfaces》從有些灰塵的書架上拿下來(我的是第一版)，翻開前言，好多以前還不知道，但後來知道的東西都在前言裡，現在再回來看，感觸就完全不同了。以下就節錄一些，我覺得特別有感觸的句子(以數字編號)，首先是對於UI設計的部分：
1. 『熟悉』不見得需要讓某個產品的一切都和某個世俗產品一致。人其實夠聰明，只要組件足以辨識，組件之間的關係很清楚，那麼人們就能夠將他們先前的知識運用在新的介面上，並瞭解怎麼一回事。 OS：抄襲和偷是不一樣的
作者對於一般性的模式的敘述中，除了談到Alexander的《A Pattern Language》及《The Timeless Way of Building》外，也提到GoF的《Design Patterns》，讓使用者介面設計也開始用pattern的方式去描述問題與可能的解，例如：《Interaction Design Patterns》。不過，我當初其實還沒聽過Alexander，所以一些話當初沒畫重點，現在再回來看，確實頗有意思，至於當初畫的重點，其實還是很有趣：
2. 簡而言之，模式(pattern)是一種結構的和行為的特色，可以改進事物的適居性。
3. 模式可以被描述為某個設計領域內的最佳慣例(practice)。這些慣例其實是許多設計張力(tension，模式的術語常常稱為force)的解決方案。有了慣例，定義上，該問題就不算新了。
4. 模式並非可以立即取用的元件，一個模式的每個實踐方式都會有所差異。模式不是簡單的規則，也不是用來啟發的道理，模式無法帶你穿越一連串的設計決策。
5. 有些非常完整的模式集合，形成了一個模式語言(pattern language)
作者建議使用書中模式的方法：
6. 學習。如果是沒有多年的設計經驗。你可以拿這些模式當作學習工具。你可以透過讀這些模式以瞭解這樣的構想，或者是在有需要的時候參考特定的模式，正如同學習越多詞彙可以讓你表達力更豐富，學會更多設計詞彙也可以幫助你建立更具有表達力的設計。
7. 範例。書中的模式都至少有一個範例，有些甚至會有多個範例，這些範例可以讓你當作構想上的參考，你可以從範例中習得一些知識，是文字無法描述的知識。
8. 術語。如果你和使用者、工程師、或經理人討論介面設計，或者如果你寫規格，那麼你就可以使用模式名稱來溝通和討論想法，這是另一種模式語言的優點。
9. 靈感。每個模式的描述都是用來表達，為何此模式可以讓介面更容易或更有趣。如果你懂原因，但是想做的和範例稍微不一樣的，你可以盡量發揮你的巧思。
最後，這本書在描述一個pattern時是這樣描述的，對於想讀這本書(不論是第一版或第二版)，希望這說明能有幫助：
a. 模式的名稱 -- 這很重要，沒有名稱就無法當成術語溝通
b. 這是什麼 -- 一個簡單的敘述，以彌補名稱上的不足
c. 何時使用 -- 這裡通常會提供幾個pattern出現的時機，不過，這不是絕對，並不是一看到某個時機就一定套什麼模式
d. 為何使用 -- 決定是否使用模式主要是要看為什麼？用了這個pattern是不是真的滿足使用者的體驗，或是解決的使用者操作上的困擾
e. 原理做法 -- 提供比較偏實作面的敘述，但不是照抄，請參考本文的第1、4、9點。
f. 範例說明 -- 用一個或多個實際使用這個模式的例子(畫面)，解說使用模式所帶來的優點
