Issues with the order of new options being added to category fields

[CarsonRedCliffLabs]

When creating a new single-select or multi-select field in the new record type, users cannot conveniently add options while the field is still unlocked, forcing extra clicks into edit mode. More importantly, newly added options can appear in an unexpected order in the UI, and reordering them is jumpy and difficult, which wastes time and makes option lists harder to manage.

Steps to Reproduce

1. Open the new record type editor.
2. Add a new single-select or multi-select field.
3. Enter a field title.
4. Add several options in sequence (for example: 1, 2, 3, A, B, C).
5. Observe how the options are displayed in the list and attempt to reorder them.
6. Continue dragging/reordering options to see whether the list updates smoothly or jumps around.

Link to Loom demo
https://loom.com/share/e292f77c910f481a8b59c3e1aa155c7e?src=composer

[CarsonRedCliffLabs]

@Leo - looking for any update on this bug.
It’s become extremely frustrating lately and multiple team members and clients have brought it up.
This short clip shows another example of the difficulty faced here:

There is a large group of options. Carefully set with correlating colors and sorted manually in the order desired. But then in the actual front end drop down, the list is totally jumbled in no specific order. Changing to sort alphabetical vs manual and back doesn’t fix anything.

Also when adding a new field, it seems like many clicks and somewhat confusing navigation to get to where to add options.
Then adding options it’s super annoying that new options display at the top of the list not the bottom of the list.
Then after dragging them all around to sort in order, it still doesn’t even appear in that order in the app.

[Leo]

Hi @CarsonRedCliffLabs,

Thanks again for the reminder and for reporting this issue. I had already added it to our internal priority list when you first posted it, but I forgot to follow up with you here

We’re planning to fix this in the coming days. We delayed it intentionally because we’re reusing parts of the options menu UI for custom labels in phone, email, and link fields, and wanted to solve this properly in one go.

On the other points: new options appearing at the top is a trade-off. In many cases, we think it’s the better default, since jumping to the bottom with scrolling can also be confusing when lists are long. However, we fully understand that managing large option lists still needs to become smoother.

We already have improvements planned here. At some point, there will be an option to allow non-admins to add new options directly from the dropdown, which can be especially valuable for tags. For that, we need to make it possible to rename and reorder options directly inside the dropdown, without going into the field settings. That should make working with longer option lists much simpler.

Thanks again for the detailed feedback, really appreciated.

Best,
Leo

[CarsonRedCliffLabs]

Thanks @Leo - glad to hear that.
I’m a little concerned about this part though…

@Leo

At some point, there will be an option to allow non-admins to add new options directly from the dropdown, which can be especially valuable for tags. For that, we need to make it possible to rename and reorder options directly inside the dropdown, without going into the field settings.

I can understand adding new choices (maybe) but non-admin users renaming or reordering options would not be good in my opinion.

Too many calc fields, automation rules, and expected ‘ordered flow of work’ is based around these options. Allowing non admins to make adjustments that could mess up any of those things would be a big mistake I think.

[Jason]

I have to add my concern here as well, I mean i am sure Leo you are thinking of ways to harden this but at first reading it is plain scary what could break.

@CarsonRedCliffLabs

Too many calc fields, automation rules, and expected ‘ordered flow of work’ is based around these options. Allowing non admins to make adjustments that could mess up any of those things would be a big mistake I think.

Not to mention the external tools via API that set fields that could be accidentally (or deliberately) broken in one easy step.

[Leo]

Hi @CarsonRedCliffLabs and @Jason,

Thanks a lot for the feedback, I completely understand your concerns

We would never allow this generally for all users. The idea is that an admin could explicitly enable it for selected apps and use cases, for example when Multi-Select fields are used for tags.

Separately, we also want to use this implementation in Unlock Mode, so admin users can work faster when managing options directly in the dropdown.

We’re fully aware how sensitive category options are for processes, calc fields, automations, and API integrations, so this would need to be designed very carefully.

Best,
Leo

[Leo]

Hi @CarsonRedCliffLabs,

good news, we’ve fixed the issue!

