4 ms·
But the article doesn't really build an argument, more like paints the alternative as "the old and bad and non-agile way". Which may be true, but it's not an ar
by Jare 13y ago
But the article doesn't really build an argument, more like paints the alternative as "the old and bad and non-agile way". Which may be true, but it's not an argument.
- ThomPete 13y agoI think this is a pretty strong argument: "There is a legacy process that sits behind the design methods we apply to software creation; 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. Most software design is still outsourced to firms who are traditionally marketing 'creative' companies. They're expensive, they'll deliver you a pixel-perfect layout of your entire application, and they'll charge you for it. It's what they know. "But it's all just documentation, really." says Andrew, "Comps, mockups, pitches, they're just requirements: visual documentation." What's worse is that we freeze this documentation as The Final Design, a canonical reference. Once that happens you stop talking about it, you stop challenging it or even being aware it needs adaptation. Worse still, there's a tendency to fall back to what you consider absolute, and the design starts driving the product. He sums it up: the accepted practice is not to redesign. Even some of the most successful Agile delivery teams are doing design the old fashioned way. Segmenting the design off as something that has to be done first. Only then do we shift into a happy Agile land. Wherein when we get feedback, we change and pivot on our product. We need to pivot our design, too. When everything is designed up front, and we change – then the vestigial parts of the design become waste. We must be leaner." Having founded and run a design and dev agency myself I was made painfully aware of this issue.
- marshray 13y agoBeen there seen that from the software side too. However it really wasn't that big of a deal. We just re-did the thing in HTML and re-used most of their graphics. Hardly worthy of a "The No* Movement" title. The part about "you stop talking about it, you stop challenging it" resonates with me. But isn't that the job of whoever's responsible for the website? Can we really blame a file format for that? Let's all try to be a little bit flexible and try to let everyone use the tools they prefer.
- ThomPete 13y agoWho is saying people can't use the tools they prefer? And it's not the fileformat it's the process that leads to delivery of the fileformat that is being challenged as far as I understand it. The argument is not a dictate, it's an argument for why they choose not to do it and some of the problem they think arise when people do it in sofware development.
- marshray 13y ago> Who is saying people can't use the tools they prefer? Isn't "the NoPSD Movement" basically referring to Photoshop?
- ThomPete 13y agoIs the Python language really a python? The NoPSD movement is making a point against what 90% of what all designers use. PSD is just used a common reference point.
- marshray 13y agoNo, 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 ago