Archives

Even though it’s on a slow rollout and has reached only a handful of users, Gmail’s new UI has already earned tons of coverage. The new Gmail boasts a fast new JavaScript architecture, an improved contact manager and a host of interface tweaks, all of which I’m dying to see and use. But the feature that excites me the most is back-button support.

From the Google Operating System blog (emphasis mine):

Gmail has a new architecture that improves the performance and the usability. Now you can use the back button in your browser and bookmark URLs from different Gmail views because the URLs change when you go to a different section. The messages are prefetched when Gmail loads so you don’t have to wait too much until a message is displayed.

With all the work I’m doing on Really Simple History, I’m excited to see exactly what kind of back-button support the new Gmail offers. If I use the "newer" and "older" links to navigate through 10 messages, will I be able to use the back button to cycle back through them? Or will only the major views of the page (Inbox, Starred, All Mail, etc.) get stored in the browser’s history? I’m also interested as to why only IE7 and Firefox users will see the new interface. What’s holding up Safari support? (For that matter, what’s been holding up official Opera support all these years?)

If you’re one of the lucky few who’s already gotten to see the upgrade, please tell us all about it in the comments – especially your experience with the back button.

In the meantime, here’s a round-up of posts about the upgrade:

• Gmail Blog
• Google Operating System
• Lifehacker
• Ajaxian
• The Google Rumor Mill

Technorati Tags

• Google
• Gmail
• back button

Since Aptana, the slick IDE/Eclipse plugin came on the scene in 2006, it has been making steady progress, adding new features on an almost weekly basis. Now they have finally released 1.0. What’s new in 1.0?

• CSS Preview
• HTML, CSS, and JavaScript Formatting
• Code drag and drop
• Visual ScriptDoc Explorer
• Enhanced Dynamic Help System

Two of the major changes? First, they have changed the name to Aptana Studio. Second, they have done that all too familiar split between "Community" and "Professional" editions. Right now it looks like your $99 intro price ($199 later) buys you a few more things beyond the free community edition:

• JSON Editor
• Internet Explorer Debugging
• Remote Project Creation
• FTPS and SFTP Support
• Reporting Engine

You also get priority support and access to prerelease and nightly builds. These dual edition splits have worked in the past, as long as the "free" edition was not too far behind the "pro" one. It is a delicate balance, making the pro edition tempting enough without giving the free edition’s users the feeling that they are getting screwed.

Technorati Tags: ajax, ide, aptana

Lots more news on Really Simple History, the open-source Ajax bookmarking library I’m now spearheading:

• SVN – RHS now has a Subversion repository. The version trail starts with the 0.6 beta. Since its release, I’ve been committing bug fixes and refinements as I get them tested. Feel free to check out a read-only copy if you’re already bored with the beta.
• Mailing list: I’ve also started a Google Group for the project. In the future, that will become the primary means of communication for RHS, and I’ll get back to other subjects here on Agile Ajax.
• Bug fix: for/in loops – It’s universally acknowledged that they’re considered harmful, but I unthinkingly added one to the codebase just before zipping up and publishing the 0.6 release. That’s now remedied in SVN.
• Bug fix: Safari – The initial 0.6 beta also had a major shortcoming in its Safari 2/Mac implementation. Bookmarking worked great as long as you didn’t navigate away from your RSH-enabled app and then come back. If you did, goodbye, history. It turns out that the history.length hack fails in these circumstances because the browser resets the value each time the page loads. My solution was to add yet another hidden form field and store the initial history.length value there the first time the app loads during a session. Upon subsequent loads, I grab the value from this field instead of from history.length. Hacks upon hacks upon hacks, but it works.
• Enhancement: test page – I’ve continued to refine the test page. It’s now got a single logging console instead of three separate ones, plus easier-to-read log messages and more user-friendly controls.
• Download archive – I’ve created a bunch of for-posterity-only downloads of Brad Neuberg’s original versions 0.1 through 0.4. It seemed a little silly to create a retroactive SVN trail for them.

