I’m not sure how labels are working. Say that you have the following:
Item1: TagA, TagB
Item2: TagA
Item3: TagA, TagC
Then you create a column view that groups by tag and:
Question 1: 5 columns are created: TagA, TagB, TagC, TagA+TagB and TagA+TagC. Is this by design? I was expecting that 3 columns were created, TagA, TagB and TagC, and items repeated (TagA:Item1,Item2,Item3; TagB:Item1 and TagC:Item3). The expectations may be different for others user, but if this is by design is there or there will be any way to achieve this?
Question 2: If you now apply a filter by TagA, 3 columns are created: TagA, TagA+TagB and TagA+TagC. This behavior is consistent with Question 1 but again I would expect only one column to be created (TagA) and listing Item1, Item2 and Item3. I know this can get a bit more tricky and therefore arguable, when filter are combined (like TagA AND TagC) but still, this current behavior felt rather unexpected to me.
So if you enable ‘Multiple Select’ field, you’ll be able to put multiple Labels to your items, thus when you group a column by label, you’ll get additional column(s) with shared attributes (Tag1 + Tag2).
On the other hand, when you disable ‘Multiple Select’ field, you’ll be able to put only one label to your item(s), and again: when you group a column by label, you’ll get only columns with that specific attributes (Tag1 / Tag2, etc.)
So if you’ve deselected the ‘Multiple Select’ field, try leaving only single labels to your items.
Ok, I think I got how the multiple selection work, however, my issue is getting that additional column that show the groups items with shared attributes.
Let me try to describe another example. Say that you have a bunch of web dev tasks. Some of them are related only with frontend, others only with backend and some of them only related with DB. Now there are some tasks that are related with both backend AND DB, other related with backend AND frontend, and finally a few of them related with the 3 (frontend, backend and DB).
Now, I would say a somewhat common board is to know which tasks touch the frontend, backend and DB — 3 columns with repeated items since some tasks belong to multiple columns.
With the current approach, one column will be created for each possible combination there is. For the example above, 6 columns will be created! This renders such board senseless. And like this example, I can find many others. It just requires to have multiple labels and group by layer.
Another example is Grouping by Assigned. If you assign multiple people to a task, and group by Assigned, a column will be created for each combination available.
I think that the implementation is simply considering that each different combination of labels is a new different label and that breaks grouping in my perspective.
I think this makes perfect sense. The assigned example is the most Stark. It breaks the point of having an assigned task column, because you have to check all columns to see if you’re included in any others, not just the one “primary” one with just your name.
If you have 13 devs, Adam … Zed. And Adam gets in a group with Zed, one of them is going to have to scroll to the far side, checking every one of the 30+ columns (depending on how many devs are combined) for their name.
Even if the above is intended behavior, I cannot imagine this is. The following screenshots are of the same view. One is grouped by “tag” (todo) and the other is grouped by “location”. When creating the items while grouped by tag I switched the order that I added the location. It ended up creating two different groups when I grouped by location, both having the same tags, just in a different order. This is not what I expected the behavior to be.
Right now we are grouping items by unique values. Which means that each label combination is a new value.
Your approach would mean that we should have duplicate items in a single view, because it would be visible in two columns at the same time, right?
We have organized our tasks and grouping you described using views. In your example I would create new view for each user, or for type of dev tasks.
I understand that both approaches are useful and it is hard to decide which one is better. Another option would be to allow users to switch between both versions which would increase complexity of the tool and some people could get confused with so many variations. It is hard decision but we will consider it. I encourage you to try views approach.
(This is essentially a brainstorming session… sorry for the longevity)
I have a question:
Can different users who are sharing the same board have personalized view organizations?
Using the “Assigned” example: if I have 13 developers working, I am going to need to have 13 different views for each person.
Maybe there could be a view based on the user. (Filter: User = person currently logged in). That would allow me to see what is assigned to me without having an overwhelming number of views open.
Another example that I have: a Board that organizes companies by country. It is nice to use the filtered views, because you can then include more information based on the status of the project. However, there are 25+ countries on my board, and if I have multiple users trying to look through multiple countries, I would need to have 25 different views; otherwise one view would get filtered back and forth because of the multiple people logged in and changing the filters of the “locations” view.
However, if I had “Private” Views that aren’t accessible to other members of the team, I could maintain one view, and change the filters based on my needs.
Maybe this sparked something for the development team… I don’t know, haha.
Yes, that is a good idea for a “dynamic” filter which would be changed based on the signed in user. We already have dynamic filters for dates where you can put “yesterday” for example. In that sense, we could have filter that would say “where member is ME”. The only concern here is whether it will confuse people working on the same view. Imagine having questions on this forum like “my colleagues and I don’t see the same items” :). Great suggestion anyway.
I don’t want to sound like I’m trying to find workarounds for multiple labels issue, but it is possible to split countries into folders, where each folder is a new country. Then you could have one “overview” view on the parent folder which would combine all subfolders.
Private and public views are something we are thinking about from the beginning and it never got a high priority because of how we work as a team. Anyway there is a real need for this kind of features along with permissions.
I just realized I haven’t responded to this yet… regarding this part:
I don’t want to sound like I’m trying to find workarounds for multiple labels issue, but it is possible to split countries into folders, where each folder is a new country. Then you could have one “overview” view on the parent folder which would combine all subfolders.
I originally thought this would work great, especially because new folders allow you to maintain upper level organization inside of a more precise view (like priorities), but I don’t think that it will be a viable alternative. In order for this organization to show all of the details necessary for each country, I think I would need duplicates of cards in all of the folders/countries that the company exists in, resulting in a big jumbled mess of inconsistencies (unless we can do card linking/updating, which I think would be sweet!).
I do agree that both methods of organization are useful! There are just more cases for me right now where the duplicate items view would be super helpful. Thanks for the responses and feedback!
