你可能不知道的 – 關於 iOS 切圖那點事

講在前面:其實這一系列文章原本想取名叫「與看不出圖片糊掉的工程師戰鬥系列」,開玩笑的 (逃)~好啦!我只是想先跟各位夥伴說 … 文中所提到的習慣跟技巧都是以個人經驗為主,並不代表「這麼做就一定是正確的」!同事間能一起開開心心、快快樂樂工作的方法肯定就是好方法。如果內容有錯誤或是需要修正的地方,歡迎各位前輩給予指教,讓我們大家一起加油!

本篇文章中將提及的內容包含:

  • ICON 的切圖該如何處理?
  • PDF 圖檔要注意些什麼?
  • PNG 圖檔要注意些什麼?
  • 按鈕的切圖該如何處理?
  • 設計師常常忽略的那點事

前言

Hello,我是 Samuel,目前是一個 iOS 工程師與半個介面設計師,歡迎各路夥伴交個朋友一起學習 ? 。由於前陣子跟幾位設計師朋友聊到 iOS 切圖 上的幾個問題,意外地發現每位設計師在與工程師合作的過程中都會衍生出一套特別的合作模式;一直以來都想跟各位夥伴聊聊這種介於工程與設計之間模糊模糊沒有絕對對錯的題目,就好比在程式碼中,相同的功能並沒有絕對正確的寫法一樣(通常的處理方式是從某個維度找出一個當下的最佳解),在文章的內容中也會跟各位夥伴分享一些小弟我在誤打誤撞東拼西湊的過程中,逐漸養成的一些工作習慣與實作細節,希望多少能夠在工程與設計的合作上面提供各位一些參考。

在文章開始之前,我必須要特別謝謝「醒大」,一位在我踏入職場至今都持續不吝給予指導的大神級前輩;從程式開發、介面設計到程式架構上面都從前輩那邊學到相當多的經驗。

 

為什麼會注意到這些?

因為工作的關係,一路走來在開發跟介面設計上面大部分走的都是單打獨鬥的路線;至於共同合作的部分,由於合作的工程夥伴一個比一個厲害(Shou & Aydan),基本上一個眼神配上一張什麼都不用標注的介面圖稿(喂,我亂講的),夥伴們就能夠把畫面做到接近完美,就是那種不偷偷把你的設計間距除以二,不偷偷把字體調大 10pt 或是不偷偷加動畫加 icon 的那種完美(各位偉大的設計師,介面被亂改的痛,我懂!!!因為我聽見你們的聲音啦!!)。

為了提升整體開發的效率,在開發與設計的過程中,我們都會盡可能地透過事前的規劃來降低溝通與設計成本,規劃的議題包含如何在 iPad, iPhone 的尺寸上面快速取得平衡(透過一些簡單的數學邏輯),如何標注跟設計能夠降低工程師/設計師彼此的負擔(找出讓我最省工的模式)等等;如何切圖的教學其實在網路上隨便一撈就可以撈到滿坑滿谷,但在這篇文章中要跟各位伙伴分享的是一些設計師可能從來不會注意到的,或是那些工程師從來就沒有告訴過你的切圖技巧與背後的原因。

 

關於 ICON

一般來說,大部分的設計師在輸出 icon 給工程師時,通常會在設計好 icon 在頁面上的尺寸之後,針對正常、點擊與不可點擊三種狀態分別輸出 PNG 檔給工程師使用;這樣的合作模式其實分工相當明確,同時也不會產生其他額外的「大問題」,那你寫這篇幹嘛?當然是有原因的啊;有一些麻煩的事情像是當設計師想要微調 icon 的顏色,微調 icon 的尺寸,製作特定的動畫效果等等,往往需要重新輸出所有的圖檔,再請工程師重新置入所有更新的圖檔,一旦今天心血來潮決定來個大改版,把所有紅色的 icon 全部換成綠色的 icon 時 … 通常悲劇就很有可能發生。(工程師抵死不從,或是說好要幫你改但是不小心就失憶了?)

以我個人的習慣,在實際開始開發/切圖前我會評估 icon 設計的類型,以下圖兩個情境為例:

slicing-icon-01

 

兩者的差異在於:當按鈕或者 icon 的狀態改變時,情境1 改變的是 icon 上相同上色區域的色彩(以下圖為例,就是 Location Icon 的線條),透明區域維持不變。

slicing-icon

 

情境2 改變的則是 icon 中不同區塊的色彩(原先的透明區域被白色填滿),看不出來沒有關係,打開 iPhone 的通訊錄,底下的 Tab Bar 就是 情境2 一個最好的案例,以聯絡資訊的 icon 為例,你會發現這顆 icon 在點擊後原先透明的區塊轉成填滿的狀態,不透明的區塊轉成透明的狀態:

Tab-Bar-icon