As of this writing, 225+ people have downloaded 0.6 beta. That’s in addition to the 2150+ people who have downloaded the stable 0.4 release in just the six weeks that it’s been hosted at Google Code. It’s really hitting me how many people actually use this thing, which spurred me to spend my weekend on the tasks listed above. I’m working hard to address the following additional issues before putting out a non-beta release:

• Bug fix: Safari infinite loading bug – I want to get rid of the stupid, eternally spinning disc on my RSH Safari tab. The fix is out there in the world; I just need to implement it.
• Bug fix: Opera history dies when you navigate away and back – I licked this in Safari, so now on to Opera.
• Bug fix: IE user-typed history entries – RSH 0.4 handled these properly, but I broke something in 0.6. It’s a corner case, but I’d hate to undo Brad’s hard work to handle it.
• Enhancement: window.onunload – RSH has always clobbered previously defined onunload handlers. In this era of memory leaks and the onunload events that help plug them, I want to handle this more gracefully.
• Enhancement: JSON bridging – The standard JSON library I’m shipping with RSH doesn’t play well with Prototype. I need to provide a better mechanism than brute force for individual users to override these methods with their own JSON serializer and stringifier.
• Enhancement: Graceful failure – I want to add better user-agent detection and set a global flag to just turn RSH off for those user-agents that aren’t supported. Right now, for instance, the library thinks Safari works, period, when really only Safari 2/Mac works perfectly.

I’m pretty confident I can get most of this committed this week. If you’re an RSH user, please let me know if there’s anything I’m overlooking.

Technorati Tags

• ajax
• javascript
• bookmarking
• Really Simple History

Welcome to Ajax Intervention, in which we dissect how major websites misuse, or fail to use, Ajax to improve their user experience.

Up this time: Comcast.com, which, despite an extremely "Web 2.0" look and feel, misses the mark with its Ajax features.

Comcast is one of those companies everybody loves to hate. Yet a quick glance at the latest version of the big cable operator’s web presence reveals some surprisingly up-to-date visual motifs. With its easy-to-read text, expansive white space, candy-colored visual palette and simple calls to action, Comcast is far more modern-looking than its competitors. Time Warner Cable, DirecTV and Dish Network all offer cramped, console-style interfaces that wouldn’t have looked out of place five years ago. But Comcast is clearly looking to incorporate the look and feel of Web 2.0.

Disclaimer: I’m a customer of Comcast and DirecTV but not of Dish Network or Time Warner, so I’m can’t speak about the password-protected areas of the latter sites. Comcast’s homepage is fairly similar to the other sites’, but the rest of comcast.com looks strikingly different from your typical sales-and-service site.

Or so it appears. Once you actually click around the Comcast site, it becomes clear that most of its freshness is merely visual. The functionality and user experience are just as inconsistent as we’ve come to expect from big corporate sites.

Problem: Wonky Login Module

The site includes two login modules: A traditional one on the homepage and an Ajax one elsewhere. When entering bad credentials into the homepage one, you get redirected to the standalone one, where a loading icon indicates an in-progress XHR. Sometimes, that XHR hangs … forever. No graceful failure message ever appears. During the site’s relatively frequent performance slowdowns, even correct login credentials can result in a permanently hanging Ajax call. That tends to confuse users. The validation scheme is even more confusing. Blank required fields earn you a JavaScript alert box, while errors from the server side get loaded via XHR into into the markup.

Solutions

• Provide graceful failure for your asynchronous requests by setting a timeout on them. The XHR object doesn’t offer this natively, but most popular libraries do.
• Use a consistent DHTML error-reporting framework rather than a grab bag of alerts and inline messaging. In addition to being more user-friendly, it will be easier to maintain.
• Build reusable components and, if necessary, style them differently on different pages. Don’t build two overlapping components with strange dependencies.

Problem: Inconsistent Shopping Cart

