We are excited to announce that as of today, the Interface Designer beta is open to everyone, which means you will now be able to create interfaces right from your bases, no code required.
What is Interface Designer exactly? Interface Designer lets you build visual and interactive interfaces using your base’s underlying data. By creating custom interfaces for your stakeholders, you can isolate the information that’s critical to them and none of the other details. This makes it tremendously easy to understand the status of a project and what’s required from whom. Jump right in or keep reading for a comprehensive round-up of everything you’ll need to get started, plus information about a few other features you’ll start seeing after today
Before we go into more details, make sure to mark your calendars for the next Airtable Community AMA on December 1, with Product Manager JB Bakst, where we’ll dive into all things Interface Designer.
Common Questions
What are some of the common use cases for interfaces?
Interfaces can be used for just about anything, but some of the popular use cases we’ve seen so far include dashboards to view aggregated information & metrics, summaries to view key information about a project, record summaries for research insights, and record triage for things like customer feedback or campaign asset reviews - we can’t wait to see what you come up with next!
What permissions are required to create an interface?
Creator and owner permissions on the base you’d like to build an interface for.
If I share an Interface with another individual or team, can they see the underlying data?
For now, interface access requires you to have base access. So yes, anyone you share an interface with will have access to the underlying data.
When should I use Interface Designer vs. Page Designer (or another feature?)
Some key distinctions that Interface Designer offers:
Dynamic & interactive
Can share data from multiple tables within a base side by side
Easy to onboard collaborators without needed to teach them how to use the Base or fear that they may edit the wrong thing
Filter records based on the collaborator viewing the interface
Page Designer is ideal for instances where you need to provide a non-editable view of static information during a specific moment in time. One example is if you need to deliver a presentation or want to create a PDF.
Resources to help you get the most out of Interface Designer:
Want more great news? We didn’t stop there, take a look at all the other fun features you can expect to see starting today as well.
Enhanced features for admins:
You’ll notice a slick redesign of the Admin Panel, created to be more user-friendly. Next, we’ve added significant new security controls—like Audit Log APIs and workspace share restrictions. And finally, we’ve improved base performance across the board, making your largest bases more responsive than ever before.
Additional power for your workflows:
And finally, we’re proud to share new integrations to help you bring more data into Airtable, and improvements to automations.
We’ve updated our automations interface to make it even more intuitive, with easy-to-read modals. Now it’s easier to set up a new automation with a fancy full-screen mode, and a handy guide that will walk you through every step of the process. We’re also starting to beta test conditional logic, which allows users to trigger automations only when certain conditions are met.
And last but not least, we’re adding new integrations for external source syncs from our partners at Zendesk, Github issues, and Google Drive—available to all customers on Enterprise plans.
Page 5 / 8
The fact that Airtable users want external people to have limited edit access to their bases (and no additional access) without paying $240/year per external editor is clear.
I may be making a lot of assumptions here, but Airtable had to decide on a method of building that external user interface first before it could grant limited access to anyone. And the ability to have a custom user interface is beneficial to users who are collaborators already. So it makes sense for Airtable to create that user interface builder and make it available to existing users as soon as the interface builder is ready, even if the other work for sharing the interface outside the organization isn’t ready yet.
Interfaces is still in beta and is barely a week old. It has a a few quirks and doesn’t yet have many of the features we want. However, I’m glad that Airtable decided to make Interfaces available now, rather than waiting until those additional features are built out.
Airtable has shown that they can periodically release incremental feature enhancements. I’m looking forward to seeing those future feature releases.
Sure. But still, it would be nice to just get some insights in their plans. Because a recent interview with Aron doesn’t indicate that they are thinking about making Interface accessible for external user in the near future, as they are aiming for bigger companies with more challenging internal processes as clients.
So please don’t blame some of us for being curious about the future in stead of always be taking by suprise. Is it something they want to do someday, somehow, or is it at the absolute bottom of their backlog? Also useful to give our clients some perspective before they invest (even more) into Airtable.
But all trust in Airtable of course
Sure. But still, it would be nice to just get some insights in their plans. Because a recent interview with Aron doesn’t indicate that they are thinking about making Interface accessible for external user in the near future, as they are aiming for bigger companies with more challenging internal processes as clients.
So please don’t blame some of us for being curious about the future in stead of always be taking by suprise. Is it something they want to do someday, somehow, or is it at the absolute bottom of their backlog? Also useful to give our clients some perspective before they invest (even more) into Airtable.
But all trust in Airtable of course
Absolutely! I completely agree that it is always nice to have more information from Airtable regarding their roadmap.
Any Airtable staff members who have been reading these forums for a while already knows that users (especially consultants) want to know more roadmap information. Airtable just hasn’t chosen to publicly share what they plan to do about this fact.
My post was mostly a reaction to the many posts where people were complaining about Interfaces not being public facing. I wanted to recognize that (1) Interfaces is a great feature, even without public-facing support and (2) I have a lot of hope for public-facing interfaces eventually.
I think that part of the disappointment over interfaces not being public-facing is that Airtable underestimated the desire for public-facing interfaces. People built interfaces assuming that they could be publicly shared, because people really wanted public-facing interfaces. Then they were disappointed that the interfaces could not be public-facing.
If Airtable had announced Interfaces with verbiage that made it clear up-front that interfaces were currently only for base collaborators, there would have been less disappointment. If Airtable had shown interfaces to consultants pre-general availability and discussed setting release expectations regarding what interfaces could and couldn’t do, this mismatch in expectations might have been avoided.
Absolutely! I completely agree that it is always nice to have more information from Airtable regarding their roadmap.
Any Airtable staff members who have been reading these forums for a while already knows that users (especially consultants) want to know more roadmap information. Airtable just hasn’t chosen to publicly share what they plan to do about this fact.
My post was mostly a reaction to the many posts where people were complaining about Interfaces not being public facing. I wanted to recognize that (1) Interfaces is a great feature, even without public-facing support and (2) I have a lot of hope for public-facing interfaces eventually.
I think that part of the disappointment over interfaces not being public-facing is that Airtable underestimated the desire for public-facing interfaces. People built interfaces assuming that they could be publicly shared, because people really wanted public-facing interfaces. Then they were disappointed that the interfaces could not be public-facing.
If Airtable had announced Interfaces with verbiage that made it clear up-front that interfaces were currently only for base collaborators, there would have been less disappointment. If Airtable had shown interfaces to consultants pre-general availability and discussed setting release expectations regarding what interfaces could and couldn’t do, this mismatch in expectations might have been avoided.
We’re 100% on the same page here. Thanks for your reaction
They really, really did :exploding_head:
Absolutely! I completely agree that it is always nice to have more information from Airtable regarding their roadmap.
Any Airtable staff members who have been reading these forums for a while already knows that users (especially consultants) want to know more roadmap information. Airtable just hasn’t chosen to publicly share what they plan to do about this fact.
My post was mostly a reaction to the many posts where people were complaining about Interfaces not being public facing. I wanted to recognize that (1) Interfaces is a great feature, even without public-facing support and (2) I have a lot of hope for public-facing interfaces eventually.
I think that part of the disappointment over interfaces not being public-facing is that Airtable underestimated the desire for public-facing interfaces. People built interfaces assuming that they could be publicly shared, because people really wanted public-facing interfaces. Then they were disappointed that the interfaces could not be public-facing.
If Airtable had announced Interfaces with verbiage that made it clear up-front that interfaces were currently only for base collaborators, there would have been less disappointment. If Airtable had shown interfaces to consultants pre-general availability and discussed setting release expectations regarding what interfaces could and couldn’t do, this mismatch in expectations might have been avoided.
A finer point might be to say that Airtable has never recognized the symbiotic relationship between those who produce information and those who consume information. Even where this segmentation is known, many vendors fail to realize that it comes in three sub-flavours:
Few producers; many consumers.
Many producers; few consumers.
Many producers; many consumers.
Each of these flavours creates architectural and pricing complexities the likes of which are rarely considered.
Peeling this back a little further and you have formal users and casual users. A casual user might be a single worker who updates a single record once a week.
In the extreme, imagine a single no-code/low-code developer created a system that produces a unique data set that millions of people could benefit from. Another extreme is a scenario where hundreds of enterprise workers jointly produce information that is ideally suited for one person - the CEO.
Setting aside the inability of Airtable to accommodate mass demand, there is no pricing model that supports either of these success stories discretely. And while these are extreme scenarios, they are intended only to make a point -
Every market of producers has a market of consumers.
If your product addresses the needs of a specific producer but fails to consider the requirements of the producer’s consumers, traction will be fleeting.
A finer point might be to say that Airtable has never recognized the symbiotic relationship between those who produce information and those who consume information. Even where this segmentation is known, many vendors fail to realize that it comes in three sub-flavours:
Few producers; many consumers.
Many producers; few consumers.
Many producers; many consumers.
Each of these flavours creates architectural and pricing complexities the likes of which are rarely considered.
Peeling this back a little further and you have formal users and casual users. A casual user might be a single worker who updates a single record once a week.
In the extreme, imagine a single no-code/low-code developer created a system that produces a unique data set that millions of people could benefit from. Another extreme is a scenario where hundreds of enterprise workers jointly produce information that is ideally suited for one person - the CEO.
Setting aside the inability of Airtable to accommodate mass demand, there is no pricing model that supports either of these success stories discretely. And while these are extreme scenarios, they are intended only to make a point -
Every market of producers has a market of consumers.
If your product addresses the needs of a specific producer but fails to consider the requirements of the producer’s consumers, traction will be fleeting.
Good points.
I see three main overlapping roles:
System Developers
Data Producers
Data Consumers
In general there tends to be fewer developers than producers/consumers. In some business models, developers have to pay more than producers/consumers. (e.g. you pay to develop the system, but the system is free for your users). In other business models developers pay less (e.g. developer for free, pay only when you publish or pay per end user).
If the goal is to democratize software creation, it makes sense to have the same bill rate for developers as producers/consumers. It lowers the bar for someone to become a developer. Thus, while some may grumble that editors have to pay the same as creators for less functionality, I don’t see this as problem because I favor lowering the bar to becoming a developer.
When it comes to data producers, I see four really broad sub-categories:
regular users who need consistent, full access
limited users who need only partial and/or intermittent access
form users who submit data, but do not read any data
non-human data producers, such as api users
People accept that they must pay for regular users who need consistent, full access. However, people don’t like paying the same amount for limited users who need only partial or intermittent access. It is these limited users that Airtable’s pricing model does not currently address.
The intermittent access issue is sometimes addressed using “floating licenses” or “concurrent licenses”. One challenge with this method is how do you count one Airtable collaborator who is logged in and using multiple instances of Airtable at the same time.
The partial access issue has much tricker technological issues. Airtable’s original architecture was designed to make sharing information easy, and changing it to securely limit read access would probably be very complex. Preventing read access is actually much more difficult than just hiding a table in the user interface. I think Airtable decided that in order to securely “hide” selected data from users, a new interface was needed. (Think about it–all those third party portal systems that provided limited access to Airtable data all have their own user interfaces.) I think that Airtable’s “Interfaces” is a necessary step towards native support for limited read access.
The pricing model change to address these partial-access users also cannot be rolled out until after the method for providing partial access exists. I suspect that Airtable has already been investigating pricing model changes, but has not announced any because there would be no point when the underlying architecture is not ready.
The form users use-case is addressed with Airtable’s forms. These forms are not as robust as people would like, but AIrtable is not in the business of generating complex forms. Of course it would be nice if there were more options for customizing Airtable forms, but where does it end? There are many companies that do provide complex form services.
I also find it interesting that non-human data producers/consumers (REST API usage) do not incur additional fees from Airtable, but other businesses charges additional fees for API access.
Consumers. Airtable is actually really generous when it comes to people who are only consumers of data. Read-only collaborators are free across the board. Sharing filtered views is free. API access to publish using a 3rd party service is free.
Of course, people want even more sharing (e.g. sharing dashboards), but that involves read-only security. As before, I think that interfaces is a step towards read-only security–and there is even a “dashboard” layout.
Good points.
I see three main overlapping roles:
System Developers
Data Producers
Data Consumers
In general there tends to be fewer developers than producers/consumers. In some business models, developers have to pay more than producers/consumers. (e.g. you pay to develop the system, but the system is free for your users). In other business models developers pay less (e.g. developer for free, pay only when you publish or pay per end user).
If the goal is to democratize software creation, it makes sense to have the same bill rate for developers as producers/consumers. It lowers the bar for someone to become a developer. Thus, while some may grumble that editors have to pay the same as creators for less functionality, I don’t see this as problem because I favor lowering the bar to becoming a developer.
When it comes to data producers, I see four really broad sub-categories:
regular users who need consistent, full access
limited users who need only partial and/or intermittent access
form users who submit data, but do not read any data
non-human data producers, such as api users
People accept that they must pay for regular users who need consistent, full access. However, people don’t like paying the same amount for limited users who need only partial or intermittent access. It is these limited users that Airtable’s pricing model does not currently address.
The intermittent access issue is sometimes addressed using “floating licenses” or “concurrent licenses”. One challenge with this method is how do you count one Airtable collaborator who is logged in and using multiple instances of Airtable at the same time.
The partial access issue has much tricker technological issues. Airtable’s original architecture was designed to make sharing information easy, and changing it to securely limit read access would probably be very complex. Preventing read access is actually much more difficult than just hiding a table in the user interface. I think Airtable decided that in order to securely “hide” selected data from users, a new interface was needed. (Think about it–all those third party portal systems that provided limited access to Airtable data all have their own user interfaces.) I think that Airtable’s “Interfaces” is a necessary step towards native support for limited read access.
The pricing model change to address these partial-access users also cannot be rolled out until after the method for providing partial access exists. I suspect that Airtable has already been investigating pricing model changes, but has not announced any because there would be no point when the underlying architecture is not ready.
The form users use-case is addressed with Airtable’s forms. These forms are not as robust as people would like, but AIrtable is not in the business of generating complex forms. Of course it would be nice if there were more options for customizing Airtable forms, but where does it end? There are many companies that do provide complex form services.
I also find it interesting that non-human data producers/consumers (REST API usage) do not incur additional fees from Airtable, but other businesses charges additional fees for API access.
Consumers. Airtable is actually really generous when it comes to people who are only consumers of data. Read-only collaborators are free across the board. Sharing filtered views is free. API access to publish using a 3rd party service is free.
Of course, people want even more sharing (e.g. sharing dashboards), but that involves read-only security. As before, I think that interfaces is a step towards read-only security–and there is even a “dashboard” layout.
Great assessment and I like the granularity you added to tease out the developers who I typically lump into the producer category because I’m lazy.
This is a complex topic.
If you charge for API access, you are fundamentally placing a tax on innovation. Most vendors try to avoid disincentives that lead to lower adoption or suppress broader uses. But, even so, Airtable has created an API architecture (unlike other vendors) where a single API “user” could exhibit the load of hundreds of actual users - indeed, a gaggle of really aggressive users. This load - however light or well-designed it may be - is confined to the Airtable account; it is not a common resource with seemingly endless capacity. Unlike almost all other APIs, this API can negatively influence the performance that actual users experience.
Great assessment and I like the granularity you added to tease out the developers who I typically lump into the producer category because I’m lazy.
This is a complex topic.
If you charge for API access, you are fundamentally placing a tax on innovation. Most vendors try to avoid disincentives that lead to lower adoption or suppress broader uses. But, even so, Airtable has created an API architecture (unlike other vendors) where a single API “user” could exhibit the load of hundreds of actual users - indeed, a gaggle of really aggressive users. This load - however light or well-designed it may be - is confined to the Airtable account; it is not a common resource with seemingly endless capacity. Unlike almost all other APIs, this API can negatively influence the performance that actual users experience.
I like the implicit metaphor here…
Is there a plan to include the ability to drop apps into the interface, such as pivot tables, or maps?
Are interfaces only accessible on Desktop?
This is perfect for my use case of sharing job info + daily scheduling with service technicians in the field, but they need to be able to access on mobile or tablet.
Are interfaces only accessible on Desktop?
This is perfect for my use case of sharing job info + daily scheduling with service technicians in the field, but they need to be able to access on mobile or tablet.
At the moment, yes. Just as many users hope for public-facing interfaces to be added, I’m sure that adding interfaces to mobile apps is another big wish. I’m confident that it’ll happen, but the timeline is (as always) unknown.
I’m working with a man who’s is a creative genius but also is ADHD and dyslexic. The regular Airtable UI is not usable for him and is a bit tedious for me. I was starting to look at 3rd parties to front end our data. With Interfaces, Airtable has EXACTLY what we needed. I’ve been able to create highly visual and targeted update forms. Being able to and rich text and especially links was particularly helpful. These new UIs are really amazing. Currently we are using the Record View with filters to progress our workflows.
Btw guys, is there a way to connect to multiple filter elements?
It’s an interesting start. My top two desires as of now are:
Cross-Base Interface, a true dashboard. (I know, I know this will be a sharing nightmare)
Embeddable Interfaces - allow sharing control like you do other shared views
Btw guys, is there a way to connect to multiple filter elements?
You can use 1 filter for multiple “elements” if that’s what you mean?
You can use 1 filter for multiple “elements” if that’s what you mean?
I want to connect to two filter elements but it is unable to do so.
I tried another way, to have multiple condition in a single filter element, there is only “and” no “OR”
I wanted to love this (I realize it’s a beta release), and it’s almost what I’m looking for but…
It seems like in order to use it with others who need even a tiny bit of editing access, you’d have to be on a free plan. Otherwise I’m expected to pay $240/year for someone to interact with a handful of records. Not feasible when working with multiple collaborators. So I can’t have the power and features of Pro and also give people minimal editing access to Airtable records.
Given that someone has to be a collaborator, they can then access the entire base and all of its tables/views. And since they need editing rights in order to edit in interfaces, they can then do the same in the base itself. Far from ideal.
As far as I can tell (maybe I’m wrong), collaborators can access all interfaces added to a base, as opposed to just the ones I’d want them to see. So, making myself a personal interface as an admin isn’t possible, since anyone else with access will see all the interfaces. Is this really the case?
It’s a great start but given that tools like Softr allow unlimited applications and up to 10,000 members (with granular access/permissions) for $79/month this doesn’t quite cut it when trying to securely give people a clean view of data (and ONLY that view) with the ability to edit/add a bit of that data.
In a perfect world:
Let the admin/owner be on a paid plan and not have to also pay for interface collaborators (or at least not full price)
Access can be granted to just interfaces, and also not to every interface in a base (this can require an Airtable login if need be)
Collaborators can edit existing records (maybe even place reasonable limits to avoid abuse and people working around upgrading accounts)…maybe they can be assigned to X number of records, and only modify those records.
(Separate from just interfaces) Don’t make every role cost the same on paid bases, such that a commenter costs the same as someone with total access. Maybe this means that someone on a paid plan would be willing to pay $2 each for 10 commenters. Or $5 each for 20 edit-only-assigned-records collaborators.
I love Airtable and find any excuse to use it, but it’s difficult trying to work with others who need just a small glimpse into data that is relevant to them, and being able to make slight modifications, occasionally. Hopefully the interface designer can be a step in that direction
I agree 100% with this. +1
Its not possible to pay 240 USD per year per each client or worker which will only modify a couple of records.
@Jordan_Scott1 - Interface designer is amazing by itself. Quick question though, can we embed interface designer into html?
@Jordan_Scott1 - Interface designer is amazing by itself. Quick question though, can we embed interface designer into html?
@Jyo_D I’m so thrilled to hear that you’re loving Interface Designer! Right now, you are not able to embed interfaces, but this is an awesome suggestion that I’ll make sure to pass along to our product team
@Jyo_D I’m so thrilled to hear that you’re loving Interface Designer! Right now, you are not able to embed interfaces, but this is an awesome suggestion that I’ll make sure to pass along to our product team
How about an html element in ID itself?
Exciting times - what would be truly beautiful for the future is if there was a way to share the interface alone without access to the underlying data and if we could create 1 interface bringing together information from multiple bases - now that would be living the dream
Synced Tables can achieve this for now FYI
Hi,
Really simple advice, when I try to change the columns width of a grill, its really difficult to change the ones that are on the right edge, because every time I press there the “properties box” pops up and cover the column, so I cannot change
The way around that I found, is move the column to the left, change the columns width, and then move back the column to the desired location.
I am loving the interface designer, it really has helped me to get the information how I want, when I need it.
Just checking to see if there’s any news on Interface Designer new features and enhancements, as there’s been a lot of community feedback, and it would be great to hear about Airtable’s progress and consideration of these features.
Edit: Feature Request - As previously mentioned buttons, but with the ability to “copy to clipboard” so that when the user clicks a button then text from a record field lands in their clipboard for future pasting.
Also useful to give our clients some perspective before they invest (even more) into Airtable.
