A quick thumbs-up. A down arrow. A smile. We’ve used all of these in tables and templates to add meaning to text, numbers, and data. In fact, some of the most commonly used drag-and-drop templates in Coda are the Topic Voting Table (thumbs up/down) and Team Sentiment Tracker (smile-face scale). But sometimes you realize you want to add the ability to react to a row or to a block of text after you’ve already begun making, and a template might not fit the work you’ve put in so far.
Enter: Reactions.
Now, you can now easily add a reaction column to any table—no formula necessary. Just choose the “Reaction” column type, and use the column settings to customize your reaction icon and logic.
We’ve also designed reactions to work on the canvas, so you can add a reaction after an interesting statement or at the end of a writeup. Simply type /reaction to start customizing your reaction.
And like any great Coda building block, you can also program it. Use “disable if” to write formulas that will disable a reaction based on a set of rules you’ve defined. This is great for simple scenarios: vote up to 3 times, upvote or downvote, etc.
Looking for some inspiration or want to learn more about the rituals at Coda that led us to build this feature? Check out this doc from our Design & Engineering team that built it.
We can’t wait to see how you incorporate reactions into your docs to get feedback, and encourage collaboration and interaction with your ideas!
Seems like a Reaction control returns a list of people who clicked, and also works as a toggle. So it doesn’t look like I can upvote more than once. Also if it’s a canvas reaction button, I cannot self-reference it to e.g. disable it once it’s clicked.
Hi Paul! The reaction itself or the reaction column settings should have a “Disable If” field. In the example doc from our Design & Engineering team, this template uses the Disable If condition to reference a scale control on the canvas: Top choices voting table
Hi there! Wondering if it’s possible to access the list of reactions via formula? Not finding it, but thought I might be overlooking. If this isn’t already available, would be a great addition!
@TSStrickand1 a reaction column is actually just an array of people objects under the hood. All you need to do to list the people who have clicked a given reaction is change the column type to People. Or, if you wanted to keep the reaction column as well, you could add a People column with column formula ‘=< reactionColumnName >’.
After watching the response from the community, I think that reactions are really useful I’ve loved using them and it seems that I’m not alone.
I’m concerned that this feels like an opaque implementation. Since the launch of this feature there have been several questions asking, “how to do xyz with reactions?”
As demonstrated by Paul’s question, it’s not intuitive that a reaction contains an internal list of users, especially since a list is not something that’s easy to add and remove from in Coda, so not a primitive I’d think to reach for or to test. It would be a bit clearer if the type of the votes column was “list of people” instead of “list of text”.
would allow you to vote as many times as you want, but it does not:
But I don’t think that’s the fundamental issue.
In Coda, we’re used to each component being a composable building block that’s transparent as to what it’s doing underneath so that it can be extended. We’re also used to an ethic of, “there is one obvious way to do a thing.” This implementation violates all three of those expectations:
It uses an unknown building block: a button that is simultaneously also a store of information
It is not clear how that store works, and unlike formulas that appear in standard buttons this one cannot be edited (which means this cannot be extended to, say, lookup a different value from a table as the one to store in the list, rather than the User() that pressed the button)
It is not how you would normally solve the problem using buttons, so now there are two inequivalent options for implementing the same behavior
This could have been implemented in a consistent way by either:
Implementing it as two columns. One which is the User type column and one which is a button
Introducing a new data storage object which is a button | action that can simultaneously hold data (a weird choice that would have its own issues, but would be consistent)
Either of these (and there are likely other options) may have been more consistent, transparent, extensible, and intuitive. I’m curious, were these talked about as alternatives? Were there concerns raised similar to those I raised above?
It goes without saying—I write all of this with love and out of deep respect for how Coda does product design. This feels like one of those features that are really hard to change once made (a type 1 design choice, since it will be part of the structure of a doc and can’t easily be undone in the future) and I wanted to flag it so that a conversation can be had about consistency and simplicity (lest we end up with over 6,000 built-in functions, or something silly like that).
This could have many uses in coda.
