Archives

I remember reading in one of Stephen Jay Gould’s books about punctuated equilibrium in evolution. The basic idea is that instead of continuous gradual change, evolution happens rapidly or not all. An illustrative example that is often given is where the less fit individuals in a population reside on the edge of the habitat and, because of the harsh conditions, evolve until they can kick the ass of the previously fitter individuals in the heart of the habitat.

An analogous phenomenon happens in the business world. After World War II, the Soviet Union (and France and Great Britain to a lesser degree) dismantled many factories in the West and East zones of Germany and transported them back as war reparations. As a result, West Germany had to retool its entire industrial infrastructure from scratch, resulting in a competitive advantage over the Allies and the East Bloc, who were stuck with Germany’s antiquated prewar factories.

Why the history and biology lesson? I’m sure you all saw the Evans Data Corporation findings that more developers are using Ajax in emerging markets than in North America. According to their survey, Brazil and India lead the pack, while China rivals North America in its adoption of Ajax. These findings pretty much square with my readership data, where Brazil, India, and China outstrip Western and Eastern Europe.

Evans only surveyed 400 developers, which seems too small of a sample to be representative of worldwide development activity. From their methodology discussion:

The EDC panel of developers includes about 20,000 professional developers in more than 70 countries. The EDC panel, having been recruited and assembled over the last five years strictly from neutral developer lists represents the finest example today of an unbiased and representative sample of developers. As the panel continues to grow, the same principle of neutral recruitment will continue to be applied, thus assuring clients of the most representative sample possible.

Still, the results somehow do feel right. The United States, with its proliferation of credit cards, definitely did steal a march on Western Europe and emerging markets in the e-commerce arena, and holds similar leads in investment in other online categories. But heavy investment in legacy technologies begins to look like stockpiles of steam engines and Betamax. While developers in corporate America are busy maintaining existing applications or laboriously retrofitting Ajax onto them, developers from emerging markets are free to start from scratch. And as anyone who has ever maintained a mature web application knows, starting from scratch is often the best way forward.

So while Ajax may have started in the United States, much of the activity and thus the innovation will be happening in emerging markets like Brazil and India. And the United States will continue to retrench until we are left with the one domain where we think we excel above all others: the efficient allocation of capital. Good luck with that.

How does one say “Agile Ajax” in Portuguese?

Technorati : ajax, brazil, china, india, innovation, trends

In a comment to my post Friday on cognitive load and the supperiority of server-side AJAX GUI frameworks, reader Matt took me to task for muddling my tiers:

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.

While I agree with Matt that if you’re going to adopt a layered architectural approach, you don’t want to mix different subtasks into the same layer, simply putting code into the same physical environment or writing it in the same language does not constitute mixing layers. Rather than blindly following the “tiered approach,” it is helpful to look at the original patterns source and understand its purpose. The first time I saw a formal discussion of the layered architecture pattern was in 1996 in the very useful Pattern-Oriented Software Architecture: A System of Patterns, Volume 1 by Frank Buschmann et al., Chapter 2, Section 2.2: From Mud to Structure. (Funny how some patterns in that book gained huge popularity, such as MVC, while more elegant patterns, like Presentation-Abstraction-Control, gain barely a mention.) From the text:

The Layers architectural pattern helps to structure applications that can be decomposed into groups of subtasks in which each group of subtasks is at a particular level of abstraction.

[snip]

The main structural characteristic of the Layers pattern is that the services of Layer J are only used by Layer J + 1-there are no further direct dependencies between layers. This structure can be compared with a stack, or even an onion. Each individual layer shields all lower layers from direct access by higher layers.

[snip]

Specify an interface for each layer. If Layer J should be a ‘black box’ for Layer J+1, design a flat interface that offers all Layer J’s services. and perhaps encapsulate this interface in a Facade object [GHJV95]. The Known Uses section describes flat interfaces further. A ‘whitebox’ approach is that in which Layer J+1 sees the internals of Layer J. The last figure in the Structure section shows a ‘gray-box’ approach, a compromise between black and white box approaches. Here Layer J+1 is aware of the fact that Layer J consists of three components, and addresses them separately, but does not see the internal workings of individual components.

