9 ms·

Yes, version control definitely seems like one of the biggest gaps. The communication between developers and designers have to improve, and the developers will

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.

vog 16y ago
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.
- rchowe 16y ago
  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%.
  - deleted 16y ago
    [deleted]
- random42 16y ago
  > 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.
  - tvon 16y ago
    Relevant Stack Overflow question on GUI git clients: http://stackoverflow.com/questions/455698/best-visual-client-for-git-on-mac-os-x http://stackoverflow.com/questions/455698/best-visual-client...
  - vog 16y ago
    > 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.)
    - jackolas 16y ago
      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.
  - josegonzalez 16y ago
    You're quite wrong. GitX is available at https://github.com/brotherbard/gitx/downloads https://github.com/brotherbard/gitx/downloads (Get the experimental branch) Git Tower is available at http://www.git-tower.com/ http://www.git-tower.com/ Textmate has a GIT Bundle at https://github.com/jcf/git-tmbundle https://github.com/jcf/git-tmbundle (It's quite good, but maybe not for designers). And Giggle (http://live.gnome.org/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.
- jianshen 16y ago
  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. :)
  - vog 16y ago
    > 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.)
- ced 16y ago
  "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?
  - vog 16y ago
    "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.
    - deleted 16y ago
      [deleted]
  - jj_aa 16y ago
    Kaleidoscope (OSX) has an "image scope" that at least integrates a couple tools for image comparison. http://www.kaleidoscopeapp.com/ http://www.kaleidoscopeapp.com/
    - vog 16y ago
      In addition, Kaleidoscope seems to have integration support for some version control systems (Mercurial, Git, SVN). Too bad it's not Free Software ...
- AaronChampagne 16y ago
  Actually, this git thing does sound cool. You mean to tell me there's an easy way of tracing different versions of a design?
  - wtracy 16y ago
    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.

vog 16y ago

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.

rchowe 16y ago
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%.
- deleted 16y ago
  [deleted]
random42 16y ago
> 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.
- tvon 16y ago
  Relevant Stack Overflow question on GUI git clients: http://stackoverflow.com/questions/455698/best-visual-client-for-git-on-mac-os-x http://stackoverflow.com/questions/455698/best-visual-client...
- vog 16y ago
  > 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.)
  - jackolas 16y ago
    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.
- josegonzalez 16y ago
  You're quite wrong. GitX is available at https://github.com/brotherbard/gitx/downloads https://github.com/brotherbard/gitx/downloads (Get the experimental branch) Git Tower is available at http://www.git-tower.com/ http://www.git-tower.com/ Textmate has a GIT Bundle at https://github.com/jcf/git-tmbundle https://github.com/jcf/git-tmbundle (It's quite good, but maybe not for designers). And Giggle (http://live.gnome.org/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.
jianshen 16y ago
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. :)
- vog 16y ago
  > 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.)
ced 16y ago
"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?
- vog 16y ago
  "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.
  - deleted 16y ago
    [deleted]
- jj_aa 16y ago
  Kaleidoscope (OSX) has an "image scope" that at least integrates a couple tools for image comparison. http://www.kaleidoscopeapp.com/ http://www.kaleidoscopeapp.com/
  - vog 16y ago
    In addition, Kaleidoscope seems to have integration support for some version control systems (Mercurial, Git, SVN). Too bad it's not Free Software ...
AaronChampagne 16y ago
Actually, this git thing does sound cool. You mean to tell me there's an easy way of tracing different versions of a design?
- wtracy 16y ago
  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.