Page MenuHomePhabricator

Add groups to workboard columns
Closed, ResolvedPublic

Assigned To
Authored By
Feb 11 2016, 11:48 PM
Referenced Files
"Love" token, awarded by 20after4."Like" token, awarded by wschroo."Like" token, awarded by zhiyuchen."Like" token, awarded by Luke081515.2."Like" token, awarded by jdforrester.


Workboard columns should support group separators. This will allow us to improve or implement several things:

  • A "Group by assignee" view on workboards, where tasks are grouped by assignee and you can drag to reassign.
  • Priority headers on "Sort by Priority" workboards, so the effect of dragging to a column on the task's priority is communicated more clearly, and tasks can be changed to, for example, "High" priority even if there are no other "High" priority tasks in the column.
  • Group by Project, see which other projects and milestones a task belongs to.

In both cases, the headers should probably also sum points/cards in the group.

Event Timeline

There are a very large number of changes, so older changes are hidden. Show Older Changes

Another possible Group By is by project. So going into Differential and grouping by projects should allow me to see all Bug Reports in their own column.

Absolutely not ever implementing that, because it allows a card to appear multiple times in the same column and requires me to rewrite all the workboard code again.

Oh, wait. Maybe we're talking about different things. Let me draw a picture.

Yeah I'm not sure how they'd appear twice in the same column, just multiple times on the board ("Easy", "Bug Report")

Here's the feature I'm thinking about:

| Backlog        |
|@@ UNASSIGED  @@|
|@@ chad       @@|
| T456           |
|@@ epriestley @@|
| T123           |
| T124           |

The basis for this is this mock:

The "High", "Medium" headers are the "Groups". This would be the "Priority" view.

The "Assigned" view would be the same, but the "High", "Medium" would be replaced with "epriestley", "chad", "unassigned", etc.

Oh. I assumed the entire column was a group.

Admittedly I didn't fully grok your description, just how I pictured it in my head. What I was thinking was grouping a whole column by say a Person (like we did in Dashboards) you can see their points and drag work between them. If we go with grouped headers inside the column... how would that work for people? You'd just have their points for that column in the header?

We could do the whole-column thing, but I worry it would be confusing / not useful.

The big use case I see for this is checking everyone's workload on a team, but if it puts a person per column, it will include things in columns like "Backlog", "Done", "Wishlist", etc., which you probably don't really care about since they're not work. I think you're more likely to only care about columns like "About to Work On This" and "Working on This Right Now".

Yeah, my detail on the header is like this maybe?

| +-+                   |
| |X| epriestley  (16)  |
| +-+                   |

..where X on the left is a small profile picture, (16) is the points. So the headers would be a little bit taller than in the mock, but I think it shouldn't be too bad (I'd guess most boards don't need all that many users to show all the states).

I like this idea. For the "assignee" options, what would the ones shown be?

  • Members of the project? If so, what happens to tasks assigned to a non-member; is it a magically-additional group that goes away later?
  • Current assignees of shown tasks? If so, how do I assign something to a member (or whomever) who doesn't yet/right now have a shown task?

It's just Group By Assignee, so of all the tasks on the board, who is doing what, how much work is it, and what is unassigned.

There's some argument for showing more headers than the actual assignees, so you can assign a task to someone with no tasks currently assigned.

That is, if we have users Alice, Betty and Claire, and a column with tasks assigned to Alice and Betty only, but we "know" that you might want to assign stuff to Claire, it might be nice to show a header for Claire with 0 points so you can drag a task into that header to give it to her, similar to how the priority mock above shows empty headers for priorities with no cards.

I'm not sure what rule would be best. I think always showing "Unassigned" (even if it's empty) at the top (or bottom?) is probably desirable, but I'm not sure.

The minimum set is just the users in the column who are actually assigned something. Other reasonable rules I can come up with:

  • All users assigned something anywhere on the workboard.
  • Members of the project.
  • All users assigned something anywhere in the whole project.

I'm inclined toward "all users assigned something anywhere on the board". So Claire shows up in every column if she has some visible task assigned to her in any column. If you need to give stuff to Danielle, you manually assign one task to her and then her headers show up everywhere.

That is, this is a valid column:

| Working On Now      |
|@@ Unassigned    0 @@|
|@@ Alice         0 @@|
|@@ Betty         4 @@|
| T123                |
| T124                |
|@@ Claire        0 @@|
|@@ Danielle      8 @@|
| T129                |
| T130                |
| T165                |
| T199                |

