Pixelapse (YC W12): GitHub-Style Sharing and Version Control For Design Projects
techcrunch.com
techcrunch.com
What I'm unclear on is how the nitty gritty of the versioning actually operates. For example, most designers would attest to heading down many "dead ends" that may only ever live in RAM. Can services like this snapshot those interim states, or do they only capture changes to files on disc? Some experienced designers will also likely do their own primitive versioning by saving a design out to different paths as they go (home_v1.psd, home_v2.psd...). Can Pixelapse et al handle this user behaviour, or does it require people to change their workflow? If the latter, is an analogous feature available to allow designers to mark major version increments?
In many ways it ultimately feels that "files in folders" is a broken way to handle designs, units of design and design projects on a computer. I applaud attempts to supersede it. As long as Photoshop thinks in terms of files though, it will be a difficult space to innovate.
There is an app that runs in the menu bar of our designer Kevin's mac, which automatically uploads "revisions" of the design he's working on. It only captures changes to the file on disk, so he has to save strategically knowing that it will create a "revision". I personally don't like this, as it discourages saving often. To be fair, you can mark different revisions as "milestones", but this just seems like a bandaid for this particular problem.
Before using Pixelapse, Kevin had his own workflow (similar to what you mentioned), where he'd save different versions of a design as project_homepage_option1.jpg, project_homepage_option2.jpg, etc. Pixelapse absolutely does not support this. It will upload each one as a different file and offers no way to combine them so that you can compare them for review (and there is no way in Pixelapse to compare different files, only different revisions of the same file.
Also keep in mind that Pixelapse, along with every other similar app I looked at, uses the revision/history paradigm for comparing designs. But I think Pixelapse at least allows for the non-timeline-based approach a bit better than others, though it still didn't quite fit our workflow without some changes to our workflow.
Edited to clarify, I wasn't trying to be too critical of Pixelapse. I actually really like it, it just required some changes to our workflow to be effective, and I think we're still trying to figure a couple things out.
The true social value of Github is in its community-oriented approach where any developer anywhere can fork code and contribute changes. That doesn't seem as possible with imagery, and my impression is that designers are more concerned with protecting their work (nothing wrong with that - just an observation).
Open source design could be massive. There are already tons of places where designers give away assets to the community - fonts, PSD templates, logo templates, etc. But they all have the limitation of being done by a single designer. I think - despite the fears of "design by committee" that some might have - there could be some great stuff that comes out of collaborating in this way.
Developers really only need to share code with other developers. There's almost no such thing as a passive receiver of code. The ability to easily collaborate on code with other developers and within a team, via cloning, forking, pushing and pulling, makes Github (and Bitbucket and Gitlab, etc) immensely beneficial.
Design interactions, on the other hand, tend to be made up primarily of designers sharing designs with non-designers, whether it be the client for feedback or the technical team for implementation (or the printers, or the marketing department).
I think Pixelapse is more like the "Github for design" if you just think of Github as a 3rd-party repository for easy version tracking and uploading of code, and which makes it easy for others to comment and compare different versions of the code. In other words, minus the forking and cloning concept. At least, that's how we use it.
Not sure how they comparefeature or quality wise but Pixellapse's pricing plans might be serious trouble for LayerVault.
http://www.quora.com/Design/How-do-LayerVault-and-Pixelapse-...
So when I'm saving for a version, I save it as a separate file.
The problem with detecting a save and treating that as a version, is going to net a me a ton of versions that I will not need.
There should be a plugin that has a shortcut key within PS and lets me save it as a version when I dictate it and not every time time I hit Cmd+S. Cause when I Cmd+S != new version.
I've been told to learn Layer Comp in CS6. Apparently it's Adobe's new feature to version control.
Consider the problem of people trying to work on the same image file at the same time. An easy/naive solution for most version control software is to stop multiple people from editing the same file at once, but AFAIK this is impractical in git; the antithesis even. Others might do something complex like allow different people to edit different layers of the same photoshop doc and try to merge them.
There are version control solutions such as Alienbrain and even Perforce that are much more efficient at handling assets out of the box.
It seems that Pixelapse isn't quite going this route. If Github can compete, they would have the advantage of easier integration between designer oriented data and program code.
As a dev I often had to tweak my designer's assets. For example, fixing the 9-patching for Android or removing bad whitespace. Could I offer these changes in a pull request?
With regards to changes made to assets, they sync automatically between your machine and your designer's.