Relationship between Front-End Dev and Interaction Design [closed]

Question

[I am not changing the original question as there are valuable answers here. but the research I was conducting is now finished and results are published here

and http://hci.me.uk/jqueryperformance/

Original Question:

I am trying to put together a paper about how to go about researching the levels of awareness about jQuery performance between Interaction designers. Performance is a vital part of user experience and jQuery is the most widely used tool for making web-based prototypes.

Prior to designing this survey completely I would like to ask 2 questions from practitioners who use jQuery in their work:

1. In your opinion how much as an experience designer you need to know about web front-end technologies and jQuery?
2. How important computational performance is to you compared to perceived performance?

Answer 1

It looks like you're mainly looking for opinions. Looking at the sample survey, I'd say you'll have some challenges. The first is that I don't see a lot of UX groups will well staffed front end developers. IMHO, that should be a requirement for a UX team, but, alas, I don't see it as much as I should.

Secondly, for rapid prototyping, people likely aren't unit testing at all, nor perhaps caring about fine tuning jQuery selectors. That usually falls onto the development side. Again, I think UX should be developing the front end code but usually that's not the case.

As for the sample questions, it appears that you are primarily looking to see if they are aware of basic jQuery optimization techniques (selector specificity, element caching, etc.). Good questions, for sure, but likely not a primary focus of UX (again, even though it should be).

Finally, there are aspects of front end development that may appear to be a performance hindrance for the end-user, but offer internal development performance increases, which, in turn, can be a benefit to the end-user. I suppose it could be called pragmatic performance tweaking.

For instance, I will often traverse up and down the DOM to build a jQuery interaction rather than using strict IDs for each element and passing it into the script to make it easier for our non front-end devs to implement and reuse. A slightly slower browser experience (though admittedly perhaps imperceptible) but a definite boost to internal development speed.

UPDATE:

Xgreen, thanks for cleaning up the original question. To add some more specific answers:

Question 1: The individual designer perhaps does not need to be a front end developer, but front end development is a core component of the UX team's toolset. I've found that UX teams that do not do their own front end dev, or at least front-end prototyping, their solutions tend to be dated and not leveraging the full range of technologies and techniques available to them.

I also find that it's simply impossible to design every detail of every interaction on paper only. You really need to get into code to fully understand the entire user experience and adjust as needed. To fully design the user experience, you need to build it.

Question 2: This is a tougher question to answer. See my answer above. There's a lot of 'well, it depends' with this one. Both real and perceived performance issues are important to address within reason.

Answer 2

On the first question, knowledge of how html, css, jquery and even Sencha ExtJS (we use that here) works is key to havng a good relationship with the front end engineers. I also try to know how basic SQL and databases work. I sit in the middle of engineers. A good relationship with engineering is as important as that with product managers. The more we can talk the same language, the better.

Regarding performance, perceived performance is much more important than raw numbers. However, you need raw numbers to measure improvements .

Answer 3

Concerning 2):

As a user, I don't care what the real performance is. As long as it feels reactive and fast, and it doesn't delay me in realizing my task, it may take as much CPU computation as necessary.

Examples:

• Word is giving the feedback: document is open, you can start working - yet, in the background, he may still fetch the pages 100-200.
• iPhone shows an cached image of how the app will look like, when loaded, until this app has completely started - which doesn't take longer than the opening animation, most of the time
• That's also why you use progress bars and the like: to give the user a sense of control and thus, the feeling that it takes less time (e.g. Gronier/Gomri 2008).

(I was saying, as a user, as the developer in me does worry of the computational performance, but rather to look ahead: how much more can I do with it so that it remains fast enough?)