When you visit the Comcast.com to shop for new service, the shopping cart utilizes a strange mixture of DHTML, Ajax, popups and traditional navigation to guide you through the process. On the first page view, before you’ve even added any services, a loading icon signals that an Ajax call is in progress. As it turns out, they’re making an XHR just to load an empty shopping cart. As you add services from multiple tabs, Ajax is again used to update the shopping cart. But to remove items from the cart, you must click an "edit" button and do so in a popup window.

Most puzzlingly, the interface doesn’t seem to validate your choices. I was able to add separate phone, cable and internet products to my cart, then add a bundled "Triple Play" phone/internet/cable package. I went very far down the checkout funnel without ever receiving a notification that I was ordering an incompatible array of products. Yet when I cleared out the cart and just played around with the standalone cable products, the interface kept me from breaking the rules. If I added cable package A, then added the mutually exclusive package B, package A disappeared from my cart. Yet there was no messaging to explain what had happened.

Solutions

• Don’t use Ajax for just one aspect of your component. If the user can add items inline, she should be able to remove them, too.
• Let your users know what’s going on. If you’re going to use validation logic to remove things from their cart automatically, then message them when you’ve done so.
• Model your GUI widgets on traditional form controls. Mutually exclusive options should behave like radio buttons; a la carte ones, like checkboxes. A laundry list of options, some a la carte and some mutually exclusive, is usually a bad idea. Group each set of logically related options into something resembling a fieldset.

Problem: Inconsistent Global Navigation

Once you’re past the homepage, with its left nav column, comcast.com presents you with a consistent top nav bar: Learn, Shop, Programming, Customers, About, and a search box. But the tabs themselves aren’t clickable; you have to drill down within the DHTML menus to select a specific topic. Certain topics inexplicably load new windows, often from separate subdomains, full of Flash or HTML content. The navigation on these windows is different from the main site – or totally absent.

Solutions

• Study basic usability. The tabbed navigation metaphor has been around for ages. Follow best practices when implementing it.
• Consolidate your content. If you can embed a Flash movie in a popup window, you can embed it in your main window. It’s jarring for users to be sent off-site without warning.
• Don’t disorient your users. Your navigation doesn’t need to be identical in every sub-domain, but do at least provide a consistent way to navigate back to the homepage.

Problem: Slavishly Consistent Color-Coding

Each section has its own design scheme in which headlines, buttons, links and tabs all appear in the same color. Links aren’t even underlined. It’s therefore impossible to tell, without mousing over an element, whether or not it’s clickable. Users often have to play target practice and click on a small "go" link to get to a subsection; the headlines themselves are inconsistently clickable.

Solutions

• Underline your links and make buttons look like buttons. UI design isn’t art; it’s science. Users know the rules and get annoyed when you break them.
• If you must abandon underlined links, then do something to differentiate your links from other content. A pretty color palette is useless if it causes users to click continually on the wrong elements.
• When in doubt, make it clickable. Don’t just link a button when you can link the accompanying image and/or headline, too.

Problem: JavaScript Users Only

If you visit comcast.com with a JavaScript-disabled browser, almost nothing works. There’s not even an old-school "please turn on JavaScript."

Solutions

• It’s 2007. Follow web standards. Use progressive enhancement. If you’re not building a cutting-edge RIA with heavy client/server data exchange, there’s no reason to require JavaScript. At the very least, inform your users that their browser isn’t supported.

Conclusions

Most large corporate sites can’t retool themselves overnight. At best, they can update their features one at a time and use fresh visual approaches to call out their new interactivity. But in doing so, they should rely on old-fashioned user exerience design, follow industry-standard UI conventions and strive for a consistent experience. Comcast’s bright, big, bold design scheme is a welcome development, but it’s only the first step in what could be a comprehensive UI redesign.

Technorati Tags

• user experience
• JavaScript
• Ajax