Could you please refresh your client and check once more on your side? It would be great if you could briefly let us know whether everything is now working properly for you as well.

Best regards, and have a great start to the week,
Leo

[CarsonRedCliffLabs]

@Leo - thanks so much for this update!
I have tested and I can confirm it is mostly better now.
To be honest, there are still some aspects of the features that I don’t totally love (like the new choices appearing at the top of the list). But those have been discussed and explained in the thread here and I understand it’s not accidental, you have rules to run this way for a reason and that is acceptable.

The true bug is fixed and now works as the expectation has been set.

However, I still have one thing to point out here regarding the color assignments which I’d consider part of this bug.
I know this is being quite specific or picky…but I do think it’s worth noting.
Myself, my team members, and client users have all noticed this and made mention of it to me, so I do think it is something worth reviewing as it is noticed by users no matter how basic or advanced they are.

When adding new category options, it seems that the automatic color assigned to the option is random.

Is there any way to get this to either A) stick with one default color unless changed, or B) progress sequentially through the list of color choices?

Just now I added 5 new choices. You can see in the screenshot below (where no changes had been made), that those 5 choices were auto assigned colors of gray, orange, pink, purple, gray.

This seems totally random, and doesn’t follow any apparent pattern.

The list of colors as shown in the selector menu would be:

As the previous value in the list was green, I would maybe expect sequential auto choices to be blue, purple, pink, red, gray.
But the 5 colors picked are jumping around the list of options and it’s annoying to have to fix them each individually.

I know, this isn’t a huge deal, but it is noticeable and annoying.

[1F2Ns]

I wish colors defaulted to gray (or any single color.) This way you can change them to whatever you need and clearly see what ones you’ve already touched.

We switch almost all of them to gray with the exception of ‘in progress’ and ‘complete’ style options. Maybe we’re a fringe case

[Leo]

Hi @CarsonRedCliffLabs and @1F2Ns,

thank you both very much for the additional feedback

First of all, @CarsonRedCliffLabs, just to confirm: the sorting bug itself is now fixed on your side as well, right? That was the most important part for us, because that was a real bug.

Regarding the color assignment topic, I can understand both of your points very well. There are basically two camps here. In the early days of Tape, we actually had one default color for category options, similar to how Podio handles it. Back then, we received feedback that the default color should be different, because some users preferred a darker gray, while others wanted something like blue. We also received feedback that using only one default color made it less obvious that more colors were available. So it is a trade-off and depends a lot on the use case.

That is why we decided to combine automatic color assignment with bulk changes. It is not really possible to bulk-assign a different color to each category option. For example, if you import 100 category options from Excel, you would otherwise have to color each of them individually. That is why we currently assign colors automatically first.

At the same time, you can change even 200 category options to one preferred color with just 2 clicks using the bulk selection. And you are not limited to one predefined default. Some users may prefer light gray, others dark gray, and others blue. In our opinion, this is the most powerful and flexible approach, even though it required more effort on our side to implement.

When the mouse is inside the options section, users can use Ctrl + A to select all options and change the color for all of them at once. Users can also use Shift + Click to select multiple specific options and update only those in one step.

I am attaching the screenshots to show how this works.

However, we probably need to make this workflow more discoverable. We want to provide a shortcut overview in the mid term, and we should also consider adding this shortcut to the tooltip near the drag indicator.

Thanks again to both of you for the thoughtful feedback. Really appreciated.

Best,
Leo

[Thaha]

OMG! I did not know we could Shift + Select multiple options at once and change colours. That’s a good tip.

[CarsonRedCliffLabs]

I’m with Taha, never knew I could shift+select and edit multiple, that’s so good to know!

and yes @Leo - the true bug of sorting is fixed from what I’ve seen. Thanks for that. And for the detailed explanation on the color situation here. Much appreciated

I honestly don’t have a strong preference whether the default for new category choices is a single repeated color, or a ‘next’ color from the list. It just confuses me when it’s neither of those and cycles through randomly.

[1F2Ns]

I had no idea that you could select all and update the fields like that