Pixelapse (YC W12): GitHub-Style Sharing and Version Control For Design Projects(techcrunch.com)
techcrunch.com
Pixelapse (YC W12): GitHub-Style Sharing and Version Control For Design Projects
http://techcrunch.com/2013/02/13/yc-backed-pixelapse-brings-github-style-sharing-version-control-to-your-design-projects/
9 comments
We just recently started using Pixelapse a week and a half ago, so I can answer a couple of these.
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.
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.
Thanks Steve, interesting stuff. It feels like revision-on-save is a significant limitation; I wonder if they have plans to tackle this in future.
I'm curious to see how the whole 'forking/cloning' concept is replicated here, especially if Pixelapse is seeking to become the Github for design. I'm fairly certain that the restrictions for use of graphic content in a public format is a lot more prohibitive as opposed to software (there's not really such a thing as 'open-source graphics' besides measly clip art galleries).
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).
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).
We recently started using Pixelapse (we're a development team that just welcomed our first full-time graphic designer a few months ago). It's pretty nice, but there is one huge difference between design and development that makes the idea of "Github for design" seem like the wrong idea.
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.
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.
I didn't immediately see a "fork" option (am I missing it?) - but I hope they add that feature. I think this has a ton of cool potential.
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.
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.
How does this compare to Layervault?
LayerVault just has one plan: $24/user/month with unlimited storage and projects. Pixelapse seems more flexible with a free plan (1GB storage) and pay plans starting from $19/month (20GB) up to $149/month (100GB).
Not sure how they comparefeature or quality wise but Pixellapse's pricing plans might be serious trouble for LayerVault.
Not sure how they comparefeature or quality wise but Pixellapse's pricing plans might be serious trouble for LayerVault.
There is a Quora question for this well, where more (helpful) comparison information might be posted in the future.
http://www.quora.com/Design/How-do-LayerVault-and-Pixelapse-...
http://www.quora.com/Design/How-do-LayerVault-and-Pixelapse-...
This particular Quora answer does not reflect highly on the LayerVault folks–it makes a lot of ad hominem attacks and comes off as immature.
Why not just link directly to the Pixelapse website? Does TechCrunch deserve to be a middle man for every startup?
Why not indeed: https://www.pixelapse.com/ - especially since TechCrunch have a broken link, and pixelapse haven't thought to redirect it.
Just caught that - it should redirect now.
One habit I developed was save often - meaning saving when it's not really at a version state yet. Why? Cause PS crashes every so often.
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.
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.
Isn't github's billion dollar valuation based on the premise that they can become the "social versioning / forking for everything". Better get moving quickly github, the competitors are coming.
Git's strength is with source control and it sucks at dealing with image/music/video/binary data. It's OK for a basic few assets that rarely change, but it takes effort to make it work properly.
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.
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.
Programmers have been struggling with version control for decades now. There's a lot of power and value in the way we do things, which is effectively placed out of the reach of non-programmers by UI issues. (And to be fair, a lot of that power needs to be hidden!)
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.
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.
The largest plan has 9 collaborators, which seems rather prohibitive.
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?
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?
Hi hannah, We'll work with you if you have larger needs. Please get in touch: [email protected]
With regards to changes made to assets, they sync automatically between your machine and your designer's.
With regards to changes made to assets, they sync automatically between your machine and your designer's.
Version Control is a concepts that every dicipline, that needs to manage documents, should try to implement.
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.