Tuesday, January 29, 2008

Keeping your session alive

Rotor
A couple of weeks ago I attempted to order prints from Flickr. I added a few photos to my cart and was redirected to a service called QOOP. This has a neat interface that allows you organize photos for printing in a book format. I played a bit with the interface and then was caught by other tasks. When I came back to my browser window and attempted to preview the photo album, I got a wonderful error message about a session having expired. The result: my album was lost. I gave up.
My adventure with expired sessions is quite common and I can bet you have had this kind of issues in the past. The least that can be said about this is that it is not user-friendly!
To address this kind of issues, we recently introduced a new feature in Orbeon Forms called the "session heartbeat". The idea is that if you happen to leave a browser window open on your computer, chances are that you will get back to that window and keep using the application. The last thing you want to happen when you come back is lose your session and therefore your data, as happened to me.
This is not always a correct guess of course: you may just happen to leave a window or tab open without planning to use it again. Conversely you may have a page which is not actually visible, for example in your browser history, yet you will come back to it. This approach wouldn't be good for banking applications either. Still, in many situations, such as filling-out large forms, it sounds like a good idea to keep your session alive for open pages.
To achieve this goal you could make all server sessions longer. However this is harder to configure for the application developer, and this won't discriminate between pages that are actually open on a client and the ones that are not. And while it may be ideal to have infinitely long sessions, unfortunately many applications are not ready for this kind of approach.
So we turned to the idea of implementing a "session heartbeat". Here is how this works:
  • When this feature is enabled, an open XForms page regularly pings the server through Ajax to keep the current session alive.
  • The ping delay is automatically computed based on the server's session timeout. The client pings the server at 80% of the session expiration time after the last interaction with the server.
  • We are careful not to hit the XForms engine too much, in fact we do a very limited amount of work on the server for each ping, so they should run fast.
  • XForms state information for pages hit with the heartbeat just migrates to the disk store over time if RAM is used by other pages, so keeping even large numbers of pages open should not have any negative impact on server RAM.
  • When a user gets back to using the page, state information migrates back from disk to RAM, and the page will be live again.
  • Sessions do eventually expire as nobody keeps a browser open forever.
Note that whenever an application keeps sessions alive for a long time, it is a good idea to keep as little data as possible in the session. The Orbeon Forms XForms engine itself uses a global state store and does not use session objects for storage, but do remember to keep your sessions small!
Hopefully, this will help prevent many occurrences of the infamous "session expired" error message. The beauty of it is that as an Orbeon Forms application developer you don't have to worry about anything: the session heartbeat is enabled by default (but it can be turned off globally in properties.xml or individually for each page).

Wednesday, January 16, 2008

Bad forms, part II

Continental Logo

I recently booked a flight on the Continental web site. I knew approximately the flight I wanted to book, so dug right away into the search to select it. I encountered the following issues:

  • When the results came, the prices were in Swiss francs. Since I was in Switzerland but using a US credit card, I decided to switch my location using the quite nicely done language and location menu available on the result page.

    I first noticed a funny glitch: for Switzerland, the language selection was English and German. English was selected by default, which suited me, but English was the second radio button in the list. When I switched to the United States location, the second radio button remained selected. However, since for that location the language selection was English first, then Spanish, the result was that the Spanish language was selected. Oops.

  • This was just a little bug though. The bigger problem was that as the language was switched, somehow the search page kept my flight dates, but lost the selected flights. So I had to go through them again.

  • When doing the final checkout, I omitted a digit in the credit card number. It took the web site almost one minute, after I pressed the submit button, to tell me that there was a problem with that number.

  • When that was fixed, I also happened to have forgotten to enter the billing address. The same thing happened: I had to wait for quite a long time after submitting the form to get a message telling me that that was wrong.

Now let's say the developers of the Continental web site decide to switch to Orbeon Forms and XForms for the next version of the web site:

  • With XForms, they easily set constraints, such as saying that the value of the radio button should be the currently selected value (say, 'en') if available, or then the default value if unavailable.

  • Localized user interface resources are stored in a separate XForms instance (which is an XML document). When switching the resources document, the entire user interface updates without losing the other data captured by the user.

  • XForms has several mechanisms to check input data: you can use XML Schema types or XPath constraints (XForms 1.1 even supports a credit card number type) to make sure that a Visa or Mastercard number is at least approximately correct in length and that the redundancy digit applies correctly.

  • XForms also support ways to mark fields as required so the user doesn't forget to enter some information.

And this is all interactive too, meaning that the user doesn't need to wait one minute to know that some fields are missing or incorrect.

Tuesday, January 8, 2008

Yahoo! goes XForms

Yahoo! Blueprint

Yahoo! today announced a new mobile platform called "Mobile Widgets". The amazing part is that the language used to describe widgets, called Blueprint, is based on XForms:

Much of Blueprint's philosophy and syntax comes from XForms. We opted for a full declarative language because it was the only way we could effectively run on the wide range of devices out there, some of which have no scripting at all. By using declarative syntax, we can encapsulate and hide the scripting specifics. In some cases, the code could run on the phone, in other case, such as XHTML, we can put the logic on our servers. It's the perfect way to deal with the various environments and their capabilities.

The Blueprint Philosophy and roadmap highlights the benefits of declarative vs. imperative, "because it was the only way we could effectively run on the wide range of devices out there, some of which have no scripting at all". For now, only very basic XForms constructs are supported, but "In our second release of the Blueprint language you'll be able to take full advantage of the power of XForms-style MVC programming".

Although Orbeon does not particularly focuses on mobile devices, this philosophy is entirely in line with our transformations- and Ajax-based approach to deliver XForms everywhere (in our case to mainstream browsers). It is excellent news that a company like Yahoo! not only recognizes the benefits of the XForms approach, but also decides to leverage the standard instead of reinventing the wheel (like Google did with their Google Mashup Editor, which looks very much like an incompatible clone of XForms).

In short this is extremely positive for the XForms community. We can only hope that Blueprint lives up to its promises.