- 相關(guān)推薦
WAP APP的柵格設計
Wap App;Native App;Hybrid App(融合體，H5頁(yè)面嵌套在Native中)，之所以說(shuō)這三個(gè)，是因為它們相互之間的聯(lián)系在某種程度上制約了Wap App 的柵格設計。下面詳細說(shuō)下柵格試驗。
Phone柵格和PC柵格，本質(zhì)上沒(méi)有區別，一樣的計算方式，無(wú)外乎屏幕大小的差別，但這屏幕大小，就有很多細節需要結合手機用戶(hù)習慣來(lái)判斷和取舍。我們試驗的Phone柵格都是流體柵格，簡(jiǎn)單說(shuō)，就是不定義具體尺寸，而是屏幕占比。
說(shuō)到屏幕占比，我們需要設定基準屏幕(這個(gè)可根據某些具體數據確定，比如我的目標用戶(hù)群使用的手機屏幕尺寸占比最多的是1136*640，即可定位基準屏幕)，這里假定基準屏幕是960*640 。
通常柵格的計算公式 (m+a)*n-a=640-2b (m 柵格寬;a 槽寬;b 留白寬;n柵格個(gè)數)
試驗 1
m=40 n=12 a=10 b=25(我們通常定義柵格數目n是2，3，4，6的整數倍，12柵格算是最簡(jiǎn)單的柵格結構)。
試驗1的柵格是沿襲PC的思想，但在后來(lái)應用到越來(lái)越多的頁(yè)面時(shí)，這種柵格做2，3，4，6等分都很OK，但不做等分時(shí)，靈活性就很差，也算是一個(gè)致命的缺點(diǎn)，對于視覺(jué)設計師來(lái)說(shuō)有很大的局限性。所以不建議在手機上使用12柵格。
試驗 2
m=44 n=12 a=8 b=12。
試驗2和試驗1其實(shí)差別不大，柵格數目都是12，也算是相對早期提出的(還沒(méi)有覺(jué)得12柵格的靈活性差)，相當于是試驗1的優(yōu)化：一是覺(jué)得兩邊留白寬度25略大，二是可以在一個(gè)單位柵格內取到最小的可觸摸尺寸44*44。但其實(shí)真正應用到界面上時(shí)體現的價(jià)值并不大。當然后來(lái)發(fā)現12柵格的弊病后，便一并放棄了。
試驗 3
m=18 n=24 a=8 b=12。
24柵格是基于設計的靈活性而提出的。在應用中，無(wú)論是等分，還是靈活性，還是前端對于柵格的基數考量上，都相對合理，但依然沒(méi)有最后選擇這種柵格，這就牽扯到開(kāi)始提到的Hybrid App。
需要應用柵格體系的H5頁(yè)面，大部分是要嵌套到Native App中，所以要盡量讓嵌套頁(yè)面看起來(lái)和原生界面保持統一性，而App 有一個(gè)不成文的柵格規定，任何的界面尺寸都要是4DP的倍數，也就是最小柵格單位要是8Px(當然這可能也是沒(méi)有足夠經(jīng)驗的原因，到最后和APP團隊溝通后才了解到，所以到試驗柵格后期才采用了柵格試驗4的方案)。
還是建議大家，如果你設計的WAP不需要配合Native，選擇24柵格是相對完美的一種方案。
試驗 4
m=8 n=80 a=8*2 b=8*3。
整個(gè)界面按8Px的尺寸等分80分，靈活性很好，可以很好匹配N(xiāo)ative。但也有不夠完美的地方，一是不論對視覺(jué)設計師還是前端工程師，應用起來(lái)都不方便，計算起來(lái)相對麻煩;二是不能3等分和5等分界面，需要在設計和開(kāi)發(fā)時(shí)做特殊處理，當然用戶(hù)是看不出來(lái)的。但因為要保持終端的一致性，所以我們對于wap柵格設計采用了柵格4。
【W(wǎng)AP APP的柵格設計】相關(guān)文章：
wap和app手機網(wǎng)站的不同08-11
分析與設計WAP的推送技術(shù)09-17
WAP的簡(jiǎn)介08-11
柵格使扁平化設計更輕松09-01
何謂WAP10-02
裝潢設計軟件APP推薦10-11
CAD柵格的設置技巧06-15
WAP基本知識的介紹09-12
WAP中WML卡片輸入的教程06-29