Collaborative tools for designers − part 6 : the Githosters

The Githosters

Part 6 of this series of posts around my quest for tools that would encourage or facilitate collaboration with and between designers, this time, I went over what I’m calling the Githosters, also known as Github, Gitlab or Bitbucket.

Github is so popular these days it might become a verb one day and for some, there is still confusion between Git and Github. But since its beginning in 2008, coders have embraced it. It’s their social network. And they’ve been followed by a growing population that works also sometimes with coders such as journalists, jurists, typographers, icon designers, cartographers, etc. So we’ve actually come a long way since SourceForge − once the “only” place to get some open source software − and I guess, for the better. Github also helped popularize Git and became a central place to experience “code based” development as a community. With a major web actor such as this one, comes a list of alternatives, such as Bitbucket, pretty much born at the same time (at the beginning using only Mercurial, but later also Git) and more lately, Gitlab, the open source equivalent that you can host on your own servers.

The crowd that has followed the coders is the one that’s the most interesting to me. And I’m guessing the future of these tools depend on it. The winner in the next years will be the one that manages to keep its crowd of developers while providing relevant tools for all the other creators that surround it. And we can see that some of those players have started to understand this.

Github visual diffing

Let’s start with Github, since they are leading the pack. Github offers previews and version comparison for certain files. Which means that you can see how some of your graphic files have evolved through their commit history. They do this for psd, jpg, png, gif, svg and stl files. They also support rendering of pdf (but no diffing). It’s worth noting that Github renders also IPython/Jupyter notebooks, csv tables and geojson map files (the latter with diffing), appealing there to the data scientists and alike.

All of these features are great and can encourage non-coders to use that service. But it’s very limited to viewing a file, just one, and in some cases, compare 2 versions of that file. But the rest of the interface is pretty focused on code only. Coders might know what to do with a file just by seeing its name, but designers like previews and thumbnails. And none of this is available so far, resulting in many clicks to view the content of a folder and finally seeing the file you were looking for. I do understand that this is a tool for coder, but if Github wants to please another crowd, they might have to propose a different interface. I’m guessing they could do this through an desktop client − by improving the one they already propose for example − or by providing a different web interface depending on your role. The issues and comments could also be enhanced to enable some form of “image annotation”.

Bitbucket psd diff preview broken

Bitbucket, from the point of view of a developer, does not seem to be lacking features compared to Github. It boils down maybe to some interface choices, but they overall look the same to me (although I’ve not used Bitbucket extensively, just for this test). Although with graphic file handling, I had the feeling Bitbucket is still buggy or unpolished in the corners. They seem to go in the same direction as Github, but if psd files are supposed to be rendered, all I got was broken/empty previews. The rendering and diffing works for svg, jpg, png and gif. Good. But no pdf rendering and most “binary” file formats spill their content source when viewing commits. I know it’s the default behavior of Git, but this creates pages and pages or gibberish content in the web browser that is totally unnecessary.

Like Github, Bitbucket proposes an in-browser file editor, if you quickly wish to correct a typo somewhere and commit immediately. But why offering this feature on image files? At first, I though: “wow, could I edit my image files right in the browser with Bitbucket?“. Answer is no, you’ll see a series of characters (Base64? or cyphered exif data?) that you’d better not touch if you don’t want to make your files definitely unreadable.

Bitbucket also offers a desktop client, but didn’t take the time to install it as it was looking more like a Soyuz cockpit again and only seemed to focus on coders also.

Gitlab file viewer

Lastly, let’s go over Gitlab CE, perceived as the open source clone of Github, but I guess that’s what most of us expect. Their Community Edition (CE) is a full featured “Github clone” that you can install on your own server. So it’s pretty convenient if you care about secrets or the indieweb. Unfortunately, they support fewer features regarding image handling. You’ll get a preview of most web file formats (jpg, png, gif, but not for svg) and visual diffing for those. But no pdf viewer (yet) or other fancy stuff. Since Gitlab is open source, it means we could drive it in the direction we’d like, or at least we might make propositions or fork it to bring it into a more designer friendly direction. Although the fork is maybe too far fetch as they seem to be very open to new propositions.

Even if these 3 solutions are a little  poor relative to what we’ve seen in previous posts about collaborative tools for designers, I’m definitely in favor of a Git based solution than a Dropbox (or similar) solution. What Dropbox misses totally is the collaborative work between designers and developers. And devs will never use Dropbox to version or share their code. While designers, provided with the right interface, could totally switch for Git. In that sense, for those looking for an easy solution to collaborate with developers on Git repos without learning any Git command, I recommend SparkleShare. It’s kind of like Dropbox, but with a Githoster backend. Though you better warn your devs that you’re going to use this, because your Git commits are going to be pretty dull and voiceless. For the rest, it’ll be as simple as saving your files from your preferred graphical application into the right folder. All the rest such as pulling, committing and pushing is handled by the Sparkleshare, running in the background.

That’s it for this part. I know there are some other Githosters out there. I did not want to go over them all, just the most popular ones. But if I missed one that has some great features or that is much more promising for designers, don’t hesitate to drop a line in the comments or contact me.

Collaborative tools for designers − part 5 : Adobe Creative Cloud

Adobe Creative Cloud App

Episode 5 already. Damn, so many collaborative tools for designers. Yes. And this post is about the one everybody talks about, but what they are actually referring to is something else: Adobe Creative Cloud. Let me rephrase that. When you tell people you are trying out Adobe’s cloud, they think you are using Photoshop or something. They don’t picture that what you are actually studying is the file hosting and syncing with Adobe’s servers. You know, the thing that works like Dropbox. Well, unless I’ve badly searched in the giant list of Adobe’s applications, the only tool they advertise doing collaboration and versioning, is Adobe Creative Cloud. Yes, the syncing app with the “real” cloud. No, not Photoshop. Your files, on their computer. You get it.

And don’t tell me it’s called Adobe Version Cue. Has anyone ever used this? I tried. A long time ago. And did not manage to make versions of my files with it. So I abandoned. And so did Adobe.

As I flew away from Adobe products since the first Creative Suite versions, I really thought that people were actually using the “cloud” services from Adobe, so I was surprised to hear none of my friends were actually using the 2Go of “free” hosting offered with their subscription. So to complete this review, I asked some friends if they wanted to test it. Sébastien Monnoye, teacher and designer, who also had never pushed files on the Creative Cloud before, answered the call and we started sharing folders together and explore the tool.

AdobeCC Hello World

One thing for sure, and you guessed it, is that it treats Adobe’s file format very well. The rest, not that much. You can, of course, see a preview of .psd and .ai files in the browser. But you can also break down that preview by turning on and off the individual layers for those files. Neat. With a click of a button you can extract certain elements from a .psd or a vector file and add them to a library of assets. These libraries are accessible right from inside Photoshop or Illustrator. So you could just drag and drop from those into a new design. It really speeds up the reuse of certain elements you might have made in your previous projects. (They also propose to buy and download existing libraries of assets. But I did not look into that too much or how you could submit your own designs.) And lastly, for all the elements in a design that you can select, they show you what are the CSS rules you need to write to have that same element behave the same way in a web page. Kind of nice. Especially for positioning.

Positioning from Adobe Creative Cloud

So, for every (adobe) file you upload, you can see some meta data, quickly access the major colors present in the design, leave comments for collaborators, extract assets, share the design on Behance and see the previous versions of the file. But don’t expect a reliable versioning system here. After 10 days, old versions are trashed.

After 10 days, we delete the past versions from the servers. If you know a version is going to be important, we suggest you make a copy of the current file you’re working on and save it with a new name. Then restore the original file back to the revision you care about. This way both copies become their own unique file that won’t be deleted automatically.

10 days is… ridiculous. And the solution proposed here kills all the benefits of using a versioning system. So let’s call this a short term memory backup, shall we. Nothing more. Why would you want to come back to a previous version of a design after 10 days, right?

Anyway, now on to the weird parts.

You know unix’s philosophy: everything is a file. Well, in the Adobe cloud, everything is an image. And if it’s not, it’s a blob. So yes, any .doc or plain .txt file is rendered as an image… Making it − if not unreadable, at least − unusable. HTML, CSS and Javascript are blobs. No way to see what’s inside them from the web interface. No versioning either (sorry, short term memory backup) for those. I’m not making this up. This is super strange. Adobe has a long list of tools related to web design, but displaying code in a web interface and versioning it, why would you want that, right?

AdobeCC file viewer

In the little application you install on your desktop, you get real-time notifications when a collaborator leaves a comment, but they don’t tell you which file has changed and who did the changes. So apart from the comments, the app is just there to do the syncing and let you access the Adobe market for apps, fonts, stock photos and assets libraries. You can also see a preview of what’s trending on Behance. (Mmmh actually, there is a way to see which files have changed, but good luck on finding where that is. Tip: it’s not in the notification window.) So to sum it up, this is more like a market place for the Adobe products than a tool to communicate and collaborate, as I thought it could be.

I’ve only tested graphic files. More tests could be made with InDesign files, Premiere, After Effects or Flash. But I’m kind of focusing from a web designer point of view. So I also tested some other file types: .odf (Libre Office), .xcf (Gimp) and .py (Python) and unsurprisingly, they are all treated as blobs. With SVG, it’s a special case.  They all are rendered correctly, but the features you can have with them are very different if you have saved them from Illustrator or from Inkscape, for example. The latter having the less feature, of course.

To wrap up, I’d say that the tool to extract assets is really a nice productivity improvement, but the syncing and collaborative features are behind what Dropbox is proposing. And since Dropbox just acquired Pixelapse, they really aim at offering an even better experience to designers, if they are not the tool of choice in that field already. Adobe is forcing its tool on everybody, of course, because you need that little app to install the Photoshop and others, but they need to polish it a lot more to get the designers to give them their files. And I don’t think that the “Publish on Behance” button is really a key here. But lets see how that evolves over time.

(Next episode: The Git Hosters )

Collaborative tools for designers – Part 1

Soyuz Cockpit

Since I’ve discovered and used distributed revision control in my day to day practice, I’ve been amazed by how much it has helped me getting more organized, stop worrying about loosing files and also encouraged me to experiment more and thus try more options in my work. And I’m not even talking about how it eased the collaboration process with other designers and coders.

But one of the major drawback is to convince other people to use it. Convincing someone who codes already, or who is not afraid of typing commands in a console, was easy. But talking just pure GUI fanatics to jump into it, is a bit harder. And for a good reason. The tools needed to manipulate the usual revision control systems are mainly designed for coders. Yes, there are some GUIs (I don’t use them), but they look like a spreadsheet or a Soyuz cockpit. And that barely helps make sense when you are looking at the type of projects that graphic designers have to cope with.

So, I’ve been trying to put my head around this problem and come up with solutions. I had a first try at it with a project called “Design with Git” that I had the chance to develop at Medialab Prado, Madrid in 2013. But this was just a beginning, a short-time experiment, and although I’ve spent energy applying to other residency programs to continue on building it, I’ve yet to find a place that would allow me to dedicate some time improving this concept.

So, since this subject is not dead for me and for a lot of others, I’ve decided to start a series of blog posts, in which I would clear my head out and put into words and graphics my thoughts around this subject. And as a start, in the coming posts, I’m planning to review some available tools for “revision control” and collaboration between designers.

A word of warning here, maybe. I’m biased by my experiences, of course. And so far, the only version control system I’ve used extensively is Git. When I started being interested in these kind of tools, I got my hands on CVS, but then Git (and Github) quickly became the trending thing and I drank the Kool-Aid. Also, CVS needed a server, and that was too much to set up for me just to manage my own projects. I’m not a Git-guru either. I use it, almost daily, for almost all the things I produce. But I’ve not gone beyond the basics of cloning, branching, diffing, pushing and merging. When I have to do more complex tasks like going back to an older version of my files or completely erase a file from history, Stackoverflow is my friend.

So here is a list of what I find useful when using Git with my projects:

  • It allows me to view a history of changes, which files have changed and a written description about it (status / log)
  • It allows me to easily make different versions of the same project and to quickly switch between those versions (branch)
  • It allows me to work with an undefinite number of people (clone / fetch)
  • It returns precise and valuable information between the changes or different version of the project (diff)
  • It allows me to integrate the changes made by another person into my own project (merge)
  • It does not require a complex setup to start using it (init)
  • I do keep my folders tidy as I don’t have to invent complex naming formats for my files (No more Front-cover-v4a-TOPRINT2-validated.pdf)
  • It allows me to view the contributions of each participant on the project (log)
  • I’m not worried about loosing a file, erasing or writing over my previous work.
  • It eases the process of working with developers because we are sharing the same tool to keep track of the project’s advancement.

This list, I think, sums up for me what are the main benefits of using a distributed version system such as Git and these are the benefits graphic designers should get from using it also. The catch is this works well when you’re dealing with code or text files. But some points here are a little or very problematic when it comes to dealing with design files. Hopefully, there is some solutions or things that can be adapted. And I believe this is possible while keeping Git at the core of the process.

But before going further into this development, I’m planing to explore some of the tools promoted as helping designers in their revision control and collaborative process and I’ll do so using this list as a frame or a grid of evaluation.

So see you next time. (go to Part 2)

(Cover image: Soyuz cockpit by Christopher Michel under Creative Commons Attribution 2.0)