Archives for category: ajax

Sort of a Maslovian hierarchy. I.e. don’t attempt a subsequent step until you get the previous step right.

  1. Load fast
  2. Don’t break the browser or the web (e.g. bookmark-ability, back/foward, searchability, etc.)
  3. Align with core web UI conventions (e.g. use hyperlinks for navigation, use forms for data entry)
  4. Be consistent with other web apps in your product family if you have one (e.g. all Google apps, all IBM apps)
  5. Make it pretty and do cool stuff if if it helps your users be more productive and/or have a more pleasant user experience

I had a fun chat today with Coté on his “make all” podcast. Here are some of the topics I remember discussing:

  • What’s important (and what’s not important) about HTML 5
  • The increasing ubiquity of JavaScript
  • Java-to-JavaScript translation technologies (e.g. GWT and JDojo)
  • Ajax, RPC, and REST
  • The nirvana of mobile devices plus cloud-based data
  • I recommend Nick Carr’s “The Shallows

Happy listening!

Shortly before winter vacation, an IBM colleague contacted me to learn more about how extensibility – particularly web UI extensibility – works in the IBM Rational Jazz Platform on which I work. After typing up my response I thought it might be interesting to a broader audience so I’ve reposted it here (with some minor tweaks for clarity). Note that some but not all of the links below require registration (sorry).


Hi <redacted>,

You are correct that as of Jazz Foundation 1.0.x (shipped this year), one contributes “viewlets” (a Jazz-specific widget mechanism comparable to OpenSocial Gadgets and iWidgets) to Jazz Dashboards via a server-side Eclipse extension point.

However, the Jazz extensibility story is more complex than OSGi bundles and Eclipse extension points. I will explain this below, with the assumption that you are interested.

Original Extensibility Mechanism Based on Bundles and Extension-points

When we first started the Jazz server work in 2005 we made a design decision that the Jazz server would be based on Java/OSGi and you contribute capabilities to the server by adding additional OSGi bundles. I’m guessing you’re very familiar with this architecture; it’s of course very similar to the Eclipse workbench except instead of contributing actions and views (e.g. to implement a Java IDE) you contributed web services and data definitions (e.g. to implement a bug tracking system). We went so far as to enable this style of programming for Dojo-based Ajax code so that developers could add “web bundles” and have the Jazz Web UI framework discover and surface their web capabilities in the Jazz Web UI. The Dashboard viewlets are one example of an extension-point-based extension. There are other extensions also enabled by extension-points (as in Eclipse, this extensibility model is open-ended).

Shift Towards a RESTful Architecture

Around 2007 we came to the conclusion that the “extend the server” model wouldn’t enable us to achieve our broad goal of “enabling integration of heterogenous tools across the software lifecycle”. There were several blocking problems with this architecture. I will list a few below:

We came to the conclusion that the RPC style service APIs were too fragile over time and would make it difficult to allow for independent upgrades of different tools in an environment containing many tools.

We could only support a narrow range of technologies (i.e. OSGi-ified Java and JavaScript code built on top of our server architecture). This limitation is readily apparent when you compare it to something like OpenSocial Gadgets or iWidget where you need only specify a gadget/widget URL to achieve integration.

This caused us to take a step back and ultimately decided to use the REST architectural style to achieve integration across tools. For instance this year we enabled several integrations between our Requirements Composer, Team Concert, and Quality Manager products using RESTful protocols and APIs. For an example of these integrations, see this video on that demonstrates how we use REST and Discovery to drive linking and “picker” integration between two tools.

Implications of RESTful Architecture on Extensibility Model

The shift to the RESTful architecture left a gap w/r/t extensibility. I.e. how do we meet extensibility needs if we can’t assume a homogeneous OSGi/Java/JavaScript-based programming model? The solution we came up with was something that we generically call “Discovery” (an overloaded term, I know). Basically each tool in a Jazz environment has a single “root services” document that describes the basic capabilities of the tool and has pointers to other documents that contain more details about a specific service. You configure tools to know about each others’ service documents, and from there they can discover and (if appropriate) consume each others’ capabilities using spec’d protocols (as opposed to physically installing code from Tool A within Tool B’s environment).

