Dropbox + git = Designer Luv | Hacker News Reader

Dropbox + git = Designer Luv

pivotallabs.com

83 pointsdko40 comments

Do yourself a favor and get a real git repository. Using dropbox is indeed super easy but has two major caveats:

1. Git is agnostic to updates to the repo, as dropbox is not a supported transport method (as opposed to SSH for example). So, for example, git hooks won't work.

2. Dropbox is extremely susceptible to repo corruption in case of simultaneous updates. Restoring a corrupt repo is not a pleasant task.

For your sanity - don't do it.

What I usually do is have multiple repos, one per machine I'm working on. This way they are write-once, read-many so you don't ever have dropbox merge conflicts. It's a bit more overhead, but safer. It's even "easier" to get the semantics right in bazaar due to the branch-as-a-folder paradigm rather than a repo-as-a-folder design of git, although I don't really want to devolve to a "my scm is better than your scm" debate.

I think you missed a point in the post: the designers are NOT using git. When the designers make a change, the designers are not doing a git add. Dropbox is just about getting the assets from the designers to the developers, so that the developers can do the appropriate git operations.

Presumably the developers have whatever hooks they want, and they still get run at the appropriate time....

At this time and age, I think designers should learn how use git. It's a tool like anything else.

Specially if your only concern is updating the images, the process should be pretty straightforward, you don't need to learn anything advanced.

This attitude that everyone should be a programmer bothers me. The designer's job is to design, and it's the programmer's job to integrate the designs.

Why don't you learn photoshop and how to do basic design? That way you don't need to ask the designer to do minor tweaks.

It doesn't work. If you've never used version control, "just learn git" can be a multi-week project. If you've never done design, "just learn photoshop" is the same.

Each person is on a team to do a specific job, let them do their jobs.

There are guis for git. And in my experience teaching someone (in customer service) how to check in and check out files in an SCM takes about 20 minutes.

I both agree and disagree. Git in its simple use case can be pretty simple. If there's a programmer handy to fix things when merges get angry, or things like that, it can be as simple as dropping two scripts on the designer's desktop -- one to commit and push; one to pull.

> Why don't you learn photoshop and how to do basic design? That way you don't need to ask the designer to do minor tweaks.

I know you're trying to be facetious here, but I think it's actually a good idea. Why bother someone else to make a simple fix (I'm thinking typo-correction level here)?

Maybe after every developer knows how to use git we can expect designers to learn it too. Until that point what you can expect from forcing someone to use a tool that is not central to their workflow is that they will use it as little as possible (if at all), and when it comes to source control, that's a bad thing.

If we programmers are so smart we'll make working "our" way easier, not harder.

On a team where Git is the source control mechanism, I do expect every developer to know how to use Git. And to a designer on that team, Git will be central to their workflow, assuming their workflow requires editing the site design.

If a developer needed to edit images regularly, I would expect them to learn enough Photoshop to do it, not to go bother a designer every time because Photoshop isn't a "developer tool".

For someone who can understand Photoshop layers, understanding commit, push, and pull shouldn't take too long!

I think that enra meant that git is a tool for people who are part of a team and modify files for the same project. Just like you know how to handle files and directories, you would know how this kind of tool works. But you are definitely right : the tool should be easy and quick to learn and understand.

I worked pretty closely with a designer just recently. We went from throwing designs over the wall, to basic git based version control. We found that it was a pretty enjoyable workflow for the both of us. It allowed the designer to have more control over the end product, since he didn't need to ask me to update images.

We got to the point where he'd own all of the HTML and CSS, as long as I had certain ids and classes to hook my Javascript into. After we got CI and CD going, he's start pushing out new designs several times a day, giving us a pretty quick turn around time.

I never asked him to use the command line, since Tower handled most of the stuff he'd do. I wouldn't ask him to learn all of git, just as how I'd be frustrated if I had to learn all of Photoshop. I wouldn't be opposed to doing some basic work, like changing the color on the background layer.

> It doesn't work. If you've never used version control, "just learn git" can be a multi-week project. If you've never done design, "just learn photoshop" is the same.

Most of us have learned to use Photoshop to perform basic tasks without needing to push it all on the designer - things like resizing images, cropping, saving from source PSD to usable formats like JPG, etc.

It's hardly so much to ask of a designer to learn commit, push, and pull.

Since when is learning/using git "being a programmer"?

A designer's job is to design and a programmer's job is to program. Both of those jobs require tools to make their jobs easier.

I'm sick of designers getting away with things programmers never would in their jobs. Programmers learn skills such as: organization (files and directories), communication (comments), workflow management (version control), etc. In my experience with designers, none of them care about things like that. You'll see 5 versions of PSDs filled with Untitled layers and no logical grouping.

These are things that are just expected of programmers and they should be expected of designers as well.

I would be happy if my designer gave me untitled layers. I usually have to use the magic wand to cut out layers from a flat picture myself. Very fun when there are gradients, drop shadows and similar stuff on a jpg-compressed image T_T In the end I'm essentially redoing all the work the designer did.

Sounds like a great guy to work with. Why do you?

> In my experience with designers, none of them care about things like that. You'll see 5 versions of PSDs filled with Untitled layers and no logical grouping.

Work with better designers :)

