在互聯網產品的研發流程中,頁面的視覺還原是很重要的一個步驟,也往往是問題最多的一個環節。如果一些細節問題在這個環節沒有被有效地發現並解決,那麼後續流程中再去解決這些問題的成本就會呈指數上升。
那麼今天我們就來梳理一下,看看前端工程師本身以及上下游的角色之間,都會容易遇到哪些常見的問題。
設計師
設計師是最貼近產品體驗的人,但是術業有專攻,設計師往往更加注重視覺的表現,而容易犯一些美麗的錯誤:
1,以原生 APP 的體驗類比 H5 頁面設計
我們都知道,原生 APP 的體驗非常流暢,界面也非常華麗,所以設計側也盡量向原生 APP 的體驗靠攏。但是現實往往很殘酷,許多 APP 的體驗換到 H5 上實現就慘不忍睹,比如一個包含復雜操作的浮層,在各種低端機上可以說是漏洞百出。所以這裡,建議設計師可以多比照其他 H5 網站的表現來進行設計,而不要經常比照 APP 的體驗。
2,設計稿都是最完美的狀態
是的,設計稿上面往往體現的都是最完美的狀態。而前端開發人員往往要考慮各種溢出狀態,多個超出、折行、撐開等等。這些情況多數在設計稿上不會體現,往往要到開發過程中再去確認細節,比較浪費時間。
3,活字用了非系統字體
所謂活字,就是直接以文本形式展示在頁面上,而不是用圖片模擬的文字。對於這部分字體,我們一般會采用系統字體中的一種,不會因為幾個特殊字體而去加載一套中文字體文件。如果是英文字體,還可以考慮在高級浏覽器下的自定義字體,不過也要考慮優雅降級,以及字體的版權問題。所以老大問:為毛跟設計稿不一樣?我們只能說,沒這字體啊… 這裡建議,即使是設計稿,活字也要用系統字體,否則就是坑啊,看著好看又實現不了。
4,版本不清晰
設計出的稿子,往往是一段時間的規劃功能,再去跟產品確認。而產品一般會說,這個先不要,那個先不做。但當真正去掉之後,所有這些間距調整,顏色背景影響等等,還是要再跟設計師確認。所以如果可能的話,應該每次需求只突出變更部分,而不是一個大而全的稿子。
5,這個應該這麼切
關於這個問題,已經無力吐槽了,這頁面真的不是切出來的。你說這麼切那麼切,你切個給我看看?分明是撸出來的嘛~
前端開發
前端開發,也有稱頁面仔,切圖仔,在還原設計的過程中,容易遇到的問題就更多了:
1,不考慮溢出
關於溢出這裡有個基本的法則,就是只要是動態輸出內容,或者有用戶輸入的,就一定要考慮溢出狀態的展示。文字溢出,列表溢出等等。當拿到設計稿時,確認好布局之後,就是各種溢出狀態的確認了。
2,不分析設計稿就動手寫代碼
作為新手拿到設計稿之後,往往都想很快寫代碼,因為寫代碼才有快感。殊不知,頁面結構的分析就跟程序架構一樣重要,分析透徹才能兼顧各種情況以及部分的需求變更,所謂磨刀不誤砍柴工,結構分析一定要先做的。
3,不考慮增刪元素的狀態
稍微大一點的公司,往往是多個需求並行,所以設計稿可能有超前的部分,或者中間由於各種原因實現不了的功能。作為一個合格的前端工程師,在實現頁面的時候,就要做到一些可能變動的部分就算刪掉也不會對頁面造成大面積影響。
4,不考慮可維護性
能自適應的地方盡量用自適應,以便應付需求變更。比如多個樓層,寬度調整,加個icon等等。舉個簡單例子,比如一個框框中間有個居中的按鈕,很多新手是直接用 margin-left 來定位的,這樣如果外層框框寬度調整,這個 margin-left 值就得跟著調整。雖說調個寬度也不麻煩,但是當開發大型復雜頁面的時候,這些聯動的小改動也足夠搞死人了。
5,不仔細看設計稿
最常見的錯誤就是,設計稿上有邊框,但是顏色太淡沒看到。或者設計稿沒邊框,由於迭代樣式,加了深色背景,忽略了邊框沒有去掉。還有一種情況就是設計稿上的色塊是蓋住邊線的,但是實現的時候沒有蓋住,就導致那一部分看起來像凹進去一樣。
6,看出 1px 沒那麼難
很多新人都覺得要對齊 1px 的差距好難,聽上也有點吹毛求疵了。但是你想想,假如你是設計師,辛辛苦苦做出來個設計稿,哪哪都對不齊,你不會覺得不爽?其實只要你認真仔細看,再加上一些練習,差幾像素幾乎一眼就可以看出來。實在不行感覺不確定,可以截圖到 PS 裡面放大,再用參考線對比。
7,不考慮可擴展性
很多時候我檢查頁面還原,無非是多加幾個項目,多填些文字先試試看,但是很多人這一關都過不了。加了項目,要麼就是沒有設置多行時候的下邊距,要麼就是再多一行邊框變了,或者結尾的項目又要單獨設置樣式。加了文字,就直接頂出去毀了結構。
好了,吐槽這麼多大家一定已經夠了,相信大家在工作流程中都會遇到各種各樣的細節問題,還有一些反反復復一遍又一遍遇到的問題,比如忽然一陣捉急的跑來:這個頁面怎麼亂了啊啊啊,麻煩快看看~~~答:ctrl+0,你放大了…… So,你有沒有什麼想吐槽的呢?