Reasoning by historical analogy can be dangerous, especially if such reasoning is untempered by recognition that no two historical events are identical and that the future is more than a linear extension of the past.  The instructiveness of historical events tends to diminish the greater their distance in time and space from the day and place they occurred.

– PERILS OF REASONING BY HISTORICAL ANALOGY: MUNICH, VIETNAM, AND AMERICAN USE OF FORCE SINCE 1945 by Jeffrey Record

It may seem a little hyperbolic to quote from a paper published by the Air War College in advance of a critique of Joel Spolsky’s latest strategy letter, but lessons about historical reasoning can apply just as well when the question is the future of software as it does when the question is war and peace. So, how exactly did Joel screw up in his analysis of the future of Ajax? Well, first to what he got right:

• He got the bit about the Forms-based interfacre (Green Screen, etc.) right. Web 1.0 was like the mainframe apps, Web 2.0 is like the desktop GUI. Welcome to the club, Joel, over a year and a half later.
• Large JavaScript apps will download faster over bigger pipes (or "tubes" or "trucks") and run faster in newer browsers with better JavaScript runtimes. So nobody cares about the 3k do everything library anymore, just like features are more important that memory footprint and performance in Desktop UI’s. Again, welcome to the club.
• The portable programming language is not likely to be Javascript in the long run. Think VM, like Tamarin or Silverlight. The same developments that make JavaScript run faster in the browser will ultimately make it irrelevant.

So where did Joel go wrong?

• For one, he confuses the categories of Hardware Platforms, Operating Systems, UI Toolkits and Application Software. Anyone remember the RogueWave GUI libraries, circa 1994, or Think’s Lightspeed C for the Mac from way back when? Where are they now? (RogueWave is still around, as is Symantec which acquired Think C, but you wouldn’t exactly say they were the "winners" when it came to GUI SDK’s.)
• What are the applications, the 1-2-3′s of the web age? Well, everyone who publishes a web site is an ISV. Some make very basic use of the platform’s (browser’s) features. Some who publish full on webapps make fairly sophisticated use of them. As a group they have more leverage over the OS/Browser than Lotus 1-2-3 and company ever had. That’s why IE can’t make crazy extensions W3C standards, just incremental ones.
• Compilers and languages have come a long way since C showed the way. The norm now is for runtimes to support multiple languages with a common API (see .NET, etc.). So no "single" language will need to be invented.
• NewSDK looks a lot like GWT. Sorry, Joel, Google isn’t snoozing. They may still get overtaken, but your narrative is a little off the mark.

What is the hardware, the OS, the GUI SDK and the Application? You could take the naive approach and say that Intel is still the hardware, Windows XP/Vista is the OS, but that doesn’t quite square with how I see things. I think that the browser is the OS, DOM and Javascript are the GUI foundation library, and Dojo, Ext JS, etc. are the RogueWave and ThinkC SDK’s of the Ajax age. As the OS/GUI library changes (new features/standards in the browser, etc.), so these SDK’s will have to scramble to keep up. They will be influential, but eventually more and more of core GUI functionality will make its way into the browser. The browser calls the tune, everyone else just dances along.

Technorati Tags: ajax, spolsky

So I ended up doing some last-minute fiddling with the Really Simple History 0.6 beta before posting it for testing over at Google Code. Matt Snider pointed me to a potential SSL problem with using DOM methods rather than document.write to insert IE’s hidden iframe. I’ve got four places where I need to insert stuff into the DOM, and I had already hemmed and hawed quite a bit about whether I should use DOM methods, document.write or a mixture. For now, based on Matt’s comments and the verbosity of DOM methods, I’ve reverted back to using dirty-but-concise document.write. I’m going to continue testing this in as many browsers as possible before settling on a permanent solution.

