Idea for a new IT Position – User Interface to Back End Liaison

25 Apr 2007

I have seen this time and time again and lately it has resurfaced in my workplace twice today alone. I thought it would be interesting to lay out the need for an industry job description that would act as a call to arms for web application development houses everywhere.

This need arises when you are in an enterprise environment using some sort of an application framework, wether it be .net, J2EE, etc. The problem is that the talented application coders are usually not the same as the talented UI coders. This is where I will insert my vision of a job description that every enterprise everywhere needs.

Any good client side developer, and I know quite a few, would tell you how complex the topics of browser standards, code efficiency and compression, as well as judicious use of flash, Ajax, jquery as well as a number of other libraries and framework are. Unfortunately, in my experience, when web applications are architected, the “web development team” is identified for the look and feel and the application team takes over all functionality.

In the days of desktop applications, this was a very capable concept. Your UI (User Interface) design team built the applications look and feel, menus, graphical assets, dialog boxes, etc. These days, the lines are gray and it makes designing a high performance, scalable and portable application very difficult. As we are finding in my enterprise, these flaws either come out when you get to usability testing, or when the site is put under actual load.

It is important to note that in certain cases, this can also extend into the other direction and a poorly designed application can place the burden of business logic and application functionality such as validation, input constraints, etc.. on the browser. Besides obvious misplacement, it brings to light new problems in cross browser compatibility and even security considerations.

So now that we have an idea of the problems that not having this individual can cause, let’s discuss who this person is. Without sounding too arrogant, I like to think that I am this type of person. I live in the development world full time as a job, and I also have what I would consider a full time job designing and maintaining this site you are currently reading. Not to say that I am an expert in either field, I just have a unique perspective that allows me to understand the capabilities and shortcomings of both sides, and the humility to seek the advice of experts in either field. This allows me to gather a better picture of what the impact of placing a particular piece of the application in any of the layers you would expect in the basic MVC (Model View Controller) model.

The Liaison should have a strong knowledge of the application framework that you are using. This person would have real world coding experience at least enough to be able to follow source code, debug applications and be able to identify potential risks at code review time. This person should also have a good background in distributed applications, especially over weak connections such as the Internet, and know the types of technologies and strategies that you can use to overcome those types of limitations. The Liaison should also be quite knowledgeable in the client side world to know where to leverage standard browser technologies to lighten bandwidth requirements, increase perceived application performance and give the user a more platform application experience.

One of the most important things this person should be able to do, is work with all of these teams separately and together, while maintaining a realistic view of the design requirements, visual impact and business needs. In other words, you should be able to look at a marketing based design and have the strength to stand up and say, “Yes, this looks great, but it is not a practical design for a high performance web application.”

The variables that make an application truly perform are often not easily visible to the direct focus of a particular team. It’s important to have a system of checks and balances that makes sure that no team is able to push the burden to another team, technology or platform for any other reason than a solid technology decision.

I can guarantee you that marketing doesn’t care about file size, application development doesn’t think about the number of server requests and assets loaded upon page refresh, and your web design team isn’t considering the complexity of a particular query vs. a structured view in database response times. The beast is just too big to slay with one knight.

So there is my vision. It’s time that old school application development teams caught up with the web world and stopped trying to build the entire house of cards under the table. I love my job, and I love that I am able to keep a foot firmly planted in both worlds. The real question is with computer science and web design such totally different tracks in terms of education, how do we build people with this particular skill set help to save the web