Columns types changing on their own

A few times I’ve noticed that I might enter or copy data into a cell and something about that data causes the field type to automatically change.

An example: I have a text column. I type a date in that column. It changes to a date column. (I can kind of see why this might happen, but I definitely don’t want it to happen and can see no way of stopping it.)

Another example: I pasted some zip codes into a number column. That field converted to a single-select dropdown. Same thing has happened with text. (No clue why this would happen, and doesn’t happen consistently.)

The first couple of times this happened, I thought it was a fluke, but now it’s happened enough times, I think it’s a bug…

2 Likes

Dear @Kelly_Claus,

Based on the content put in a column, Coda creates automatically a column type, without asking for your consent.
It’s not a bug, but I agree that you will not always benefit from it.

To my opinion, this should be set optional or at least the “Maker” :building_construction: to confirm.

1 Like

Hi @Kelly_Claus ,
as a matter of fact it’s a feature rather than a bug.

It’s called (data) type inference and it’s a way to simplify the life for most of the times.
Excel and Google Sheet - as well as other data related tools - do the same.

I understand that from time to time it can be annoying, but let’s say it usually happens quite rarely compared to the benefits.

In case this is something really affecting your work, then maybe it worth understanding better what kind of operations you usually do and how to overcome with that.

@Federico_Stefanato and @Jean_Pierre_Traets thanks for responding.

I assumed this was the case when it happened with dates, but it doesn’t make sense why a column would ever change to a single-select dropdown, does it?

Hi @Kelly_Claus,
I don’t know exactly the threshold adopted to consider a set of values as coming form a select list.

Let’s say that post codes are good candidates: always 5 digits and perhaps some repeated values it would guess that these are - well - codes :slight_smile:

I’ve been facing this issue multiple times, and my workaround is to create a “hidden row” (create one checkbox column named “_hidden” then filter all data by this column value, and put a data on the column you want to keep). I hope example explains:
image

But yes, my suggestion to Coda is not to change column type if it has been chosen explicitly by user.

Hi, is there any news on how to workarround this? My case is users auto changing column type when type date type titles in a row. If it’s a feature it should be optional to disable it. It’s affecting several times a week our workflow

1 Like

Dear @Digital_99

I could not find the relevant post, but somebody suggested to paste from the second row the content in the table and then to delete the empty row.

This has been so far a work around for the time being.

As we see from recent posts, the Codans start to catch up with pending points that we experience as “improvements of life” - lets hope that this subject soon sees daylight too.

1 Like

I’m using it as a form, so that workarround doesn’t help for us. Let’s hope Codans catch up to this soon enough

I would like to report that I have the exact same bug.

A text field is automatically changed to date or number based on the content.

Since the users use the doc exclusively on the phone, they always need to report it to me and wait to fix it (change it back to text field). Until then they are blocked from using the table

2 Likes

And I would like te report that I have a button column that seems to have changed itself into an empty text column. When I noticed (one hour ago) I went to version control to look up an old version of this button. I can see it grayed out in version control preview, but when I copy that version to a real doc, the button disappears in front of my eyes.

This happend to be a simple function button, but for some of my buttons I really can’t afford for this to happen, in particular if I can’t trust version control.

3 Likes

If you have ever used CoPilot (an AI pair programmer that predicts the code required based on your comments), it performs similar inferencing assumptions and it is vastly correct in making these assumptions. It’s certainly not perfect, but it is learning.

I’m delighted to see that the Codans have begun to lean on AI to advance the science of Maker tasks. I hope the underlying AI mechanisms are learning when we correct missteps like these.

Along this path to faster and more efficient Maker assistance there will be bumps and mistakes, but inferencing based on previous patterns and known best practices is likely to stick now and eventually transform how we make Coda applications. Imagine building a table and being largely unfamiliar with advanced features that could improve your user experiences. This type of assertive Maker assistance may become extremely valuable and especially as the techniques and more advanced features continue to emerge. The future of app development cannot end with no/low-code; it must embrace the capacity to help Makers plan, design, and architect solutions to meet increasingly complex requirements.

Curious @Federico_Stefanato is Coda actively developing underlying AI based on GPT-3?

If this is indeed related to an attempt to exhibit helpfulness, it suggests the AI is not learning. :wink:

sigh…

trouble with AI = very big A & very small i