切圖及效果圖管理

前言

設計師和程序猿溝通老是須要花費很多時間,而且不少時候由於沒有規範可依最終致使設計師修改設計或切圖(開發童鞋通常比設計師更強勢)。凡是這類問題均可以經過規範來改善和提升效率。網上不少編碼規範和設計規範,可是缺少程序猿和設計師之間溝通的規範。下面我和你們分享一下目前我工做中程序猿和設計師的溝通規範--切圖命名及切圖管理。若是你有更好溝通規範歡迎留言分享,也能夠加羣溝通:19676167七、311536202。android

命名規範

目前存在的問題

  • 設計師不知切圖如何命名,尤爲是圖片多了以後。
  • 設計師不知道應該命名成中文仍是英文,使用中文的話那麼在程序這邊用的時候還須要程序猿從新命名,使用英文的話估計只有本身看得懂。

命名規則

統一的命名規則:功能_ 尺寸 _ 主題 _ 狀態,固然其中有一部分是能夠省略的。ios

命名元素

  • 名稱(按功能)。這個切圖的名稱。
  • 尺寸。一般是指大小。
  • 主題。一般包括兩部分,一部分是主題名,一部分是主題樣式。
  • 狀態。咱們經常使用的包括4個狀態:正常、點擊、不能點擊、選中。

示例說明

完整命名

咱們有一個消息按鈕圖標。下面是咱們應該考慮的幾個點。git

  • 名稱。圖標的功能是消息。
  • 尺寸。暫且咱們認爲消息圖標有2個界面都在使用,並且一個是大圖標一個是小圖標。
  • 主題。通常狀況都不會有換皮膚的要求(畢竟這個工做量大),暫且咱們認爲這個消息會有深色和淺色的樣式。
  • 狀態。按鈕的狀態一般有三種,正常(一般都是設計的時候考慮的天然狀態)、點擊(手指點擊上去沒有釋放時候的狀態)、不可點擊(不知足條件時不可點擊的狀態)。 根據以上的一些點,那麼咱們消息切圖命名分別爲。
  • msg _ small _ light _ normal
  • msg _ small _ light _ pressed
  • msg _ small _ light _ disable
  • msg _ small _ dark _ normal
  • msg _ small _ dark _ pressed
  • msg _ small _ dark _ disable
  • msg _ large _ light _ normal
  • msg _ large _ light _ pressed
  • msg _ large _ light _ disable
  • msg _ large _ dark _ normal
  • msg _ large _ dark _ pressed
  • msg _ large _ dark _ disable 這是一個比較全的命名,基本上能夠應付咱們工做作的絕大部分截圖的命名。設計師也能夠根據本身的需求簡化命名。

簡化命名

仍是上面的栗子。只是條件變了,咱們認爲這個消息按鈕圖標只有一個地方在用。web

  • msg_normal
  • msg_pressed
  • msg_disable 所謂的簡化命名實際上是咱們去掉了命名中固定屬性部分(大小、主題樣式)。
  • 看看咱們實際切圖是如何作的,如圖:

命名總結

  • 這樣有章可循的命名規則可讓設計師不用爲命名發愁,惟一須要肯定的就是名稱部分。
  • 這樣命名的切圖在多個平臺上(android、ios)直接使用不須要再重命名,最明顯的好處是有兩點。
    • 程序猿徹底不用考慮圖片命名的問題。
    • 設計師換切圖的時候能夠直接拷貝到程序資源中覆蓋掉以前的就能夠了。(尤爲是換圖比較多的時候能夠體現出優點)

切圖管理

目前存在的問題

  • 切圖到底放在哪了,我找不到。
  • 切圖目錄太多、太亂,我只關心我須要的那部分。
  • 項目多了以後應該若是管理,徹底沒有套路。

歸類管理

  • 管理工具。圖片資源託管在gitlab上(大部分設計師不熟悉git,全部暫時不涉及分支)。
  • gitlab項目命名規範。採用命名規則爲:平臺 _ 項目名,eg:移動端p2p項目->app_p2p。
  • 項目目錄層級結構:項目名->版本號->切圖倍率(@2x/@2.88x/@3x)。
  • 全部的切圖都放在上面對應的目錄中,程序猿這邊使用git拉下了就好了。

示例(如圖)

效果圖管理

目前存在的問題

  • 目前用的比較可能是方式是文件拷貝或者文件共享。但此方式不適合異地配合。
  • 以文件拷貝的方式那麼每次更改的內容說明比較麻煩。
  • 效果圖上標準不全,不許確。
  • 效果圖標註工做量較大,並且都是苦力活,浪費人生。

更好的方式

使用瀏覽器就能時時看到效果圖及標註。瀏覽器

使用的工具

  • 設計工具。app的設計使用sketch。使用插件不用擔憂切圖和標準不規範(不過偶爾仍是有小偏差,徹底能夠接受)。
  • 使用gitlab進行版本管理。
  • 使用jenkins監控gitlab的更新,自動發佈到web服務器。
  • 須要一個web服務器。

總結

一旦肯定了切圖的命名方式和切圖的目錄,那麼程序猿和設計師溝通上面會省不少溝通時間,而且咱們也但願凡是和UI相關的內容都由設計師這邊來主導。服務器

相關文章
相關標籤/搜索