It has five user groups (Unassigned, Alice, Betty, Claire, Danielle) but only two of them (Betty, Danielle) have any tasks. But the existence of the "empty" groups lets you give tasks to Alice or Claire easily, or unassign them.

We obviously don't want to list every user since having 30K groups is pointless, but if we can "guess" (using a rule above, or something similar) that you might reasonably want to give stuff to Alice or Claire, we can give them empty groups in the column.

In this case, you might see that Danielle has too many points and want to give some of her stuff to Alice or Claire, so the presence of their groups might be helpful, provided we can pick a rule that often guesses right.

If so, how do I assign something to a member (or whomever) who doesn't yet/right now have a shown task?

The strict answer to this is "click the Edit button to go to the full edit UI". We can't make all possible reassign operations accomplishable by dragging, so this has to be the safety net for the cases where we can't guess who your likely assignees are. But I suspect we can do pretty well most of the time with some set of those rules, and make the cost of guessing wrong low.

The strict answer to this is "click the Edit button to go to the full edit UI". We can't make all possible reassign operations accomplishable by dragging, so this has to be the safety net for the cases where we can't guess who your likely assignees are. But I suspect we can do pretty well most of the time with some set of those rules, and make the cost of guessing wrong low.

Maybe instead of guessing, you should have a form of the auto-complete sort where a user can plop another user on to the board to assign things to. This could be accessed through the Manage gear symbol if you don't want to add to the Workboard UI (when it's transformed to include the assignee 'rows').

cburroughs added a subscriber: cburroughs.
cburroughs moved this task from Restricted Project Column to Restricted Project Column on the Restricted Project board.May 3 2016, 7:44 PM
chad updated the task description. (Show Details)
chad updated the task description. (Show Details)
eadler added a project: Restricted Project.Sep 15 2016, 6:08 PM

Another possibility for assigning to members not already on the board would be to add an "Another User…" category, perhaps only once you start dragging, and if you drop on it, you have to select/type a user in a modal dialog to complete the 'drop' operation (or cancel it). This might work better than guessing; every column would have "Unassigned", headings for users with tasks actualy in that column, and "Another User…". On the other hand, for us, guessing is likely to result in a lot of wasted space, because the users we assign to in different columns are very different. The feature would quite probably be useful to us, though, as moving columns concurrently with reassignment is an extremely common task for us.

This could potentially work for priority grouping, too. It would be somewhat inconvenient to have "Unbreak Now!" on every column, as we use it very rarely (but we do need it sometimes). Also, I would only want "Needs Triage" to appear when tasks are assigned that priority, because I would expect a task moved between columns to be triaged at the same time if it needed it. We would also rarely want to move tasks into the wishlist priority. Having "Another Priority…" would allow a lightweight way to use other priorities, while minimising the spacial loss.

Perhaps some priorities/users should be able to be marked as "Always Show" though. E.g. it would probably be helpful to always show High, Medium and Low. It wouldn't be helpful to us for assignees, though, unless it could be chosen on a per-column basis.

Just some thoughts.

Technical stuff:

  • Columns need to become a mixture of cards and headers.
  • The sorting functions need to be able to sort these mixed lists in a uniform way.
  • If card "X" is followed by header "Y", dropping card "Z" after "X" versus after "Y" need to be different operations even though the afterPHID will be "X" in both cases.
  • When a card updates, we need to send its header back. The header may be a new header which isn't currently present on the board (for example: you edit a task and assign it to a new user with no other tasks currently assigned).
  • The point count element should probably be client-side, since rebuilding it to send back the header after an update is a bit of a mess otherwise? This element isn't critical, regardless, and I think the other point counts are client-side already so this is probably easy.
  • When an edit generates a new header in a column, we should possibly add that header to all other columns (for example: you edit a task and assign it to "alice", so "alice" gets an assignee header in every column).

This now exists for priorities. I'd like to get at least one more grouping (likely: assignee) built before calling this resolved since "Priority" has some magic interaction with "subpriority". I'm moving toward getting rid of "subpriority" in D20263, but I'm not yet completely sure that it'll stick.

epriestley triaged this task as Normal priority.

I'm going to consider this resolved at this point. The one thing I haven't built is the "task/point count" from the mocks (on the right-hand side of the header, counting points in each group), but I think this is probably only of much use under "Group by Owner", and maybe not even then. I'm open to building this in a future iteration and it's not likely to be very much work, I'd just like to see feedback that we're generally headed in the right direction first and that the element would have real-world use cases.