3 ms·
No, it's a tool. If we went about promoting a "NoPython Movement" in the context of computer programming I suspect that some people would get the idea that we
by marshray 13y ago
No, it's a tool.
If we went about promoting a "NoPython Movement" in the context of computer programming I suspect that some people would get the idea that we didn't like Python very much.
Substitute 'XCF' and 'Gimp' in place of 'PSD' and 'Photoshop' and my point still makes sense.
- ThomPete 13y agoThe difference is that 90% af developers do not use python, 90% of designers do use photoshop. So no your point does not stand. All you have done is shown that you either doesn't know anything about the design community or you deliberately don't want to understand what is meant. I am guessing the last.
- marshray 13y agoI do understand about the popularity of Photoshop. I know relatively little about "the design community" and am just a bit skeptical that it is as monlithic as some folks make it out to be. Again, my point was simply that in our development process, "asset pipeline", or whatever you want to call it, we ought to be a bit flexible to let professionals use the tools they feel they are most productive in. Obviously, sometimes the workflow calls for HTML output. But if there's a brilliant designer in town who only knows how to generate EPS, PDF, or PSD (we've all met them) maybe it's not the end of the world if someone else does the HTML/CSS/Javascript. The tools and the processes exist to serve the talent, not the other way around.
- ThomPete 13y agoI don't think you got are getting the point they are making though. It's not about the result of the PSD files, it's about the result of the process of designing for something that isn't a final composition but rather an ongoing process. It doesn't matter whether someone is a brilliant designer. What matters is that the de-facto way most work is creating friction that isn't necessary and is often counter-productive. It's not argument against photoshop or psd, but rather a process philosophy if you like. And for something very specific namely app design.
- marshray 13y agoI get it: using bitmap files for an app introduces a big ugly manual process step and so using them as a static master for an app design discourages iteration and evolution. > It doesn't matter whether someone is a brilliant designer. Perhaps we can agree to disagree on that. > What matters is that the de-facto way most work is creating friction that isn't necessary and is often counter-productive. Maybe I've just heard this 'lessons learned from assembly-line manufacturing' applied to design and construction too many times.
- ThomPete 13y ago* > It doesn't matter whether someone is a brilliant designer. Perhaps we can agree to disagree on that.* Perhaps you shouldn't take a sentence out of it's context. Maybe I've just heard this 'lessons learned from assembly-line manufacturing' applied to design and construction too many times. What on earth does it have to do with what we are dicussing?
- marshray 13y agoPhrases that make me think of assembly-line software construction: Design process: "it's about the result of the process of designing for something that isn't a final composition but rather an ongoing process." Process standardization: "It doesn't matter whether someone is a brilliant designer. What matters is that the de-facto way most work is creating friction" Process philosophy: "but rather a process philosophy if you like. And for something very specific namely app design" Process optimization: "It's such a bloated process, full of wasted energy. It might work for selling billboards but it certainly doesn't work for building software." To be clear I don't disagree with any of these statements. But they trigger my PTSD flashbacks of Deming and TQM. Additionally, if this friction is such an up-front one-time event early in the life of a new product, how important is it really to software development? How often does your development shop experience this friction really? The article is arguing against the entire business model and workflow of these agencies: ...most of it comes from traditional marketing and design. It's an approach that's worked for creative agencies: magazines, TV advertisements, advertising campaigns – all these things are planned meticulously up front. In some cases, it's necessary – after all, it's harder to change an advertisement that's aired, or a magazine that's been printed then it is to change software...When dealing with traditional creative agencies it’s a well known fact that designs will not go back once they are pronounced final because they are too expensive to re-engage. What he's advocating for is a change in the contract terms for their creative industries. So phrasing the solution in terms of "NoPSD movement" makes for good blog, but even as a metaphor for asset workflow it just totally understates the fundamental-ness of what he's asking. It's as if we were going to reign in unrecognized cyclic dependencies on Wall Street in the from of credit-default swaps by advocating a "NoXLS movement". Of course this is largely innocuous in the grand sceme of things. But the danger lies in Dilbert's manager thinking himself cutting-edge by decreeing "OK team, from this day forward nobody uses Photoshop".