In all seriousness, I think many designers haven't be shown the benefits of why they should change their workflows. If you can demonstrate how using Git would make their jobs easier, you might get some converts.

Also, most designers think visually, so text-based commit history is kind of useless to them. I'd love to see tools like Timeline [http://pixelnovel.com/timeline], but for Git.

As for not naming & grouping layers? That's just a bad designer. Send them this: http://photoshopetiquette.com/

For the record, I'm a designer, and do frontend coding.

I'm not advocating everyone to be a programmer, but to deliver the best experience, you need to be in control of the design. And I don't say you need to do frontend coding (even I think you should) but just to be part of the workflow, making your work better and everyone's else easier.

I taught my girlfriend to use git/github.com(how to commit, push and pull) in an afternoon, and she's not a coder or a designer. So I think quite easy to learn, specially if you have people around helping you if you get stuck.

It's like saying "I'm a designer, I cannot use email, IRC or Skype", when everyone else around you are using these tools.

I strongly disagree: the designer is on the team and what she produces has to be integrated with the work of the other members of the team.

Git is just one tool to share work within a team, and it happens to have nice GUI (like SmartGit) which make it almost unnecessary to learn the Git command line. I cannot believe that someone who can use Photoshop is unable to learn to press "Pull", "Commit", and "Pull".

Sometimes it depends on the team dynamic. If the non-developers have the will and time to incorporate git into their workflow, then it makes sense. If not, it's not their fault either.

In the end, it's about adopting what is most effective for the entire team to get the job done.

The team or the non-developer? You mention both as the most important.

Given how often I get synchronization conflicts on regular files with Dropbox, I would be quite wary to use it to put and synchronize repositories there. The problem is (obviously) that Dropbox is really a local synchronized folder, so a Git push will only be reflected on Dropbox if there is an opportunity to sync. So, if you have mobile coworkers, it's easy to mess up things.

Given that there are many companies who offer repository hosting for just a few dollars per month (also for teams), I cannot see why one would go this route.

I think the main advantage here is the designer doesn't need to learn git, they just work away on a Dropbox folder without knowing it's a git repository. Additionally, the main git repository doesn't need to be in dropbox, just the designers remote.

As someone else in this thread mentions, I think version management is becoming indispensable for the modern designer, and also feasible given the prevalence of vector graphics.

Besides that, there are some great, easy to use git clients (Tower, GitBox, SmartGit). I have non-CS colleagues who adopted git in no-time with SmartGit (for LaTeX documents).

> and also feasible given the prevalence of vector graphics.

As a designer who has had git on his "To Learn" list for way too long, can you explain what you mean by this?

Version control systems work best when they're dealing with files made up of lines of text. Bitmap images don't have this property, but vector graphics usually do.

It's twofold:

1. (x)diffs of binary files are usually more expensive than text files.

For instance, consider a git-tracked bitmap image where you apply a global filter. If you add the revised image, and every pixel was touched, this will usually result in a large diff. So, git will either store the large diff, or the modified file completely.

If you, on the other hand use SVG with filter effects, the application of a filter will just add a few lines of text to an SVG file. This gives a small diff, meaning that the object can be stored compactly.

