設計的開源協作思考-2

繼上次與友人亂聊的說到設計如何開源協作這件事

今天因為前輩的這篇文章:設計師的版本控管被cue到,引發了我的二度思考,一位上次只是聊聊並沒有再次分析設計的gap在哪,今天剛好借這個機會來理理頭緒,希望順便整理出g0v適用的設計模式。

這已經不是我第一次聽到有人在許願說要一個設計師的github,大概有如月經一樣一個月會聽到一次,但是設計師需要的到底是啥?

根據某次深夜的促膝長談(真的很愛聊)我跟友人討論著設計與工程的差別,大部份的“設計師github“幾乎都以工程角度出發,這是什麼意思?就是許多位設計師開發的版本控制系統,都擺脫不了github的思維模式。確實github的種種功能可以快速地達到開源協作的功能,但為什麼設計不能用同一套模式進行??

共通的語言不同

雖然說程式語言百百種,但是github所要處理的是”字元“,但是設計師的產出光一個psd檔可能那個大小就抵過五六個專案。那麼除了psd檔案外,遑論ai,pdf,sketch.jpg,svg等等等等一堆可相容不可相容的檔案,所以設計的共通語言是”畫面“,沒有畫面,無法討論。

這件事情在我轉戰sketch的時候發現他與invision上個月的合作將這件事情做得很不錯
Sketch + Invision
在sketch的每一次存檔透過invision的雲端系統做及時的連動,而invision本身具備多人協作的功能,雖然無法記步驟,但是invision將sketch裡的每一次變動圖都記錄下來。聊勝於無,有圖就知道之前是怎麼個回事,夠讓我振奮了

記錄步驟

photoshop裡面有記錄步驟的基本功能,但除非要複製同樣的工作模式,才會使用到,但作為步驟記錄的基礎已經足夠,但是同樣的問題,沒有畫面我也不知道你要回復到哪個動作去。而且設計師在調位子的時候常常移過來之後又放回去,光想要怎麼判斷哪個點要記錄就挺頭大的。

如果說要以程式碼去做記錄,現行的向量檔都可以做到如svg(illustrator,sketch),但是結果一樣是很肥很肥的檔案,而且設計會受制于扁平化。

風格挑戰、影像格式挑戰

風格就是設計師之間的溝通問題了,但是影像格式的話就會很麻煩,所以我們腦中對設計師github的想像大概是一個超級雲端繪圖軟體吧,不然向量檔、點陣圖你怎麼應付,這件事情由一個系統做整合還不如由繪圖軟體本身做開發,我想adobe一定想過這種事情,給他們煩惱好了

人為版本控制

以前在做稿,就會習慣性做人為版本控制,美其名是版本控制不如說是留後路、做比較。像是做編輯設計的時候,老師就說可以將不同做比較,於是我的一份ai檔裡面就會有好幾個複製區,以便回頭是岸。面對客戶則是不斷的另存新檔,對工程師來講還在傳檔案存備份應該真的是很受不了,但是不存的悲劇也是讓人更受不了。

縱觀以上的幾點思考,要做到像github一樣的系統,在當下的科技與技術上是很吃力的,就連我在用invision時也是覺得不夠即時(他處理圖檔需要花時間),今天暫時性的討論結果是

如果想要記錄所有的動態、檔案=>等待電腦處理器與網路大進化
不記錄動態=>必須作好檔案管理、備份、或是紀錄圖檔(invision)

所以,等待技術吧(這裡指的是硬體技術)or try to figure out something。這件事情,又回到g0v的基礎建設,如果現有技術跟不上,勢必建立出一個良好的人為模式,協作的習慣。
嗡嗡嗡,來去籌備設計松
希望由我這個菜鳥搞出來的設計松大家會捧場嗚嗚,上週在黑客松跟幾位資深設計師聊天讓我好剉….如果講出什麼很怪的理論還是原諒我吧,因為沒有人要做所以我就當一下沒有人啦。

對「設計的開源協作思考-2」的一則回應

  1. 引用通告: 設計的版本控制服務-實測心得 | mooon._

發表迴響

在下方填入你的資料或按右方圖示以社群網站登入:

WordPress.com Logo

您的留言將使用 WordPress.com 帳號。 登出 /  變更 )

Google+ photo

您的留言將使用 Google+ 帳號。 登出 /  變更 )

Twitter picture

您的留言將使用 Twitter 帳號。 登出 /  變更 )

Facebook照片

您的留言將使用 Facebook 帳號。 登出 /  變更 )

w

連結到 %s