Button formula finally (almost) down :(

Maybe I am wrong, but I’m fearing I’m not:

Button formulas stopped working for me when inside Concatenate formula: they keep showing correctly the text in preview and button in formula editor, but not elsewhere.

Outside the editor, what you get is that deadly “(bolt) Action” sentence

3 Likes

Yes noticed and confirm exactly the same problem.
And it is very sad that the developers intentionally disabled such a possibility, such a workaround to combine several buttons in one column.
Since in my work 50% of the documents use this method, the readers of my documents are pleasant and comfortable to read the data in tables of this kind.
I hope I’m wrong, and soon we will see new features on this formula.

UPD: I received a reply from tech support about this problem. They reported that the formula is now unsupported as this formula is unstable and experimental, they recommend using the official list of formulas.

Dear @shishir and the Coda team please next time alert you to which formulas will no longer be supported in the future. Still, it’s sad that they disabled the workaround for the button formula. Which allows combine in one column saving space across the width of the table, with formulas: Concatenate Text + Button, BulletedList Button, Lookup formula ActivateRow button in another table, etc

Please do not ignore this, and return or allow the implementation of such functionality.

Thank you for your attention

Yeah, I also had this response. I am well aware of that it was an unsupported formula, and that the button column type has received some improvements, yet the possibility of place different buttons together, and furthermore, combine them with text, was essential for me to develop advanced UX.

They asked me to request officially that feature (Feature Request Form)

I suggest we all the people who used this make some noise. I am sure many advanced users got their docs broken with this change, maybe if some of this community vips, such as @Paul_Danyliuk or @Filmos make some noise our pledges are listen :slight_smile:

4 Likes

We see you. We hear you. Your buttons should come back to life within the next two prod pushes.

10 Likes

And we stand with you dear codians, keep doing your outstanding magic :blush:

2 Likes

We were able to fix this to allow it to keep working for now, but if you are creating a doc that you rely on and cannot have it break, I would seriously consider finding a different solution and stay away from unsupported formulas.

This is still not supported and still could break with future updates.

2 Likes

Thank you for the update!

Please give us some official way to render inline buttons. Can’t say for everyone (although evidently it’s not only me who needs this) but I often find myself needing:

  • A variable number of buttons rendered inline, e.g. these are Concatenated from a table:

  • Different-colored buttons in different rows (no example at hand; I’m using colored labels instead because coloring a Button() is very risky):
    image

  • A button inline with text either within a cell sometimes:

    or as part of a canvas/cell function that may hide the button altogether:

    Before clicking the button:
    image

    After clicking that button:
    image

  • Adding a button to a table group to enable for custom logic. E.g. here a button is necessary to provide Add Row capability because the normal “add row” button would not automatically resolve the lookup (because we’re not grouping on a Lookup). Of course we could have a separate column for a button, but we’re constrained in horizontal space there:

  • Sometimes I’d like to not have a disabled button to keep the table cleaner. A disabled button with regular label would add visual clutter. Right now I have to render buttons with empty label to aid that, but imagine a long grey line here that would only distract the user. I’d rather not have this at all:

and many similar scenarios where this would be useful

5 Likes

All these use cases + rendering multiple buttons horizontally on a card in Kanban view.
An example would look like this
image

Without Button() formula, the above card would instead look like the one below. That big empty white space on the right side is useful for nothing except to enforce 60px social distancing between buttons in adjacent cards.
image

Since this is an integral part of my workflow, I am really grateful that the Button() formula is back (for the second time since it broke once in last November)

2 Likes

Also, if you want to clearly separate consultation UI from edition UI (something really necessary in my opinion, since there is little visual difference between editable fields and calculated fields, and because if you have many to many relationships you need some tricks and intermediate forms to provide user enough support) button formula comes in handy.

About first scenery, I tend to use this trick to show what text you can edit, and ease advanced edition access to user:

About the second scenary, I have no time right now to paint something easily understandable, but there are some cases, such us: delay row change until user presses accept button, assist with intermediate form where user can navigate hierarchy to find desired row, and so on and so on

1 Like

Hi @BenLee - I saw in @Filmos post about undocumented formulas and the risk that the document can crash and require reverting to a previous version or resorting to tricks to navigate to a stable page and then perform workarounds to purge data and remove the problem formulas.

Is that required to use things like the button() formula? If so, IMO it’s pretty dangerous to even expose those formulas to users in the first place? I’ve discovered a need for the button formula but it’s surprising I would even need to worry about something like that since when I type button( in the formula editor, I see the function signature for it and it’s surprising that I could get myself into such a dangerous situation in such an innocent way.

What sort of guarantees do we have when using a formula like button? Would your team help to fix a broken document if such a case arose? Thanks as always!

They are not exposed. They are not on the list; they won’t show up in the formula editor suggestions until you’ve finished typing them out; they have this icon before them saying these are experimental formulas.

image

Basically if you didn’t know about them, you normally wouldn’t even try typing them, and if you found them by chance you’d be scared away by the experimental icon.

No one would fix your broken doc if it’s you who broke it by ignoring the warnings.

1 Like

I didn’t notice the experimental sign, thanks for pointing that out.

If an experimental feature is buggy, behaves in unexpected ways, is deprecated, removed, or has breaking interface changes in an update - I think that’s fine. However in my opinion anything exposed to the user should guarantee that the document at least loads or that the user can somehow recover. Buttons can be broken, formulas can be broken, tables can have the wrong data, views, etc, but I should at least by able to modify the doc and attempt to fix the problem.

Maybe this would require a sort of “debug” mode of the document where no formulas are evaluated, no automations run etc, or maybe it would simply be a matter of making all the code paths production ready.

If Coda experimental features have no such guarantee, then in my opinion I think the app should give a much louder warning to the user that the feature should not be used in any production scenario, including when copying docs. There are plenty of docs used as examples here on how to implement things that contain these formulas, it’s quite easy to use something someone else set up that has these formulas without even knowing it. This is actually how I came upon the button formula.

2 Likes