I am stumbling on this issue also on my side, as I am working on keeping track of which columns are affected by each change recorded in the project history. Essentially, the stars and flags form two special boolean columns which are always present in projects. The fact that they are special means that, well, we handle them as special cases in the code, which is quite difficult to work with internally. Nothing that can't be overcome, but it feels a bit odd to be crafting all those special cases given that the feature isn't fully satisfactory from a user perspective:
- as a new user, it's unclear whether those stars and flags have a particular function (see @Ebere 's first post in this thread). The intended use of those buttons is not self-explanatory.
- as a user who understood the purpose of stars and flags, I am limited to two of those special columns (I cannot have a third one with another symbol). I cannot rename the existing two columns. I cannot remove them if I want to save space on my screen.
That being said, it's definitely a feature that is used and I don't think it can be just removed.
I think there are multiple ways we could get out of this situation:
- let the user add or remove those special columns. Perhaps we can offer a collection of symbols that people can use to define new annotation columns. We could keep only one by default. The fact that users would be able to add more of those columns would perhaps make it clearer that it's up to them to decide what those mean (just like any other column in the project).
- or remove them entirely, but make it super easy to use a regular column with boolean values instead. For instance using @Antoine2711's idea to render booleans as checkboxes that the user can modify just by clicking on the checkbox directly. We would also need to provide a similar option to "(un)tick all the checkboxes of the currently filtered rows in that column"
To me the second option would be pretty nice and flexible, because it would also ease the use case of working with any other boolean column, make it possible to move those annotation columns anywhere in the table, and so on. But one would need to design the UI changes pretty carefully, so that people are able to switch to this workflow easily and discover it in the first place.
What other designs can people think of?
It's not a blocker for my work, as I can work around the issue, but I did not want to miss the opportunity to give more steam to this interesting design problem 