0730 月會會議紀錄

[kuaniscreative]

會議目標

1. 使用狀況彙整——搜集 7 月份（及之前的）使用狀況，搜集需求、改善方向
2. 持續狀況回報的方式——包含會議記錄、開發方向、執行狀況等等的資料彙整地，讓大家可以參考的地方
3. 擬定 8 月份執行細節
4. 今年度執行方向

前次會議結果

1. 需要文件支援
2. 每月會議討論

會議內容

mezzanine 在 design system 差異過大時，工程會不好改動

1. 專案使用 mezzanine 時，設計拉的 design system 應與 mezzanine 的 design system 相符
2. 現有 design system 可能需要調整

調整 color system

1. 工程整理出每個顏色現在的使用狀況，由設計去調整
2. 工程與設計對於顏色的命名有疑慮，等使用狀況整理出來後再討論

需要讓大家對使用規範有個共同的認知（包含使用極限認知）

讓 pm、設計、工程知道現在的 component 可以做到哪些事情。因為現在每個 component 都要 review 過後來製作文件，那在 review 前會先列出應該要可以做到的使用情境，review 時依照每個使用情境去檢查是否可達成、如何達成

新需求/元件整理方式

需要知道需求程度有多高，可能可以開個 thread 每個專案使用到的時候就記一筆，讓之後 v2 可以權衡誰優先

【工程】減少使用 mezzanine 的人要用多個 loader 去處理 css processor

1. 未來可以做個類似 mezzanine-loader 去專門處理這個 loader
2. 或許 v1 可以處理
3. 或許可以一起達到時間 library 的 config(issue core/calendar Datetype should given from user #47 )

checkbox/radio 的 hover background 跟常見的（其他 lib）的長相不太一樣，對於使用需求有疑慮

設計討論是否有 redesign 的需要

設計稿上的 input 有預留 padding，不確定是不是應該要拿掉

工程這邊確認沒有 icon 時的結果，同步給設計，由設計決定 figma component 是否需要修改

Select 使用情境討論（multiple & searchable）

1. 使用情境釐清：要根據 option 的數量決定使用 select 或者 autocomplete。數量少的不需要讓他去搜尋選項，也就是說 Autocomplete 才需要 search input。
2. 使用情境釐清：對工程來說，Select 跟 Autocomplete 可以共用一個 base component，但在開發上會獨立出一個 Autocomplete 是因為當使用者想找這個 component 不會直覺想到他是被分在 select 底下
3. 無論 Select 或是 Autocomplete，都有分 single 跟 multiple
4. 無論 Select 或是 Autocomplete，都可以控制選項太多時要不要刪節到一行。可參考

5. 當 Autocomplete 有刪節到一行的需求，focus 時一樣要把所有已選取選項灑出來。 6. 此項目需規劃在 v1

Menu 選項的 separate line 要有 padding，不然看起來會怪怪的

設計這邊會改，工程看時間去安排

Form label 等等或許可以獨立成元件

如星號、驚嘆號 popover 等

表單元件底下的 error，是要預留空間塞 message 還是有 error 時直接往下推

預留空間，但工程提出訊息過長時的解決方式

當需求超出 mezzanine 時，設計方向應該是盡量符合 mezzanine 的規範，還是請工程師額外製作來達到設計需求？

盡量以 mezzanine 的內容為主，但當需求超出 mezzanine 的規劃範圍，需要讓 pm 知道工程需要額外花時間製作。

長期時程規劃

在今年能夠將文件產出來、已知的 bug 修正以及必要 feature 產出(如上面提到的 select)

[stevenho0811]

#91
#92
#93

其他的記錄在這邊