Things I Learned Designing at Disqus(joshuasortino.com)
joshuasortino.com
Things I Learned Designing at Disqus
http://joshuasortino.com/journal/14-things-learned-designing-at-disqus
8 comments
If you are writing for a design audience, you are going to get a lot of frowns for the 700KB paper background image you have on your blog (and the paper barely even shows).
much worse (dark pattern?): on my mobile it puts a Twitter share link exactly where my thumb is touching the screen for scrolling.
"Engineers should teach engineers GIT, designers should teach designers GIT."
is git part of modern design workflow ? how are designers using git ?
is git part of modern design workflow ? how are designers using git ?
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?
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?
git does allow you to check out only a selection of version history
Oh ok, but that's not how it would operate, right? So, say it was just me working on a project using a psd. If I committed it a couple of times a day, I'd end up with all the old copies in the local object store. Maybe it's possible to clear those out, somehow? Either way, you'll find that you have to jump through hoops to get reasonable behaviour with git in this use case.
I see I've been downvoted for my previous comment. I'd appreciate a justification from the downvoter as this is actually an area in which I have some experience.
I see I've been downvoted for my previous comment. I'd appreciate a justification from the downvoter as this is actually an area in which I have some experience.
All sorts of assets have been stored in version control systems for decades now. That includes designs, images, documents, specifications, and so forth.
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.)
Clone the repository and start a webapp locally to tweak CSS and do other designery things.
I agree with pretty much everything, except designers using Git. Sadly, Git doesn't work for PSD files properly. Some of the PSD files I've worked with before (900mb+) for larger websites and applications would definitely not be a good fit for Git. Although I think the blame lies mostly on Photoshop's end not being the right tool for web design, but being used by designers anyway. I think whatever tool ends up replacing Photoshop as the de-facto standard (if it happens) should ideally have a visual re-visioning system built in a la Adobe Creative Cloud.
We aren't quite at that point where designers are saving out all of the assets for you, then that would be different. You can source control individual assets, but not a large PSD file properly. I've begun to train the designers at my work to save out assets for pretty much everything leaving me to solve the engineering problems like how everything is going to work and less time cutting out images from a PSD file, but we aren't quite there yet where this is a universal thing that designers just know and willing do.
Some people might disagree with point #6, but I wholeheartedly agree as someone who works for a company where designers design and developers develop. I think to be truly great at design, you need to devote at least 90% of your time (minimum) to bettering your design skills. If you're a developer, the opposite rings true. 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?
Fortunately, the employer I work for doesn't compartmentalise the teams from one another. There is nothing more horrible than working in a place where design and development teams are on separate sides of the office or even different floors with the only communicative layer being a project manager or team leaders. Designers and developers sit down and tackle problems together and educate one another in the process. This is something that happens through the whole process from wire-framing to prototyping to final build. I think designers and developers should work together at every step. I have met talented design/developers, but great ones of both fields are extremely rare.
PS. Joshua, if you're reading this comment, you might want to reconsider the 670kb background image on your site. I loaded your blog on my slow ADSL connection and it was painful.
We aren't quite at that point where designers are saving out all of the assets for you, then that would be different. You can source control individual assets, but not a large PSD file properly. I've begun to train the designers at my work to save out assets for pretty much everything leaving me to solve the engineering problems like how everything is going to work and less time cutting out images from a PSD file, but we aren't quite there yet where this is a universal thing that designers just know and willing do.
Some people might disagree with point #6, but I wholeheartedly agree as someone who works for a company where designers design and developers develop. I think to be truly great at design, you need to devote at least 90% of your time (minimum) to bettering your design skills. If you're a developer, the opposite rings true. 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?
Fortunately, the employer I work for doesn't compartmentalise the teams from one another. There is nothing more horrible than working in a place where design and development teams are on separate sides of the office or even different floors with the only communicative layer being a project manager or team leaders. Designers and developers sit down and tackle problems together and educate one another in the process. This is something that happens through the whole process from wire-framing to prototyping to final build. I think designers and developers should work together at every step. I have met talented design/developers, but great ones of both fields are extremely rare.
PS. Joshua, if you're reading this comment, you might want to reconsider the 670kb background image on your site. I loaded your blog on my slow ADSL connection and it was painful.
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.
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.
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.
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.
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!
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!
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.
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.
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?
Usually layers itself do not make a PSD big. A big PSD file is usually because the DPI is huge and >500mb PSD files are very common in the print industry where designers have typically design between 300 to 600 dpi. A B2 poster at 600dpi will easily be >500mb.
*A PSD file has a max height and width of 30,000 pixels, and a length limit of 3 Gigabytes. Hence, Photoshop created PSB filetype which supports max height and width of 300,000 pixels and the length limit to around 4 Exabytes. https://en.wikipedia.org/wiki/Adobe_Photoshop#File_format
*A PSD file has a max height and width of 30,000 pixels, and a length limit of 3 Gigabytes. Hence, Photoshop created PSB filetype which supports max height and width of 300,000 pixels and the length limit to around 4 Exabytes. https://en.wikipedia.org/wiki/Adobe_Photoshop#File_format
Tons and tons of layers, I mean literally hundreds.
To elaborate, for anyone who hasn't used Photoshop (in several years): you can have layer groups which act as folders containing several related layers, so when you're browsing layers, it isn't just a mess of 500 some-odd rows.
Yeah, I should have mentioned that. You can also stuff a lot of component images into a psd that wouldn't necessarily make it into a final web design.
Sounds like what's needed is a way to extract a PSD into a component file structure, and combine that structure back into a PSD. Without knowing anything about PSDs, I assume it would contain lists of layers with links to resources such as images or whatever is required to approximate the desired view. Something like that as a plugin or hooked to run before and after commits would be really useful in this case.
Depending on how hard the PSD format is to grok (purposefully or otherwise), this may be nigh impossible, but it also seems like it would be a great exchange format (which may be a another reason Adobe wouldn't want it). Then again, maybe there's already something like this...?
Depending on how hard the PSD format is to grok (purposefully or otherwise), this may be nigh impossible, but it also seems like it would be a great exchange format (which may be a another reason Adobe wouldn't want it). Then again, maybe there's already something like this...?
[deleted]
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/
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.
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.
> Designers are generally right brained and engineers are usually left brained
Is that true? Even if it's a myth of left vs right side of the brain are designers and engineers really that different in the brain?
Is that true? Even if it's a myth of left vs right side of the brain are designers and engineers really that different in the brain?
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.
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.
Yup.
I know the whole left/right brain thing isn't real science. I was using it as a common metaphor. Designers and engineers typically approach things differently. Learn from someone else's approach.
I know the whole left/right brain thing isn't real science. I was using it as a common metaphor. Designers and engineers typically approach things differently. Learn from someone else's approach.
Would you say #6 and #7 are true generally, or Joshua's opinion?
To avoid inefficiency I find having people 'jigsaw-puzzle-piece' shaped helps - it means they're not always waiting on Bob on the desk over there to do the task that's blocking them (even if that task is only "Export an item from a PSD").
To avoid inefficiency I find having people 'jigsaw-puzzle-piece' shaped helps - it means they're not always waiting on Bob on the desk over there to do the task that's blocking them (even if that task is only "Export an item from a PSD").
#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?
Isn't there something to be said about engineers teaching designers git, and the other way around? I understand that what you're saying is easier and more efficient, but learning to communicate should be a pretty big deal, and teaching others helps a lot.
Does anyone have any thoughts on Disqus, particularly reviewing the usability and/or design aspects?
I see the service itself as meeting a need for those with static sites or who otherwise don't want to deal with managing their own commenting system. Disqus has also made some business decisions to increase revenue that have upset a few HN'ers¹. I haven't heard any complaints about usability or other design issues, though.
¹ https://news.ycombinator.com/item?id=5220072
I see the service itself as meeting a need for those with static sites or who otherwise don't want to deal with managing their own commenting system. Disqus has also made some business decisions to increase revenue that have upset a few HN'ers¹. I haven't heard any complaints about usability or other design issues, though.
¹ https://news.ycombinator.com/item?id=5220072
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.
As for the business decisions, those were decided by VPs and the business development team.
The thing that stood out for me is that over a billion unique people use the service. Does it really underpin that much of the modern Internet?
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.
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.
sheesh. That's a bit much.
The site owner chooses a commenting system. People who want to comment, comment using it. Victims?!
The site owner chooses a commenting system. People who want to comment, comment using it. Victims?!
Victims is a pretty loaded term, but it's not an unreasonable accusation. The number of unique monthly users of disqus shouldn't be based on those who unwittingly use it.
Reading your comment again, I wonder what the true definition is. Is the number based on page views? Or is it the number of people who actively interact with the widget (say, posting a comment) after it has loaded? Sounds like you're assuming the later metric while the 'victims' comment is assuming the former.
Edit: thinking about it, 1 billion unique people, that sounds like the victim class to me.
Reading your comment again, I wonder what the true definition is. Is the number based on page views? Or is it the number of people who actively interact with the widget (say, posting a comment) after it has loaded? Sounds like you're assuming the later metric while the 'victims' comment is assuming the former.
Edit: thinking about it, 1 billion unique people, that sounds like the victim class to me.
yep, speak my peace or not, have no voice or use their crap system. victim is about right imho.
It's similar (though a bit stretched) to count site visitors as google analytics users. Or, less stretched, users who click on ads as a Google Adsense/words users. It doesn't subtract from their success though.
i cant stand disqus, i leave articles more than not because i dont like to be forced to comment using the system. it blows and needs to die... i thing webmasters use it because they are lazy, not because it is good.
I don't know if you've used a lot of blogs/CMSes/etc, but you definitely overrate their commenting systems. Most of them are crap. That's why Disqus is so popular, because it has tons of cool features (like the little popup that says when someone has posted before you).
Heck, Disqus is better than 90% of the forums out there (Hi, there, PHPBB or vBulletin!).
Heck, Disqus is better than 90% of the forums out there (Hi, there, PHPBB or vBulletin!).