1.HTML + CSS是很底層的東西，所以如果要加快開發速度，就是需要有個東西可以封裝它的細節，讓你在開發時不用面對那麼底層的事情。簡單說，它可能就是一個Bootstrap framework（但可以再走遠一點）

不管你是在哪種平台作業，得到了某個mockup或檔案，是photoshop做出一個jpg樣版好了，或是excel做一個內含公式的表格好了，當它轉到web，就顯示而言（也就是View）那就是HTML + CSS的事情，這就是屬於web必須面對的底層→所以要加快速度必然要從封裝底層的細節著手

封裝HTML+CSS我認為有好幾個層次。就像Bootstrap做到了相當程度的封裝，但你可以說基於AngularJS寫的UI Bootstrap又是更高一層次的封裝

（引入UI Bootstrap真的比使用Bootstrap components要簡潔許多）

之前有提過我認為做自己的一個樣版檔也是一種封裝（畢竟從Bootstrap doc上看到的效果和實際使用還是有出入），可以加速你掌握HTML+CSS的呈現。然後最近我準備要做一個UI的樣版檔，它也是根據Bootstrap更進一步的封裝→因為在實際使用過後，你會對Bootstrap的零件提出自己的組合方式

=====

2.平台的轉換一定會有一些痛點。就像當你在Illustrator排版的東西，它是用ai檔描述的，到了web上就必須轉成HTML+CSS再描述一次，這就是痛點

同樣地，一樣的結果但在excel與web上就會不同的互動性，你要把這種差異性抓出來，並且用該平台自己的互動邏輯去詮釋它，這就是痛點。簡單說，你要在web上做一個和excel界面一模一樣的應用，然後把這張excel表藉此做到web上也是可以（只是很蠢），但如果要用屬於web互動的方式去做這件事，就是要把控制項（input form）與顯示項拆開來，然後重新整理它的UX

所以說，我們得到一個觀念：「互動」這件事在不同的平台上轉換也會有它的成本。一樣的資訊、一樣的工作內涵，在不同的平台上它的互動邏輯就不同（當然底層實作不同就不講了），所以你要抓到屬於該平台的互動邏輯，把東西的內涵再詮釋出來

所以1.即使是單純的顯示，轉換平台時也是有底層實作的問題。2.轉換平台後，「互動模式」也要跟著調整

=====

3.當初毅然決然地從excel VBA轉換到web，就是看準web可以做更細緻的互動（和程式碼邏輯）。而當我轉換到web後第一個關卡就是UX問題浮現出來，也就是：控制與顯示分開來了→當所有控制項被集中在一起，為了讓使用者有更好的認知模型，就需要思考控制項的分組、控制流程、和輔助資訊的提示

這裡面某些UI的功能類型就出來了，例如(1)tab, collapse panel || well就是做資訊分組用的，然後每個群組裡面你要(2)用排版的手法再分出小組，讓使用者區分出資訊的相關性。(3)另外要有像pagination, breadcrumbs就是給使用者一個mind map，告知他工作的完成度，降低進入與學習的門檻

(4)再來則是適當加入一些alert || popup hint，讓輸入的過程不要那麼無助

(5)即時驗證也許可以算進UX的一環（但它不屬於UI），可以讓錯誤的壓力不要一口氣累積在最後資料送出階段

=====

4.我花了一點時間去學習在背景使用ajax request data並自動填入（驗證）的事，它有一些http +promise的知識要了解

這也是我當初從桌面應用轉入web的原因之一。因為我可以用server/browser架構把一些死硬的資料查詢寫進Restful API服務裡，並且在背景執行，這樣我可以免去很多一邊工作、一邊查資料的瑣事

在backend我可以把那些不常更動的業務資料（例如法令）用比較容易維護的架構撰寫，例如我目前有個組合是js+json檔，而不一定要寫進資料庫維護麻煩

這部分最大的重點是「易維護」，能夠彈性面對公部門法令行政資料的調整做省力更新

「背景查詢+自動填入」是UX在web應用的一個重要手法，所以與其說背景查詢是一種資料操作的主要功能，不如說它是一個輔助手段──你可以沒有它，但有了它很方便

再來註冊和登入（撇開前面說過的那些點）關係到一些傳輸、加密、安全性的知識。在資料庫上它只用到一點皮毛而已

5.多種顯示模示的課題。雖然我一開始就瑣定不做responsive web design，因為我認為它是在大螢幕工作的應用，但還是碰到把分頁後的表格做成一整張列印模式的需求