2. In the SVG scenario, you could easily spot the changes between both revisions of the image with a 'git diff' (since both files are plain-text). In the bitmap scenario, you can only spot the differences visually.

Ah, so it's a file-size issue. Thanks to both of you for explaining.

Git, like most versioning systems works by adding a file to a repository. Then subsequent changes are added to the repository by saving only what has changed in the file.

In the case of a bitmap image think of a grid made up of pixels. Each pixel is stored on the file as binary data (0's and 1's). Anything that affects that pixel will change it's value in the file.

With a vector file there aren't pixels necessarily. The drawing is saved as shapes and those shapes have properties. These shapes and their properties are actually saved as text (sort of like HTML markup).

So as the file changes the changes in those various file types are more drastic. With a bitmap there will be greater changes so overall more space is used to store the file and it's history. Also, because it's binary it's difficult to see the changes in the actual file (without opening it in a photo editing program). With a vector file only small amounts of text would be changing and you can literally see the changes in the file and make sense of it.

Hope that helps.

Very much so, thank you. So it's more how the data is stored and updated in the different kinds of files. I definitely had the basic gist of raster vs. vector, but had no idea how it could affect something like version control in this way. Very interesting.

Yes basically. Your repository could grow faster using binary files but it's still worth it to have a version history. Even if for nothing else other than to be able to see how something evolved.

What are the real advantages of using version control from the designer point-of-view?

In most cases, a good backup system is what they need. Use Apple's Time Machine or Crashplan and backup every 15 minutes automatically.

From a programmers point of view VC is great. We actually have the tools to deal with different versions of text files: find differences, resolve conflicts, merge, split off new versions, etc.

And designers? What do they get beyond a more complex and opaque form of Backup. Sure it makes it easier to get the designers output into our programmers workflow, but the way this is usually sold is a Pain in the designers backside with no real benefit.

If programmers want to win over designers to version control, we need to sell them on real advantages. We need to show them tools like pixelnovel's timeline that integrates SVN diretly into Adobe CS and provides an in app version viewer. Or Kaleidoscope.app which allows the visual comparison of image (and text!) files.

    http://pixelnovel.com/   (SVN only)
    http://www.kaleidoscopeapp.com/   (Git, Mercurial, SVN & Bazaar)

However, even these tools only scratch the surface of the power that programmers gain from the pain of version control.

Designers need more than just backup. They work with binary files that would need specialized diff and merge tools. They need to share files with (non-technical) clients.

PixelNovel looks interesting, but it seems mostly focused on "timelines" for single users, not teams.

Hylke Bons wrote a very nice git-based Dropbox alternative with focus on collaboration called SparkleShare (http://www.sparkleshare.org). It's still in beta state but a few members of the GNOME design team are already using it to collaborate.

What's the difference between this and just using github? I think it's just the daemon-ness of dropbox. It would be cool to have something similar for arbitrary git repos that runs 'git fetch' periodically in the background. (or something fancier, if you want to scale it out) That keeps the conflict management at the git level, and you aren't keeping history of history anymore.

If you don't want your repositories public, price is a big difference. All of my repositories would fit in 10% of my free Dropbox space. It would cost $100/month to put them on Github.

Github's pricing is based on the number of repositories. Dropbox's is based on the amount of storage used.

You could set up a gitosis server if you have access to your own server of some sort and don't mind administering it.

I have a linux VM on my main computer that is accessible to the outside world with gitosis on there and it's pretty great for a private git repo.

Gitosis is obsolete.

If you are starting frsh, set up gitolite servers instead. Gitolite is actively maintained and has more features and better documentation.

I regularly work across multiple computers(all macs, but 2 desktops and my laptop), so I actually put my virtualenvs in my Dropbox and then they contain git repositories. So I have my full environment installed on all the computers all the time.

You do have to install git, virtualenv and pip on all the computers, but thats not too much to ask.

The open source SparkleShare gives users the same feel of Dropbox, while using Git as its backing storage:

http://www.sparkleshare.org/

It currently has native clients for Linux and Mac, with Windows coming soon.

Super cool idea. I will try this with a client's design team. They already use and love dropbox.

Reply on news.ycombinator.com