Asynchronous Record Finding in Web Forms

By Deane Barker on May 14, 2006

In any content management (or information management) system of sufficient complexity, you will have to interlink records. You will always get to the point where, in the process of editing a record, you will have to specify another record.

(Let me note here that the title to this entry is insanely overblown and academic. But I couldn’t figure out how to describe this otherwise. I’m really not that boring. Really.)

Example: you’re writing an article and it’s an update to another article. Somewhere in the article edit form, there’s a drop down of the other articles so you can specify its “parent.”

Example: you’re managing an employee record, and you need to specify all their direct reports, which are other employee records.

Example: you write a news story, and you need to specify an image from a directory tree that’s potentially 14 levels deep and contains 10,000 image files.

This seems straightforward, but there’s a threshold of record volume where it becomes an interface problem. The question becomes whether or not you can make the selection “synchronously” or not, which means, can you make it without moving away from the form you’re editing?

Put another way: can the form in which you’re working “pre-load” all the possible selections you could make? Or is the volume of possible selections too large?

If you have 50 employees in our example from above, then yes, you can generate a drop-down box with 50 options so the user can select one. The user would be able to select “Record B” from the drop-down box while “Record A” is still in the edit form.

But what happens when you have 50,000 employees? You ain’t going to have a drop-down box with 50,000 records in it (though I know someone, somewhere has tried).

In these cases, you have to select another record “asynchronously,” which means out of the context of the current form. This gets tricky from a user-interface perspective.

Some options for how to handle this:


You can move to another screen. eZ publish does this pretty well, but it’s an inherently bulky solution. The main problem is that there’s no way around the fact that you’re leaving the form in progress. How does the data get persisted until you get back?

You click a button for “Select Object,” and that button essentially submits the form and the server stores the half-completed record in the session. You get sent to another page (or succession of pages) to find your other record, and when you’ve found it, you get dropped back into your form with data reloaded from the session.

Like I said, eZ publish does this, and it generally works. But it’s jarring to see all your form input disappear while you get shuttled to another window. What happened to your form input? Can you go back?


You can do a pop-up miniform. You click your button for “Select Object,” and you get a pop-up within which you can navigate to find a record. When you find it, the window populates some hidden (or not) field on the main window, then closes.

The problems with this are the same problems endemic to pop-up windows in general – the box isn’t modal, which means the user could end up with some orphan window floating around, or they could “lose” the window somewhere amidst their other windows and get confused, or the window could get blocked by their pop-up blocker.


You can do some snazzy stuff with Ajax, and I think this is the smoothest solution. So now when you press the “Select Object” button, you can get an “integrated object finder” within your form – an “live” area within the page that you can use to “navigate” your records and select one. You essentially get all the benefits of a pop-up, with none of the drawbacks.

The benefit of this is that the finder can be modal, which means you can supress the rest of the form while the user is on their little scavenger hunt. Perhaps you do something like the “fade the screen and pop a little window in the middle method” (man, that technique needs a name).

You use this little mini-form (perhaps using an embedded browser like Bitty), find your record, and the finder populates the main form transparently, without you ever have “left” the form. This is awfully close to how a desktop app works, which is not coincidentally wickedly usable.

Those are the techniques I’ve seen so far. Ajax holds a lot of promise here for the sole reason that this fits in very tightly with what Ajax offers – in these cases, you need browse the server for something while not losing the context of what you’re doing at that moment. This is Ajax’s sweet spot.

Anyone else have any bright ideas here or descriptions of techniques they’ve seen?

Comments (3)

Sauron says:

One idea that I’ve seen when working with a large number of options is to use a selection menu with broad sections. Select one of the sections and it becomes a list of subsections and so on to as many subsections as are reasonably needed. I think it shouldn’t be difficult with Ajax to make it occur without reloading.

Joseph Scott says:

As I’ve thought about this problem I keep going back to the Lightbox display. If you aren’t familiar with it go check out Lightbox JS. It started out as a neat way to display pictures, but others have already started expanding on this, see Lightbox Gone Wild!. On their example page they are already putting a form in the lightbox.

Although I haven’t done it yet myself, it seems like there should be a way to send values back from the lightbox form to the main page. Perhaps by making use of Prototype.js. Making this work has been on my to-do list for awhile.

Even if it still needs more work to be fully flushed out I think this would be slightly better than your #3 option because it makes it very clear to the user what is going on. Disabling a form will get you the functionality that you are looking for, but I don’t think it will be immediately obvious to the user what you have done.

Joseph Scott says:

I knew I should have gone through my old links on Lightbox before I posted the previous message. It looks like others have already developed code using the Lightbox display model that can display a form and update the main page based on the values entered/selected. Here are some other Lightbox like references to look at:

GreyBox - The demo speaks for itself.

ThickBox - Similar to Lightbox but can display HTML pages as well as images.

Lightbox Effect Without Lightbox - from the folks at Wayfaring.

There are plenty of other variations out there as well, but this should be enough to get you started.