Interactive Expo Floorplans Built in Flash

Exhibitor registration for a trade expo has a resource allocation problem at its core. There are N booths on a floor and M exhibitors who want them, with uneven demand. Booths near the entrance, at high-traffic intersections, or adjacent to anchor exhibitors are contested. Others fill as an afterthought. The ranked-preference model — submit your first, second, and third choice — is a reasonable mechanism for handling this: exhibitors state their preferences, organizers work through submissions, and booths are assigned by priority.

The weakness was in what exhibitors knew when they submitted. The information package was a static printed image of the floor layout with numbered booths. No availability data. No indication of which booths were already claimed. The image showed the layout as of print time, which could be weeks before the registration window opened. An exhibitor who targeted booth 47 had no way to know it was already gone.

This produced a predictable outcome: a significant proportion of first-choice submissions were for already-claimed booths. Exhibitors who lost their first choice frequently ended up with their third or worse, because their second choice was often just as contested and equally blind. Staff spent the back half of every registration window doing conflict resolution — matching submission timestamps against allocation state, notifying exhibitors of conflicts, collecting alternative preferences. It was manual, time-consuming, and entirely downstream of an information problem in the interface.

The initial instinct for this class of problem is to add an availability indicator somewhere adjacent to the existing workflow — a lookup form, a list of taken booth numbers, a notation on the printed image. None of those address the underlying gap, which is that exhibitors need availability information in the same context where they're making selection decisions. An exhibitor mentally tracking a list of available numbers while looking at a floor image and typing into a form field is doing cognitive work the interface should be doing for them.

Making the floorplan interactive meant treating it as a data layer rather than an image. Each booth needed an identity: a stable ID, a shape on the floor, an availability status, and an occupant reference when claimed. The visual rendering would bind to that data. Color, label, and interactivity would all derive from the booth's current state. The map had to become a live view of the allocation, not a static reference.

This is a recognizable pattern in modern terms — a view layer driven by a data model with asynchronously updated state. In the early 2000s the tooling to build this on the open web was limited, which made the next decision straightforward.

SVG was technically standardized by 2001 but browser support was thin outside of specialized viewers. Canvas didn't exist yet. JavaScript was capable but browser inconsistencies were significant enough that complex interaction layers were fragile at best. The practical options for interactive vector graphics in a browser in the early 2000s were narrow.

Flash offered exactly what the application needed: vector rendering that worked cross-browser via the plugin, reliable event handling on arbitrary shapes (hover and click on each booth's polygon, not just rectangular hit regions), and external data loading via XML at runtime. That last capability was what kept the application data-driven rather than hardcoded into the compiled SWF. Booth state came from the server; the Flash application was a renderer and interaction handler whose output changed as the underlying data changed.

ActionScript — Flash's scripting language, roughly JavaScript-adjacent in syntax and event model — was adequate for the task: event handlers on booth shapes, XML parsing, dynamic rendering state, a ranked-selection model. The tooling was primitive by any modern standard, and ActionScript 2's type system was looser than most server-side engineers preferred. These were real constraints. The alternative wasn't a better development experience; for this specific problem in this specific era, it was no viable solution at all.

Each booth was a MovieClip — Flash's composable display object — positioned to match the physical floor layout. Geometry was authored in the Flash IDE as a library of vector shapes. The runtime data that gave those shapes meaning — availability status, occupant company name, contact reference — was loaded from the server as XML at application startup and refreshed on a configurable interval. FileMaker Pro served as the backend database and published booth allocation records as XML directly, which Flash consumed at runtime.

Booth MovieClips and XML records joined on booth ID. This separation was deliberate: the Flash application was a generic renderer; the data it rendered was externally controlled. A new expo could load a different floor layout and a different booth inventory without touching a line of ActionScript. An exhibitor submitting a selection changed the server-side record; the next refresh cycle reflected it in the rendered state for every active session.

Visual state encoded availability directly. Available booths rendered in a neutral fill. Claimed booths rendered in a distinct color with the occupant's abbreviated company name either overlaid or surfaced on hover, depending on booth size. An exhibitor's own pending selections rendered in a third state — color-coded by priority slot, so their first, second, and third choices were visually distinct on the map at a glance.

The occupant visibility on claimed booths was a contained feature with a disproportionate effect on the quality of selection decisions. It wasn't just "is this booth taken" but "who's in this booth."

An exhibitor could see where direct competitors had already positioned. They could see where strategic partners or anchor exhibitors were clustered — useful context for deciding whether adjacency was an asset or a liability. They could see how much of their target area of the floor was still available before committing a first choice, rather than discovering the conflict after submission.

None of this was new information in the abstract. The expo organizer knew all of it at any moment during the registration window. But that information had never been in the hands of exhibitors while they were making selection decisions. Surfacing it in the selection interface changed how exhibitors engaged with the process: from picking numbers off a static reference to making spatial decisions with current data. The difference in the quality of submitted preferences was observable.

The ranked-choice submission model stayed intact. It was the right mechanism for managing contested booths, and changing it would have altered the allocation mechanics in ways orthogonal to the interface problem. First, second, and third choices remained the output; the difference was how exhibitors formed those choices.

Clicking a booth added it to the ranked preference list in a sidebar panel. A first click set it as the first choice, a second click on a different booth set the second, and so on. Clicking an already-selected booth removed it from the list. The sidebar showed the current ranked state with controls to reorder or clear. Submission sent the final ranked list to the server in exactly the same format as the previous text-entry form — the backend allocation logic was unchanged.

No number entry. No transcription step. No opportunity for a misread digit or a transposed character. The selection was made by clicking the booth the exhibitor wanted. Booth number was a backend concern that never surfaced to the exhibitor at all.

First-choice conflict rates dropped substantially. When exhibitors could see claimed booths before submitting, the proportion of first-choice requests for already-allocated booths fell considerably. Exhibitors whose first-choice booth was visibly claimed moved on to their second and third choices in the application itself, resolving what would have been a conflict cycle into a decided selection.

Staff time on post-registration conflict resolution decreased accordingly. The manual process of comparing submission timestamps, notifying exhibitors of conflicts, and collecting revised preferences — which had been a fixed cost of every registration window — shrank to a small fraction of its previous scope. Highly contested booths still generated competing claims when two exhibitors clicked within the same refresh interval, but the frequency dropped materially.

The longer-term signal was harder to quantify but consistent in exhibitor feedback: selections made with spatial context and live availability were more deliberate. Exhibitors were choosing booths that matched their actual positioning goals rather than hedging against not knowing what was available. The ranked-preference model worked better when the preferences it collected were informed ones.