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”.
Given this post,
you’d think that this:
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).