iOS 通訊錄 Tab Bar

 

當你的 icon 使用情境以 情境2 為主時,恭喜你,保留你原本三種狀態分開出圖的習慣吧!那樣肯定會是與工程師合作最快速的一種模式(還是要往下看啊,還有其他的重點需要注意);但是當你的 icon 使用情境以 情境1 為主時,我們可以一起來嘗試一些新的設計方法。

基本的 icon 統一設定尺寸為 30×30,Tab Bar icon 尺寸統一設定為 48×48,繪製上與邊距保留至少 1pt 的間距,統一色票為 #808080,最終輸出 PDF 檔。

 

sketchapp-icon-design

 

看完這樣的做法相信大家心裡多少都會有些疑惑,就讓我們來聊聊每一項選擇的原因吧!

1. 尺寸的選擇:採用 30×30、48×48 這兩種尺寸的原因其實相當單純,在 iOS Human Interface Guideline 裡面有提到 icon 建議的兩種尺寸大小:Navigation Bar Icon 的最大尺寸建議為 28×28,一般尺寸建議為 25×25;Tab Bar Icon 的部分則為 48×32 與 25×25。我想你應該也看得出來為什麼我會選擇 30×30 這樣的尺寸吧?(嗯 … 總不會選個 29×29 來為難自己吧?)

UI - custom icon size

 

2. 尺寸的選擇 II:大部分的設計夥伴們在切 icon 給工程師時,都會根據頁面上的需求尺寸進行切圖(聽說的聽說的),需要 28×28 就切一顆 28×28 的 icon,需要 24×24 就切一顆 24×24 的 icon 給工程師,這種模式產生的問題跟接下來會提到調整顏色的問題其實相當類似,一旦設計師有微調 icon 尺寸的需求時,往下調還好不會有問題,一但往上調 icon 立馬糊給你看 ?,最可怕的狀況就是工程師可能還覺得沒有糊,開始質疑你的設計師之眼有問題,死不幫你改(眼神死),然後就讓我們一起回到切圖,改圖,跟工程師戰鬥的無限迴圈吧。在尺寸的選擇第一點裡面提到了「統一尺寸」這件事情,沒錯,輸出的 icon 統一設定尺寸為 30×30(除非你很確定你會用到更大的尺寸才需要提前做準備,不過到時候再調整也不會太遲跟費工);那 … 既然固定了 icon 的尺寸,如果在裡面需要使用到像是 24×24 這樣小尺寸的 icon 進行設計時該怎麼處理呢?基本上所有的 icon 在 Sketch 裡面都會被我製作成 30×30 的 Symbol,再加入 Symbol 到畫面後再把尺寸調整到需要的大小,沒錯!其實這就跟工程師在程式裡面做的事情一模一樣。在標注時請清楚的標註 icon 在畫面上的尺寸,但切圖時都提供統一尺寸的 icon,工程師在根據標注的尺寸在程式中進行調整,如此一來既可以避免前述的問題,同時也能夠幫助設計師整理 Sketch 中的 Symbol 頁面(看起都一樣覺得很整齊很開心)、系統性的管理所有繪製過的 icon。除此之外,這樣的設計邏輯也會讓你跟工程師走在同一個思維上面,當你發現不停調整不同尺寸的 icon 非常麻煩的時候,想必你就會意識到工程師接下來也需要跟你做同樣的一件事情,進而激發你去調整介面上的一致性 … 嗎?(笑)

3. 保留 1pt 的間距:在 30×30 的 Artboard 上面繪製小於 28×28 (上下左右各保留 1pt 的間距)的 icon 。這除了滿足上述 iOS HIG 最大尺寸的建議以外,在 icon 繪製的過程中,往往會出現一些神奇的圖形(要旋轉啦,要調整粗細那種),這些圖形常常會讓你怎麼調整都沒有辦法調到一個完美的狀態,那 … 這時候神奇的間距就發生作用啦!在這樣的狀況底下,我通常會讓 icon 超出一點點範圍,無法調整的部分就落在彈性調整 1pt 的間距裡面。

