Coming soon: a new building block for connected data

[joost_mineur]

Hello to all readers,

I am not sure how this thread evaluated from “a new building block” to the maker-editor subject, but I do want to pitch in on this later part of this discussion.

For many use cases, there is one or a limited number of makers and many editors. When discussing/suggesting a differentiated subscription model I think we have to be really careful to not loose the great environment we have for building useful docs/apps without having to worry about excessive costs for having many users that don’t do anything but occasionally using the “app” to look things up or edit data (rather then editing the document).

The statement that is is not going to be sustainable to have a doc with 1 or just a couple of makers and hundreds of “editors” needs soms elaboration. Factually, there are a lot of great solutions that become unaffordable for many (smaller) businesses because of the licensing model.

Obviously, there are many user cases, but the following is probably very common:

1 (or a few) maker(s)
1 (or a few) editors, fine tuning text and layout on existing pages
10’s or 100’s of users (also called editors in Coda) with login access to the document, checking schedules, looking up and/or adding data and use the document as an app, without the authorization to change the structure of the doc, layouts, tables or formula’s.

The current subscription model works really good: you pay a very reasonable amount for makers, you pay the same for the editors if you want to grant them access as described above. That works fine, although I understand the discussion about two different rates (but as far as I am concerned, not necessary).
But for the group that I call users, a paid subscription model would kill the concept of building apps in Coda, because the tab will run up in a hurry.

So, please think about what you (we) are asking for.

When we get ‘unlimited’ databases and/or really large documents, I can understand that there is going to be a point where some extra money is needed, but a more expensive maker subscription should suffice (or would be preferable).

Looking at the past, development software got more expensive to buy over the years (like Delphi), but you could use to build programs for your own or third party use, without any price difference. Eventually, most development software has become a subscription model, but is charged based on the number of developers (like Coda makers), not based on the number of users of the finished product. When building database type applications, you might have to pay extra based on the number of users, but there are plenty of alternative databases without a user count.

I hope Coda will stick with ‘maker’ subscriptions and, if necessary, ads a reasonable usage fee for really large docs or databases, but allow for ‘unlimited’ free ‘users’ like we enjoy today.

The above is largely inspired by my use-cases, but I a sure I am not alone.

Greetings,
Joost

[Brock_Eckles]

Me too… it’s great! Thx!

[Stefan_Stoyanov]

Coda now has new competitors in no-code development of actual native apps and web platforms. And if it gets too expensive, it’s SOM (market) would, not quickly, but instantly shrink to less attractive size (especially to investors)

[Piet_Strydom]

Back to the OP….

I have started using the tabbed views, and it makes the user experience much, much simpler.

Thanks to the Codans, this is great.

P

[Stefan_Stoyanov]

Seems promising, indeed. Not sure about the performance and resource usage, though - still evaluating.

And, I finally built something like a menu in Coda

[Cristian_Nichifor]

Still, we cannot reference a specific layout to a tabbed view inside a button.

[Diego_Delfino]

I see it, or am I missing something?

[Dima_Petrov1]

I’ve already had a chance to try out the tabs, and I have to say they’re very convenient. I was skeptical at first, but everything works very well and is easy to set up. I even got the impression that the system as a whole has started running faster. I like that each tab can be configured with everything I need — sorting, filters, grouping, and so on. It really works well

[Pablo_DV]

I like this new feature, it could reduce the amount of pages in many of my docs and improve the user experience. But the main issue for me is that tabbed views don’t seem to be full-fledged views. That means:

• You can’t reference them on CFL
• You can’t select different detailed view layouts per tabbed view. If you change it for one it changes for all.

Without these I feel the tab views would not be very useful, but on the other hand I think this is not so easy to solve, because it would make the object model not so intuitive: Once you add a tab to a view, the view would become a container of views, rather than a typical view.

Considering a DB Tasks table with a Tasks view with Open and Closed tabs, the tabs could be referred to in CFL using the dot notation: Tabs.Open and Tabs.Closed, but then Tabs by itself would be empty, which doesn’t feel intuitive. Or it could return the data from the first tab, which feels arbitrary.

TL;DR: Great potential, but not fully baked yet.

Edit: I somehow didn’t realize that tabbed views can indeed be referenced from CFL. And the container view is not referenceable at all once a tabbed view has been added, which I find a good solution.

[Chris_Williams1]

I have similar feedback. We make frequent use of the CSV export action via button since my team regularly exports lists for email campaigns. The tabbed views are genuinely helpful for them because they simplify access to the right filters. However, since I can’t reference them in CFL we’re maintaining a separate set of views for now.

[Chris_Williams1]

Nevermind, I’m wrong @Pablo_DV.

I can see the tabs in the formula editor. I’m not sure how I missed this earlier, but I stand corrected. The tabs are available using CFL.

[Nad]

I’m excited about this feature and immediately took it for a test drive when I got access to the beta.

The good:

• The views are independent: you can configure each to your liking and access each independently in CFL.
• Can be a huge help when bulk editing very wide tables, by allowing you to split them into thematic “sections” that group relevant columns together.

