首页 → 名言 → 美文
app柵格系統布局 web柵格
日期:2023-02-22 23:47:35    编辑:网络投稿    来源:互联网
WAP APP的柵格設計  Wap App;Native App;Hybrid App(融合體,H5頁面嵌套在Native中),之所以說這三個,是因為它們相互之間的聯系在某種程度上制約了Wap App 的柵格設計。下面詳
为你推荐:
  • 100句名人名言
  • 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柵格的設置技巧

    这里有更多你想看的
  • 關于后會無期的文案
    • 本类最新
    • 精品图文
    • 时尚
    • 新闻
    • 生活
    • 视觉
    • 微爱
      栏目ID=88的表不存在(操作类型=0)

    头条推荐

    热门推荐

    特别推荐

    返回顶部