Good design practise tells us to use the black-box approach whenever possible, because it supports system evolution better than other approaches. Exceptions to this rule can be made for reasons of efficiency, or a need to access the innards of another layer. The latter occurs rarely, and may be helped by the Reflection pattern, which supports more controlled access to the internal functioning of a component. Arguments over efficiency are debatable, especially when inlining can simply do away with a thin layer of indirection.

The first observation I have is that writing our code all in Java still allows us to adopt a layered approach. The UI code can be nicely abstracted from the business layer, as people have been doing now for decades. Just because we are writing both in Java doesn’t mean we are mixing the tiers.

The second observation I would make is that there is some confusion over which is the highest tier in web applications. As it’s usually illustrated in architectural diagrams, the presentation tier sits on top. Certainly that’s the way the end user sees it, and you can make an argument that that is how interactive applications should be architected, with the presentation tier using the services of the next tier down. I’d suggest a further refinement, one that’s been creeping into web applications and various frameworks: the rendering tier. That’s where the details of the underlying user interface device are abstracted as a set of functions for use by the presentation tier. That’s precisely what Echo2 does, hide the details of HTML, Javascript, CSS, etc., in a rendering layer.

Although no other rendering implementations exist at present for Echo2 and ZK (another server-side framework), they are perfectly positioned to add support for Flash, mobile, desktop and other user interface devices.

So, my response to Matt is that we aren’t mixing layers here, but — staying true to the original intent of the architectural pattern — improving the design of web applications by abstracting the details of the browser into a lower level rendering tier.

Technorati : ajax, cognitive load, complexity, layered architecture, patterns

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

I’ve been using Google Maps for Mobile for a few weeks now and find it rather useful, especially when I’m in a strange city driving a rental without a nav system. OK, what does this have to do with Ajax? Nothing. And that’s precisely the point. Google, arguably the pioneer in all things Ajax, is distributing their Maps application — the Ajax app that first made people sit up and take notice — to mobile devices as a Java application.

Now maybe under the covers it’s actually a custom web browser that supports Ajax, (if anyone has taken the time to test this theory out, please let me know) but I somehow doubt it. What does this say about the state of mobile Ajax if the big dog on the block puts their money down on a custom Java application? I think it means that we’re a long way away from practical mobile Ajax and even further away from the winners being picked.

That of course doesn’t prevent Nokia and Opera and various other players from claiming that they’ve solved the mobile Ajax puzzle. Until they solve the problem of direct manipulation, though, they haven’t convinced me. Once Opera Mobile allows me to drag Google Maps (the non-mobile kind) around on my phone’s screen, they haven’t passed the Ajax version of the Turing test.

There are just too many interfaces for mobile devices now to make this practical. How do we support in an Ajax capable browser the buttons, pens and wheels that make up the beastiary of mobile device user controls? It’s not just about filling out forms anymore. Some phones may never be Ajax capable for this reason: their controls are just too limiting.

So, don’t hold your breath on mobile Ajax. By the time everyone has upgraded their phone, it’ll be 2008.

Update 1: I guess some people didn’t get the point of this post, and I do admit that I might have burried the lede. So let me try again: Google isn’t placing a bet on mobile Ajax. Mobile phones continue to have diverse user controls unsuitable for direct manipulation, which seems necessary for the Ajax version of Google Maps. The next generation of phones (RAZR, etc.) may not have the kind of pen interfaces to support that style of interaction. Therefore, mobile Ajax won’t be a reality for quite some time, maybe not even 2008. It’s not the software, but the hardware, and that’s why google is crafting a seperate app for each phone.

Technorati : ajax, gmm, google maps, java, mobile

I hate to be a blog echo chamber, but there’s a post from Alex Russell of Dojo Toolkit that is worth spreading around a bit more.

