Page MenuHomePhabricator

Workboards should support alternate ordering rules, including "don't keep arranged by anything"
Closed, ResolvedPublic

Description

I'd like to share some feedback having tried to use workboards for project management within my organization. I'll start with a UI surprise: dragging tasks up or down in the list changes their priority. I wasn't expecting that, even though I read about it in T1344 recently.

I suppose this could be addressed in the UI somehow, making it more clear as the dragging is happening that the priority is going to change. Already priority is associated with color: perhaps the color can change to reflect what the priority will become, and when it's going to change, an animated halo draws attention to the changing color. Or, since there are only a few priorities, there could be rows for each one, making the workboard a matrix, where it will be obvious to the user that moving between rows is just as relevant (in that it will change some property of the task) as moving between columns.

But, I also think that maybe priority should be independent of order. Two reasons:

Firstly, a task may be in multiple workboards, and it may make sense to have different orderings in each. For my experiments, I had created an "estimation" project and associated workboard with 1, 2, 3, 5, 8, 13 columns. The idea is to play planning poker to estimate the effort required for tasks, then drop them in the corresponding column. I can't think of any particular way I'd want to order tasks in the workboard. If I could, it probably wouldn't be by "priority".

I can think of an alternate ordering for a different kind of workboard, say one that represents a sprint. I may, when planning a sprint, decide that tasks should be addressed in some order. This order is likely not priority order, either because of dependencies between the tasks, or because of another reason: there's "important", and there's "urgent", and they are not the same thing. I don't know about how everyone else works, but in my organization, this is a common problem:

We decide that we need to develop a frobnicator because we are frobbing things all the time. We decide that it's important, because we stand to save so much time. We make a note to do that real soon now. Then, Bob says "I need those TPS reports for the meeting tomorrow!" We decide that's urgent, because it must happen soon. So we make a note to do that too.

A week later, we discover that we've successfully addressed the scads of urgent tasks that have come up, but failed to make any time to address the important tasks.

It's hard to plan because it's easy for someone to say "I need this urgently", but it's hard to tell them "OK, but we don't have time" when you don't have a way to see how much time you need to budget to address important but not urgent work.

I remember reading something in particular on this problem, but I can't find it. Anyway, if you search for "important versus urgent" you can get plenty of stuff. Though a lot of this stuff downplays the importance of "urgency", there are legitimate things which are urgent, especially when one commits to delivering things on time. A deliverable for a particular client may not be that important (it's just one client), but it becomes increasingly urgent as the deadline approaches.

If workboard order is not the same as priority, this gives me a way to indicate visually a two-axis state of "urgency" and "importance". I can choose to denote one with the "priority" property, and another with top-to-bottom ordering on the workboard. Furthermore, I can have arbitrarily many other orderings by creating more workboards, with the ordering defined by some property relevant to that workboard.

Event Timeline

bitglue raised the priority of this task from to Needs Triage.
bitglue updated the task description. (Show Details)
bitglue added a subscriber: bitglue.
bitglue renamed this task from Maybe "priority" and "order on workboards" should not be the same thing to Top-to-bottom ordering on workboards is suprising.Apr 16 2014, 10:09 AM
bitglue updated the task description. (Show Details)

I think there's some discussion of this somewhere; I'll merge this or that if I dig it up. We're probably going to add a "things stay where I put them and position has no meaning outside of the board" mode as other users have also found this confusing.

there's "important", and there's "urgent", and they are not the same thing.

Do you think this is a desirable distinction? That is, if you could design an organization in isolation, would you care about these separately? How much urgent, unimportant work would workers in your ideal organization perform?

One of these values helps you answer "What should I do next?", presumably "Urgency" in the case where you care about both. What question does the other field help you answer? If every task has an urgency, and its urgency dictates when it is scheduled, what decision would you make by comparing the importance of two tasks?

For us, at least, they're close enough to the same that they can be represented in one field. That is, the overall goal of any attempt at prioritization for us is to do the most important work first. Sometimes the importance of that work is partially a result of its urgency, but work which is urgent but not important hints at a management error: why is the work urgent and/or why don't we think it's important? For us, I think the answer to this question is usually either "it's not actually urgent", or "it actually is important", or "something is wrong, and we should fix our process to avoid this kind of error".

To this point, most advice on the important/urgent matrix from Google offers tips on eliminating, avoiding, or preventing urgent-but-unimportant work. If there isn't much of this work, you can map everything else linearly:

  • not important, not urgent: Low
  • important, not urgent: Medium
  • not important, urgent: High, but indicates preventable, systematic failure; stop this kind of work from existing.
  • important, urgent: High

