Amos：思考-設計
- 設計的好，設計的爛，在很多時候是很主觀的，但作為一個設計者，應該要更深入的去想哪裡好？哪裡爛？怎麼改？
簡單來說，要培養「詢問問題背後的問題」的能力。 - 先不論一開始建立的論點、想法是否正確，但唯有透過自己的實際驗證、建立起自己的一套系統，去解構、分析、重構現下看到的事物，才能逐漸培養出自己的設計觀點、設計邏輯，以及所謂的「Fu」。
Paul ：Story to Reality
分享一個「想法」到「實作」的過程，以Facebook新功能導覽列為例。
- Fire Up：PM根據需要，提供需求
- UED’s Track：使用者行為研究，包含使用者行為研究與介面設計，但不牽涉切版
A.Mockup
B.Spec：實際規格，這裡的規格是指畫面上的到時候要用css寫出來的東西，像是border、color、padding、font-size等等。
C.Skin：因為有的東西需要切圖，所以要提供「把文字都拿掉」的版面圖 - FE’s Track：前端工程師分析LSM（Layered semanitc markup），我的理解是這應該是跟寫php的時候的MVC架構是類似的意思，把使用邏輯、跟介面這些都切開，讓之後維護、擴充、修改時，不會設計卡程式程式卡設計。
可點選的元件使用a或是btn，但btn的行為其實比較複雜，且對a來說，按enter= click的意思。若是使用a的話，建議在錨點要下功能名稱，例如點了關視窗就用 #close、點了執行搜尋就用 #search 這類。
在這個階段主要是分析html要怎麼寫、css要怎麼寫比較好。所以SEO也是在這個階段時要規劃。 - Test Circle：在不同瀏覽器測試版面是否有問題，無窮無盡的測試循環
- Minimize event：制定行為細節，例如mouseover、mouseout、click、resize、Transtion
- Easy use ：易於複用，把整個功能包成js，用js去跑出前端的樣子，方便之後重複使用
- Get More Score：自我改良，看如何修改會更好（PM端不一定有說的需求）以新功能提示來說，可以讓使用者開網頁時畫面自動滑到新功能的位置接著顯示提示。並考慮到優使性，按鍵自動focus讓使用者按enter就可以下一步。自殺系統：當提示結束之後，要把不再使用的功能提示js 自我毀滅，釋放資源。
- Add Tracking module：追蹤使用者行為，可以了解使用者的使用頻率、方式。
Q&A
Q.如何分辨UED（使用者行為設計） & VD（視覺設計）的差異
Ans.問對方：為什麼這樣設計？答：因為好看（這一定是VD）*大笑*
測試相容性的時候，使用VM去測試。因為模擬的還是會有落差，例如IE8的class數目超過某個數量之後，實際在某版的win系統底下，後面會死掉不給出來。但在模擬環境下測不出來。
OS.我相信這問題真的是在開發大系統的時候才會發生…class數量我忘了，但很大，一般小網站不會用到那麼多數量。
Leo ：App Store的黑暗兵法
- 在ASO的結圖要吸引人，所以不需要一定要擷取「正在使用」的圖，請找最漂亮的就好。
- 在ASO有評價的名次權重會比較高，所以在設計App的時候，要把「引導使用者去幫你做好評價」的流程也設計進去，不要只是放個按鈕。
Troie ：語意-html5初探
這部分討論的時間比較多，發現大家對語意的認知很不一樣，很有趣，大概整理一下聽大家討論後我自己的看法
- 在探討語意以前，應先定義「這個語意是要給人看的語意還是要給機器看的？給人看又是給誰看的？」html5的一些新標籤確實在「字面上」比起html4來的有「語意」，但會去細看原始碼的只有兩種1.網頁相關技術人員（網頁設計、程式…）2.搜尋引擎機器人。對這兩種人來說，只要能夠明確定義每個標籤的「意義」，那字面上是否能夠「直接」看出語意，似乎就不是那麼的重要。因為「一般人」看不懂h1~h6其實不太重要。他們看得出來字大小有差就好，不會去翻原始碼。
- 討論到商品列表，商品是否要用li包，有兩種觀點
A.商品屬於「同一類」，所以可用li包，表示他們是有關連性的。
B.商品內容有「圖片、文字」，在li內包似乎不符合li的「清單」的意義，可改用section包。但section可拿來區分彼此之間比較沒有關連性的區塊。
我在切版的時候，商品列表我都用li包，因為我覺得都屬於商品、算同類。但因為我下css的時候，目前考慮到向下相容，我還是不會下在html5的標籤上。所以若拿來當商品，我通常會把li的內容再用article去包（應該用section亦可），另外用li有個好處，整包要複製什麼比較好找，因為都會報ul包住，html字元也比較少。且把css拔掉的時候，用li包，每個商品前面都會有小點點，比較容易「分隔區塊」。
strong 、 em優於 b、i的原因主要是在使用朗讀式瀏覽器時，前者會加重音，後者不會。但我的疑問跟Amos一樣：為什麼不把b、i的定義改良成strong、em就好？為什麼要產生新的標籤？不過Troie提出的想法我覺得也滿有道理的：這樣不重要的icon就可以拿b、i來用，不用一定要用div、span。
因為後來落跑回家做案子了，有的沒聽到，或是聽了但比較沒有心得的就沒寫囉。