4. 統一色票(#808080):對於大部分的夥伴來講,這點可能是感到最莫名其妙的一點(笑);一般來說在 iOS 開發過程裡面如果使用的是基本的 Button 元件,相關設定圖片的程式碼如下:

DemoButton.setImage(UIImage.init(named: “正常狀態圖片名稱喔耶”), for: .normal)

DemoButton.setImage(UIImage.init(named: “點擊狀態圖片名稱喔耶”), for: .highlighted)

DemoButton.setImage(UIImage.init(named: “不可點擊狀態圖片名稱喔耶”), for: .disabled)

簡單來說就是針對不同狀態設定不同的圖片,但是相信跟你們合作的工程師應該也知道我們可以透過改變 Button 身上 ImageView 的 TintColor 來達到渲染 icon 顏色的效果(記得設定的 Image 要使用 alwaysTemplate 的 rendering mode 才有辦法上色喔),這也是為什麼在這邊使用#808080的灰階,灰階的色彩在顏色渲染上基本上不會有出錯的情形;工程師只要寫一個簡單的 Button Extension,不管是搭配 Setter 或是客製化的 Button Class,運用類似底下程式碼的邏輯,都可以輕易達到根據不同按鈕狀態渲染不同顏色的效果:

switch 按鈕狀態 {
case 正常:
DemoButton.imageView?.tintColor = 正常顏色
case 點擊:
DemoButton.imageView?.tintColor = 點擊顏色
}

這種處理方式最大的好處在於…如果設計師想要改變 icon 各種狀態的顏色時,原本需要重新輸出 n張新顏色的 icon 再請工程師幫你更換到 App 的 Asset 裡面,在過程中可能會發現像是加班加到太累不小心漏掉幾張圖,或是放到螢幕上覺得有點色差想要在微調時真的會很崩潰;現在工程師只需要幫你改一行 Code,世界從此太平,顏色就全部換完啦!

補充:除了上述日常的狀況以外,隨著前端技術的發展(App,網頁)與設計師們想像力的噴發,設計師與工程師彼此透過靈來溝通的頻率也日益增加(一種互相通靈的概念);在使用者體驗與互動效果被慢慢重視的狀況下(在不做點動畫好像就是輸別人那麼一點),客製化的按鈕肯定就會是第一個下手的目標;以下圖 Tickle 裡面的按鈕為例,唯一使用的圖檔就只有一張 30×30,#808080 灰階的 PDF icon 檔案。

Tickle 裡面的按鈕 ICON

Tickle 裡面的按鈕 ICON

5. 使用 PDF 檔案:好 PDF 不用嗎?回想當時 iOS 在 2014 年的某一個版本開始支援向量圖檔的使用,由於當時我還不會寫 iOS, 所以我也不知道是哪一個版本(逃)。重點是:對於設計師而言,使用 PDF 格式出圖就只需要處理一個尺寸,是不是很棒!但是別急,在使用 PDF 前需要提醒各位夥伴幾項重點,才能夠避免掉一些來回調整的額外成本:

a. 輸出正確的 PDF icon 尺寸
系統並不會因為它是向量的圖檔就不會糊掉;iOS 是在程式編譯時,把 PDF 圖檔根據螢幕的解析度處理成對應的 PNG 圖檔,舉例來說,當你使用潮潮的玫瑰金 iPhone SE 進行測試時,一顆 30×30 的 PDF icon,在程式運作時,iOS 系統會自動把 30×30 的 PDF 圖檔做成 @2x 60×60 的 PNG 圖檔,程式裡面使用的就是這顆由系統幫你做出來 60×60 的 PNG icon;所以注意囉!程式運作時並不是讀取原先輸出「向量格式」的圖檔,如果你在程式裡面將 icon 的尺寸設定超出 icon 自身的尺寸範圍(60×60),它馬上就會糊給你看 ?,並不能因為你給的是一顆向量格式的 icon,就可以毫無限制的在畫面上調整 icon 的尺寸喔!

Hi, 我是一顆糊掉的 icon

b. 妥善的處理 PDF 圖檔
在正常的狀況底下, PDF 格式的圖檔通常尺寸都會比較大,因此在處理時需要格外注意;遙想當時年輕不懂事,剛進公司沒多久,在製作下面這張Template圖的時候很開心的複製貼上亂疊各種圖層,然後背後留下來雜七雜八的圖層也偷懶不整理,導致最後輸出的 PDF 檔案一張就有20MB,造成工程前輩的困擾。

Tickle 中使用的 Template Image

Tickle 中使用的 Template Image

c. 使用 PDF 跟 PNG 格式的圖檔在畫質的呈現上面有沒有什麼差異呢?
對於幾何形狀為主的 icon 而言幾乎沒有任何的差異,但是對於較複雜的圖像而言 PNG 的表現實際上是優於 PDF 的。各位可以參考這篇文章的說明:Why I don’t use PDFs for iOS assets,嗯 … 這個標題好像很驚悚,但是我在讀完之後基本上都還是使用 PDF 進行切圖啦(通常是檔案尺寸降不下來或是特別追求高畫質的圖檔我才會回去使用 PNG)。老實說對於肉眼而言,兩者產生的差異幾乎是看不出來的。

d. 如果我堅持要使用 PNG 有什麼要注意的嗎?
這邊補充一個優化的小細節:在輸出類似 icon 或者 Logo 之類的 PNG 圖檔時,建議可以使用 8-bit 的 PNG 圖片(灰階圖片就是一個最佳案例)。除此之外再使用 24-bit PNG 的狀況下,也可以透過類似 TinyPNG 這樣的服務來壓縮你的 PNG 圖檔。兩種方式都可以有效的降低你的圖片大小喔;有餘力的夥伴建議可以花點時間處理一下。畢竟,一但超過 100 MB 的應用 App Store 是不會讓你透過 4G 網路下載的(Tickle 早在一年前就已經遠超過 100 MB,小弟我是很早就放棄啦 xDDD)。

。。。

在開發的過程中,也許是個人習慣關係(各種懶惰),我都會盡可能嘗試「最大彈性」的作法。換句話說「只要能在程式裡面上色,上陰影或者調整尺寸這種,大部分的狀況我都會選擇在程式裡面進行修改」,畢竟保留彈性對於未來介面的優化、調整甚至使用者體驗的改善上其實都是相當植得投資的。

 

接下來我們再來聊聊另外幾點:

按鈕

關於按鈕的部分,有不少的內容已經在上面 icon 那部分就跟各位聊過了,在這邊要另外跟各位補充幾點:

  1. 原則:在按鈕切圖這件事情上面,不論是考量到文字內容的調整,或是未來可能有 Localization 的需求,不管是 Android 或者 iOS ,基本上都應該盡可能避免按鈕 icon + 文字 一併輸出的情形。
  2. 點擊範圍:如果對於按鈕點擊範圍有調整上面的需求,以下圖為例,其實唯一要輸出的就只有一顆 30×30 的 PDF icon,剩餘調整點擊區間,按鈕大小等等的部分都應該由程式進行處理。
只要輸出 30x30 的 icon,點擊區間、按鈕大小等則由程式處理

只要輸出 30×30 的 icon,點擊區間、按鈕大小等則由程式處理

 

標注上常常會漏掉的細節

這個部分可以講的內容其實非常非常非常的多(笑),每一點背後踩過的都是滿滿的坑啊(汗)!如果設計師在設計時能夠注意到這些細節,偶爾站在工程師的立場進行設計,對於工程師而言,你彷彿就是個天使。當然,如果你能夠站出來否決 PM 或老闆,對於工程師而言,你已經如神一般的存在了(握)。好啦,有機會再跟大家分享更多這類型的狀況。

除了前面針對 icon 與按鈕的部分之外,今天我們就再來聊聊一個彈出式視窗可能會遇到的狀況吧!以下圖為例,下圖是我在 Hahow 課程中所繪製的畫面:

ios UI

 

看到這樣的畫面,相信各位都可以很快速的把畫面拆分成四個元件,包含廣告圖、標題、敘述以及按鈕。在畫完這樣的介面後,一般設計師可能會很開心的把 Artboard 輸出到 Zeplin 就以為故事到此為止了,但 … 一個善解人意的設計師卻會作出類似下列的說明:

sketch 輸出 Zeplin

 

看到滿滿的標注內容,簡單來說,這邊的重點就是:不管今天設計的是 Web, iOS 還是 Android,盡可能提前告知工程師「畫面中可能會產生變動的元件」,包含元件的數量,元件的高度等等,以及「內容發生變動時,畫面應該要如何去處理這樣的狀況」,這樣的習慣除了有效地幫助工程師規劃你的介面以外,也能夠幫助你在設計的過程中學著提前考慮畫面的狀態變化,以及保留介面上面的各種彈性等等。一旦內容有變動,在標注不清楚或讓工程師自由發揮(偷懶)的狀況下,很有可能會導致類似下圖的情形(有點誇張 xD):

UI 標註

 

對於有經驗或重視美感的工程師可能還好,一個通常在設計程式架構時就會考慮不同狀況而保留一定的彈性,而另外一個會礙於美感的關係,毫無怨言地幫你調整,但是 … 如果你遇到的是這兩種工程師以外的 … 恭喜你中獎 ??,下次好好注意一下吧(笑)。

 

結語

哇,是不是結束的有點突然!!!嗯 … 莫名其妙又寫了一堆不知道對各位有沒有幫助的內容,其實還有很多想跟各位分享、抱怨的內容但是礙於篇幅(惰性)… 就讓我保留到下一篇文章裡面吧!其實,程式可以做出非常多不同的視覺效果,但犧牲的就是工程師的時間、價值、產品效能。如果透過程式繪製時,過程過於複雜很有可能會導致效能的下降(畫面會卡卡的),找出一個彼此合作的平衡點就是這篇文章的首要任務啊(笑)。

 

本文章已獲得作者授權,翻譯自:你可能不知道的 —關於 iOS切圖那點事 by Samuel,原文出處 medium

 

 

本文章所屬設計大舌頭與作者所有,未經授權,不得轉載!如需轉載,煩請通知

如果你也喜歡我們的文章,請 Follow 我們的 Facebook 專頁,每天都會分享許多精選文章!

分享此文: