Things I Learned Designing at Disqus

much worse (dark pattern?): on my mobile it puts a Twitter share link exactly where my thumb is touching the screen for scrolling.

All sorts of assets have been stored in version control systems for decades now. That includes designs, images, documents, specifications, and so forth.

Clone the repository and start a webapp locally to tweak CSS and do other designery things.

At any scale, git is probably not going to be your best bet. svn might actually be a better option as it allows you to checkout just the parts of the repository that you need.

More crucially, it doesn't keep the entire history locally (just working copy and a the latest(ish) version in the repository). This really starts to matter when you have 200mb PSDs.

There are probably even better options out there (though previous searches didn't reveal anything I particularly got on with) - there are certainly better options than git.

Ideally something based around the dropbox model (doing block level deduplication) would be wonderful. Maybe such a product exists?

I was talking about the 10% of the time designers should be coding in this type of environment. (I.e. pushing polish code or hacking together a quick marketing page.)

I'm not a designer, so please enlighten me. What kind of data can be held in a single image for a PSD to be 900 megabytes? Is it a single PSD for hundreds of web pages or?

It's unfortunate that PSD files don't work with git because so much of the development and release process ends up being built around git (e.g. merging code into trunk triggers the continuous integration tests). If designers don't use git, they can end up out of sync with their engineering peers. As the author said, designers who code are at a big advantage, even if they spend most of their time designing.

As a compromise, we had some luck syncing the PSD files with Box and checking in the exported static assets to git, but it was more of a patch than a solution.

Git doesn’t handle image files well at all, because it wasn’t designed for it. That said, I think the OP is talking more about designers using Git for code, not images. Designers don’t just make images, etc.

I really disagree with you that Git is not a good tool for designers. It's certainly not friendly to learn, but for designers who get the process, it is incredibly useful. If you have lots of 900MB binary blobs I guess that's going to be a problem, but the vast majority of assets in a website or app are text files, jpg and png files which are small, and the vector artwork or PSDs used to generate them (for vector that's really small, for psds that can vary from a few MB up to 100MB (which git is perfectly fine with), but 900MB is in my experience really rare). Photoshop is just one tool in the arsenal, and not particularly effective for anything involving text (the layout tools aren't great), anything which will be translated to html (just mock up in HTML/CSS after some quick roughs - far less friction), or anything which requires resolution independence (almost every asset nowadays).

Of course this depends on workflow and tastes vary, but for designers who don't use PSD to actually design websites (a purpose for which it is not very well suited), git or other version control tools are incredibly useful. Wasting a bit of extra space storing a few versions of a psd file is no problem - I've worked on 20GB local repositories before with a lot of assets, without issues, and it's easy enough to separate out large files into another repo or leave them out of version control if you have to. If a designer is creating 1GB PSD files with hundreds of assets in, I'd say (as a designer) their workflow is fundamentally broken unless they are producing billboard advertisements which require very high resolution files - you shouldn't have that much of anything glommed together in one file. So git works perfectly fine for lots of designers today, even working with binary files.

It's just a shame that these version control tools are mostly isolated to the workflow of programmers, as people at most workplaces I've come into contact with, from architects through writers or editors, sorely need a tool like git in order to manage collaboration and versions.

I don't think he was talking about using Git for graphics files. I assume he meant html/css/javascript files.

As a designer who codes (or a coder who designs, not sure at this point), I can see what he means about learning Git. It was tough for me to grasp until I saw this:

http://nvie.com/posts/a-successful-git-branching-model/

I should clarify, I wouldn't normally recommend using Git for PSDs or binary file collaboration in general.

My point was that a primarily right-brained designer should teach fellow right-brained designers how Git works. Things just make more sense that way.

In my experience as both a designer and a developer, Git is not the right tool for most designers. Technically, Git is not ideal for binary files. When the file size is too large, Git fails badly. Git works well for text files, not binary files.

Many designers who do not code at all do not understand the workflow of Git. The process of pull, commit, push is extremely confusing. E.g. One large company that forces all designers to use Git ended up with multiple files with slightly different names in the repo system. Designers do not understand the concept of merge conflict and will just rename the file so that they can push to the repo. Case in point: the mental model of Git has worked well for developers, but does not translate well to non-coders.

Overall, I think a version control system for designers should be transparent, non-intrusive, and just works. Designers should not have to worry about when to push or pull, should not have to worry when to commit. I think it should just backup every saves and then subsequently allow them to flag specific design iterations that they want to highlight.

Disclaimer: I am co-founder of Pixelapse - Version Control for Designers.

> I think it is important for design/dev to have a mutual understanding of one another, but I don't think you can truly be a great designer and great developer in one. Having an understanding of the other perspective is important. You'll never meet a surgeon who specialises in brain and heart surgery, why should design and development be any different?

What is the definition of "developer" here? Does it include HTML and CSS? I love working with designers who can translate their designs into actual layout and styling because it seems a lot closer to what they're good at than it is to what I'm good at. It seems like there's quite a bit of gray area in these definitions, but building front-end application behavior seems to flex similar muscles as building back-end application behavior, while tweaking CSS seems to flex similar muscles as tweaking element widths in photoshop. I'm genuinely curious what the common designer point of view is on this!

In my experience working with designers, and having done a decent amount of design-y work: yes, definitely.

In my experience, designers tend to be more holistic in their view on things, to a point where they might outright hate it when things are picked apart and defined and categorized. Which is exactly what engineers excel at.

I also find designers to generally be more... emotional, or at least they show their emotional side more, or allow it to express itself.

And then there's the strong value they place on the 'design' of things. The feeling, the cohesion, etc.

One of the best examples of the difference I can think of is when I showed worrydream.com to a designer friend. I was excited about Brett Victor's talks, his views on programming and interfaces and whatnot, and figured my friend would be at least interested in the UX stuff. This friend, however, hated how the site felt bloated and slow and how that in itself was pretty much enough for him to not take this guy's articles seriously. It was an affront, and surely anyone who had anything interesting to say on design and UI would take care of his own site!

Now in many cases the difference between designers and engineers might not be so pronounced. I suppose it's a spectrum. But I notice very clear differences between developers and designers, and it seems to be a common cause of conflict.

I've also noticed this difference within myself. For the past two years I mostly focused on development, after a long time of taking care of more of the whole pipeline (especially client contact and the 'social' aspects of design). I noticed that I started caring markedly less and less about the end result's 'beauty' or logic, and more and more on the internals. I actually stopped noticing things that would've bothered me tremendously in the past: fonts, padding, margins, UX, and so on.

In part, maybe it's also a role you step into (where either role somehow excludes the other).

And the mere fact that I come across very few people who seem to be both excellent designers and engineers supports the idea that there's a difference.

I’m a systems-minded designer who can code. Left/right-brained signifiers work decently well in theory, but fall apart with real humans. People aren’t that binary.

It's pseudoscience. His point isn't, though: some people are more deductive/math oriented, some people are more associative/aesthetically oriented, and some people are neither. It's good for them to mix.

#6 is just semantics. Multi-purpose people are great. Rare and exceptional people are great. Designers who can code are great. What does it matter what you call them?

Even if you haven't heard them, we still get complaints about the usability of the product! It's what we did with the feedback that matters.

As for the business decisions, those were decided by VPs and the business development team.

How many of those are voluntary, active users, though?

I see them more as "victims" of it, who are subjected to it without giving much consent at all. Somebody loads a blog article or some other web page that uses Disqus for accepting and showing comments, and without necessarily wanting to use it the page's visitors have become "users" of Disqus.