萬盛學電腦網

 萬盛學電腦網 >> 網頁制作 >> 交互設計 >> WAP APP的柵格設計

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柵格。

WAP APP的柵格設計 三聯

  試驗 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。

copyright © 萬盛學電腦網 all rights reserved