Cognitive Load and the Superiority of Server-Side Ajax GUI Frameworks

Back in 1993, the professor I was working for at the time won the Nobel Prize in Economics. Articles were published about him in many languages and he asked me if I would translate one from German into English. "I know German and English," I thought to myself, "piece of cake." I sat down with a German-English dictionary at the console of my Sparc-10 and inside of two hours had the translated article finished and a huge headache pounding in my brain. Keeping two paragraph and sentence structures in my head and trying to juggle the conections between them turned out to be a hellish task. I don't know how those UN translators do it.

As it turns out, I've been performing a similar juggling act since that time, from the first CGI/HTML form pair that I wrote to the multi-tiered J2EE beasts that my company develops today. It's not unusual for a developer to have to juggle Java, Javascript, XHTML, CSS, ActionScript, SQL and several different dialects of XML for a single use case. Each of these is a different language (though different from a natural language like German or English) and requires remembering seperate concepts and then remembering the connections between these concepts in each language context. It's enough to give you a headache.

Cognitive Load

But why do we get a headache? Back in the 1950's, a professor of Psychology named George Miller observed that the average human being could retain seven items in short term memory, plus or minus two items. When we work with ideas or concept in any sort of analytical thinking, we run up against this limitation again and again.

John Sweller, a professor of Education, came up with the idea of cognitive load in the late 1980's. The basic idea was that your ability to learn and problem solve was limited by your short term memory. If a particular learning task required keeping track of many concept at the same time, it is said to have a high cognitive load and as a result you don't learn as well or as easily. In fact, in analytical tasks like doing complex arithmetic, it can increase the rate at which you make errors. There's a whole body of literature on cognitive load, cognitive stress, etc. Applied to our example of web application development, we see that juggling all of those different concepts in different programming and markup languages and runtime environments in our head, creates a high cognitive load, increases our error rate and impedes our ability to problem solve.

Usability is Not Just For End-Users

When we think usability, we usually think application user interface. That's the stuff our clients end up using. But API's and programming languages can also be more or less usable. API's that have many method calls with seven or eight or nine parameters are a lot less pleasant to use than those that have method calls with one or two parameters. In Object Oriented programming, we use certain principles like abstraction, encapsulation, or the Facade pattern because we say they lead to good design. They also have the effect of decreasing the cognitive load of a design, allowing us to solve programming puzzles while keeping fewer concepts in our head.

Consider now a server-side Ajax GUI framework like Echo2; it allows you, for the most part, to write in one language -- Java -- and avoid having to juggle the client and server-side states in your head. If it doesn't make a webapp development team many times more productive than a multi-context J2EE approach, I'll eat my hat. Yet another reason to try out Echo2.

Technorati : ajax, cognitive load, memory, software development

Comments

[Matt]

I would argue that mixing the middle tier (java) with the front-end (javascript, html, css) is the same as mixing the middle tier with the backend (db). In general, it is bad practice. Sure, some companies still directly access the db from inline sql, but the majority of developers agree it is bad practice. If I was you, rather than arguing cognitive load and pushing for some middle-tier to front end hack, I would push for a front-end architecture position at your company. In the end, specialization always wins out, and in time, we will see the same with front end development.

[Phil Hershkowitz]

I think your points about cognitive load and usability for programmers are some of the reasons why more streamlined / lightweight web development environments like Ruby On Rails are gaining popularity with Java programmers

[Sami Ekblad]

Yes, I very much agree with this post. Bad programmer usability yields to more or less bad applications user interfaces. What Matt says about "mixing the layers" is valid, but for UI frameworks I see no mixing: the role remains the same, but the MVC-controller is getting thicker. Good separation between layers is needed to ensure maintainability of large systems.

We use terms like "user interface logic" in contrast to "business logic" to make clear that there is a separation between them.

[Mikael Bergkvist]

XIN is a serverside AJAX framework all in javascript.
The same as described, but for javascript.
It's used for this thing, among others: http://www.xindesk.com

[Samia Celsor]

Agree, but I'd rather suggest ZK (http://www.zkoss.org). It is more intuitive and elegant. The community is more active, too.

[Neil Erdwien]

I would argue that minimizing the cognitive load has been a goal of computer science for many years. Structured programming means you don't have to have in mind all the various paths the program could get to a specific location. High level languages mean you don't have to worry about register allocation. Etc.

I have two problems with driving JavaScript from Java.

First is the extra cognitive load of debugging JavaScript that was generated from Java.

Second, one of the premises is that people know Java, but not JavaScript, and thus generating JavaScript makes sense. In some environments, that is undoubtedly true. However, I don't think JavaScript is harder or less productive than Java, so it makes sense to pay the one-time cost of retraining rather than the continuing cost of the complexity.

I'm intrigued by the server-side JavaScript frameworks like Jaxer, http://www.aptana.com/. However, such frameworks are not nearly as mature as a Java servlet container, so I'd be afraid of running into bottlenecks.

I was also a fairly early adopter of Netscape's Server-Side JavaScript year ago. That technology was a dead-end, so I'm gun-shy.

My solution?

Make the server-side components as simple as possible in a REST, Service Oriented Architecture sense. Keep all of the presentation and user interface logic on the client-side.