The bad:

• Forces your hand on naming. Any serious maker will have a naming convention for tables and views that help them find things in formulas, and a different name that they present to the user. In regular views this is easily achievable by hiding the real, formula-friendly name (say _ProductsEdit), and slapping a canvas header just above the view with the user-facing, localized name (for us that would be 产品编辑 —something that would be horrible to use in formulas). But in the current iteration of tabbed views, you only control the group’s name. The individual views are automatically named after the tab names. That’s never what we want. I want to name the tabs in a user-friendly way and name the underlying views in a sane way for use in formulas.

• Forces your hand on layouts. You can only have one layout that applies to all the views. Everywhere else in Coda we can have a different layout per view, and it should be the case here too.

• Auto-hiding tabs. Currently, if you have more than two tabs, some unclear logic sometimes decides to hide the remaining tabs behind the kebab menu. This is unintuitive—none of my users will ever think to click the kebab menu to find more tabs.

The sad:

This solution has all the good intentions, but it’s over-engineered and comes in a straitjacket. All we really needed is a Canvas Tabs Building Block, similar in spirit to Canvas Columns. Then let the maker insert whatever they damn well please in each tab—whether that’s just a view, a view with some headers and callouts on top, or even just some canvas controls. Let each person design for their specific use case as they know best. Job done, high-fives all around.

Of course, sunk cost fallacy will hit and no one wants to go back to the drawing board, so we’ll probably end up with this crippled version anyway.

[Stefan_Stoyanov]

Very often Codans seem to copy other tools instead of using the unique capabilities of their own creation. Very often l have the feeling that they don’t know their own creation very well. And, at the same time, they keep on building features without empathizing with their customers.

I am not saying tabs per-se are bad tabs; they are not. But the way they are build sort very little of the paint points. It’s a missed opportunity. (Or at least it looks so because we don’t know the roadmap - maybe this is just stage one of a bigger feature )

What we need is a menu of any sort that can be used as a separate block on canvas or detail view. Much more like app menu

[Pablo_DV]

@Nad

But in the current iteration of tabbed views, you only control the group’s name. The individual views are automatically named after the tab names.

That’s not ideal, but not a deal breaker for me. You can continue to give the view container a hidden technical name and then it’s easy enough to select the tabs from the suggestion box.

@Nad

Auto-hiding tabs. Currently, if you have more than two tabs, some unclear logic sometimes decides to hide the remaining tabs behind the kebab menu. This is unintuitive—none of my users will ever think to click the kebab menu to find more tabs.

I didn’t experience that. For me, as many tabs were visible as the width of my table allowed.

@Nad

All we really needed is a Canvas Tabs Building Block, similar in spirit to Canvas Columns.

That’s a great idea, it would be order of magnitudes more flexible and useful.

I think the current implementation could still have its place (if they fix the different layouts per tab issue) since it would be a bit cleaner UI-wise and simpler to set up, but if I had to choose only 1, your idea is way more powerful.

[Astha_Parmar]

So far, loving the tabbed view.

I am often working internally with teams and trying to get them to use Coda for process automation, productivity, and collaboration. And typically, the learning curve is too steep to get adoption going. Some of the recent changes Coda has made seem to be addressing the ‘intuitive for the non-maker’ piece of the puzzle.

So while I would love the canvas tab as a maker, I also love the ease of duplicating different contexts of the same data: Done v. In-Progress Tasks, 2025 v. 2026 dataset, Chart v. Table view.

Some things I wish could be different:

• To me, personally, it would be more intuitive if canvas filters applied to all the tabs instead of just the base tab. And then, the filter bar applies to the tab, which is perfect.
• Because tables need more space than charts – I now wish I had the ability to specify the size of the chart to make it go with the tabbed view.

On the discussion on pricing, I exclusively work in the nonprofit space. I have used Coda to truly save folks doing last-mile work hundreds of hours. Thank you, Codans And the nonprofits I work with, would a would not be able to afford the editor pricing option. Adding a plus one to the Maker + Seats idea…with the hope that the non-profit pricing comes with grace on that.

[Stefan_Stoyanov]

Does anyone have issues with switching tabs on mobile in Coda app?

[Reinout_Decock]

@Shelley_Garg Can you confirm you cannot use the newly tabbed views as source for a cross doc? Is it something that is on your road map?

I see the newly tabbed views as a possible selection, but it only allows me to select the first one (documenten > Inbox). If i select another view (Documenten > To pay) it won’t select it.

[Shelley_Garg]

On performance: resource usage for tabbed views should be about the same as using standalone views. Let me know if you’re seeing something unexpected.

[Shelley_Garg]

Good catch - this was a bug, and it’s been fixed! You can now set different layouts per tab, and when you reference a specific tab in a button like add or open row, it will automatically use that tab’s layout.

[Shelley_Garg]

Good news on the layouts—that was a bug and it’s been fixed. You can now set different layouts per tab, so each tab can have its own configuration.

On CFL references: noted that this wasn’t immediately obvious. We will work on making it more discoverable that tabs can be referenced in formulas.

Appreciate the detailed feedback!