For instance, we have a “viewlet provider” service type that announces that the tool in question has viewlets that can be embedded in Dashboards. Here’s an example of how it works:

  • Tool A has Jazz Dashboards capabilities
  • Tool B claims to be a “viewlet provider”
  • Tool A is configured to connect to Tool B (this includes specifying Tool B’s root URL and configuring an OAuth consumer / provider relationship)
  • Tool A is now able to host Tool B’s viewlets in its Dashboards

The interesting thing about this is that Tool A and Tool B could be implemented in wildly different ways… e.g. OSGi/Java vs. PHP.

* As an aside, we are currently working to deprecate Jazz Viewlets and adding the ability to host iWidgets and OpenSocial gadgets in Jazz Dashboards. This is in plan for 2010.

Going Foward

Even though we have moved to a REST-centric architecture, OSGi and Extension Points are still important, but less so than they used to be. We will continue to ship and use the OSGi and Extension Point-based Ajax frameworks and building blocks for the near future, but our major development investments and the Jazz SDK‘s focus will only assume fundamental web technologies like HTTP, HTML, JavaScript, and CSS and provide optional higher-level frameworks around emerging web standards like OAuth and OpenSocial.

I hope this was useful for you.

– Bill

I hit a JavaScript issue recently that stumped me. I’m trying to detect if the code I’m running is in an IFrame or not. It seems like the safest way to determine this would be the following comparison:

