feat: New post - building ui without burden

src/content/post/building-ui-without-burden/index.mdx

@@ -0,0 +1,40 @@
+---
+isDraft: false
+icon: { name: 'material-symbols:problem-outline-rounded', title: '有驚嘆號的卡片的符號' }
+title: 'Building UI without burden'
+titleTC: '建構正確的網頁 UI 不應該是個麻煩的問題'
+excerpt: '身為前端工程近期工作的感悟是很多時候開發問題還是陷於介面的外觀、行為或互動層面上，並不是說花時間製作這些層面的事情就很遜，它們實際需要依靠經驗豐富的開發者透過多方面的研究與考量才能打造合理的架構，例如有許多要留意的事：效能、適用性、可維護性、可測試性、搜尋引擎最佳化、跨平台相容性、多語系……'
+category: 'UI'
+tags: ['元件']
+publishDate: 2024-04-21
+---
+
+## 建構網頁 UI 會遇上那些問題？
+
+身為前端工程近期工作的感悟是很多時候開發問題還是陷於介面的外觀、行為或互動層面上，例如：「拖放頁面元素功能」、「日曆」、「下拉式選單」、「資料清單」……並不是說花時間製作這些層面的事情就很遜，它們實際需要依靠經驗豐富的開發者透過多方面的研究與考量才能打造合理的架構，例如有許多要留意的事：
+
+- 效能 Performance
+- 適用性 Accessibility
+- 可維護性 Maintainability
+- 可測試性 Testability
+- 搜尋引擎最佳化 Search Engine Optimization
+- 跨平台相容性 Cross-platform Compatibility
+- 多語系 Internationalization
+- ...
+
+不經讓我感嘆客製化 UI 的開發與維護成本對小團隊來說實在是太高了。一方面希望「快速推出產品」而另一方面又希望有「高品質的實踐成果」，結果就是做正確的事一直都很困難，相較於成熟制度完善的專案，剛起步的專案 UI 工作更為繁重且面臨更多挑戰，舉幾個例子：
+
+- **被忽略的適用性與網頁標準**：開發時適用性大多是種可選功能，但對某些人來說理論上是必要的
+- **缺乏文件與自動化**：沒有經驗或時間規劃 UI 的自動化測試，只能完全依靠手動測試並祈禱不會有功能爆掉
+- **無法適應網頁變化**：由於用戶幾乎不用小裝置查看網頁，所以完全捨棄小尺寸，初期來說負擔輕鬆，但長遠來說卻可能要付出更多代價（寫死樣式尺寸的網頁已非常態）
+
+## 所以可以怎麼面對這些問題？
+
+**開發與設計者會需要適應一直都在變化的網頁製作方式**。像是現在製作元件化 UI 時應該大多數的開發者多少有類似於樂高積木的概念，更具體的規範一點像是： [Atomic Design](https://bradfrost.com/blog/post/atomic-web-design/) 也蠻受歡迎的，有望將成為業界典範。
+
+並且有些必要的捷徑可以幫助我們少受些苦並更快的迭代產品：
+
+- **保持網頁 UI 的單純樸素**：好快速反應，在功能得到市場證實後再去加深品牌風格，我相信[無聊的 UI 會是好的 UX](https://uxengineer.com/blog/good-ux-boring-ui) 並且成本應該花在刀口上：「解決用戶的痛點」。
+- **尊重瀏覽器標準**：雖然有些標準還是很迷惑不一致甚至功能不齊全，但長遠來說瀏覽器標準是網頁開發真正不變的準則。
+- **善用現成工具**：套件、樣式庫、無頭 Headless UI，像是：[React Aria](https://react-spectrum.adobe.com/react-aria/)、[Radix UI](https://www.radix-ui.com/)、[headless UI](https://headlessui.com/)都是非常穩固的基石。
+- **自動化文件工具**：有空打算多了解相關工具，像是 [Storybook](https://storybook.js.org/)。