When creating a new list, there is the option to choose a set for the list. The pull-down should only show sets that are compatible with the list, but now it shows all sets. For example, when creating a word list, I shouldn’t be able to choose a kanji list set, and vice versa.
It’s possible this is a new bug that appeared with the B2 fix, but I can’t verify that.
Ok, I now remember what happened. This was an intentional change (although I can now see the side-effects of it) for people who wanted to use the same set/group name across term types.
Possible compromise: put the sets for the current term type at the top, then a "sets from other types" subcategory below (if present)?
So if I actually select one of these wrong-type set names, it will go ahead and create a new set for me? That’s not what I would’ve expected to happen.
The way I see it, I should only see sets that already exist. If I wanted to create a new set with the same name as one from another category, I can type out the new name.
I understand that, but there is a different expectation for other users - if they make a group name for any section, they feel it should appear anytime there is a group selector.
Oh. Are we calling them groups now instead of sets?
I don’t have a problem with there being super groups that cross categories, but I want control over whether a group that I create is a normal group or super group.
It would be visual only, and not even 100% correct. The sets do have "term type" markers on them (vocab, kanji, etc.), so it would just be feeding off of that. However, there is nothing in the system to say "this was originally kanji, but it is now also being used for vocab", and I do not think it'll be worth the dev work to implement that.
If you are keeping the existing term-type tags on groups, then a simple workflow would be to add a fifth category for global groups to the existing four (words, kanji, grammar and sentences). The only trick would be identifying which groups need to switch their categories to global in a way that feels natural to users and doesn’t require much additional ui work.
I think if you want to implement the ui the way you describe above, all you’d probably have to do is sort by category, first local, then global (if any), then everything else. If the user selects a group name that’s not local, then promote it to global.
Open questions:
sort “everything else” by category or alphabetically?
Limit the number of group names shown if more than e.g. 20?
If limiting, how to decide which group names to display?
I think all of these could be addressed at the database level, so you can decide to decide later if you want to.