While fiddling, I discovered something interesting that contradicted yesterday’s (now-corrected) post. I originally wrote that if you’ve got script-generated DOM elements that need to be treated as native to the document (so, for instance, you can persist form values across an entire session regardless of whether you navigate off-site), you must use document.write to insert them into the DOM. Not true, as it turns out. It doesn’t matter whether you call document.write or standard DOM methods from the head of your document. Either way, both methods seem to result in "native" HTML form fields that can properly persist values. Looking at Firebug or Opera’s developer console, you can see that these elements end up being children of the body element even though they were, in fact, inserted into the head element. Modern browsers are so smart!

This whole issue of when to generate DOM nodes brings up an interesting facet of library development: Deciding how much stuff the end user (i.e the developer who is leveraging your library) has to do in the actual document. For most libraries, it’s not an issue, because their objects and methods aren’t going to do anything until called by application code. But it’s different for something like Really Simple History, which relies on a variety of browser-specific hacks, many of which need to be set up before the DOM finishes loading. Sure, you could include inline script blocks in the body of your document to write the hidden, browser-specific DOM elements that enable your library to function. But developers really hate it when the use of a library forces them to fiddle with their page templates. Library authors have to get creative – for instance, by calling their initialization methods in the library file itself, even though that will result in DOM elements getting written to the document head.

As I said in yesterday’s post, Ajax history management works only thanks to a variety of browser quirks and hacks. If you want clean code that doesn’t break any standards, then you should cross history management off your list of requirements.

Things get even more interesting when your browser-specific DOM hacks work best when they’re included as actual markup. My beta is out there, but I’m still scrambling to figure out the best strategy for Opera which, thanks to a bug introduced in 9.x, relies on a hack involving an image tag a crazy URL:

<img src="javascript:location.href=’javascript:dhtmlHistory.checkLocation();’;" style="visibility:hidden" />

This image throws errors in IE, so I couldn’t tell developers to include it in their actual markup even if I wanted to release a library with such brittle implementation rules. If I want it to go in the actual HTML, I’d have to ask developers to do server-side browser sniffing and include it only for Opera users. YUCK. Yet all of the methods of writing it to the DOM via script have drawbacks. The way I’m doing it now, it works in Opera, but it throws an exception in the JavaScript console. Sure, only developers will see that exception, but still…. I guess I still have my work cut out for me.

Technorati Tags

• ajax
• javascript
• bookmarking
• Really Simple History

Late tonight over at Google Code, I’ll be posting a beta of Really Simple History 0.6 for testing. The goal is to elicit help from RSH users in chasing down any bugs I’ve failed to catch, then push out a stable release around Halloween.

I’ve tried to be as ambitious as possible with this release: full support of IE7/Win, Safari/Win, Safari/Mac, Opera/Win, Opera/Mac. I’ve didn’t quite get there, but I got close.

Features in the new version include:

• Full support for IE7/Windows (though my only Windows machines use IE7 Standalone, so I need help testing on "real" IE7 installs).
• Full support for Safari 2/Mac (though I’m still trying to eliminate the "infinite loading" bug before I push out the beta).
• Partial support for Safari 3/Windows (hampered by bugs in the current beta version of the browser).
• Full support for cross-platform Opera 9.22 (though you may need to hard-code an image into your markup).
• A totally revamped test page that allows you to play with the library in your browser of choice and see how it works behind the scenes.

As always, RSH works beautifully in Firefox 2 for Windows and the Mac. I hope to give it a good shakedown on Linux browsers in the next release.

So what is Really Simple History, and why am I updating it?

An Ajax bookmarking and history-management framework originally developed by Brad Neuberg, RSH became my responsibility a little over a month ago. I tinkered with it for a few weeks, then finally camped out with it for most of the past week to get a release out.

This is the first time I’ve ever contributed in this manner to an open-source project. It’s been a lot of fun, but it’s also been maddening, as anybody who’s ever dug into the bowels of cross-browser history management can tell you. Here’s a sampling of what I’ve learned from RSH:

Safari is crazy

