Formula for "Back" on Modals

Suggestion Box
1

Hi all,

Often we use the Modal view for data entry.

Sometimes users need to go into a Modal view of a subtable to add new categories, etc. (especially for Pack tables).

Currently there’s a hacky work around to enable users to be returned to the primary Modal after completing an action in a “sub” Modal view.

However the “< Back” button on Modals enables you to move back to a previous Modal window, which is the desired functionality.

It would be great to have a formula that let’s us access this “< Back” functionality so we can call it after a user clicks a button.

1 Like
2

Great idea, I’d love Coda to even adopt this more in general though.

In game dev there’s a thing called “Putting it on the grid” (Random tiktok where I learned this gets the point across nicely)

We already have an amazing grid, being the Coda Formula Language.
I don’t understand why we have so many things external to this grid.

So the current back button then like you’re talking about could just be there by default, and be editable like any other column in a layout. And then the actual action it uses would be available anywhere, like any formula.

Here’s a quick list that I personally believe also should be on the grid:

  • Comments
  • Users currently in doc
  • Columns
  • Notifications
  • Automations
5 Likes
3

this is a game changing list.

I turn off comments on all Detail views because it’s not actually data in the table, but it’s a great UX I’d love to use.

Users currently in doc would be a winner for Standup - everyone’s gotta get into the doc before the timer loads, etc.

Columns - oh man, the ultimate “Coda in Coda” wish list items next to tables. There’s deep architectural reasons I don’t see this happening.

Notifications - not sure about this one. I generally don’t find users actually engage or respond to app notifications. you?

2 Likes
4

I think notifications have potential but definitely room for improvement.

If they were on the grid it would allow us to see what tables (or rows?) users are even subscribed to in a single table.

A second table could hold the history of sent notifications, with a column relating to the first table to see which subscription might have triggered it for example