APP切圖命名規范:介紹一種通用的命名規則

13 評論 78625 瀏覽 225 收藏 7 分鐘

今天菜心要分享的內容是關于切圖命名的規范,由于最近正在總結這一部分內容,所以拿出來和大家一起分享探討一下。

關于切圖命名的規范,我個人覺得關鍵是在于團隊能夠有一個統一的規則,所有成員嚴格遵守并且和所有開發全盤拉通,不然一切都是空談。

因為不同的團隊使用的軟件都不一樣,如果經常使用sketch軟件中symbols的同學,可能在命名的時候會考慮更多內容,但是照顧到還有很多同學在使用 ps 作圖,所以這里只介紹一種通用的命名規則,當然大家也可以根據自己的實際情況去制定,這里只提供一種方法與思路,僅供參考。

一、為什么要制定規范的命名規則

1. 自身層面

對我們自己的文件整理有很大的幫助,后期修改文件、圖層的時候更加方便快捷,而且規范的命名也顯得我們自身比較專業。

2. 團隊層面

如果命名不統一,大家就很難達成共識,任務交接時需要很大的學習成本,所以規范的命名對于團隊協同也有極大的推動作用。

3. 開發層面

這一點是最重要的,可以極大的節省程序開發的時間成本,減少很多不必要的溝通與重復切圖的概率。因為只要我們的命名足夠規范,并且和開發達成共識,他們完全可以直接使用的我們切片而不更改切片的名稱,后期我們更換切圖,只要切片名稱不變,開發看都不用看直接替換就可以了。

二、所有命名全部為小寫英文字母

這一點的理由很簡單,我們的目標是讓開發直接拿我們的切圖進行使用,不能夠隨意修改名稱,但是我們要知道,開發哥哥的代碼里只有小寫的英文字母,如果你給出的命名全是中文的,那么他們是一定會更改的。所以命名全部用小寫的英文字母是最基本的規則。

三、命名格式

眾所周知,一個大型項目會分很多模塊,每個模塊由不同的設計師來獨立完成,還有人會專門管理公共的組件,如tabbar、navbar等等,這種情況下就會分為兩種切圖,一種是通用類型的切圖,還有一種就是各個模塊特有的切圖。

通用切片命名格式

組件_類別_功能_狀態@2x.png

舉例:tabbar_icon_home_default@2x.png

(對應中文:標簽欄_圖標_主頁_默認@2x.png)

模塊特有切圖命名規則

模塊_類別_功能_狀態@2x.png

舉例:mail_icon_search_pressed@2x.png

(對應的中文為:郵件_圖標_搜索_ 默認@2x.png)

當然這兩個例子都是比較基本的情況,有很多時候可能一個單詞并不能清楚的描述功能,比如有兩個名字相同的搜索圖標,大小不一,那這種情況你就可以這樣命名:mail_icon_search_big_default@2x.png,我們的原則就是清晰的表達出切片的具體內容并且沒有重復的名稱,希望大家能夠活學活用。

大家要注意,命名中不能含有空格!

四、常用英文單詞表

如果所有命名都寫為全稱,名字就會特別長,所以我們可以將一些常用的英文單詞進行縮寫,減少工作成本與開發代碼資源。至于怎么縮寫,只要整個團隊能夠達成共識并且輸出一份縮寫清單,任何縮寫規則都是可以的。

下面提供一些命名時常用的英文單詞列表(有些是已經縮寫過的,僅供參考)

  • bg(backgrond 背景)
  • nav(navbar 導航欄)
  • tab(tabbar 標簽欄)
  • btn(button 按鈕)
  • img(image 圖片)
  • del(delete 刪除)
  • msg(message 提示信息)
  • pop(pop up 彈出)
  • icon(圖標)
  • selected(選中)
  • disabled(不可點擊)
  • default(默認)
  • pressed(按下)
  • back(返回)
  • edit(編輯)
  • content(內容)
  • left/center/right(左/中/右)
  • logo(標識)
  • login(登錄)
  • refresh(刷新)
  • banner(廣告)
  • link(鏈接)
  • user(用戶)
  • download(下載)
  • note(注釋)

有些人會覺得寫這么多英文太麻煩,但其實為了自己專業能力的提高,這種規范的命名方式是必須要經歷的過程,當你習慣了這樣的命名方式后,你的成就感會油然而生。

五、總結

今天要分享的內容就這么多,最后還是想和大家說,有什么不懂得地方,真的要多去咨詢開發的同事,去思考問題的本質原因是什么,每一個小問題都需要我們去透徹的理解,反之積攢多了,最后吃虧的還是你自己。

任何別人給出的規范,都不要直接拿來就用,要去思考為什么用這樣的規范,解決什么樣的問題?你有沒有更好的解決方案?試問一下,蘋果和安卓開發的切圖文件管理機制是怎樣的?有什么區別?如果這么基礎的問題你都不知道,而是拿著別人的規范直接套用,那結果就是被別人牽著走。

所以去了解所有表層背后的思考與邏輯,也許下一個規范就是你制定的!

 

作者:菜心(微信公眾號:菜心設計鋪),華為ITUX用戶體驗設計師(主視覺)

本文由 @菜心 原創發布于人人都是產品經理。未經許可,禁止轉載。

更多精彩內容,請關注人人都是產品經理微信公眾號或下載App
評論
評論請登錄
  1. 總結的真好,即使是兩年前制定的現在也覺得很規范又明了。但是 background 好像寫錯了喲 ??

    來自浙江 回復
  2. 這種命名在sketch中OK,但是不知道菜心用不用principle,在principle里面做動效,同一個按鈕的不同狀態為了創建補間是需要命相同的名字的。之前我也是用文中的這種命名方法,結果一導入到principle里面我就崩潰了,圖層亂飛,后來還是全部重新命名

    來自廣東 回復
  3. pressed是默認狀態嗎??

    來自香港 回復
  4. 模塊_類別_功能_狀態@2x.png , almost a coder ,orz

    來自廣東 回復
  5. ??

    來自廣東 回復
  6. 瞎扯、、、要么prototype里注釋清楚,要么開發自己能找到就行了,復雜化反而減低團隊效率

    來自廣東 回復
    1. 不知道閣下在哪個大團隊就職,是騰訊還是阿貍?這種命名格式至少解決了我們目前團隊協作出錯的問題。我也說過了,問題的關鍵是在全局拉通。至于每個團隊各自也許會有不同的習慣與制度,分情況而定。
      如果您是一個人的團隊,其實不命名都是可以的。

      回復
    2. 支持菜心,我是菜花

      來自上海 回復
    3. 2019了 這個命名規范現在還在用

      來自廣東 回復
  7. 我們的做法是,視覺第一次切好圖放共享上,如果開發覺得有必要就修改名字,沒必要就不修改名字,視覺后期重新切圖時,一律以開發在共享上確認的名字為準。

    來自廣東 回復
    1. 恩,這種做法是非常棒的,我們是各個模塊的設計師放在svn上面共享,審核資源通過后,才會發給開發,但是暫時沒有和開發共享的機制。

      來自廣東 回復
  8. 平時我們進行開發的時候,是自己切圖,所以全部都是全拼或者是縮寫,但是沒有這么細致,所以更改圖片的時候,相對來說有點麻煩了,看到你的這篇分享,還是有所幫助的,多謝

    來自上海 回復
    1. 謝謝支持

      回復