Plenty of people who’ve worked on Ajax bookmarking projects have commented about this, but it only becomes clear once you’ve actually seen it in action. Getting this thing to work in Safari 2 for the Mac took a wildly disproportionate amount of time considering its market share. I wouldn’t have been able to do it without Bertrand Le Roy over at Microsoft, whose blog entry on the development of the .Net history manager pointed the way for both Safari and Opera.

As Le Roy and others have noted, the Safari 3 Windows beta is so buggy that history management is hopeless. You can enable the back button for Ajax apps, but once you use it, the forward button becomes disabled. I noticed yet another wrinkle in this behavior (skip ahead if you’re easily bored):

Navigate to a non-RSH site – Google, for instance. Then travel to an RSH site, create some history entries via RSH, and use your back button. The forward button stops working: a known bug. Now keep hitting back until you get back to Google again. Suddenly, your forward button works again. Hit forward and land back in your RSH app. Magically, the forward button continues to work.

If I hadn’t spent so much of the last week lost in Safari-land, this interesting behavior might be worth further investigation. For now, I’m just hoping the Safari 3 team fixes this before the final Windows release.

Don’t try to retire document.write just yet

A couple of different RSH users suggested getting rid of Brad’s original calls to document.write in favor of standard DOM methods for adding elements to your page. That approach worked for some elements, but not for others.

In IE, RSH writes a hidden iframe into the document and uses the location and history of that iframe to help it track application state. Writing the iframe with document.createElement works just great.

But for all browsers, RSH uses a hidden textarea to store the entire history stack behind the scenes. This powers one of RSH’s coolest features: its ability to retain history even if you navigate away to another site and then come back to your RSH application. This works because modern browsers retain form-field values throughout an entire browser session. But they do so only for form fields that exist in the DOM natively – that is, exist in the actual HTML markup or get inserted via document.write get inserted into the DOM before it’s finished loading. 

If you create a form element after your DOM is already loaded, the browser has no way to persist values in that element after you leave the page. Each time the page loads, even from the cache, you essentially create a virgin new form field. I’m therefore using document.write for the hidden textarea – and for the hidden form field I’ve added to RSH for Safari support.

UPDATE: As it turns out, it’s immaterial whether you use DOM methods or document.write. The important thing is to use either method before onload fires. I ended up using document.write in the 0.6 beta because of SSH concerns and the fact that it’s so much more concise. For more on this topic, see this subsequent post. 

Because of the way RSH is structured, these elements actually get written to the head rather than the body of your document. Still, it works, and it should only offend the most anal-retentive of standards geeks. After all, if you’re hacking the browser 10 different ways from Sunday just to enable Ajax bookmarking, then inserting a bit of non-validating markup via JavaScript is hardly the worst of your sins.

RSH won’t be hitching its wagon to [insert name of your favorite framework here]

A few users suggested rewriting RSH in Prototype so it would be more compact. I appreciate the impulse, but I think that defeats one of RSH’s chief virtues: the fact that it’s written in Plain Old JavaScript and doesn’t lock you into any specific Ajax framework. It plays well with any library you want it to: Prototype, jQuery, YUI, whatever. (If it doesn’t, please file a bug so I can find out why.)

A little JSON never hurt anyone

The one library that RSH does require is a JSON parser; it ships with the latest open-source version. RSH 0.4 included an earlier version of the parser in the same file as its native code; I’ve broken it into a separate file under the logic that many users will already be serving a similar library. RSH’s methods don’t actually call toJSONString or parseJSON directly; instead, I’ve provided bridges so that you can hack in your own JSON methods without having to modify the guts of RSH itself.

Future roadmap

I’ve got quite a punch list for the next release:

• Provide minified versions of RSH and JSON for download
• Make use of Crockford’s module pattern for better encapsulation
• Add official support for Linux browsers, Safari 3/Mac and Safari 3/Win

That’s the future. For now, I have to get 0.6 packaged up and ready for testing. Check Google Code late this evening or first thing tomorrow.

Technorati Tags

• ajax
• javascript
• bookmarking
• Really Simple History

There are a lot of nice things about Agile Development from a BA perspective.

