about GUI development trends
I have a question concerning the general trends about GUI development in small-to-big software projects having a polished GUI as a primary requirement, both from the esthetic and usability POV, over the Microsoft platforms ( both traditional desktop and "metro-like" applications ).
More specifically, many new GUI technologies ( XAML as the foremost representative ) sell themselves as promoting separation of GUI authoring from GUI "logic".
Now, my question is: to what extent does this actually happen in the real world ? that is, how often software teams using these technologies actually employ people solely dedicated to the authoring of the GUI ( = people that reads or writes no code in any language other than those supported by the authoring technology itself, like scripts or the markup itself ) ? when it does happen, do the project leaders make a trade-off between production costs ( possibly minimized by the said GUI-authoring/GUI-logic separation of concerns ) and flexibility ( what if, say, you need a graphics effect or behavior not supported by the GUI technology ) ?
thanks for answers !
Re: about GUI development trends
Quote:
Originally Posted by
superbonzo
Now, my question is: to what extent does this actually happen in the real world ? that is, how often software teams using these technologies actually employ people solely dedicated to the authoring of the GUI
The larger the organization the more likely it is for people to be specialists. That's why many like to work for smaller companies. Jobs there tend to be more versatile.
But the idea to introduce domain-specific (scripting) languages is not new with XAML for GUIs. You have HTML for documents, SQL for data bases, regular expressions for string matching, X3D for 3D graphics, just to name a few. And the purpose of such languages is not to promote specialization among developers as you suggest even though that may be one practical consequence. The main objective is to induce more flexibility into software designs to promote ease of change. There's even an established OO design pattern called Interpreter dealing with how to introduce small application-specific languages (an underused possibility in my opinion).
The trade-off you mention is everywhere: -What if the tool we've selected in the name of productivity limits our ability to accomplish what we want technically? In my experience most technical problems can be overcome. The only time you need to really watch your step is when a limitation would be a strategic disaster and maybe even put the whole company at risk. For example if a company were known for its innovative avant-garde GUIs and that's why people prefer their products it shouldn't bet on XAML. Unless of course they control the whole XAML implementation.
Re: about GUI development trends
Quote:
Originally Posted by
nuzzle
And the purpose of such languages is not to promote specialization among developers as you suggest
well, actually, I didn't suggest anything :); my question was not about "why" these technologies or patterns are used in theory ( as you said, mainly for well known and quite general software design issues ), but specifically about "how" and "how much" they are used in the real world.
More specifically, I'm interested in finding out in how many real teams (>=2 developers) there's a net separation between people working on and only on GUI authoring ( eg. say, artists' work, markup + script ) and those working on code behind, and how many times and to what extent this team organization is the cause or the effect of such a design choice.
so, have you ever worked on a software project where the GUI has been authored and programmed by two different persons, respectively ? ( to clarify again, by "programmed" I don't mean the business logic of the program; I'm still referring to code strictly related to GUI presentation and behavior ).
Re: about GUI development trends
Quote:
Originally Posted by
superbonzo
so, have you ever worked on a software project where the GUI has been authored and programmed by two different persons, respectively ? ( to clarify again, by "programmed" I don't mean the business logic of the program; I'm still referring to code strictly related to GUI presentation and behavior ).
Yes I have but every time non-programmers were on a team this was completely unrelated to what technologies were used. So I think your question is moot because it assumes a correlation that simply doesn't exist.
On the other hand there's a strong correlation with organization size as I mentioned. The larger the company (*) the more likely you'll find pure content specialists on software projects. But even so, whether what they do should be called programming is a matter of definition I think. It's also a question of using resources wisely. If you hire some expensive Rembrandt to design the GUI you wouldn't want him to waste time fiddling around with XAML even if he thinks he's pretty good at it.
(*) What's considered large and how it's measured depend on industry sector.
Re: about GUI development trends
Quote:
Originally Posted by
nuzzle
Yes I have but every time non-programmers were on a team this was completely unrelated to what technologies were used. So I think your question is moot because it assumes a correlation that simply doesn't exist.
come on ... where on earth do I assumed something ? it's just a simple question that for some obscure reason you cannot understand ( is my english so bad ? where in my question I asked about "non-programmer" being on team or not ? :confused: ) ... or are you having yet another paranoid crisis ? :rolleyes:
Re: about GUI development trends
Quote:
Originally Posted by
superbonzo
come on ...
I understand your question, it's just that I have a different take on it. Hopefully someone else can give you the reply you were expecting.
Re: about GUI development trends
It's an interesting question. I believe in the perfect world designers would be using something like Blend to produce the UI and the devs would wire it up to the view code. In the perfect world, there would be complete separation and everything would just work when the dev merged the UI code with view code.
In the non-perfect world, I believe the UI code the designers produce is fine for wire-frame mockups, but isn't production quality. Plus the designer code seldom ever merges seamlessly into the view code without a good deal of refactoring by the dev.
As a result, I kind of doubt even in larger corporations, designers can produce the level of quality in their work, to have the code seamlessly integrate with the rest of the project. If this does happen on a regular basis, I'd be surprised.
Re: about GUI development trends
The idea with XAML and the separation of presentation logic is to use a variant of MVP called Presentation Model in Martin Fowler's terminology; the most notable example of Presentation Model is the MVVM architecture used for .NET WPF application developement. In short, the architecture introduces another role to the presenter - to model an abstraction of a view (using standard tools devs use to model other concepts - that is, variables, methods, classes...), without maintaining references to the actual controls. The view, which represents one of the possible renditions of the presentation model, is then essentially generated from XAML and left very thin and dumb. Presenation Model relies on the data binding capabilities of the UI platform to sync the View with the presentation model (ViewModel in MVVM). This in turn makes it possible to unit test complex presentation logic (what you called GUI logic) and application logic without even having to make test doubles or mockups for the View - since all the presentation logic is moved from the View into the presentation model part of the Presenter.
(Look here for more details on the variants of MVP.)
In theory, it should be possible to have a really high degree of separation, which would enable the designers and the devs to work almost independently, as long as the designers develop thin, stupefied Views that by themselves are incapable of doing anything of relevance (knows how to paint controls, change the state of buttons, detect input and translate it into events, but that's about it).
But I suppose that in reality, due to various factors (imperfections of the platform, or the desing/dev business process, etc.) this separation is not so easy to achieve.
Re: about GUI development trends
Quote:
Originally Posted by
Arjay
In the non-perfect world, I believe the UI code the designers produce is fine for wire-frame mockups, but isn't production quality. Plus the designer code seldom ever merges seamlessly into the view code without a good deal of refactoring by the dev.
As a result, I kind of doubt even in larger corporations, designers can produce the level of quality in their work, to have the code seamlessly integrate with the rest of the project. If this does happen on a regular basis, I'd be surprised.
Thank you, this was exactly what I wanted to know. So, in your experience GUI programming with existing technologies always requires the developer to have a coordinated view of both the presentational and behavioural aspects of the GUI, at the code level. Otherwise, if a sharper separation is chosen for some reasons ( like labor force management in the developer team ) this impacts on either the GUI quality ( GUI entities and code entities don't match ) or production costs ( increased refactoring effort of the GUI developer ).
Quote:
Originally Posted by TheGreatCthulhu
In theory, it should be possible to have a really high degree of separation, which would enable the designers and the devs to work almost independently, as long as the designers develop thin, stupefied Views that by themselves are incapable of doing anything of relevance).
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 )
Re: about GUI development trends
Quote:
Originally Posted by
superbonzo
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 :D (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.
Re: about GUI development trends
Quote:
Originally Posted by
TheGreatCthulhu
An analogy:
yeah, the analogy is highly pertinent; IMHO they are both cases of the same premature abstraction syndrome, where separation is pushed too far making efficient communication between entities more difficult than necessary, in general.
Quote:
Originally Posted by
TheGreatCthulhu
of course, we still need to get there.
so, getting back to my original question, what about your work experience ? is it the same as Arjay's ?
