Building the Dropbox “Design Cabin”
The quest for team-wide consistency and collaboration amongst the Dropbox Design team
When I first joined the Dropbox Design team, most of our work was stored in the aptly-named “Design” Dropbox shared folder. The folder was shared amongst the Design team, as well as a number of non-design folks.
This system worked very well when the company was small, but Dropbox isn’t a small company any more. As a result of the liberal sharing of this folder, there were a number of problems that I and other members of the folder kept running into:
- It was unclear to members what belonged in the Design folder; are banner ads the responsibility of the Design team, or the Marketing team?
- If the Design folder is for projects, are resources (such as templates) kept there too?
- Since the Design folder is itself a shared folder, how can I share subfolders with peers without giving them full access to the Design resources?
- How can we prevent accidental writes, edits, and deletes of important files by non-Design team members?
- Does the whole Design team really need the hundreds of gigabytes worth of files in the folder on their computer?
- How can we avoid conflicted copies?
This list is really a subset of the problems that occurred on a daily basis, but you get the picture; something was broken. We’ve since added a bunch of features to Dropbox — including read-only shared folders — that could help alleviate some of the problems above, but one vital thing was still proving a challenge; keeping a comprehensive library of resources available for (and limited to) the Design Team.
I love building tools, so I had a natural attraction to this challenge. With a number of resources already in the Design folder, I tried to imagine a world where they existed on their own. Here’s what success looked like:
- Access to the resources was limited to those who really need it; members of the Design team
- There would be a well-documented system for organising the resources
- As well as product-wide resources, such as branding guidelines, each platform (mobile, web, desktop) would have its own collection of resources, each potentially with an “owner”
- This collection of resources would be the undisputed and solitary home for designers — new and old — to become familiar with the Dropbox design system(s) and gather resources to kick-start a new project
With the help of a few other team members, a new shared folder was created; the “Design Cabin.” To quote the Design Cabin readme:
[The Design Cabin] is where you’ll find resources to help you start new projects, get through product reviews, and generally save you a lot of time and hassle.
As with any design challenge, this was no one-step task; the Design Cabin went through a few iterations before the workflow we have today.
Take 1: Dropbox Read-Only Shared Folders
One decision I made early on (and predicted would be an unpopular one) was to make the new folder read-only for everyone except myself, with the intention of reducing accidental edits to and deletion of files, amongst other unintended actions. I figured that as other team members came up with contributions, they would become “owners” of platforms or collections of resources, and would gain editing privileges as needed.
One problem with this system quickly became clear; it created a significant bottleneck for Designers who had resources to contribute. They’d have to share new resources with me, wait for me to approve their contributions (often with a lot of back-and-forth emailing), and manually update the shared folder or give the contributor temporary permissions to make the changes themselves. Phew. All that work for everything from a comprehensive icon set to a typo correction for a readme.
We could do better.
Take 2: Git + Dropbox
I figured that many of the collaboration/contribution issues I was running into had already been solved by a tool I already used every day: Git. Though we couldn’t move entirely to Git for these resources any time soon (many of our Designers use Git, but for those that don’t it’s a tough learning curve), we could use Git to allow contributions to be more easily reviewed by multiple peers.
So, I created a private repo on GitHub that was essentially a clone of the Design Cabin, with a few Git-specific additions (things like contributor guidelines amended for use with Git and GitHub). This way, conversations about contributions happened outside of email in a more public forum, and allowed any collaborators in the repo — not just myself — to merge changes.
However, one major piece was still missing; even as the Git repo was updated with new resources, I was still the person manually updating the read-only shared folder on Dropbox. The collaboration flow had improved, but the bottleneck was still there.
Take 3: Git in Dropbox
The next iteration was short-lived. I foolishly figured I could cut out some middleman work by storing the Git repo inside Dropbox, so that manually updating the folder to the latest version of the Git repo was at least as simple as a single click or a “git pull.” However, since Git makes many changes to many files at once (often inside the .git folder), conflicted copies would occur within seconds of making changes. It also meant that other members of the shared folder would get kicked around branches as new resources were developed, as well as end up with many resources they’d never actually see, hidden in unused branches.
Close, but no cigar. It was time to introduce a third party to the workflow; a remote server.
Take 4: Git + Dropbox + Web Hooks
One of my favorite features of Git is the ability to add post-receive hooks: actions that are performed after a remote repo receives changes. I’ve used web hooks on almost all of my own websites — my blog, Brills, and Just My Type to name a few — to automate updates, so adding a new task was fairly straightforward. I added a web hook to the GitHub repo that would ping a PHP script on my server. The script had a few fairly basic functions:
Dropbox has a CLI application, which I installed on my server and set up to exclusively sync the Design Cabin folder. With everything set up, collaborators on the Design Cabin GitHub repo could make changes, open a pull request and have those changes reviewed, merge those changes, and then my server will automatically pull those changes and sync them to Dropbox. With everything automated in this way, the manual work I was doing is no longer necessary, and if any accidental edits are made to the Dropbox shared folder (which is extremely unlikely, given that the only editing “member” of the shared folder is now my server’s script), they’re as easy to fix as pinging the web hook URL manually, which ensures (thanks to rsync) that the Dropbox shared folder reflects bit-for-bit the same files as the Git repo.
This new workflow covers many of the needs of the Dropbox Design team, and has worked out pretty well for the week or so it’s been in use. It took many cases of trial and error to get to where we are today, and I’m confident there’s much more work to do, but it will undoubtedly save many Designers many hours in the future.
If you enjoyed this, you may well enjoy working with us. Come join the Dropbox Design team; we’re hiring.