The one I like most is one of the corollaries that stem from the Agile Manifesto’s decree that Agile Teams are self organizing.

Since I’m a consultant, I need to create a TLA (Three Letter Abbreviation) of a sexy, ridiculous (can you say ‘mashup’?) or metaphoric term, send it to the marketing department and add 2-6% more to your bill because of my creativity. The Agiprop (Agile +Propaganda as opposed to the original Aggitation + Propaganda from the second red scare of the 1940s, get it?) I endow this new TLA as:

Powered by ScribeFire.

Echo3 is showing a few more signs of life. Since my update last month on some early details of Echo3, the pace has picked up. No alpha release, but already there are two forums, one especially for folks looking to contribute to Echo3 development. Also, a few other things worth mentioning about Echo3:

• The SVN repository can be found at svn://svn.nextapp.com/echo3/trunk (Echo3Extras are at svn://svn.nextapp.com/echo3extras/trunk).
• If you just want the binaries (or binaries with source), the Echo3Go project is handy.
• Initial performance numbers of Echo2 vs Echo3 show a more than 2x improvement in performance.

Further, a more detailed description of the new features, design principles and ideas behind Echo3 can be found on the wiki. Two items that are especially interesting for those looking to write their own components:

• Automatic Serialization: Data objects sent between client and server can be automatically serialized between Java, XML, and JavaScript. The serialization architecture is extensible–serialization code for new object types may be added by the developer.
• Simplified Client/Server Synchronization Peers: Serializing components and commands between client and server is performed automatically using the built-in serialization architecture. The component developer only need specify which properties should be sent (for components, all local style properties are automatically sent).

Serializing and deserializing data between client and server can be one of the more timeconsuming and error prone parts of developing Ajax apps. Packaging this into the framework with improve productivity at the very least.

Technorati Tags: ajax, echo3, echo2

All the fuss around LIE reminds me of my days when I was scared of NPE (NullPointerException). No matter how hard I tried, I just couldn’t write code that couldn’t run into NPE. Slowly, I learnt that it is not a question about not running into NPE, it is about implicit awareness about the possibility of any reference being a null at any given place and time in code. Isn’t LIE very similar to NPE in that way?

Folks are afraid of switching from Hibernate 2.0 to Hibernate 3.0 because their app starts throwing LIE everywhere as soon as they do. So, instead of trying to figure out the reason for this. They switch back to 2.0.

Follow these simple rules and we can avoid LIE in most places:

• Use OpenSessionInViewFilter (OSIV), it is your friend (as described here and here): Atleast in web applications, this ensures that you have a valid session in all layers – controller, service and finally view. One argument I came across recently against OSIV-filter is that it couples your application with Hibernate and makes it harder to replace persistence layer with some other persistence mechanism. An interesting thought! But does it really stick? Think about it. Any persistense framework will either not use lazy loading (like hibernate 2.0 did) or have some mechanism for loading object on demand ("lazy" that is).
• Avoid keeping reference to a hibernate managed entity outside of a hibernate session: If you need to keep an object around longer than a request (http-request or any other request), create a data-transfer-object out of your hibernate object. There are few common situations where this occurs most often. Currently Logged in user’s information is retrieved from database when the user logs in and is kept in HttpSession. It is very easy to get into the habit of modifying this User object in HttpSession and trying to save it which will run you into Hibernate Merge issues. The easier (and Hibernate mechanism independent) solution is to create UserDTO and keep that in HttpSession. Another common situation is when you need to use caching to reduce database load. Again, why not use DTO(s) inside cache and not hibernate managed entities. It can be argued that this promotes struts action-form like anti-pattern ("bridge" anti-pattern?). However, I prefer keeping a known entity (fully initialized with a controlled hierarchy depth) around than a magical entity (hibernate object that may not have been fully initialized).

Just like NPE, once we ensure that an open connection to database (hibernate session) exists whenever we deal with a hibernate managed entity, we can avoid LIE.