Sharing files via Dropbox, Box, iCloud, Sync is a thing of yesteryear.
The day just before Sketch 43 launched, I published the article Design Is Code and Code Is Design. The article covers what the open format will mean and imply for the design profession. Since writing the article I kept thinking about the challenges that teams would face in making the open format a part of their design workflow.
What intrigued me the most was how practical the open format is right now.
(Pssst: blended.io will launch two workshops: Version-Controlled Sketch for Skillful Designers & Design Teams and Git for Marvellous Designers)
Integrate Sketch into a versioning workflow based on Git whilst making it as simply as possible for non-technical people to use it (read about the benefits here).
Let’s get to the details.
Step 1: Understand the new sketch file format
As described in the initial Design Is Code & Code Is Design article Sketch now allows to get to the data behind the visuals. What do we get: The unzipped .sketch file contains a small preview image and JSON data for all layouts (as well as some user- and document related data). The pages folder contains one single JSON file for each page. These JSON files contain the data for every single element that is designed in Sketch. Furthermore, the .sketch file contains originally sized images for all image assets.
There are a couple of things to note about extracting or creating a .sketch file
Step 2: Use a git platform to collaborate with sketch
(True) collaboration via Github or Gitlab requires data to be human-readable (aka text files) instead of in a binary format. The vector data comes as JSON which is good for versioning. All binary images are also included which is not great for versioning. To be clear, versioning does also work with binary files. The difference is though that in versioned binary files, the entire file will be stored with each version. When versioning is applied with text files only the differential change will be recorded. This mechanism keeps repo sizes small and maintains speed.
Although having binaries in a repository isn’t great, storing original images isn’t all that bad: A “change” will be recorded in the repository first when an image is added and second when it is removed (for a max. of two records). All changes in between are simply references to the original source file and therefore the source is not stored again and again. The preview image does change constantly and, therefore, we decided to remove it.
Let’s use Github as the collaboration platform for our imaginary team of designers (and developers).
We have two issues to start with:
The conceptual workflow would be as follows
Based on the capabilities that Sketch gives us now, the actual base-bones workflow as outlined below is this:
$ sh upload.sh "message"
(from within the repo) in order to commit and push the changes to Github.$ sh download.sh
(from within the repo) in order to download the latest state and to continue her work.The upload script extracts the core Sketch data from the file .sketch and then uploads (commit and push) only that core data (plus the scripts on the first push). The core data is versioned on Github, hence, we do not need the original .sketch file. It would only clog the repo and reduce speed.
The download script pulls all new data from the repo and then creates the sketch file .sketch which you can open with Sketch.app.
You can execute the script like this:
sh upload.sh "message"
or sh download.sh
. A message must be added otherwise $1
will be used as the (commit) message text.
upload.sh
and download.sh
in TextEdit (or any other text editor) and add the filenames without the extension .sketch
into the ""
like so files="filename1 filename1"
. Save both scripts.
How to add Sketch files into the file upload.sh script.
How to add Sketch files into the file download.sh script.
For you to test-drive the workflow, you will find the entire repo on Github.com as well as both scripts, upload.sh and download.sh.
Pros
file1.sketch1, file2.sketch, …, file12.sketch, file12-final2.sketch etc
Cons
I am aware that we could use Githooks, a NodeJS file watcher or a Sketch plugin to streamline the actual process above (I am happy to hear your feedback and suggestions). I did choose to build a script because it allows us to test-drive the lowest common denominator. A simple workflow will be crucial for non-technical people to use repos for their design work. Using scripts in Terminal isn’t the greatest thing since sliced bread and therefore this process and workflow is to be improved quite a bit to ease the way. Besides, auto-save should be deactivated as it might overwrite freshly pulled data.
I am very much convinced that the fundamentals described above are the way to go. Now, we must come up with ways to simplify the workflow even further. Please get in touch to discuss how to make this happen.
Special thanks to Kristina @kriesse for reading a draft of this.
Thanks for reading. We at blended.io are incredibly excited and passionated about the potential innovative leaps for software design and engineering in fintech, investtech and industry 4.0. Get in touch!
Get hands-on articles about innovation, experience design or engineering! No spam and worthwhile content only.
Update: See this post and great tool for Mac for details on what I describe above in Terminal.
(Pssst: blended.io will launch two workshops: Version-Controlled Sketch for Skillful Designers & Design Teams and Git for Marvellous Designers)
Originally published at blog.blended.io on June 15, 2017.