Not exactly a bug, but an unwelcomed change about formulas in tables

Recently, “f” mark on table headings has disappeared. When you hovered over a field heading, the mark appeared if the field was formula defined. It was very convenient: if you wanted to checked it out, it was as simple of clicking on the “f” mark and the formula appeared, ready for editing or copying.

Since f is no more, you always have to raise field dialog, clicking on the heading, its icon or whatever. Then you browse the dialog, and then you click on “Edit formula”

1 hover-n-click vs click,browse,click

We can live with that, but if you check a good number of formulas daily, it is a little bit inconvenient

Please return our humble but beloved f on field headings


Thanks for reporting! We’ve been doing some work around here to make our column headers more robust, but it resulted in the trusty f icon disappearing. Rest assured, we’re working on bringing this back soon. Thanks for the call out!


I recently tried to change a formula clicking on the f, but it didn’t worked. Had to go in the menu of the column to do so. It’s too much clicks.

I expressed this privately to someone from Coda (@Angad, I think), but will echo here too.

I don’t welcome the change with the “unified drop-down” to set up column format / formula. It was much more robust previously. For someone who regularly sets up dozens of new columns daily, this just became a huge pain in the arse. I know about pressing-the-(=)-button shortcut for formulas, but there’s no such shortcut to change column type (previously it was click-on-column-type, select from drop down — now it’s open the drop down, open format settings, click the type to open yet another drop down, and only then select another column type)

1 Like

:+1: I second the opinion of Paul.

Especially for the makers between us, these functionalities need to be on top.
Maybe it should be depending on your role in the document

I also had this feedback in queue to be submitted, so I guess I’ll drop it here. :smiley:

With many of the udpates that have been rolled out recently, UI friction seems to increase with each new release. For example, it will go from a 1-2 click process to a 3-4 click process.

This stuff is starting to accumulate.

Most of the updates seem solid to me. I understand why they’re being implemented. However, as someone who now spends a great deal of time in Coda, it feels to me as if there is a level of QA that is lacking from the feature development process.

If it doesn’t exist already, it would be nice to have a QA step in feature development that addresses UI friction, answering these types of questions:

  • Are we adding or reducing UI friction?
  • Are we adding or reducing clicks?
  • Are we enabling the user to keep their hands on the keyboard, or requiring them to go to mouse?
  • Are we establishing efficient keyboard patterns (both hands relatively stable or even one hand only), or are we requiring wide stretching of both hands? (especially important, the smaller the hands)
  • Are we requiring the user to make large inefficient traversals across the monitor, or are we keeping monitor traversal tight and efficient (especially important, the larger the screen).
  • Etc.

NEW USERS: For new users, the more UI modals they are forced to navigate through, the more labyrinthine and hard to remember the UX becomes. For as much as I use Coda, I have trouble remembering the exact sequence of UI menus I must click through to perform routine things. :sweat_smile:

SUGGESTION: At the root of all UI sequences, include a search box that lets users type the exact thing they want to access, get the auto-complete menu, arrow down to their selection, and go straight to it. In the places where this already exists, I use it and love it. I suggest just basing the entire UI off that core module. On top of this, the UI can still be broken down into sub-menus and navigational signage as a way to increase on-boarding traction and new user education… and the universal UI search would allow new users to increase their own operational pace as they begin to learn the system. Best of both worlds.

Addressing this bucket of considerations before release is likely to cut down on much of your post-release overhead.


EDIT: Hi @Angad, just saw your post re beta access for slash commands: :point_down:

In this new centralized way to discover a full list of objects you can insert, I would encourage you to not stop at insertable objects, but to also include the UI menu structure within this centralized searchable scheme, as outlined above.

1 Like

Yeah as long as this topic is opened up - right now to create a new column and set the format it takes numerous clicks. This is fine (although prior it was less) AND it would be great if there was a ‘mouse-less’ way to create a new column and set its format without leaving keyboard. In my utopia this would include the ability to set a Lookup to match another table, without needing the mouse.