Making… and Breaking the Grid
The Design Behind Airtable’s New Calendar View
Airtable was built around the grid. It’s the most honest presentation of your data, exposing the structure and content in one elegant interface. It’s an efficient way to interact directly with your content, and thanks to the spreadsheet, it benefits from massive consumer familiarity.
But Airtable is not a spreadsheet. It’s a database. Where a spreadsheet is by definition a grid — an infinite plane of cells with no inherent structure — a database contains lists of items (records), with each item sharing the same set of field types. Airtable merely appropriates the grid as a fast and intuitive interface to its underlying database.
For the most part, the spreadsheet is blissfully unaware and agnostic to the layout of its content (you could throw your items in horizontally, vertically, or even diagonally if you really wanted), but the database knows that each record represents a real-world item or idea. This means that the database can, when suitable, represent those items in ways that depart from the grid metaphor.
For Airtable, we’ve chosen the calendar view as the first such departure. It’s not just useful for managing events: customer records might have last contacted or followup dates, livestock might have vaccination or birth dates, and projects might have check in and deadline dates. Indeed, dates are one of the most common dimensions of real-world information.
Not Just a Pretty View
While we could have just displayed your records on a calendar and called it a day (ahem), we wanted the calendar view to meet the high bar for usability and interaction quality we’d established with the grid view.
It’s tricky to design an experience that not only offers rich functionality, but feels smooth and effortless in the process. In our first prototype, clicking on an existing event (or clicking on an empty date to create a new one) would expand a full-screen detail view of the record.
This was the path of least resistance in terms of implementation, as it allowed us to reuse existing view components. Unfortunately, it ended up making this common interaction feel unnecessarily heavyweight, obscuring the context of the surrounding events. It also made errant clicks (whether from idle habit, or by accident) trigger an unexpectedly disruptive action.
Though existing design patterns should be challenged and weighed against first principles, they do carry weight. Leveraging existing user expectations is like getting a free pass to an effortless interaction. In this case, many dedicated calendar applications display a small bubble dialog upon the initial click. The full event details are exposed with a second click or a “more” button.
Our initial prototype included the monthly calendar above, but not the sidebar to the right. While that design made it easy enough to quickly rearrange records within a single month, you’d hit a wall when you wanted to “schedule” a record without an existing date value. Thus, we created the sidebar, allowing you to simply reach out, grab a record card, and drop it onto the calendar to set or change its date value. The sidebar also elegantly exposes other useful interactions — you can search for records by name, or easily filter the list to show only unscheduled or scheduled records.
Thinking With Your Hands
Our Love of Cards
Speaking of cards, I’d like to touch briefly (sorry, it’s a good day for bad puns) on the card metaphor and its importance to Airtable. If you’ve used our iOS or Android app, you’ll know that we lean heavily on cards as a tap-friendly alternative to a sea of tiny grid cells.
But our love of cards goes beyond a convenient mobile UI. They help to establish that critical difference between databases and spreadsheets — namely, that Airtable records represent distinct items. Cards are a visually immediate metaphor which surreptitiously teaches our users this concept.
Plus, for the calendar view in particular, they’re just plain fun to drag around. This tactile aspect further helps to make Airtable records feel much more tangible, which is important because they’re intended to represent human information — real world stuff, not just abstract gobs of “data”.
Calendars on Calendars
How We Use the Calendar View to Manage Feature Launches
One of the really cool things about working on Airtable is that we tend to improve our own team productivity with each new feature we release. This is where things get meta, because I’m going to tell you about how we used the calendar view to launch the calendar view.
When I was at Google, there was an internal tool called “LaunchCal” that was used to track upcoming launches. Each launch in LaunchCal had fields listing the owners from various departments, marketing collateral, and approval bits that needed to be flipped by various higher-ups. It was a great way to keep track of all the moving parts involved in a feature launch, and we’ve adopted a similar process at Airtable.
Like many apps in the world, the LaunchCal application was essentially just a simple view on top of a relational database — just the type of thing for which Airtable is excellently suited. The launch calendar we created in Airtable looks something like this:
With the new calendar view, we can easily see upcoming launches for the month, and effortlessly shift their timing as needed:
In addition to keeping everyone on the same page for our launch plans, we found it unexpectedly useful to keep different people on different pages. For the marketing team, the actual public feature release date matters most, because that’s when all marketing collateral needs to be ready. For engineering, on the other hand, the feature deployment date is more important, and occurs before the public launch date (we do this through rigorous use of feature flags).
Unlike traditional calendar apps, which have a hardcoded “schema” for calendar events (and a single, hardcoded date field), Airtable users can create as many date fields as they’d like for their records. In the case of our “Feature Launches” internal database, we’ve created separate fields to track the “launch date” and the “deploy date” of any given feature. Luckily, we designed our views in a similarly flexible way. So for any particular table, you can create as many different calendar views as you’d like, and each one can refer to any date field in the table.
As such, we have separate “launch” and “deploy” calendar views using their respective date fields, but any details added to a feature item from either view are synced across all views.
From Tool User to Tool Creator
Our new calendar view is just the first of many building blocks to come which enable individuals to create their own tools and workflows. Alan Kay, whose ideas from past and present are a great inspiration to us, has championed this cause for decades:
“Users must be able to tailor a system to their wants. Anything less would be as absurd as requiring essays to be formed out of paragraphs that have already been written.”
— Alan Kay
This idea of a tool creator, or software-as-lego-blocks, is desperately needed in a world where the uniqueness of individual needs will always exceed the capabilities of inflexible software. Here at Airtable, we’re devoted to giving people increasingly expressive ways to creatively build their own tools in software. We hope you’ll join us along the way.
Want to see calendar in action? Check out this editorial calendar or head on over to our support page to get all the nitty gritty details.
