I agree with pretty much everything, except designers using Git. Sadly, Git doesn't work for PSD files properly. Some of the PSD files I've worked with before (900mb+) for larger websites and applications would definitely not be a good fit for Git. Although I think the blame lies mostly on Photoshop's end not being the right tool for web design, but being used by designers anyway. I think whatever tool ends up replacing Photoshop as the de-facto standard (if it happens) should ideally have a visual re-visioning system built in a la Adobe Creative Cloud.
We aren't quite at that point where designers are saving out all of the assets for you, then that would be different. You can source control individual assets, but not a large PSD file properly. I've begun to train the designers at my work to save out assets for pretty much everything leaving me to solve the engineering problems like how everything is going to work and less time cutting out images from a PSD file, but we aren't quite there yet where this is a universal thing that designers just know and willing do.
Some people might disagree with point #6, but I wholeheartedly agree as someone who works for a company where designers design and developers develop. I think to be truly great at design, you need to devote at least 90% of your time (minimum) to bettering your design skills. If you're a developer, the opposite rings true. I think it is important for design/dev to have a mutual understanding of one another, but I don't think you can truly be a great designer and great developer in one. Having an understanding of the other perspective is important. You'll never meet a surgeon who specialises in brain and heart surgery, why should design and development be any different?
Fortunately, the employer I work for doesn't compartmentalise the teams from one another. There is nothing more horrible than working in a place where design and development teams are on separate sides of the office or even different floors with the only communicative layer being a project manager or team leaders. Designers and developers sit down and tackle problems together and educate one another in the process. This is something that happens through the whole process from wire-framing to prototyping to final build. I think designers and developers should work together at every step. I have met talented design/developers, but great ones of both fields are extremely rare.
PS. Joshua, if you're reading this comment, you might want to reconsider the 670kb background image on your site. I loaded your blog on my slow ADSL connection and it was painful.
I really disagree with you that Git is not a good tool for designers. It's certainly not friendly to learn, but for designers who get the process, it is incredibly useful. If you have lots of 900MB binary blobs I guess that's going to be a problem, but the vast majority of assets in a website or app are text files, jpg and png files which are small, and the vector artwork or PSDs used to generate them (for vector that's really small, for psds that can vary from a few MB up to 100MB (which git is perfectly fine with), but 900MB is in my experience really rare). Photoshop is just one tool in the arsenal, and not particularly effective for anything involving text (the layout tools aren't great), anything which will be translated to html (just mock up in HTML/CSS after some quick roughs - far less friction), or anything which requires resolution independence (almost every asset nowadays).
Of course this depends on workflow and tastes vary, but for designers who don't use PSD to actually design websites (a purpose for which it is not very well suited), git or other version control tools are incredibly useful. Wasting a bit of extra space storing a few versions of a psd file is no problem - I've worked on 20GB local repositories before with a lot of assets, without issues, and it's easy enough to separate out large files into another repo or leave them out of version control if you have to. If a designer is creating 1GB PSD files with hundreds of assets in, I'd say (as a designer) their workflow is fundamentally broken unless they are producing billboard advertisements which require very high resolution files - you shouldn't have that much of anything glommed together in one file. So git works perfectly fine for lots of designers today, even working with binary files.
It's just a shame that these version control tools are mostly isolated to the workflow of programmers, as people at most workplaces I've come into contact with, from architects through writers or editors, sorely need a tool like git in order to manage collaboration and versions.
Git doesn’t handle image files well at all, because it wasn’t designed for it. That said, I think the OP is talking more about designers using Git for code, not images. Designers don’t just make images, etc.
In my experience as both a designer and a developer, Git is not the right tool for most designers. Technically, Git is not ideal for binary files. When the file size is too large, Git fails badly. Git works well for text files, not binary files.
Many designers who do not code at all do not understand the workflow of Git. The process of pull, commit, push is extremely confusing. E.g. One large company that forces all designers to use Git ended up with multiple files with slightly different names in the repo system. Designers do not understand the concept of merge conflict and will just rename the file so that they can push to the repo. Case in point: the mental model of Git has worked well for developers, but does not translate well to non-coders.
Overall, I think a version control system for designers should be transparent, non-intrusive, and just works. Designers should not have to worry about when to push or pull, should not have to worry when to commit. I think it should just backup every saves and then subsequently allow them to flag specific design iterations that they want to highlight.
Disclaimer: I am co-founder of Pixelapse - Version Control for Designers.
> I think it is important for design/dev to have a mutual understanding of one another, but I don't think you can truly be a great designer and great developer in one. Having an understanding of the other perspective is important. You'll never meet a surgeon who specialises in brain and heart surgery, why should design and development be any different?
What is the definition of "developer" here? Does it include HTML and CSS? I love working with designers who can translate their designs into actual layout and styling because it seems a lot closer to what they're good at than it is to what I'm good at. It seems like there's quite a bit of gray area in these definitions, but building front-end application behavior seems to flex similar muscles as building back-end application behavior, while tweaking CSS seems to flex similar muscles as tweaking element widths in photoshop. I'm genuinely curious what the common designer point of view is on this!
It's unfortunate that PSD files don't work with git because so much of the development and release process ends up being built around git (e.g. merging code into trunk triggers the continuous integration tests). If designers don't use git, they can end up out of sync with their engineering peers. As the author said, designers who code are at a big advantage, even if they spend most of their time designing.
As a compromise, we had some luck syncing the PSD files with Box and checking in the exported static assets to git, but it was more of a patch than a solution.
I'm not a designer, so please enlighten me. What kind of data can be held in a single image for a PSD to be 900 megabytes? Is it a single PSD for hundreds of web pages or?
Usually layers itself do not make a PSD big. A big PSD file is usually because the DPI is huge and >500mb PSD files are very common in the print industry where designers have typically design between 300 to 600 dpi. A B2 poster at 600dpi will easily be >500mb.
*A PSD file has a max height and width of 30,000 pixels, and a length limit of 3 Gigabytes. Hence, Photoshop created PSB filetype which supports max height and width of 300,000 pixels and the length limit to around 4 Exabytes. https://en.wikipedia.org/wiki/Adobe_Photoshop#File_format
To elaborate, for anyone who hasn't used Photoshop (in several years): you can have layer groups which act as folders containing several related layers, so when you're browsing layers, it isn't just a mess of 500 some-odd rows.
Sounds like what's needed is a way to extract a PSD into a component file structure, and combine that structure back into a PSD. Without knowing anything about PSDs, I assume it would contain lists of layers with links to resources such as images or whatever is required to approximate the desired view. Something like that as a plugin or hooked to run before and after commits would be really useful in this case.
Depending on how hard the PSD format is to grok (purposefully or otherwise), this may be nigh impossible, but it also seems like it would be a great exchange format (which may be a another reason Adobe wouldn't want it). Then again, maybe there's already something like this...?
I don't think he was talking about using Git for graphics files. I assume he meant html/css/javascript files.
As a designer who codes (or a coder who designs, not sure at this point), I can see what he means about learning Git. It was tough for me to grasp until I saw this:
We aren't quite at that point where designers are saving out all of the assets for you, then that would be different. You can source control individual assets, but not a large PSD file properly. I've begun to train the designers at my work to save out assets for pretty much everything leaving me to solve the engineering problems like how everything is going to work and less time cutting out images from a PSD file, but we aren't quite there yet where this is a universal thing that designers just know and willing do.
Some people might disagree with point #6, but I wholeheartedly agree as someone who works for a company where designers design and developers develop. I think to be truly great at design, you need to devote at least 90% of your time (minimum) to bettering your design skills. If you're a developer, the opposite rings true. I think it is important for design/dev to have a mutual understanding of one another, but I don't think you can truly be a great designer and great developer in one. Having an understanding of the other perspective is important. You'll never meet a surgeon who specialises in brain and heart surgery, why should design and development be any different?
Fortunately, the employer I work for doesn't compartmentalise the teams from one another. There is nothing more horrible than working in a place where design and development teams are on separate sides of the office or even different floors with the only communicative layer being a project manager or team leaders. Designers and developers sit down and tackle problems together and educate one another in the process. This is something that happens through the whole process from wire-framing to prototyping to final build. I think designers and developers should work together at every step. I have met talented design/developers, but great ones of both fields are extremely rare.
PS. Joshua, if you're reading this comment, you might want to reconsider the 670kb background image on your site. I loaded your blog on my slow ADSL connection and it was painful.