Building a Grid Interface for Batch Actions

Our FileMaker client is an advertising agency, responsible for purchasing ad space each month at various newspapers, tv stations, radio stations, etc. in several market geographies. They often prepare a set of media orders in advance, working with each client to create the right mix, and then need to send out a collection of orders once ready.

Often a media order for a particular station or paper will be quite similar from month to month. This makes it convenient to start a new order by duplicating a previous order.

In some cases, rather than creating and placing the media order for a given station or paper each month, they will negotiate a longer period of media at once. These “annuals” might be for a full set of 12 orders or for a few months’ worth at a time.

The Problem: Single-Order Tools Make Batch Tasks Time-Consuming

The FileMaker application had several tools already for creating, duplicating, and sending orders, one at a time. There was also a batch-sending tool for a given market/month, to send that whole collection of orders out at once.

But with the situations created by “annual” orders, these tools were insufficient. To create a set of 12 orders, the duplicate button would need to be clicked 12 times, with a different destination month and year chosen each time. Our client sought help in building their annuals out more efficiently.

Design/Foundation

We needed a way to let users select multiple stations or papers for which to duplicate orders and to duplicate them into multiple months in one step.

It would have been too much information to manage if we let users choose from the whole set of Orders in the whole system. The client arranges all their media ordering work into groups by month for each client or market, so we agreed to have our starting point be one of those groupings, called “Media Plans.” The user needed to choose from that set of orders and then indicate which destination month(s) were wanted for the new copies of those orders.

We limited that set of months as well, to the ones within a single calendar year. That allowed us to work with an explicit set of months, no more than 12.

The Media Plan grouping was already presented on screen as a grid, with the order labels down the left side, and various attributes in columns (dollar totals, status indicators, tools, etc.). With that already familiar to users and the fact of a fixed, known set of months that could become column headings, we could present a different grid as the interface for our batch order-duplicator tool.

Implementation

We realized early in development that we had quite a bit of logic running during our single-Order duplication. This made sure we trapped any potentially unsafe circumstance and confirming the user’s preferred action.

In particular, if the destination month already had an order, we needed to see if the user wanted to replace that order with the new copy or cancel their duplication request.

If the selection grid was a simple, dumb instruction collector, we would have to do all those checks once the batch duplication script had started running to process the user’s selections. That could have resulted in a large set of potential conflicts to be resolved, all of which would have to be presented to the user for resolution. That seemed a painful prospect, confusing at best!

Therefore we pushed our error trapping logic into the selection grid itself. If we triggered our checks at each checkbox selection, we had only one case to consider, and on which to report to the user. That made it easier for the user to understand the problem presented and to decide on the correct action. Each checkbox became a button, triggering the validation handling script, and returning with the checkbox either set or remaining un-set.

At that point, we could be sure that any selected checkbox represented a valid order duplication action. We handed off the set of selected instructions to a different script, which needed to do all the copying and adjusting needed to build those new orders.

This order-building work was fairly time-consuming, and the users preferred not to wait for this to finish with their FileMaker locked up, preventing other work in the meantime. Because we knew the copying could happen without the need for user interaction, aside from reporting success or errors at the end of processing, we moved our order copying script to run on the server. This server-side script ran faster and left the user free to do other work while waiting for their new copies. The script would email the user to provide the success or error messages.

Results: Success!

The batch duplicator was a big hit. Users took to it quickly, and it saved them significant time in setting up new orders for upcoming timeframes.

After a few weeks, they came up with another time-consuming activity they hoped to shorten with a batching tool: sending out the orders.

With a bunch of orders made and ready to go, across multiple months’ Media Plans, they needed a way to send all those orders off to the stations and papers easily. We had a batch-sender that would send all pending orders in a single Media Plan, but that wasn’t fully safe to use. They might have other orders not ready to send when they want the annuals to go out, which left them having to go to every single order individually, clicking Send on each one. That could be dozens of orders at a time, and if they were in the thick of annuals, it could take hours to send things out.

Batching Orders 2: Electric Boogaloo

Sending out a big batch of orders posed many of the same constraints as the original order-duplication request:

• Need to constrain the set of selectable options to a manageable set
• Need to do significant validation work before performing the action
• User doesn’t want to wait for success with their machine locked up

We turned to our trusty grid UI and figured out how to re-work it to support this second task.

We kept the structure of order labels from a given Media Plan as rows but expanded the set to include ALL orders for the given market in ANY month of the same calendar year (whether or not that order was in the Plan on which the user started work).

We kept the structure of columns for each month in a single calendar year.

With rows and columns defined, we could know if an order existed for that station or paper and month. If not, we kept that grid cell empty. If the order was there, we could know things about it, and indicate some of them with coloration.

For example, if the order was for a month in the past, we “grayed out” the cell – you can’t send an order out for a time period that already happened. If the order was already sent out, we’d show a blue cell, and so on, for a few other important status indicators.

We also kept the notion of doing all our validation when each grid cell is clicked for selection. We run all our validation logic and report out the reason in a dialog if something cannot be selected. We also collect a few supporting details if something is being selected to send, but due to a revision rather than for the first time. Again, we end up with a set of selections that are known to be 100% ready for processing by the time the big green go button gets clicked to start the batch.

The batch process generates PDFs for each order, and bundles these up into attachments on email messages created in the user’s Outlook client. The PDFs get made server-side for speed, but the messages have to be done client-side.

The creation of those messages in the Outlook client is all the success messaging needed, so no emailed success/error report was needed here.

Got Batches?

We hope the riveting tale of our two batch-processing grid interfaces has given you inspiration. It won’t be the answer for every batch task, but if a grid layout is feasible, it might be just the thing. If you need help, feel free to reach out to us.