1，頁面寬度問題
主要內容部分，目前主要的解析度一般都在960以上：960、1000、1200等，這些都屬於正常的尺寸，但也有設計師做出類似973、1011等奇葩尺寸… 這個問題我不太好意思拿出來聊，太低階了。當然，奇葩的單數行高、相同元素不同大小等等這都是屬於相似問題。
2，毛邊問題
乙個方方正正的按鈕，帶著一圈毛邊。這個問題也是在重構中經常看到的事情，雖然這個在寫頁面的時候可以很輕易的避開這個問題，但是不是看著很不爽？看下圖：
正常邊給人的感覺整齊乾淨，毛邊顯得邊緣模糊不清，並且容易造成按鈕高度不明確。假如是半透明按鈕需要切圖的時候，還會造成體積變大，所以這個問題應當避免。
3，圖層模式
有些設計圖中，某個元素例如某個按鈕，需要切png半透明，但是這個按鈕居然跟背景圖是正片疊底或者顏色疊加。每當我遇到這個問題的時候會有一股想自殺的衝動，所以為了世界和平，這個問題一定要避免。
4，圖層鏈結
頁面重構的某些時候需要選擇某些圖層進行移動，結果一動發現壞了，好多其它的元素跟著刷刷移動，瞬間感覺無力，默默的乙個個取消圖層鏈結。不需要的圖層鏈結，能取消就取消吧。
5，某些的尺寸
例如在某些列表中，縮圖的尺寸，經常會遇到119*73等等奇怪的尺寸。其實這種最好是用整數：120*80等，對頁面的柵格化、響應式以及後台裁圖存圖等都有很大的好處。
6，圖層命名和資料夾
這個其實跟題目關係不大，但這裡要提一下。舉個例子：
你喜歡哪個？不用說了吧…
7，奇葩的邊距和填充
同等級的模組，從視覺及內容上都屬於同一型別，但上下邊距乙個20px乙個27px，左右填充乙個10px乙個7px，這種問題跟「1.頁面寬度問題」類似，都屬於低等級問題。
8，需要運營的文字內容使用特殊字型
這個請google一下網路安全字型，中文的安全字型少的可憐，放過非設計師的頁面使用者吧。
9，不做極限設計
假如要設計乙個按鈕，放在某個比較小的模組裡，那麼請考慮一下按鈕包含的字數最長的情況下是怎樣的。再比如乙個類似微博名片的東西的簡介，設計圖中做了30個字，那麼請考慮下100個字的情況。假如需要做截字，請規定多少字或者幾行字開始截，不要讓前端去猜。
以上問題都是設計師經常遇到的一部分問題，並不是全部，下邊說說前端這邊的。
1，用輔助線說話而不是自己猜測
很多前端自詡畫素眼，一眼就知道某個模組的邊距是多少，字型有多大。這個一般問題不大，但有些時候差一兩個畫素你不一定看的出來。凡是涉及到尺寸問題，一律輔助線。
2，css3圓角還是切圖圓角？css3投影還是切圖投影？
3，各種寬度寫死，各種切大圖啪啪啪
前者會導致，只要編輯或者資料與設計圖中的不一樣，你的頁面效果就完全「不一樣」了，做頁面重構怎麼算優秀？最大程度的模組化、最大程度的模組可移植性、最大程度的自適應性、各種極限情況的考慮。也就是你考慮的情況越多，自適應性越強，你的**越健壯。
後者會導致啥？後台或者編輯拿著刀子**…
4，字型問題
假如一段需要後期編輯或者拿資料的文字內容，設計圖裡是乙個特殊字型，例如：「方正蘭亭西黑」，你自己電腦上也有，然後你直接在css樣式裡用了這個字型… 會有啥結果不用多說了。遇到這種情況最重要的是需要跟設計商議，替換成安全字型，例如：微軟雅黑、宋體、黑體、arial等，假如設計死活不同意，講道理！再不同意，叫上產品經理一起講這個問題。
同樣，以上問題也只是眾多問題中的一小部分，以後想到的話也會逐漸補充進去。解決各種問題最好的辦法是：多溝通。
react與前端UI介面進行互動
在react中通過this.state在construtor構造器裡面進行設定值，對變數進行初始化，然後在render 函式的內部進行this.setsatae 鍵值對改變值，通過props在ui介面裡面進行資料間的互動。const cardexamplecard props wilson 管理員 ...
前端的UI設計與互動之資料展示篇
合適的資料展示方式可以幫助使用者快速地定位和瀏覽資料，以及更高效得協同工作。在設計時有以下幾點需要注意 依據資訊的重要等級 操作頻率和關聯程度來編排展示的順序。注意極端情況下的引導。如資料資訊過長，內容為空的初始化狀態等。1 被公認為是展現資料最為清晰 高效的形式之一。注 1.中的時間 狀態 操作欄...
許可權系統與UI互動心得
截止到現在，itoo許可權系統已經做到了3.0版本了，當接收3.0的時候，大家反應，許可權系統的介面沒有被ui系統控制，所有的css樣式，以及js 都是系統內部人員自己編寫的，所有3.0的任務之一就是要和ui系統進行互動。當3.0開始以後，框架的搭建就花費了半個月的時間，隨後就是整合 出介面，看著u...