“No matter how talented you are, if you are a C, your talents will often be watered down by A and B. If you want more power, there’s only a limited amount A and B will be able to grant, no matter how much they need and respect you.”

Thanks a lot for the comment.

I’ll try to answer your points:

1) “The tools do not give complete control as claimed” … you are right, because in real life, you still need some old-school specifications, but they should be enough, and for me I see multiple reason it is not the case, and won’t be very quickly:
* you need some kind of “agile” process, where prototyping equal implementation, and specification roughly equal prototype (My program manager won’t like that :-))
* But above all you need to communicate with your client …and he knows MS word…

2) Agreed : I prefer the Control term, over Widget for the “UI technologies” part, it is why I have introduced “Control” in my glossary (the yellow table). The Widget term have effectively been stolen to describe mini application either in a browser or in a native container, this will be part of a later article.

We have begun some work about this Interaction Designer and Engineer interaction, if you have some inputs, or want to share data, I’ll be very happy to do so.

1) The tools do not give complete control as claimed, a proper specification document and process can ensure that the person with the correct ability is able to influence the system at the appropriate time. (Software that supports makes life a lot easier).
2) Widget is poor terminology when covering these three disciplines as they could be different things to different people (An application developer and a web developer see widgets as very different things). Additionally in the mobile area it is coming to mean a mini-application running in a dedicated container.

I also think you have highlighted a gap that creates issues with development, by the lack of formalization in the relationship between the Software Engineers and the Interaction Designer

The Interaction Designers today are not as good as they should be of extracting from and agreeing with the software engineer what the impact of certain application events will be in terms of the user experience. Certain application events will take a few seconds (establishing network data connection or heavy requests to a server are good examples). The point at which these events occur and what is communicated to the user at this time is not accurately captured in a screen flow or screen layouts and needs an enhancement to most UI documents I have seen or a dedicated User Experience (UE) document developed after the screen flow has been agreed.

One small note the: The Interaction Designer is also responsible for defining what is to be captured by a screen, not just presented but I see no controversy here.