First, some background. There are two technologies that Alex and Co. have been working on. One is called JSONP, which stands for JSON with Padding. The essential idea is that you can insert a script tag dynamically in a document and have it pull a script from a server in a different domain. This URL for this script takes a parameter that is prepended to the JSON which is also wrapped in parentheses. In the case where the prefix is null, we have just a JSON object. Otherwise, it’s a function call. This gives us the ability to do a callback when the script loads; you want to do a callback, otherwise, how will you know that the thing loaded? Obviously, this requires some cooperation from the server — you can’t just do this with any old JSON service. A discussion by Alex of this technology can be found here. Dan Theurer has a somewhat clearer explanation, IMHO, of a similar technology used by Yahoo.

The other technology is Cometd. What is Comet? Without getting too technical, when a web application is to update a browser using AJAX, the browser “polls” the client, i.e. it keeps opening up connections to the server to ask “is it ready?” With Comet, the browser opens up a connection to the server and keeps it open until the server has something to say. There are all sorts of issues in doing this, from limitations of the HTTP protocol, to the Servlet specification, to the consumption of resources on servers and network appliances that are expecting short connections. Cometd is a server that tries to solve some of the issues.

What Alex has done is combine Cometd and JSONP to allow cross domain Comet. You can read Alex’s post here…

Is Cross Domain AJAX/Comet a ‘Good Thing?’

There’s a school of thought that AJAX apps should really be the SOA orchestrator of various backend services from various domains — a little Amazon S3 here, a little Google maps there, a little Yahoo mail there — and voila!, the ultimate mashup. While it is seductive to think you can assemble applications in this way, it makes me nervous for some reason that I can’t quite articulate. Having been the victim of bad SOA governance within companies, I have to think that these types of applications will be very brittle at the least, and vulnerable to security exploits at the worst.

A number of readers have noted that XMLHttpRequest can only communicate back to the same host that served up a page. This is true. We’ve all played around with XMLHttpRequest to see if we could make it break. Barring browser bugs, even with iframe and document.domain hacks there isn’t much you can do. You can use the super twin powers of Flash to do cross domain scripting in some cases, but even that has its limitations. So we’re safe, right?

As I pointed out last week, sites that allow for the persistence of executable artifacts — Javascript scripts and Flash files — can provide a leading wedge for AJAX worms and viruses. Many of these same sites have various forms of messaging, such as email. If you can push the buttons on these apps, you don’t have to make cross domain XHR calls at all. So, is an application like Yahoo or Google mail “scriptable” enough to allow this sort of subversion?

I know that reading through code like this

may make you feel confident that no one could decipher the inner workings of Gmail, but remember the old cracker war cry: “Security through obscurity is no security at all.” What man has compiled, man will also decompile — the Google Web Toolkit will give up its secrets.

With this in mind, I would be much more at ease if all of the various google applications I use — maps.google.com, spreadsheets.google.com, mail.google.com, and the various apps under www.google.com — didn’t all have single sign-on and the same google.com domain. It makes for a better experience, to be sure, but I’m pretty certain I don’t want someone mailing my spreadsheets to a compromised mailbox.

In the olden days, a popup browser window that started behaving strangely was a dead giveaway that foul play was involved. These days there is no window or status bar message and email may be going out in your name that you don’t even know about.

“Too early is the same thing as wrong.” — Old Venture Capitalist Proverb

Most Venture Capitalist (VC) proverbs are actually stolen from investment banking, but I think this one is actually home grown. (Full disclosure: my wife is a VC and I count many VC’s among my friends and acquaintances.) I thought it would be instructive and amusing to look at the predictions of one VC and see if he was right, too early, or just plain wrong.

Dan Grossman of Venrock was kind enought to publish a top ten list of AJAX apps last September. I would classify the picks in his list into four categories:

