-
Notifications
You must be signed in to change notification settings - Fork 0
Media Orders Airtable
The Media Orders Airtable is a complex beast with 15 or so different tables and hundreds of fields. The primary table is the Orders table, which has a record for each unique order that we process as part of our work. This is really the bread and butter of our unit: if someone wants to see something from BMA, it's a media order. It's akin to a circulation record at a traditional library. You'll feel comfortable in the Airtable the more that you use it, but this page includes some guiding information to get you started.
Interfaces are where the bulk of our work occurs. We have a staff interface, a lab interface, a licensing interface, and a support interface. Most of the work in the digitization unit happens in the lab interface. The interface is just a shiny, better-looking GUI layer that allows you to manipulate the data without having to wrangle the clunkier records that make up the back-end. We design the interfaces and can manipulate them to better serve our functions.
The data, or "back-end," of the Airtable can be thought of as a series of connected spreadsheets. It's a simple-to-create relational database, that, if you aren't as familiar with relational databases, can be thought of as spreadsheets where columns and rows can be moved around at will, but what is more important is what's in those fields. Records (or rows) can also relate to data in other spreadsheets within the same base, and that related data can be used to inform the content of fields, make calculations, and so on. The data does a lot of things for us that we would have to do manually otherwise.
The automations can be thought of as the operations that Airtable performs on the data...well...automatically. We use automations to send emails out to researchers, notify staff of specific types of orders, and lots of other little tasks. This also saves us a lot of time, and if you think you have a good idea for an automation, we can probably make it happen.
The best place to start is the Lab Interface, as that's where you'll be spending most of your time anyway. The structure of this interface is centered around the idea that our work is mostly differentiated based upon which station it's completed at. So, there's a film station, audio station, video station, inspection station, and so on. Typically, wherever you're sitting right now probably determines what station's work you can complete, and so that's where you can jump into the queue and do work. Some stations can be done almost anywhere, like digital, upload, and delivery, and are more defined by what part of the order they're taking care of. Each station is also differentiated by what fields are pertinent to that stage or type of work. So, we don't need to see the baking log or recommended bake hours if we're working on film, but we do for video. All stations, with the exception of inspection, also have a key function that will move an order to another station. For example, if I'm working in the video station and I've completed the transfer, I'll use the "Digitization Complete" button to move the order into the Trimming station and onto the next part of the process. The purpose of this stations structure is to allow you to focus on the work that you can do right now and not get overwhelmed by all orders that are currently in our queue.
The Staff Interface is designed for everyone not in the digitization unit. It allows other BMA staff to check on the status of orders, create records for contacts, or just see how busy the lab is generally. Of course, it can also be useful to staff in the digitization unit when we're doing some of those tasks that everyone else in the department is doing. If you need to put in an order for someone, this is probably the easiest and most straightforward place to do it.
Sometimes you will prefer to do certain tasks in the back-end, and that's perfectly fine. There are a significant number of shared views already created that will do a lot of things you might need. Views are just presets of different layouts, filters, and sorting applied to the same data. So if you change something in one view, you're changing the record itself, and it will be reflected in all the other views and interfaces. A specific view can just make it easier to find the information that you're looking for.