Hacker News new | past | comments | ask | show | jobs | submit login

Yes, version control definitely seems like one of the biggest gaps. The communication between developers and designers have to improve, and the developers will have to realize they can't ask every designer for commits, but they can probably ask them for .zip files.



On the other hand, maybe we should make designers want to use Git.

This might be not as crazy as it sounds, as I recently learned:

A few weeks ago, there was a short presentation about Git, targeted at non-programmers such as graphics and web designers. After the presentation, one of the designers (who apparently already knew about Git) stood up and criticized the presenter for not going deeper into branches and auto-branching.

Of course, the presenter intentionally left that topic out, in order to not confuse all those Git newbies.

However, the designer argued that this is what would make Git interesting for designers. He said that all this diff/commit/push/pull stuff was boring for designers where a "diff" between graphics files is neither readable nor meaningful, and where automatic merges are impossible anyway. But branching has the power to reflect the natural work-flow of a designer who permanently goes back to previous versions in order to try different variants. Reflecting this via "Save as ..." (and naming files accordingly) is very cumbersome.

Although I personally think this guy overrated the power of branches, this might change once the Git user interfaces becomes simpler to use, more targeted to designers (rather than just software developers) and better integrated into graphical tools like Gimp, Inkscape or even Photoshop.


Source control is also not part of a designer's natural workflow because the options aren't that great (usually backups on a NAS is all there is and a few proprietary snapshot plugins from Adobe. Kaleidoscope looks the most interesting). Also, svn branch numbers or git hashes don't make nearly as much sense to designers as "HiFi Mockup iPhone4 Right Aligned Inbox.ai" when they want to backtrack or compare current "in the running" designs.

I'd love to see the OSS community develop better source control software targeted towards designers. :)


> svn branch numbers or git hashes don't make nearly as much sense to designers as "HiFi Mockup iPhone4 Right Aligned Inbox.ai"

That's what the commit comments are for.

BTW, programmers also prefer reading commit comments, commit dates and author names. They don't read hashes. (Although they sometimes copy&paste them because they are short and unique.)


> On the other hand, maybe we should make designers want to use Git.

I use Git, and its a wonderful piece of software craft indeed, but it does not have Windows/Mac clients, that designers often use, as their base OS.

A decent usable frontend for Git, on platforms other than Linux too, needs to be developed, for it to be usable by designers.

Edit - I meant to say officially supported frontend and support for other oses by git.


You're quite wrong.

GitX is available at https://github.com/brotherbard/gitx/downloads (Get the experimental branch)

Git Tower is available at http://www.git-tower.com/

Textmate has a GIT Bundle at https://github.com/jcf/git-tmbundle (It's quite good, but maybe not for designers).

And Giggle (http://live.gnome.org/giggle).

Windows is the only OS lacking a good client, but I use GitX for Mac every day, as do the less technical "devs" at our Startup.


Yes, I just picked up git for Windows, and it is atrociously unusable. Brutally atrocious. It's not like Windows is a popular operating system - git shouldn't support it as a first-class citizen. ;)


Care to elaborate?

I've been using the whatever default Windows port that is linked from Git's download page for several months bow and there is nothing atrocious about it. It works well and it does differ much from the Linux version. (edit) The command line version that is.


The GUI is atrocious. I use the GUI for branch visualization, and, well, I had expected something far better.

I use TortoiseHG and I expected parity.


Git was developed for improving Linux Kernel development. You see why they don't care about Windows, right?


Most people seem to say that it works just fine. In my limited experience, it was just like git on Linux.

Given that git was created for hosting the Linux kernel, it should be obvious why it's not a first-class citizen.


git gui works wells for me on Windows with msysgit. It's ugly, and there are a good number of small issues, but it definitely provides a reasonable user experience.

And of course, the command line option through msysgit is great.


> Windows is the only OS lacking a good client

Git Extensions (http://sourceforge.net/projects/gitextensions/) is actually really, really, good. The UI is well-designed and fast. Wish more people knew about it.


Hmm, there does seem to be a tortoisegit project at http://code.google.com/p/tortoisegit/ ..


> Git [...] does not have Windows/Mac clients

Since the target group were designers, the presenter used a Mac, and tried to do everything using a GUI client for Git. I don't remember which one he used, but it ran natively on the Mac and it looked quite nice.

(Still, the presenter sometimes struggled with that GUI. He was obviously more used to the command line.)


Most git actions don't need a deep understanding of Git nor a full GUI to function. I think git gui and gitx probably are enough to get a designer going.


Relevant Stack Overflow question on GUI git clients: http://stackoverflow.com/questions/455698/best-visual-client...


What Git really needs is a few tools like Versions and Cornerstone were for SVN: simple apps that didn't require any command line use at all. Git Tower might be there, but I haven't used it so I can't say that 100%.


"diff" between graphics files is neither readable nor meaningful, and where automatic merges are impossible anyway.

Both problems seem "hard but solvable" to me. Isn't there software doing that already?


"diff"

Simple pixel-by-pixel "diffs" are of course possible, but only useful in trivial cases.

What if someone changed the color scheme (which affects almost all pixels)? What if someone moved some part of the image to another part? What about resolution/size changes and multiple layers? What about vector graphics?

And the most important thing: How to display that in a way to be easily understood by non-technical people?

For hard-core techies, there is of course the option to use a text-based image format. For raster graphics, the "plain" variants of PNM come to mind. For vector graphics, SVG or EPS might be good choices. Then, a good (indention-aware) textual diff should produce sensible results - especially if only details were changed.

"merge"

Automatic merges are only useful if they aren't too "clever". That's important for text and especially important for graphics.

So if two distinct areas of an image are edited, a simple merge can and will work. But overlapping changes or even global changes should always result in a conflict.

However, if only trivial merges are desirable, most changes will cause conflicts, which would be not much different from the current situation.

Also, that kind of merges will already happen automatically with the current (text) merge anyway, provided that formats like PNM, SVG and EPS are used.


Kaleidoscope (OSX) has an "image scope" that at least integrates a couple tools for image comparison.

http://www.kaleidoscopeapp.com/


In addition, Kaleidoscope seems to have integration support for some version control systems (Mercurial, Git, SVN).

Too bad it's not Free Software ...


I don't think image comparison is the problem here. The problem is that designers works in rather different flows. To us a file can be many different states at once.

Kind of like a developer would have 10KLOC but be commenting the 8K of them in and out all the time.

In other words the document have many states at once depending on what you make visible or not.


Actually, this git thing does sound cool. You mean to tell me there's an easy way of tracing different versions of a design?


Git and similar tools are designed to track multiple revisions of a file. Imagine the history feature (undo/redo) from your favorite editor, but for saved files, and with the ability to point to two arbitrary versions and ask, "What changed between these?"

On top of this, Git added the ability to merge changes together automatically. Imagine that one person changed a bunch of stuff in the first paragraph in a document, and someone else changed a bunch of stuff in the second paragraph, and the computer could automatically merge those changes into one document.




Join us for AI Startup School this June 16-17 in San Francisco!

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: