WAP APP的柵格設計
Wap App;Native App;Hybrid App(融合體,H5頁面嵌套在Native中),之所以說這三個,是因為它們相互之間的聯系在某種程度上制約了Wap App 的柵格設計。下面詳細說下柵格試驗。
Phone柵格和PC柵格,本質上沒有區別,一樣的計算方式,無外乎屏幕大小的差別,但這屏幕大小,就有很多細節需要結合手機用戶習慣來判斷和取舍。我們試驗的Phone柵格都是流體柵格,簡單說,就是不定義具體尺寸,而是屏幕占比。
說到屏幕占比,我們需要設定基準屏幕(這個可根據某些具體數據確定,比如我的目標用戶群使用的手機屏幕尺寸占比最多的是1136*640,即可定位基準屏幕),這里假定基準屏幕是960*640 。
通常柵格的計算公式 (m+a)*n-a=640-2b (m 柵格寬;a 槽寬;b 留白寬;n柵格個數)
試驗 1
m=40 n=12 a=10 b=25(我們通常定義柵格數目n是2,3,4,6的整數倍,12柵格算是最簡單的柵格結構)。
試驗1的柵格是沿襲PC的思想,但在后來應用到越來越多的頁面時,這種柵格做2,3,4,6等分都很OK,但不做等分時,靈活性就很差,也算是一個致命的缺點,對于視覺設計師來說有很大的局限性。所以不建議在手機上使用12柵格。
試驗 2
m=44 n=12 a=8 b=12。
試驗2和試驗1其實差別不大,柵格數目都是12,也算是相對早期提出的(還沒有覺得12柵格的靈活性差),相當于是試驗1的優化:一是覺得兩邊留白寬度25略大,二是可以在一個單位柵格內取到最小的'可觸摸尺寸44*44。但其實真正應用到界面上時體現的價值并不大。當然后來發現12柵格的弊病后,便一并放棄了。
試驗 3
m=18 n=24 a=8 b=12。
24柵格是基于設計的靈活性而提出的。在應用中,無論是等分,還是靈活性,還是前端對于柵格的基數考量上,都相對合理,但依然沒有最后選擇這種柵格,這就牽扯到開始提到的Hybrid App。
需要應用柵格體系的H5頁面,大部分是要嵌套到Native App中,所以要盡量讓嵌套頁面看起來和原生界面保持統一性,而App 有一個不成文的柵格規定,任何的界面尺寸都要是4DP的倍數,也就是最小柵格單位要是8Px(當然這可能也是沒有足夠經驗的原因,到最后和APP團隊溝通后才了解到,所以到試驗柵格后期才采用了柵格試驗4的方案)。
還是建議大家,如果你設計的WAP不需要配合Native,選擇24柵格是相對完美的一種方案。
試驗 4
m=8 n=80 a=8*2 b=8*3。
整個界面按8Px的尺寸等分80分,靈活性很好,可以很好匹配Native。但也有不夠完美的地方,一是不論對視覺設計師還是前端工程師,應用起來都不方便,計算起來相對麻煩;二是不能3等分和5等分界面,需要在設計和開發時做特殊處理,當然用戶是看不出來的。但因為要保持終端的一致性,所以我們對于wap柵格設計采用了柵格4。
【WAP APP的柵格設計】相關文章:
1.Website、WAP、APP的差異化設計
2.wap和app手機網站的不同
3.分析與設計WAP的推送技術
4.WAP的簡介
5.柵格使扁平化設計更輕松
6.何謂WAP
7.裝潢設計軟件APP推薦
8.CAD柵格的設置技巧
这里有更多你想看的
|
- 上一篇:校園元旦主題活動策劃方案怎么寫 校園元旦主題活動策劃方案模板
- 下一篇:返回列表