if(window !== top) {
   var mode = "frame";

‘window’ of course is the global object in which your code is running. If you’re running in a frame, your window object is actually a child in a window hierarchy. ‘top’ refers the to the top-most window in the hierarchy. Therefore if window and top are the same, then you are in a top level page; conversely if they are different, then you are in a frame (or iframe).

This works great on Firefox but on IE, the window !== top expression never evaluates to true. That is, even if you’re the top window, ‘top’ and ‘window’ aren’t considered equal. I’m not sure why this is. My current fallback code is this:

try {
    if (top.location.href !== window.location.href) {
        var mode = "frame";
} catch (e) {    
    // if you're in an iframe in a different domain, the top.location check
    // results in a security exception
    mode = "frame";

This code has two problems:

  1. There’s a small possibility that you could have the a frame with the same URL as the outer page. This is very unlikely because there’s no scenario I know of where you want to nest a page, but it’s still a latent bug.
  2. You have to deal with the exception in the cross domain case. Not a big deal but unclean.

I’m curious if anyone has a better solution for detecting whether or not you’re in an IFrame.

Between early 2006 and early this year, my team at IBM Rational and I built a framework for component-based Ajax development for use in the Rational Jazz platform. The framework’s capabilities aren’t the focus of this entry, so I’ll just list some of them briefly:

  • A nice component model based on OSGi bundles and the Dojo module system
  • Request-time “building” of many fine-grained JavaScript files into monolithic files for faster download based on the introspected relationships between the files – i.e. no developer effort required for fast code loading other than writing good application code
  • Making a subset of the Eclipse extension registry available in the web page and queryable via JavaScript APIs modeled off of the org.eclipse.core.runtime extension registry Java APIs, allowing for open-ended extensibility using the Eclipse extensibility model
  • A simple framework for demarcating UI states that made the back button, history, and page titles work seamlessly within the Ajax page, even when a user gesture resulted in crossing a component boundary (e.g. loading and displaying a new virtual “page” from a different component) [1]
  • Dynamic, transparent loading of missing code in response to a user gesture that required it

We did a fairly good job of keeping our Ajax framework decoupled from the rest of the Jazz Platform both for the purpose of design cohesiveness but also to allow for possible future use by teams who weren’t building full-blown application lifecycle management applications like Jazz SCM or Iteration Planning.

Over time, other IBM teams heard about some of our capabilities and saw the positive results in our Rational Team Concert web UIs [2] and contacted us to explore whether they could make use of our code in their products. Each conversation went like this:

  1. We gave a demo and talk about the capabilities and architecture of the framework
  2. The other team said “that’s really nice, that’s really useful, that would be great to have”
  3. The other team said “we’re not sure we want to live within your framework, we’ll get back to you”
  4. The other team didn’t get back to us

Initially this didn’t really bother me – after all my job was to deliver the foundation for our Jazz web user interfaces, not to create a general purpose Ajax framework for IBM, but as I’ve thought about it more over time and seen this anti-pattern from other teams and other frameworks, I’ve decided that we should make a conscious effort to make our useful functionality available as simple building blocks (in the form of libraries) and then provide frameworks that layer on top of these building blocks.

Let me take a step back and explain what I mean.

A library is a set of reusable functionality where your application uses parts of the library as necessary. For instance, most programming languages have a library for creating and manipulating dates. Frameworks also provide functionality to the application programmer, but instead of the application programmer making simple function calls, the framework runs the show and calls into the application at well defined hook points. For example, GUI frameworks provide ways to wire up code to run in response to users clicking on buttons.

Both the library and the framework provide useful functionality intended to make the application developer more productive. Though it’s dangerous to make a general statement, it feels to me that the big difference between the two is that frameworks generally provide more power, but require you to make a bigger commitment to the framework’s way of working, while libraries provide generally less power, but make few (if any) demands about how you structure your application.

What’s unfortunate is when you’ve got some useful bit of functionality that could be made available as a simple library but it’s only available in the context of a framework. This is where we were with our Ajax framework. This stuff is too abstract, so here’s an analogy: Imagine that you heard about a new refrigerator which provided every feature and characteristic you ever dreamed about having in a refrigerator. The catch however was that you couldn’t just buy the refrigerator – you had to move into a house on the other side of town that included the new refrigerator. After about 10 seconds of thought you realize that even though it’s the fridge of your dreams, you’re sure as hell not going to move into a new house across town in order to get it. This situation (switching back to software from refrigerators) is shown in the diagram below.

Useful building blocks locked inside a framework

Useful building blocks locked inside a framework

My recent realization (which seems obvious in hindsight) is that the useful functionality provided by frameworks and libraries need not be mutually exclusive. For instance, in our Ajax framework’s dynamic build system, rather than requiring applications to run within our framework to enjoy this capability, we could have created a simple callable library to perform dynamic optimization on a set of files, and then created a framework that simply used this same library. This approach is shown in the diagram below:

Useful building blocks used by a framework but also available independently of the framework

Useful building blocks used by a framework but also available independently of the framework

Over the past month or so we’ve been refactoring our Ajax framework to extract the useful building blocks into simple callable libraries and making the framework proper smaller by delegating to these libraries. We’ve done this in the hopes that our code will be useful to other IBM teams but as a result of the exercise, we’ve gained a deeper knowledge of our software and the software’s quality has improved as we’ve decoupled the framework aspects from the building blocks aspects.

Going forward, it’s my intention that our team will generally start with building blocks first and then consider if we should provide some higher-level framework that uses these building blocks. I only wish we had taken this approach from the beginning but you know, live and learn.


  1. This UI state management framework evolved into dojo.hash
  2. You can see our Jazz web UIs built on top of this framework in the development section of if you register.


Changed “other than writing good code” to “other than writing good application code”

Last Friday I did an RIA weekly podcast (mp3) with Michael Coté of Redmonk and Ryan Stewart of Adobe. This was a fun and interesting experience. Fun because I like Coté and Ryan a great deal and enjoy talking to them and interesting because of the subject matter and also because it was the first podcast I’ve ever done.

There were a few things I said in the podcast for which I’d like to provide a bit of extra context, because it’s difficult in the podcast format to provide a great deal of context.

Network Transparency and Latency

At one point in the podcast, I talk about Jazz‘s early RPC-style web services and say something along the lines of “This is great for the Java client developers because they essentially get network transparency, which is awesome except for the latency.” This is sort of like saying “Not paying income tax is great, except for the eventual fines and imprisonment.” RPC-style interfaces that strive to provide network transparency have the unusual problem that they make remote connectivity too easy for developers. The result, which is almost a cliché, is that developers design applications which are way too chatty and which work fine on local area networks (the environment in which they are developed) but fall apart in wide area networks (the environments in which they are deployed). Later, in the clichéd scenario, the developers learn about explicitly designing the “stuff” that travels over the wire to provide a good balance between the needs of the application and the realities of the network.

Sometimes you just shouldn’t make things too easy. Like you shouldn’t put the car’s ejector seat button where the toddlers can reach it 🙂

Why We Didn’t Consider Flash as the Basis for the Jazz Web UI Infrastructure

At another point, Ryan asked me if we ever considered Flash and I said something along the lines of “Well we didn’t select Flash because it wasn’t as ubiquitous as the standalone browser” but after saying this I remember Pat Mueller telling me recently that Flash is the most widely deployed web client technology when you compare it against particular browsers (i.e. browsers in general are more widely deployed than Flash, but Flash is more widely deployed than any particular browser like Internet Explorer or Firefox). So though my memory is a little fuzzy, I believe the reason was that just as a general principle, we didn’t want any core Web UI application functionality depedning on a particular plug-in; for instance, the user shouldn’t require Flash to create a bug report. Another factor was that this was early 2006 so Flash was probably not as ubiquitous as it is today. Yet another factor was our later principle that “look like a normal web page” and some examples of Flash violate this (i.e. the big box of Flash in the middle of the page, or overly ambitious site welcome screens). But I have to say, my thoughts on Flash have really changed over the past two years, because I’ve seen some incredibly useful, subtle applications of it. I can’t think of a particular example, but I know a couple of times some page on had a really cool little visual effect and sure enough when I right-clicked it turned out to be a little Flash app seamlessly embedded in the page. So using Flash in tactical ways where it can provide a powerful but non-jarring user experience is something I would like to explore in the future.

Meeting with the WebSphere Application Server Folks

At one point early in the interview Coté mentions that we hung out and got drinks in Austin one night and I mentioned that I was down for a meeting with some WebSphere Application Server folks and it was also a good opportunity to meet with Coté which is why I accepted the meeting. Listening to the podcast, I feel bad about how this came out because in reality the WebSphere App Server folks were doing us a favor by taking a day off to review the security architecture of and indeed they pointed out both important security and scalability issues. The missing context is that I hate work travel (I repeat hate) because I have two toddlers and they just grow too much and we miss each other too much when I travel without them. So the only time I travel for work is if I really need to be there in person (like if I’m speaking at a conference) or if I can accomplish more than one goal with a single trip. If not for the chance to both do the review and meet Coté, who in my opinion (don’t blush Coté) is both a cool guy and important industry analyst, I would have probably called in.

Innovation vs. Standardization

At another point in the podcast, I mention a blog post by Alex Russell of Dojo where he talks about standards not saving us and encourages browser vendors to provide non-standard innovative features. I think in the podcast I may have come across as “standards don’t matter”. In fact I think standardization is important to build the applications of today but agree with Alex and that the future won’t be invented by standards bodies.


Otherwise I agree with everything I said 🙂

There’s a theory called ‘The Uncanny Valley’ regarding humans’ emotional response to human-like robots. From The Wikipedia entry:

The Uncanny Valley is a hypothesis about robotics concerning the emotional response of humans to robots and other non-human entities. It was introduced by Japanese roboticist Masahiro Mori in 1970 […]

Mori’s hypothesis states that as a robot is made more humanlike in its appearance and motion, the emotional response from a human being to the robot will become increasingly positive and empathic, until a point is reached beyond which the response quickly becomes strongly repulsive. However, as the appearance and motion continue to become less distinguishable from a human being’s, the emotional response becomes positive once more and approaches human-human empathy levels.

This area of repulsive response aroused by a robot with appearance and motion between a “barely-human” and “fully human” entity is called the Uncanny Valley. The name captures the idea that a robot which is “almost human” will seem overly “strange” to a human being and thus will fail to evoke the requisite empathetic response required for productive human-robot interaction.

While most of us don’t interact with human-like robots frequently enough to accept or reject this theory, many of us have seen a movie like The Polar Express or Final Fantasy: The Spirit Within, which use realistic – as opposed to cartoonish – computer-generated human characters. Although the filmmakers take great care to make the characters’ expressions and movements replicate those of real human actors, many viewers find these almost-but-not-quite-human characters to be unsettling or even creepy.

The problem is that our minds have a model of how humans should behave and the pseudo-humans, whether robotic or computer-generated images, don’t quite fit this model, producing a sense of unease – in other words, we know that something’s not right – even if we can’t precisely articulate what’s wrong.

Why don’t we feel a similar sense of unease when we watch a cartoon like The Simpsons, where the characters are even further away from our concept of humanness? Because in the cartoon environment, we accept that the characters are not really human at all – they’re cartoon characters and are self-consistent within their animated environment. Conversely, it would be jarring if a real human entered the frame and interacted with the Simpsons, because eighteen years of Simspons cartoons and eighty years of cartoons in general have conditioned us not to expect this [Footnote 1].

There’s a lesson here for software designers, and one that I’ve talked about recently – we must ensure that we design our applications to remain consistent with the environment in which our software runs. In more concrete terms: a Windows application should look and feel like a Windows application, a Mac application should look and feel like a Mac application, and a web application should look and feel like a web application.

Obvious, you say? I’d agree that software designers and developers generally observe this rule except in the midst of a technological paradigm shift. During periods of rapid innovation and exploration, it’s tempting and more acceptable to violate the expectations of a particular environment. I know this is a sweeping and abstract claim, so let me back it up with a few examples.

Does anyone remember Active Desktop? When Bill Gates realized that the web was a big deal, he directed all of Microsoft to web-enable all Microsoft software products. Active Desktop was a feature that made the Windows desktop look like a web page and allowed users to initiate the default action on a file or folder via a hyperlink-like single-click rather than the traditional double-click. One of the problems with Active Desktop was that it broke all of users expectations about interacting with files and folders. Changing from the double-click to single-click model subtley changed other interactions, like drag and drop, select, and rename. The only reason I remember this feature is because so many non-technical friends at Penn State asked me to help them turn it off.

Another game-changing technology of the 1990s was the Java platform. Java’s attraction was that the language’s syntax looked and felt a lot like C and C++ (which many programmers knew) but it was (in theory) ‘write once, run anywhere’ – in other words, multiplatform. Although Java took hold on the server-side, it never took off on the desktop as many predicted it would. Why didn’t it take off on the desktop? My own experience with using Java GUI apps of the late 1990s was that they were slow and they looked and behaved weirdly vs. standard Windows (or Mac or Linux) applications. That’s because they weren’t true Windows/Mac/Linux apps. They were Java Swing apps which emulated Windows/Mac/Linux apps. Despite the herculean efforts of the Swing designers and implementers, they couldn’t escape the Uncanny Valley of emulated user interfaces.

Eclipse and SWT took a different approach to Java-based desktop apps [Footnote 2]. Rather than emulating native desktop widgets, SWT favor direct delegation to native desktop widgets [Footnote 3], resulting in applications that look like Windows/Mac/Linux applications rather than Java Swing applications. The downside of this design decision is that SWT widget developers must manually port a new widget to each supported desktop environment. This development-time and maintenance pain point only serves to emphasize how important the Eclipse/SWT designers judged native look and feel to be.

Just like Windows/Mac/Linux apps have a native look and feel, so too do browser-based applications. The native widgets of the web are the standard HTML elements – hyperlinks, tables, buttons, text inputs, select boxes, and colored spans and divs. We’ve had the tools to create richer web applications ever since pre-standards DOMs and Javascript 1.0, but it’s only been the combination of DOM (semi-)standardization, XHR de-facto standardization, emerging libraries, and exemplary next-gen apps like Google Suggest and Gmail that have led to a non-trivial segment of the software community to attempt richer web UIs which I believe we’re now lumping under the banner of ‘Ajax’ (or is it ‘RIA’?). Like the web and Java before it, the availability of Ajax technology is causing some developers to diverge from the native look and feel of the web in favor of a user interface style I call “desktop app in a web browser”. For an example of this style of Ajax app, take a few minutes and view this Flash demo of the Zimbra collaboration suite.

To me, Zimbra doesn’t in any way resemble my mental model of a web application; it resembles Microsoft Outlook [Footnote 4]. On the other hand Gmail, which is also an Ajax-based email application, almost exactly matches my mental model of how a web application should look and feel (screenshots). Do I prefer the Gmail look and feel over the Zimbra look and feel? Yes. Why? Because over the past twelve years, my mind has developed a very specific model of how a web application should look and feel, and because Gmail aligns to this model, I can immediately use it and it feels natural to me. Gmail uses Ajax to accelerate common operations (e.g. email address auto-complete) and to enable data transfer sans jarring page refresh (e.g. refresh Inbox contents) but its core look and feel remains very similar to that of a traditional web page. In my view, this is not a shortcoming; it’s a smart design decision.

So I’d recommend that if you’re considering or actively building Ajax/RIA applications, you should consider the Uncanny Valley of user interface design and recognize that when you build a “desktop in the web browser”-style application, you’re violating users’ unwritten expectations of how a web application should look and behave. This choice may have significant negative impact on learnability, pleasantness of use, and adoption. The fact that you can create web applications that resemble desktop applications does not imply that you should; it only means that you have one more option and subsequent set of trade-offs to consider when making design decisions.

[Footnote 1] Who Framed Roger Rabbit is a notable exception.

[Footnote 2] I work for the IBM group (Eclipse/Jazz) that created SWT, so I may be biased.

[Footnote 3] Though SWT favors delegation to native platform widgets, it sometimes uses emulated widgets if the particular platform doesn’t provide an acceptable native widget. This helps it get around the ‘least-common denominator’ problem of AWT.

[Footnote 4] I’m being a bit unfair to Zimbra here because there’s a scenario where its Outlook-like L&F really shines. If I were a CIO looking to migrate off of Exchange/Outlook to a cheaper multiplatform alternative, Zimbra would be very attractive because since Zimbra is functionally consistent with Outlook, I’d expect that Outlook users could transition to Zimbra fairly quickly.

Related to yesterday’s post, I just caught up on the comments to Peter Gurevich’s (MS IE Performance PM) guidance to avoid using closures in IE. Matt Kruse had a perfect, concise response which I feel compelled to quote here verbatim:

Closures don’t cause memory leaks.

Browsers that have garbage collection bugs (IE6) and continue to retain those bugs in new versions (IE7) cause memory leaks.

Closures are an extremely powerful and useful programming technique. It’s unfortunate that you would recommend against their use simply because your browser has a bug that causes a memory leak.

A huge amount of time has been spent by the js community to detect, resolve, and work around these IE memory leaks. It’s too bad this was required, and will continue to be required as long as MS refuses to fix the problem.

Hopefully IE’s market share will continue to drop and we can begin to ignore these memory leaks because every other browser out there handles closures just fine.


Peter Gurevich, Performance Product Manager for the Microsoft Internet Explorer web browser, just wrote the third part of a blog series on improving the performance of Javascript execution within IE. Peter’s trying hard to help developers, but he’s got a thankless job since many of the problems are the result of not so much developer coding errors as IE design and implementation problems. The situation is compounded by the bitterness many developers feel towards Microsoft for taking a long vacation from major IE enhancements after winning the browser wars though a combination of rapid innovation and monopolistic business practices.

So when I hear Peter say things like:

Closures (functions that refer to free variables in their lexical context) are both extremely powerful and extremely dangerous. There are certain programming techniques that demand their use and once you learn how to use them they can quickly become one of the most overused features of the JScript language. Currently the misuse of closures in connection with the IE DOM and various COM components are the number one cause of heightened memory usage within IE.

While this is all true, it’s frustrating to read since he advises to avoid idioms that are not necessarily incorrect or misguided from a language perspective, but rather they’re problematic in the context of IE’s rusty engine. It’s like calling to report a busted-up highway and being sent a map of the backroads.

So while these posts on care and feeding of IE provide useful information, I’d also like to see frequent transparent communication on what Microsoft are doing to address the most fundamental problems that their browser presents to web developers.

What is Microsoft doing to address IE’s problems? Though they say they’re working on it, they haven’t published any concrete goals or plans for IE vNext. More transparency is welcome. What should they do? Rewrite or replace the layout engine. And the Javascript implementation.

Once again I must stress that I applaud Peter for writing these articles, but Microsoft also needs to communicate (in detail) about how they’re addressing root causes.