Quote Originally Posted by superbonzo View Post
isn't there a contradiction here ? you're basically saying ( and after many casual and non-casual experimentations with MVP-like designs I agree with you ) that in order for that separation to succeed the non-code GUI authoring tool should produce empty shells with no relevant behavioural content. Now, given that good GUI software do rely on a rich user-interaction with the program specific entities, this gives us Arjay's conclusions that "the UI code the designers produce is fine for wire-frame mockups, but isn't production quality". In other words, those potentialities of "high degree of separation" are far from reality even in theory, aren't they ? ( note that I'm not speaking of conceptual seperations of concerns at the design level; I'm referring to physical separation of labor force in the developer team )
That depends on the general approach to the work process and the kind of tools available - at this point, you are probably right for the most part. An analogy: I once saw a speech by John Carmack of id software, and during it he mentioned that in videogame industry developers traditionally strive to provide non-programmer friendly scripting languages, so that anyone can implement the gameplay logic; however, after years of experience, he began to see the problem with the approach, so at the speech he states something that should, apparently, be obvious - you don't want the code to be written by non-programmers. For the purposes of game industry, another approach to the whole process needs to be taken, in order to improve the quality of the product.

Getting back to GUIs, in this context, ideally, the design team should produce two kinds of output artifacts: one is a wireframe-like mockup that demonstrates both the static and the dynamic aspects of the visual design, but it only represents a reference for the developers (that is, just another design requirements document); the other is the equivalent, (auto generated) bare bones UI that will become the View in the implementation phase, which the developers can "hook up" into their MVP-based design, and implement all the presentation-related behavior themselves, and then test it. So, in essence, there should be a tool that supports this kind of output.

However, this doesn't mean that the dev team and the design team should stop communicating, and that the design team should be entirely oblivious to the implementation requirements (at least on the conceptual level, as this could influence their design decision) - steps needs to be taken during planning to insure that the design phase output accounts for the in-process requirement for easy integration into the MVP architecture. And that's what "high degree of separation" is all about - not complete separation, but collaboration with clear-cut responsibilities. Kinda like classes in OOP (on the other hand, as you know, even in OOP it's sometimes not so easy to achieve this).
So, of course, we still need to get there.