APP切圖命名規范:介紹一種通用的命名規則
今天菜心要分享的內容是關于切圖命名的規范,由于最近正在總結這一部分內容,所以拿出來和大家一起分享探討一下。
關于切圖命名的規范,我個人覺得關鍵是在于團隊能夠有一個統一的規則,所有成員嚴格遵守并且和所有開發全盤拉通,不然一切都是空談。
因為不同的團隊使用的軟件都不一樣,如果經常使用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用戶體驗設計師(主視覺)
本文由 @菜心 原創發布于人人都是產品經理。未經許可,禁止轉載。
總結的真好,即使是兩年前制定的現在也覺得很規范又明了。但是 background 好像寫錯了喲 ??
這種命名在sketch中OK,但是不知道菜心用不用principle,在principle里面做動效,同一個按鈕的不同狀態為了創建補間是需要命相同的名字的。之前我也是用文中的這種命名方法,結果一導入到principle里面我就崩潰了,圖層亂飛,后來還是全部重新命名
pressed是默認狀態嗎??
模塊_類別_功能_狀態@2x.png , almost a coder ,orz
??
瞎扯、、、要么prototype里注釋清楚,要么開發自己能找到就行了,復雜化反而減低團隊效率
不知道閣下在哪個大團隊就職,是騰訊還是阿貍?這種命名格式至少解決了我們目前團隊協作出錯的問題。我也說過了,問題的關鍵是在全局拉通。至于每個團隊各自也許會有不同的習慣與制度,分情況而定。
如果您是一個人的團隊,其實不命名都是可以的。
支持菜心,我是菜花
2019了 這個命名規范現在還在用
我們的做法是,視覺第一次切好圖放共享上,如果開發覺得有必要就修改名字,沒必要就不修改名字,視覺后期重新切圖時,一律以開發在共享上確認的名字為準。
恩,這種做法是非常棒的,我們是各個模塊的設計師放在svn上面共享,審核資源通過后,才會發給開發,但是暫時沒有和開發共享的機制。
平時我們進行開發的時候,是自己切圖,所以全部都是全拼或者是縮寫,但是沒有這么細致,所以更改圖片的時候,相對來說有點麻煩了,看到你的這篇分享,還是有所幫助的,多謝
謝謝支持