This may not be practical, of course, but our current approach is to ship a sort of idealized and lightly opinionated product (which is mostly driven by a desire to eliminate process) and let installs add whatever additional process they want, but not assume that everyone needs due dates, separate severity/urgency/importance fields, time tracking, etc., out of the gate.

(I think we are largely successful at eliminating urgent, unimportant work, although we're a very small and relatively unusual company. However, I think Facebook also does a fairly good job of this, and is a much larger and more traditional company at this point. At the least, I rarely felt like I was doing unnecessary busywork when I was employed there, and the culture was relatively adversarial toward process, unnecessary meetings, etc., and relatively friendly toward process elimination, simplification and improvement.)

Anyway, this isn't at odds with a "things stay where I put them mode", just some attempt to explain our thinking here about not distinguishing between importance, severity, and urgency.

Totally agree with not having separate "importance" and "urgency" fields -- that is too much process to exist in the product and force upon everyone. The biggest problem I'd like to see solved here is just the surprise I get when dragging things around in the workboard. That could be fixed either by separating ordering from priority, or making the current behavior more clear, UX-wise.

I think there are two factors that drive my desire for this sort of distinction in my own organization. Perhaps the most relevant is that "not important, urgent" work you mention which indicates systematic failure is endemic here. It's so culturally entrenched it will not be easily changed. My solution to this (still to be attempted) is to express directly on a task what long-term value a thing has, and then make that really visible in the organization. Make it visible when people look at tickets, make it visible on the kanban board in the lunch room, discuss it in planning meetings, etc. Just generally get people to think about long-term value all the time. Then they will do the right thing.

Having worked at times as a professional software developer, an IT administrator, and an engineer delivering services in the field, I think I can offer some perspective. Software developers, by nature of their job, are relatively shielded from urgent, unimportant work. The art of writing software (good software at least) requires a long-term view, and good developers instinctively seek the long-term solution: don't just copy & paste that code, write a library. Don't just fix the bug, implement regression tests. Don't just commit the change, have it reviewed. Medium to large software development companies even have entire departments with the function of shielding the developers from urgent, unimportant work: the "support" department. It has the role of catching all the urgent reports of people experiencing problems with the software, then informing development without overwhelming the developers. The tasks created by a good support department will already be filtered to extract the important patterns out of a deluge of urgent support requests.

My organization is a services company that is growing a development organ (painfully, out of necessity). We come with the opposite instincts. When a lot of people all have the same problem we think, "more money for us". When an individual has an urgent problem we think "good customer service requires that we pay attention, urgently". Almost everything we do is bound by a deadline that has been promised to a customer. So, if you allow such an organization to make tasks, you get only the unfiltered, probably urgent, not necessarily important tasks. Your development task tracking system becomes a support task tracking system.

I completely realize Phabricator is a development system, not a support system. I'm not saying it should compromise, either. Of course, I could have a separate system for support, which most of the organization can access, and quite separately Phabricator, which they can not. However, I think there is some value in having an integrated approach to the two, with some workflow that helps filter urgent support into important development.

Another consideration which I had just now, after reflecting on how this "task" itself isn't a task: feature requests seem to fit in here somewhere also. A feature request is neither important nor urgent, but you do still need a way to work it down a pipeline of defining the problem, the solution, deciding to act, and eventually ending up with code. What will you do with this task? Will you read it, conclude that we've made our points and the feedback has been received, and close it? Will you decide if a change is justified or not, and if so, how do you indicate that?

Back to the original report, there is a factor not mentioned that I actually find to be the most confusing:

Why do cards move? I we have 5 cards as "High" at the top of the column, we want them to stay in the same order. Now they change, and we haven't even found the pattern. Highly annoying, because some teams do pay attention of the specific order of the cards.

Tasks have a global, internal priority which isn't exposed directly in the UI: so the visible priority is "High", but the internal priority is something like "High-100". When you drag tasks around, the internal priority changes, so you can have a "High-50" task, a "High-100" task, and a "High-150" task.

This priority is completely global, and applies on both boards and the main list. I'd guess that users have been testing out the dragging feature and dragging tasks around, maybe on the list view rather than the board view.

Of course, it could just be a bug too. We don't currently record internal priority changes so there's no way to see who has been doing this.

I think we should just implement alternate ordering first (like "stay wherever I put it") and then dig into global priorities if they're still causing issues.

Makes sense, thank you.

I couldn't find a policy to define who can drag tasks in project lists and boards. Is this defined by the project's "Editable by" policy? The idea would be that only the members of a project can drag tasks.

aklapper renamed this task from Top-to-bottom ordering on workboards is suprising to Top-to-bottom ordering on workboards is surprising.Apr 24 2014, 9:33 AM
aklapper added a subscriber: aklapper.
chad triaged this task as Normal priority.May 16 2014, 5:17 AM
epriestley renamed this task from Top-to-bottom ordering on workboards is surprising to Workboards should support alternate ordering rules, including "don't keep arranged by anything".May 18 2014, 6:25 PM

FWIW I think task management systems should have no overlapping dimensions as this invites complexity, confusion, extra conventions and maintenance. In practice, this means you shouldn't have a dimension for which some values require another dimensions to only be in some other specific values: that's redundancy of information. A bit of information should only be stored and defined in a single place. It can of course be displayed in multiple places.

Typically you have a type dimension (feature, task, bug...), a priority dimension (P1, P2, P3...), a project dimension (iOS, Android), a milestone dimension (2.0, Later, etc...) and an assignee dimension. All of these are clear and orthogonal concepts, easy to understand for engineers and non-engineers.

In Phabricator, projects and milestones are sort of combined (you would have "iOS 2.0" as a project), but that doesn't break the general rule.

When it comes to work boards, they add a column dimension, which is freely definable and can therefore still be made orthogonal to other dimensions. For instance, columns could be used for milestones inside a project, grouping tasks, routing tasks while in the "open" state (Kanban style), etc...

But if you were to add some sort of custom order of tasks inside columns that is not the priority order, that's suddenly adding an overlapping dimension and it breaks the rule.

Long story short: I don't think it's a good idea to let users order tasks inside columns in a way that has nothing to do with task priorities. And if it is implemented, there should be an opt-out (and even be off by default).

Regarding re-ordering the tasks within a column affecting their priority: I didn't know it was the case, I thought you could only do that in task query results. IMO that's a great feature but UI could indeed make this more obvious. And how do you move a task to a priority for which is no task of that priority already in the column (without editing it that is)?

My sense is that a lot of users want and expect this feature to work like sticky notes on a whiteboard: you move them around, and they stay where you put them, and "where the thing is on the whiteboard" is just some loosely-defined spatial dimension that isn't related to anything else. We also exist in the context of Trello, which is probably the most popular software of this type and does not implement the priority rule.

I personally tend to agree with you (we implemented the priority rule first, and it's currently the only option) but I think it's reasonable not to want it.

This will probably end up looking more like very lightweight filtering (a "View this board arranged by <nothing, priority, ...>" option in the UI), not some sort of permanent board setting.

There's currently no way to set absolute priority, only priority relative to other tasks in the column. Earlier mocks had slots for each priority:

https://secure.phabricator.com/M10/10/

Implementing those might help provide a stronger visual cue about the priority-ordered nature of the columns, too.

See also T4476.

I like the idea of "slots" in the board UI (it would be a config setting: "show slots" I assume). Is there a task tracking this specific enhancement?

(from my merged T5675) I think the most confusing aspect of the current behavior is when a task exists in two separate projects. Dragging a card up or down in a list can change the priority globally, which then silently reorders cards on all other boards the card appears on. This can be confusing for other teams, who seem to lose control of their own boards.

This is now live on this install. In particular:

  • There is a new "Sort" dropdown menu in the upper right when viewing a board. This defaults to "Natural", and also allows you to select "Priority".
  • "Priority" is the old mode, and works just like it previously did. It is no longer the default, and must be explicitly selected.
  • "Natural" is the new mode. The intent of this sorting mode is for the board to work like a whiteboard with sticky notes on it and for things to stay where you put them and not cause surprising side effects.
    • Cards have an internal ordering on the board, and changing their position does not affect anything else or any other boards.
    • When stuff is added to a board (for example, tasks are tagged with a project), the new stuff floats to the top.
      • Things float to the top based on when they were added to the board, not when they were created (so an old task which was recently added will float to the top).
      • (When a group of things are added at the same time, the most recently created stuff within that group does sort above the less recently created stuff.)
    • Overall, this should implement a more natural set of rules, with the backlog column serving as an approximately-FILO stack.

The ordering code is somewhat complex so I might have missed some edge cases, let me know if you catch anything odd.

This looks good. Thanks for all the work to implement "natural" ordering.

This seems to be working OK. I'm going to close this out; you can find some followups here:

  • I assume this mitigated most of the need for locking down policies around who can move things, but weigh in in T5674 if not. That task has some more discussion of context. We can definitely let you lock stuff down too, I just want to make sure we still need it after these changes.
  • We'll probably make the priority view more useful (e.g., add slots from the M10 UI) eventually, but this isn't a priority right now (ha-ha!). We could implement other orders too, although we'd probably want to do this only after improving the "priority" order, to avoid all the issues it has. If you want any of this sooner than "whenever we get around to it", feel free to file something specific.