Slashdot Mirror

← Back to Stories (view on slashdot.org)

The New Link Between Designer and Developer

Posted by ryuzaki0 on from the brain-to-brain-contact dept.

Scott Kinder writes "Ryan Stewart of ZDNet discusses the importance of the workflow between designers and developers. Both Adobe and Microsoft have a lot at stake in their respective software projects. Given how important experience is in making software, ensuring that it is easy for designers and developers to work together is more important than ever." From the article: "The key here is going to be the workflow between designers and developers and making sure that the tools support both types of content creators. Creating world class RIAs simply will not be possible without an efficient workflow between the two areas. Adobe has focused a lot on incorporating Adobe and Macromedia products, making sure that designers can easily move between both companies software. But they haven't quite perfected the designer/developer workflow, and I think Microsoft has a bit of a head start here. The Expression Suite seems built from the ground up to work well with their developer tools. The question will be whether or not designers will use these new tools."

70 comments

  1. Ryan Stewart by Anonymous Coward · · Score: 1, Insightful

    Let me guess, this guy is a developer and that's why he prefers the MS approach?

    1. Re:Ryan Stewart by RAMMS+EIN · · Score: 1

      Developers prefer something that is from MS? That's news to me!

      --
      Please correct me if I got my facts wrong.
  2. Title should read by Bague · · Score: 1

    "The New Link between Intelligent Design and Developers Developers Developers." Who would have ever thought that 71% of the earth's surface was a blue screen of death?

  3. How about a link between developers and users? by Morgaine · · Score: 3, Interesting

    "The customer is always right" we hear, and indeed when the silly crud and newbie chaff is separated out, there is often good substance and insight coming from the more knowledgeable users, sometimes even terrific suggestions.

    Yet, how many companies actually have a strong official link between users and developers, taking user suggestions and pinning them up visibly as official input to the works process, duly accredited? Almost none, in my experience. The trend seems to be to have a Customer Relations officer whose job is to answer obvious questions from users and to keep fanboys happy, and little else. If a requested feature is implemented, it appears by a form of magic as a fait acomplit; the process of design, development and testing is certainly is not made visible, in general.

    This area could be improved a lot in the corporate world!

    On the FOSS side of things of course, we have merging of designer/developers and users, so the issue is somewhat irrelevant. We can still improve our communications and documentation *a lot* though.

    --
    "The question of whether machines can think is no more interesting than [] whether submarines can swim" - Dijkstra
    1. Re:How about a link between developers and users? by abhi_beckert · · Score: 0, Flamebait

      The whole idea of increasing feedback between users and developers is total bullshit: developers have more important things to do than explain why it's a bad idea to implement xy in the next release.

      I've worked as a developer in both software that people download and more recently custom software developed for a single client, and there's one thing that hasn't changed in either model: the customer is *never* right. Or at least, so close to never that it rounds down to nothing.

      I agree 100% that there needs to be a good system in place for developers to receive feedback from users, but in most cases it's best as a one way flow. Developers need to see what needs to be done first, but end users don't really need to see what will happen next. Also, user's feature requests almost certainly never, ever, *ever* will happen for one simple reason: it takes five seconds to request a feature, and five days to implement it. When combined with the fact that feature requesters outnumber feature implementers by *several thousand to one*, it's pretty easy to see why that's an impossible situation (and that doesn't even take into account the fact that most customers, and especially clients, have no idea what they're talking about). If a feature you requested gets implemented, 99% of the time it was already on the to-do list long before you dreamed it up.

    2. Re:How about a link between developers and users? by Timesprout · · Score: 5, Insightful
      On the FOSS side of things of course, we have merging of designer/developers and users, so the issue is somewhat irrelevant. We can still improve our communications and documentation *a lot* though.


      You must be joking. Most companies _have_ to pander to their customers. They dont make money otherwise. Even MS have gone to astonishing lengths to support their customers. OSS tends to utterly ignore the mainstream user which is why many mainstream users would rather steal a copy of windows than use OSS. Report a bug and be told to fuck off thats intended behaviour/user error, request a feature and be told to fuck off its a stupid request, ask for help and be told to fuck off and read the documentation, point out there is no documentation and be told to just fuck off. Think about that for a few mins and tell me if you can see a problem.
      --
      Do not try to read the dupe, thats impossible. Instead, only try to realize the truth
      What truth?
      There is no dupe
    3. Re:How about a link between developers and users? by honkycat · · Score: 2, Insightful

      Perhaps I'm not understanding you right, but are you really suggesting that users have no place in the software development cycle other than buying the software and firing off feature requests into the void? That seems like a broken view, but I may not understand what you're saying.

      Now, I'll agree that the *developers* are probably not the right people to be fielding user feedback directly. This isn't because they have "more important things to do," rather, it's because a developer doesn't usually have the authority over the architecture of the product to engage in that sort of decision one-on-one with the end user in the first place.

      However, to suggest that the users should be left out of the loop entirely is an arrogant view that puts WAY too much confidence in the ability of the architects ("designers" in this article's lingo, I guess) to anticipate every need of the users. Instead, the architects should have some mechanism to get feedback from users. The users are the folks who actually know what they're trying to do with the software, so even if they don't know what's easy to implement, they know what is holding them up. The architects are in a place to understand why the user has requested a feature and to decide whether it is consistent with the design and reasonable to implement.

      Every company I've worked for has done this and it's often invaluable, but it does require some effort and discipline. It's a part of understanding the application that the architects must do to some degree as part of the design process. The level of hand-holding that the user gets while making requests will depend on his clout as a customer, ranging from application engineers or even architects going on-site to tailor software to a key customer's needs, to tech support tallying requests for various features and passing them along in aggregate.

      One other thought -- just as the user shouldn't be telling the *developer* what to implement, it's also more useful to solicit feedback as "capability requests" rather than "feature requests." The distinction is that a feature request implies (to me, anyway) something like "I want to click here and here and then type "blah blah" and it's done." This is usually too detailed. Instead, the feedback should be "I need to accomplish XYZ rapidly" and the architect should be free to design a solution to this that's consistent with the existing design.

    4. Re:How about a link between developers and users? by Breakfast+Pants · · Score: 1

      Redhat has never told me to 'fuck off'. And for all the OS people that have, I've never been paying them for support.

      --

      --

      WHO ATE MY BREAKFAST PANTS?
    5. Re:How about a link between developers and users? by jsebrech · · Score: 1

      Redhat has never told me to 'fuck off'. And for all the OS people that have, I've never been paying them for support.

      Bad example. Redhat makes money selling proprietary software and services, and only uses OSS as a leveraging tool to gain technology and mindshare. When you look at pure OSS projects, that aren't trying to sell people something, the user focus just isn't the same.

    6. Re:How about a link between developers and users? by jsebrech · · Score: 1

      One other thought -- just as the user shouldn't be telling the *developer* what to implement, it's also more useful to solicit feedback as "capability requests" rather than "feature requests." The distinction is that a feature request implies (to me, anyway) something like "I want to click here and here and then type "blah blah" and it's done." This is usually too detailed. Instead, the feedback should be "I need to accomplish XYZ rapidly" and the architect should be free to design a solution to this that's consistent with the existing design.

      Exactly. Being able to ask a user what task they want to be able to accomplish is important, being told what it is before you even get to think about asking is even better.

      One of the apps I've built is a floorplan viewer. I didn't have much in the way of guidance or feedback during the design and development phases, so I mostly did it all myself, trying to figure out what a user would need. I ended up making a few design blunders that seemed perfectly sensible at the time. Like, floorplan printing. My idea was "print exactly what the user sees, scaled to the dimensions of the page, including any whitespace". That sounded reasonable, but it doesn't apply to the most common case of printing floorplans: print the entire floorplan, without extraneous whitespace.

      Talking with the user about the task they're trying to accomplish is very important.

    7. Re:How about a link between developers and users? by theshowmecanuck · · Score: 2, Interesting

      Customer's feedback should be listened to, and I bet even you do it. The problem is, in a corporate environment, a developer's work has far too many end users and he/she cannot possibly take in all the feedback. That is why they have requirements and design teams between them and the customer. They filter the feedback/feature requrests and figure out what can possibly fit. My impression is that it is the communication between the designer and developer in this process that they are trying to improve so that the developer doesn't just receive orders from above that are technically difficult to achieve. i.e. having an idea of what the code is doing can help streamline and improve the design. I have seen this done in several places where the requirements person or designer does not program, but understands through close relations with the developers how the code is implemented. They can then understand what is sensible and even do-able when requirements are added and design is taking place.

      Since you are a 'one man show' you probably do this intrinsically.

      --
      -- I ignore anonymous replies to my comments and postings.
    8. Re:How about a link between developers and users? by WilliamSChips · · Score: 2, Informative

      I've never seen somebody told to fuck off unless they say stupid and illogical things in the development(NOT user support) channel multiple times, and even after having everything carefully explained to them they just come back and do the same thing. Everywhere else I've seen people be way too nice to people who should be sterilized to prevent the propagation of their sterility.

      --
      Please, for the good of Humanity, vote Obama.
    9. Re:How about a link between developers and users? by Anonymous Coward · · Score: 1, Insightful

      Instead, the feedback should be "I need to accomplish XYZ rapidly" and the architect should be free to design a solution to this that's consistent with the existing design.

      That is precisely what a requirement is. You find that users are really quite particular however, because they're not really sure what the requirement is, all they typically have is a vision of how their ideal app might work that they narrate back to you. A good architect distills requirements out of this sort of thing and makes sure the customer agrees on the shared idea before proceeding.

      A decent use case is good for documenting a requirement, as any use case that dictates implementation is probably too detailed. It's always a continuium from perfect to broken: there's always functional specs that creep into requirements as well as vague requirements not given functional specs. Hell there's probably some sort of incompleteness theorem that says the two won't ever meet perfectly, but getting everyone clear on the difference is a good first step.

    10. Re:How about a link between developers and users? by honkycat · · Score: 1

      Yep, you're quite right. This is part of the reason that a two-way communication between users and designers/architects is important. Since the users and the architects typically think about the software in different ways, there's usually some back-and-forth to make sure that the architect understands what it is that the user is trying to do. Then, if the architect needs to specify a different way to accomplish that goal, someone needs to pass that along to the user so he knows how to get his job done.

      As for connectiong functional specs and requirements, I think you're probably right that they never quite match up. In my experience, this is one of those things you've just got to live with. Often, the paper-pushing effort to nail down those last few things just doesn't pay off.

  4. I've R'd TFA and... by Anonymous+Brave+Guy · · Score: 2, Insightful

    ...I still have no idea what its point is.

    Are they working on the basis that companies have graphics designers who work out the visual appearance, and programmmers who write the scripts to update the content in whatever way, and these two roles are independent?

    In my experience, that rarely happens, just as it rarely happens for desktop apps that there's someone who designs the user interface, and then there are guys who write the code behind it. Perhaps for very large projects in very large companies this is more common, but certainly not in smaller outfits IME.

    Even if the larger companies want to put more effort into the presentation/usability aspects of their web sites, how is this any different to the problems of UI design for desktop apps that we've been working on for years? Just get the guys who are experts in graphic design, accessibility, and so on to put together the concepts and work out the HTML, CSS and graphics they want to use. Then give the specs and prototypes to the programming team to insert their code into them. This idea is not difficult to implement for even the largest desktop applications, and I don't see why the fact that the presentation medium is a web page makes any difference.

    Then again, I still code up my pages using text editors and scripted tools rather than all these funky "web design" applications, and I only maintain a few hundred pages with thousands of hits per day single-handed and in my spare time, so I have no idea what I'm talking about. :-)

    --
    If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
    1. Re:I've R'd TFA and... by CaymanIslandCarpedie · · Score: 5, Insightful

      Then give the specs and prototypes to the programming team to insert their code into them.

      I've just seen to many cases of everybody wants a slightly different look/feel that I don't believe in any "prototype" being what will eventually be wanted. Thus developers should never "code" what the GUI will look like. Devleopers should implement a framework which seperates function from presentation and give designers the tools to allow them to completely change the design without having to recompile or touch a single line of code.

      There are so many amazing tools and code examples about this type of application "skinning" that its really VERY easy to at least offer some basic functionality in this respect. In fact there are a number for 3-rd party controls which support this type of application "styling" without the developers even having to think about it or add a single line of code depending how far they want to go with it.

      Obviously, this flexibility isn't important in all applications but for any application that gets distributed (not just an in-house application) I think there should at least be a serious look into offering this.

      --
      "reality has a well-known liberal bias" - Steven Colbert
    2. Re:I've R'd TFA and... by Anonymous Coward · · Score: 0

      >>Then again, I still code up my pages using text editors and scripted tools rather than all these funky "web design" applications, and I only maintain a few hundred pages with thousands of hits per day single-handed and in my spare time, so I have no idea what I'm talking about. :-)

      Well, ermm yeah. If you think a few hundred pages and a few thousand hits per day qualifies you as some sort of authority on running commercial websites, then obviously you have no idea at all!

      Get to tens of thousands of 'pages' and millions of hits per day, then say something.

    3. Re:I've R'd TFA and... by jsebrech · · Score: 1

      There are so many amazing tools and code examples about this type of application "skinning" that its really VERY easy to at least offer some basic functionality in this respect. In fact there are a number for 3-rd party controls which support this type of application "styling" without the developers even having to think about it or add a single line of code depending how far they want to go with it.

      If you're talking about how programmers shouldn't restrict the designers in what interfaces they can build using the tools that the programmers deliver, I'm in total agreement.

      However, if you're talking about making your UI skinnable so the end user can pick or design the interface that's most suited to him, I don't agree. Developers shouldn't shove the hard problems like good defaults in interface design to the userbase. The aim of a software development project should be to deliver the user something that solves his problem, and not to require any more effort from the user than is absolutely necessary. The most usable applications I've seen generally don't support much in the way of skinning. The most unusable applications have all been skinnable. Draw your own conclusions.

    4. Re:I've R'd TFA and... by Anonymous+Brave+Guy · · Score: 1

      You miss the point repeatedly, Mr AC.

      For a start, a lot of big name web sites aren't significantly bigger than what I described. Most of my pages are unique. I doubt many web sites for SMEs have much more than 100 unique pages on them. Not everyone is Amazon or e-Bay, and even those that are still use a few templates for the vast majority of pages they serve. They just have bigger databases and server farms, which makes no difference whatsoever to the difficulty of co-ordinating the design and presentation aspects with the scripting and database look-up. Just take a look at the code and templates for Slashdot, which receives the kind of volume of hits your talking about.

      In any case, I wasn't proposing myself as some sort of authority on large-scale web design. Rather, my site is a counterexample to the effectiveness of over-priced and under-powered "web design" programs. If they aren't much use even for the site I've set up, then any team of professionals who are doing this as a day job on a larger scale are bound to want more powerful tools than a glorified text editor that does syntax highlighting for CSS (wow!) and checking for broken links within your own site (whoopee!).

      --
      If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
    5. Re:I've R'd TFA and... by CaymanIslandCarpedie · · Score: 1

      Yeah, I wasn't really meaning end-user skinnable. If fact I'd agree that being end user skinnable just adds confusion in many cases. What I really mean is it should be designer skinnable (and then of course it depends on your products audiance). What I really am trying to say is the seperated your applications function from its presentation the better. If you have code specifically saying this control should use this font and this color, etc when the next version comes out and the PHBs decide they want a more modern look/feel its going to mean a lot of code changes for something completely irrelevant to you as a developer. There are many tools out there which make if very easy to make these types of properties completely independent from code so when look and feel needs to change for whatever reason it takes next to zero of your time. Its just the designers how can "reskin" the app without needing to touch any code. Here is a suite of controls for .NET and Java which at least do the basics of this for you with really zero code on the part of the developer. Now depending on the flexibility you want this may not be enough but it certainly gives you a great starting point VERY easily. Now there are other tools offering similar stuff (these just happen to be my favorite).

      --
      "reality has a well-known liberal bias" - Steven Colbert
  5. Not convinced by also-rr · · Score: 2, Funny

    Why don't they let the developers do the design? What's *not* intuitative about

    >_

    ?!

    --
    Think of the Children; Sleep with your Sister
    1. Re:Not convinced by Anonymous Coward · · Score: 2, Funny

      >Why don't they let the developers do the design? What's *not* intuitative about

      For the same reason you don't let your painter & decorator anywhere near the electrics.

    2. Re:Not convinced by Anonymous Coward · · Score: 0

      isnt this the way microsoft has been doin it from the start? having developers do the design? ;)

      on a serious note: this article writer is quite ill-informed about adobe it seems, he is talking about dreamweaver as the option from adobe!?

      why not talking about the Flash IDE for the designers, combined with Flex ID for developers? (or currently eg. Eclipse + FDT if you wish)
      as a workflow you have then the designers, who design in illustrator/photoshop import there stuff in flash (seen the Flash 9 .psd importer?), the developers can code evrything then, whilst the designers can still make adjustments to their design in their .fla without messing up the code
      (an ideal workflow allways go back and forth between designer and developer)

      from this point of view + the fact that adobe its solutions are available on pc & mac + main platform for designers is mac = microsoft its advantage is nowhere

      note:
      posts below mention designers who dont have a clue about app dev or web dev, in fact, you should differentiate between designers, don't ask a graphic designer to make a design for websites/RIA if they don't have a clue about interfaces / human interactivity...

    3. Re:Not convinced by typidemon · · Score: 1

      Why don't they let the developers do the design? What's *not* intuitative about

      Because, in general, most developers design really shit products as far as usage is concerned. Not because they can't create great things, but because a) they are expert users and go though workflow differently to novice users b) when they are designing interfaces and interactions they are mostly thinking about how those decisions work with the code set and not really how people will use it.

  6. Ideological claptrap by Savage-Rabbit · · Score: 3, Insightful
    In my experience, designers are lazy f***ers. Integration software is useless. Get them to draw up a design and pass it along to the coders where they can deal with integrating it. Then the designer can get on with going back to sleep.

    This idea of a design passing between coders and designers frequently and being modified as they go is idealogical claptrap. Get the design done right first time and then have the designer go back to the hole where they came from.

    Nice flame troll, not very subtle though. Cooperation always results in a better product than if people each sit in their own corner and only talk when the project is in danger of being derailed. This guy seems to be talking about interaction between (web)designers and (web)developers but planning and design in general, even if we are only talking about the design and structure of the software code it self, is something that is completely missing in a lot of coding projects. I wish I had a penny for every badly planned, badly designed and as a result bug ridden and semi useless block of Java, C#, C and C++ code I have had to rewrite because the original coders didn't take the trouble to apply fundamental software design principles like layer abstraction, code re-use and modularization to their projects.
    --
    Only to idiots, are orders laws.
    -- Henning von Tresckow
    1. Re:Ideological claptrap by Jonboy+X · · Score: 1

      There are both good and bad coders. There are both good and bad web designers. However, it is frequently the case that the skillset of coders is a near superset of that of designers. Coders canto fall into the mindset of "I could do your job better than you, so why should I follow your design?" Also, during crunch time on a software project, the web designers have already washed their hands of the project. This leads to the impression that the designers aren't working as hard as the rest of the team.

      --

      "In a 32-bit world, you're a 2-bit user. You've got your own newsgroup, alt.total.loser." -Weird Al
  7. Adobe only has the design covered by Krimszon · · Score: 1

    Dreamweaver is nothing but a fancy text editor with some snippets, using Flash for authoring actionscript is horrible. The have Flex Builder which is baed on Eclipse, but there's not much integration between that and the creative suite software.

    Microsoft otoh has Visual Studio which is a fine IDE, and in the new Orcas version it will share designer surfaces with the Expression tools. So the visual interface is exactly the same for developers and design. The designers will also keep 99% of your underlying code (html, xaml) formatted the way it was. So as a dev you can safely hand over your .aspx-pages to a designer that will create a nice theme for your pages.

    I don't know what Adobe will do, but they have a long way to go in this integration. Eclipse might be their best bet, but I'm afraid they will continue developping Dreamweaver.

    1. Re:Adobe only has the design covered by Anonymous Coward · · Score: 1, Insightful

      So the visual interface is exactly the same for developers and design.

      The problem is that designers and developers have very different needs, so giving them the exact same interface/tools doesn't particularly make a lot of sense. You don't give the guy who's painting your house a hammer and say "go to it." I'm amazed that you guys can't figure this out.

    2. Re:Adobe only has the design covered by Anonymous Coward · · Score: 0

      Dreamweaver is nothing but a fancy text editor with some snippets, using Flash for authoring actionscript is horrible. The have Flex Builder which is baed on Eclipse, but there's not much integration between that and the creative suite software.

      Microsoft otoh has Visual Studio which is a fine IDE.

      Visual Studio is only a mediocre editor with fancy tooltips and a debugger interface. What's the difference?
    3. Re:Adobe only has the design covered by Anonymous Coward · · Score: 0
      "So as a dev you can safely hand over your .aspx-pages to a designer that will create a nice theme for your pages."
      This is a classic example of the wrong way to design a website. The designer is the one who creates the layout, then works with (not 'hands off to') a coder to get the mechanics down. The result of doing it the way you describe usually is exactly what you'd expect from ASP - crap pages that look as if design is an afterthought, and don't work half the time.
    4. Re:Adobe only has the design covered by Anonymous Coward · · Score: 0

      "The problem is that designers and developers have very different needs, so giving them the exact same interface/tools doesn't particularly make a lot of sense."

      That's why Microsoft is creating tools for designers (Expression Suite) while developers will keep using the tool they are confortable with (Visual Studio), and both tools work on the same project files.

  8. Missing Tool: Aluminum Softball Bat by RobotRunAmok · · Score: 3, Funny

    It remains the only effective means of convincing some developers that they are *NOT* designers in the first place.

    "Art? Design? C'mon, I've mastered AJAX, XHTML, JAVA, JavaScript, ColdFusion, PHP, Ruby, PERL, and I own the only remaining data glove on the East Coast, what do I need art for? See, it's got a template... I'll just change the colors... try and find out the client's favorite color... hell, I've been building websites since '93, and I'm no artist... and I used vi... still use vi, heh... look here, I've got a CD full of clipart, we can use one of these... pic of an Asian chick on the phone, yeah, this'll work fine... designers? gimme a break... look, here's a website with cool fonts we can download, I'll download a bunch, client'll love 'em, never seen anything like 'em... talk to legal, see if we can get the rights to "Dark Side of the Moon," it'll be cool, see, when you first come to the client's site, Floyd's "Money" will start playing. Get it? Damn! I'm good! friggin' designers, who needs a designer, just make everything more complex, take all the credit, man..."

    1. Re:Missing Tool: Aluminum Softball Bat by gEvil+(beta) · · Score: 3, Funny

      I think I've been to that website.

      --
      This guy's the limit!
    2. Re:Missing Tool: Aluminum Softball Bat by Chelloveck · · Score: 3, Interesting
      It remains the only effective means of convincing some developers that they are *NOT* designers in the first place.

      There have been many a time when I've wanted to bludgeon the designer with that same bat. Like, would it kill them to use a consistent naming convention? Or keep an indexed table in the same order from version to version? Or, the most difficult concept I've ever had to get across -- "I don't care if those two curves look coincident on your monitor. They're on different layers [in Illustrator] and they're slightly different. The gap between them will be visible in the product!"

      I won't call the designers lazy or stupid. They're not. But they do have a tendency to be overly creative in areas where discipline is called for. (Just like developers have a tendency to be unimaginative in the realm of graphic design.)

      --
      Chelloveck
      I give up on debugging. From now on, SIGSEGV is a feature.
    3. Re:Missing Tool: Aluminum Softball Bat by Thrip · · Score: 2, Insightful
      It remains the only effective means of convincing some developers that they are *NOT* designers in the first place.


      And, I might add, the same applies to graphic and layout artists. Just because you can draw pretty doesn't mean you know a thing about human/computer interaction.
      --
      I'm awake! The answer is BONK!
    4. Re:Missing Tool: Aluminum Softball Bat by foniksonik · · Score: 1

      I only have this problem with the clients... and wish I could use an ASB on 'em but unfortunately I'm not italian or russian so they'd just laugh at me.

      --
      A fool throws a stone into a well and a thousand sages can not remove it.
    5. Re:Missing Tool: Aluminum Softball Bat by stubear · · Score: 2, Insightful

      It is far moire likely that designers have studied and understand interface design than for a programmer to have done so given that it is the very thing we do, we do not just "draw pretty pictures". Design is a commercial art for which I make no apologies. We utilize type and image to interact with people in a myriad of ways. If it's print, then the use of paper, folds, and design all come into play to guide the audience through the piece. If it's broadcast design then understanding how to fit a huge amount of information in as tight a space such as tickers or lower thirds requires a bit more knowledge than how to draw pretty pictures. Same goes for the web. I'm sure you coudl find examples of designers who used pretty pictures on the web simply to use pretty pictures. However, I point to sites like http://www.geoterra.com/, or http://www.bmwusa.com/allnew3 for examples of excellent design with human interaction in mind (both won top honors in Communication Arts - you can view more great sites by following this link). If you want to see a coupe excellent examples of design studios who do web sites very well hop on over to http://www.secondstory.com/, http://www.terraincognito.com/,

    6. Re:Missing Tool: Aluminum Softball Bat by Thrip · · Score: 1
      It is far moire likely that designers have studied and understand interface design than for a programmer to have done so given that it is the very thing we do.

      Note that, I didn't say "designers" -- I think that term's too imprecise to work with -- I said "graphic and layout artists." Both interface programming and digital art overlap with interface design. It's quite likely that an experienced interface programmer understands many aspects of interface design. But I think we usually learn it mostly through eating our own dog food, rather than intentional study (although many books on GUI toolkits include some advice on making things usable). This often leaves us completely blind to some aspects of the field. I had worked on a lot of interfaces before I happened on the book "The Design of Everyday Things," which changed a lot of my thinking on the subject. It also gave me a perspective that I realized all of my coworkers lacked, including the "artist."

      There is something in what you say: a lot of artists do study human factors more than programmers. Nonetheless, all the artists I've worked with have been uniformly terrible at designing a computer interface.

      Interface design is its own field, and ideally you would get someone who specializes in it. If that's not possible, my experience tells me you should let the programmers put together the interface, and then let the artists decorate it -- but most importantly you should get a lot of feedback from the intended users (and anyone else available) at every stage of the process.
      --
      I'm awake! The answer is BONK!
  9. Designers should learn by elh_inny · · Score: 1

    Is it really a good expectation, to have designers do only the design?
    In my view the designers absolutely need to know at least a little about the underlying technology.
    On a little scale I tried having an artist draw a picture of a webpage, which took him like 10 minutes and then I had to encode it into CSS, gifs etc., shouldn't this be a designers role to know that a wepage is not a picture, but it's constructed of the elements like headings and that it's pulled from DB and it has to be formatted?
    That's why I say that every designer should have at least a little insight into the code aspect.
    What's your view?

    1. Re:Designers should learn by CaymanIslandCarpedie · · Score: 1

      I basically agree. Being a pro at Photoshop does not a application designer make. Undertanding of html, CSS, etc (at least for web designers) is essential. Luckily there is no shortage of great graphic designers with these skills. So yes they need to know those basics and that its constructed of elements, etc.

      Thats however where I'd draw the line. I don't think they should care if this stuff is pulled from a DB, from flat files, or know the difference. If they have to know that I'd argue there isn't a proper seperation of function and presentation within the application.

      --
      "reality has a well-known liberal bias" - Steven Colbert
    2. Re:Designers should learn by Oligonicella · · Score: 1

      No. When I first design an interface, I make a sketch. There is no need to know where your info comes from to organize an attractive and easily assimilated presentation.

      To address your example, a web page IS a picture. My browser cares not how you find and go about creating said page. It just paints it. The construction can be done in any number of ways for the same presentation.

    3. Re:Designers should learn by mooingyak · · Score: 2, Interesting

      Agree completely. I do mostly design work now, though primarily coded in the past. I have insisted (and my CTO agrees, so I don't exactly have to fight about it) that on at least some of the projects I design I take a break from the design work and do some coding along side the developers. Sometimes you pick up some things from developers that you hadn't known were possible. Sometimes your design is bad and it becomes painfully clear when you start trying to implement. All in all I think participating in the coding makes the quality of design work better.

      We recently interviewed a candidate for one of our design positions, and in the interview he refused to answer a question about the level of detail of his UNIX knowledge (general, vague UNIXish questions, hadn't gotten to any kind of precision yet) on the grounds that it was irrelevant to the work he'd be doing. I don't know if it was a philosophical objection or if he was trying to cover for the fact that he didn't know anything, but his stance guaranteed he wouldn't get the job.

      --
      William of Ockham had no beard. The most likely explanation is that it was chewed off by squirrels every morning.
  10. Re:lazy designers by Anonymous Coward · · Score: 0

    Looking at the interfaces of all of the products on sourceforge, coders are lazy fuckers. Not to mention the number of projects that are only at alpha or very buggy beta stages. Bug and regression testing is a bunch of ideological claptrap. If they're so great at what they do, why can't they get it right the first time?

  11. Take the easy route. by CrazyJim1 · · Score: 1

    Hire a developer who's also a designer. There's a boat load of them around. And don't say that they sacrificed one to be better at the other, you can be a master at both.

    --
    God spoke to me.
    1. Re:Take the easy route. by Anonymous Coward · · Score: 0

      Wrong. The mindset of a skilled designer is generally the complete opposite of that of a programmer. Designers are focused on aesthetics and user experience. Developers are focused entirely on writing the quickest code that gets the job done, with aesthetics and user experience as an inconvenient afterthought.

      I know a lot of designers who make an honest effort to learn what they can about the development process, but there's only so much of that drudgery they can tolerate and absorb - otherwise they'd be programmers and not artists. On the other hand, I've yet to meet a developer with any serious interest in or appreciation of the design aspect. Many of them THINK they're good at design, but they're wrong.

    2. Re:Take the easy route. by Anonymous Coward · · Score: 0

      that's not true and disrespectful to the many designers/programmer, programmer/designers out there.

    3. Re:Take the easy route. by Tim+C · · Score: 1

      Well, I've been in the business for 7.5 years and I've never met any. The closest I've got is a small handful of excellent interface developers who are willing and able to do some simple JSP work, set up new tiles definitions, etc, as well as use Photoshop, do HTML, CSS, Javascript, etc. I've yet to meet any who have any interest at all in doing "real" programming (ie Java, C, etc).

      I'd be very tempted to say that the two things are almost diametrically opposed, or at least so different that there aren't more than a small handful of people who are truly a master at both - much like artists tend not to make good scientists, and vice versa.

      --
      It's official. Most of you are morons.
    4. Re:Take the easy route. by Ayende+Rahien · · Score: 1

      *couhg* De Vinci, anyone?

      --

      --
      Two witches watched two watches.
      Which witch watched which watch?
    5. Re:Take the easy route. by Breakfast+Pants · · Score: 1

      You have to emphasize that you want these types of developers when you hire, and you have to, *gasp*, pay more.

      --

      --

      WHO ATE MY BREAKFAST PANTS?
    6. Re:Take the easy route. by WilliamSChips · · Score: 1

      Da Vinci was honestly horrible at both.

      --
      Please, for the good of Humanity, vote Obama.
    7. Re:Take the easy route. by Anonymous Coward · · Score: 0

      john maeda.

      fwiw, i have a four year degree in visual communications, have won several awards, been published in major design mags and written two books on interactive design. i have also been programming since i was 7 (BASIC) and now count amongst my repertoire: ASP, JSP, PHP, Perl, Java, VisualBASIC, ActionScript, JavaScript, Lingo, ColdFusion & just a smattering of Objective-C; not just simple print/echo statements either. i've written entire applications both for online and offline use with full use of classes, inheritance, casting and memory allocation and all those fancy terms that programmers like to throw around.

      just because you have not met these people does not mean we don't exist.

    8. Re:Take the easy route. by typidemon · · Score: 1

      The problem is that you can really on wear one hat at a time. So, when you are developing products it biases your designs.

    9. Re:Take the easy route. by rblum · · Score: 1

      Dude. He *sucked* at Java!

  12. Re:lazy designers by Anonymous Coward · · Score: 0

    that would be because all of the stuff on sourceforge is open source. 1/2 completed failures are the hallmark of the open source development model.

  13. Define design by Judge_Fire · · Score: 2, Insightful

    Discussing design and development always suffers from the various definitions people attribute to those roles. At the extreme end, designers are seen as graphic designers responsible for surface styling, 'skins', while the developers are expected to be socially incompetent eccentrics who value only code elegance.

    That's just stupid, there's a huge gap there where no-one is looking at interaction design.

    Any product still ends up with a design - a form - whether there is a dedicated designer or not. How well that product then fares from its users' point of view should be used to assess the quality of the design.

    In my opinion, it's fair to assume a designer being the person in charge of the end user's experience, the individual using the product. Can they do what they set out to do? Are they happy using the product? A designer must absolutely be able to justify the rationale of user-beneficial design decisions to others, who may not be on speaking terms with the actual end user, like developer and marketing types.

    And hopefully they do that way before a single line of code is written.

    That's my definition of a designer.

  14. Re:lazy designers by Oligonicella · · Score: 1

    Basically, it's because only the ignorant think something of any complexity can be done correctly the 'first time'. One can see this by observing coders, who never get it right the first time either. Goose Gander Yes, once in a while, I feed trolls.

  15. Score of 2? by Mateo_LeFou · · Score: 1

    This was hilarious. The other day I was in a team meeting for a client and we quoted our prices and the designer's hourly was twice what mine is for my scripting/dB stuff. I was all "geez, I should do design..."

    Then I saw some of his designs; I was all "nvm. gg me".

    --
    My turnips listen for the soft cry of your love
  16. Additional reading by Randolpho · · Score: 2, Informative

    Those a little confused about the separation of concerns between designers and developers should read the following blog entry from one of the MS Expression developers. Designers. Whatever. Just read it:

    http://lostgarden.com/2006/02/software-development s-evolution.html

    --
    "Times have not become more violent. They have just become more televised."
    -Marilyn Manson
    1. Re:Additional reading by davros-too · · Score: 1

      Thanks, good link. Anyone got any experience with Expression in combo with Visual Studio?

      --
      In theory, there's no difference between theory and practice; in practice there is.
  17. This is funny by Spiked_Three · · Score: 2, Interesting

    I get a real kick out of reading some of the comments. Some people, programmers for the most part I assume just don't get it.

    What would TV commercials be like if they all were written and produced by software programmers? It would be incredibly ugly and boring.

    Do the people that make commercials think them out, write out a script and then turn it over to a programmer to produce? NO. They have tools like Adobe After Effects and Final Cut (and other high end stuff most people here never heard of).

    I have not looked in depth at the flash approach, but I am investing a lot of time becoming as smart as I can at the Microsoft approach (XAML). This is a huge change in the way applications can be written; allowing designers to declaratively specify the User Interface. It might not apply to every single application out there, but in the ones where it makes sense, your application can become as creative and appealing as a super bowl commercial. Microsoft is giving the designers After Affect like tools to create their designs and they are not dependent on the developer to make it happen. And, it can happen in parallel. It does not need to be a back and forth effort as it currently is.

    Programmers need to remember that it is not just programmers who use computers anymore. I know this is less true with the Slashdot crowd, but the computer illiterate user population has overtaken us quite a few years ago. Applications need to be visually appealing to people who are not computer professionals - changing the terminal font family and size is no longer enough. For years a lot of this crowd has talked about how much better the OS X interface is - well this is an effort to get rid of the OS UI limits and leave it up to the designers. Yes, we could have always done that with code, but now we are putting high end tools, like After Effects, in the hands of the UI designer and saying, "Let's see what you can come up with." Some will fail, and some will be great.

    The biggest problem I see in this is I'm still stuck with clients who think every app should be web based. Microsoft's approach to web apps is the same as the previously failed Java web app approach - the browser simply hosts a local application. (I'm not saying the Java approach was bad or wrong, just that it has ZERO adoption and momentum). I don't have a lot of faith that web based XAML will do any better than web based Java applets (not script) did.

    --
    slashdot troll = you make a compelling argument I do not like the implications of.
    1. Re:This is funny by Anonymous Coward · · Score: 0

      Do the people that make commercials think them out, write out a script and then turn it over to a programmer to produce? NO.

      Actually, this IS what happens, only they aren't called programmers, it is called a post house.

      They have tools like Adobe After Effects and Final Cut (and other high end stuff most people here never heard of).

      Most post houses use what was done in After Effects as a prototype and assemble the finished spot from the raw source, using the other high end stuff you mention. It is a very similar process, where the end result is made by specialists from input provided by the creative as it is called in the industry.

    2. Re:This is funny by DCGregoryA · · Score: 1

      Heh. Myself and many programmers I know don't even watch TV. What's a commercial?

      I agree with most of what you say though. I don't want the designers on my staff to turn things over to me.

    3. Re:This is funny by Spiked_Three · · Score: 1

      Nope, sorry, I used to own a post house, we had designers who deliver TV ready video. I'm not sure where you got that idea.

      --
      slashdot troll = you make a compelling argument I do not like the implications of.
  18. FOSS side by wysiwia · · Score: 1

    On the FOSS side of things of course, we have merging of designer/developers and users, so the issue is somewhat irrelevant. We can still improve our communications and documentation *a lot* though.

    If this merging would be true, we all and not just a few percents would use a FOSS desktop system these days. Just think why does the OSDL survey (http://www.osdl.org/dtl/DTL_Survey_Report_Nov2005 .pdf) mentions "Application support" as its first "Top inhibitors of Linux desktop adoption"? And why still use 60% of all Linux users some kind of running Windows applications (http://www.desktoplinux.com/cgi-bin/survey/survey .cgi?view=archive&id=0821200617613)?

    O. Wyss

    --
    See http://wyoguide.sf.net/papers/Cross-platform.html
  19. personal experiencie by Tei · · Score: 2, Insightful

    Is hard for programmers to help users. Is also a bad idea to be the developper AND the tester. And this why we have teams. One guy can be a programmer, other guy tester, and another do the marketing/media stuff. And thats Ok. The problem here are tiny teams with tons of programmers, but not tester or not marketers. You really need people that think like clients, and is not a programmer.

    --

    -Woof woof woof!

  20. Developer and Designer should be the same person by SethEaston · · Score: 1, Insightful
    I design and code web GUIs - mostly in Perl/CGI, until last year, when our beloved tech lead decided to go with the bleeding edge in technology - JSF.

    The problem is that none of use knew JSF. A few of knew JSP and had experience writing beans and whatever, but JSF turned out to be a nightmare. Had I known the technology and how it worked, I would have designed the GUI differently. Having a working knowledge of the implementation tools helps you to design a more appropriate application from the beginning. It turns out that we had to make some changes to make JSF "fit" my design, and in other cases we simply had to re-think some of the functionality.

    I will give credit to my tech lead for making me code my design and actaully write a few of the backing beans (we had four developers, so most of the beans were written by expreienced Java folk).

    My point: a designer must also wear the developer hat, and I might add, the tester's hat. I think many dev shops are splitting up roles too much. Working in a vacuum is, as I have discovered, counterproductive.

  21. my 2 cents by Anonymous Coward · · Score: 0

    I'm a "designer" by trade, and have worked with engineering teams in the web and software industries for 10+ years. I peronally think there's confusion around this division of labor. In my experience, developers focuse on how to build things, and designers focused on how people use things. When you get the two groups working together with a common goal, you speed up the process, reduce customer frustration, and hopefully have built a product that meets the needs of a particular audience. They're both as engineering, both "creative," and complement each other to make "good stuff."

    Dot-com brought lots of bad "creative" backwash into the design space, and it hurt the general perception of "design" as it is applied to technology. Adobe, Google (yes, low-fidelity google; for example, Jeff Veen is over there, and he's one of many design-folks over there that's got a clue), Apple, Nokia, etc understand this and are using designers to increase revenue, not "make things pretty in flash." Msoft is getting better at this too, believe it or not.

  22. no way by chillicockoff · · Score: 2, Funny

    no way.