1. More or less useless “Oh, cool, it’s AJAX type apps.” Amazon Zuggest is probably foremost among them, but the periodic table is also showing it’s age. Any kid with Dojo and a few minutes on their hands could whip that up now.
2. Desktop style applications that are enabled by AJAX technology. These are Kiko, Writely and Time Tracker. Of course Google’s Calendar app has turned off the oxygen for Kiko. Look for Writely and it’s pygmy competitors to suffer the same fate shortly.
3. Improvements on existing apps — portals, news readers, etc. — through AJAX technology. Everyone has a portal and a news reader, so slathering on the AJAX was pretty easy. Now everyone has an AJAX portal and RSS reader — Pageflakes and Bloglines come to mind.
4. Proto Web 2.0 applications. These combine the usability enhancements of AJAX with collaboration and network effects. Backpack is probably the best of these. I’m not sure whether to put Del.icio.us Director into this category or not. Social bookmarking sites like Digg certainly seem to dominate this category right now.

I think if I put together a list of my top ten AJAX applications, two things would be true. First, at least four of those applications would be from Google. Second, in one years time, at least four of those applications would still be from Google, but everything else on the list would have changed. Maybe “AJAX” is not a specific enough category on which to base a top 10 list. (Should we say Web 2.0 and then proceed to define what Web 2.0 means?)

Thanks to Dan for sticking out his neck and making the list. I’m not sure any of these applications other than Backpack make it onto the list now. What does your list look like?

Via Ajaxian, Coach Wei over at AjaxWorld Magazine has an article expressing reservations about AJAX and what might hinder it’s adoption:

1. 10% browsers have Javascript support turned off (see statistics at http://www.w3schools.com/browsers/browsers_stats.asp). It means that 10% users can not access Ajax-based web sites or applications. This is definitely a problem for Ajax.

[...]

2. Taking the issue a little further, let’s talk about accessibility. Plain HTML is fairly good at this because most browsers take good care of accessibility. Most Ajax applications use Ajax widgets that may or may not support accessibility. For example, a lot of Ajax toolkits don’t have support keyboard navigation (mouse-less operation), which is a key requirement for a lot of operational applications. Does anybody know the capability of accessibility support from some of the leading Ajax toolkits such as Dojo, Yahoo UI toolkit and GWT?

Let’s take these objections each in turn. First, who are these 10% that have Javascript turned off, and should we care? If Javascript is turned off (as long as that’s an option in the browser), that’s the end of the conversation. The "J" in AJAX stands for "JavaScript." Rather than have AJAX applications degrade gracefully into some old-browser dottage, as Coach Wei suggests, I think the Network Effect is the thing to bank on here. From the Wikipedia:

The network effect is a characteristic that causes a good or service to have a value to a potential customer dependent on the number of customers already owning that good or using that service.

One consequence of a network effect is that the purchase of a good by one individual indirectly benefits others who own the good – for example by purchasing a telephone a person makes other telephones more useful. This type of side-effect in a transaction is known as an externality in economics, and externalities arising from network effects are known as network externalities. The resulting bandwagon effect is an example of a positive feedback loop.

All of those Web 2.0 collaborative apps will drive people to upgrade their browsers and turn on Javascript. I think it was bold of Google to determine they were not going to knuckle under and support any old browsers in their AJAX’ified applications. If you’re big enough, people will upgrade just to use your product.

If you really do need AJAX to degrade gracefully, I think the place to do that is in the framework, i.e. write your code and let the framework provide the code to go all the way from full AJAX to nasty postback. No framework does that right now, but it’s an opportunity that frameworks like Echo2 are poised to fill.

On point 2, again Echo2 (am I repeating myself here?) does have a facility for handling events such as focus, blur, keypress, etc. I don’t see why these things couldn’t be fleshed out an built into most AJAX frameworks.

Frankly, though, I don’t see either of these two issues as show stoppers or major stumbling blocks for AJAX. That ship has already sailed, as we’re seeing from the adoption of AJAX in ecommerce and web 2.0 sites.