Asynchronous Record Finding in Web Forms

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:

1. 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?

2. You can do a pop-up form. 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 among their other windows and get confused, or the window could get blocked by their pop-up blocker.

3. 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 suppress 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?