Page MenuHomePhabricator

drag & drop on a workboard sorted by priority behavior is surprising
Closed, ResolvedPublic

Description

I've been trying to figure out some spooky 'why did my ticket priority change' issues and believe it is related to the behavior when a workboard is sorted by priority.

  • Sort workboard by priority.
  • Lackadaisically drag a card from one column to another.
  • The priority of the task is changed based on wherever your mouse pointer happened to land.

I understand that this makes a certain sort of sense but the reason I sort by priority is because I don't want to worry about sorting order. Instead the actual priority changes which matters even more than the natural sort. This is exacerbated by the difficulty of scrolling with long columns (T5240).

It's also results in inconsistencies with the natural sort behavior: with natural sort dragging to the bottom of a column makes that task the least important thing in that column, while with priority sort it makes it tied with whatever is currently at the bottom (if everything is Normal you can't drag to Low).

Related Objects

Event Timeline

cburroughs updated the task description. (Show Details)
cburroughs raised the priority of this task from to Needs Triage.
cburroughs added a project: Workboards.
cburroughs added a subscriber: cburroughs.

See T5474. I'd expect this to get resolved as having this automagical prioritization trigger be made more explicit alongside the rest of T5474. I should go on the record that I love this behavior and wouldn't want to simply remove it. :D

It's also results in inconsistencies with the natural sort behavior: with natural sort dragging to the bottom of a column makes that task the least important thing in that column, while with priority sort it makes it tied with whatever is currently at the bottom (if everything is Normal you can't drag to Low).

I think that should be fixed here too, though its unclear to me how to go from currently-tied-at-Normal, to letting you drag to Low and even lower priorities which may exist . Kind of reminds me of T8120.

See T5474. I'd expect this to get resolved as having this automagical prioritization trigger be made more explicit alongside the rest of T5474. I should go on the record that I love this behavior and wouldn't want to simply remove it. :D

I get the workflow where this could be nice for re-ordering within a column, but how often do you move between columns and change priority at the same time on this install?

I do this all the time. For example, new conpherence bugs are filed and are in the "backlog" column. I then drag them to "v2" (if I think they are pressing and they tend to be bugs being reported) and change priority at the same time. I don't change priority as often if moving from v2 to v3 but its also not a rare action and its easy for me to just drag it to the right spot to not change priority. <3 <3 <3 this feature :D

That said, I don't triage the whole install via a project workboard; just ones I am actively working on like conpherence.

Huh weird, our desires for what this feature would do are just complete opposites.

omgsurvivor

I tried carefully dragging a Low priority task from column A to the bottom of column B where the lowest priority so far was Normal. This still changed the priority from Low to Normal.

epriestley added a subscriber: epriestley.EditedMay 14 2015, 1:05 PM

I think the likely way forward is:

  • Distinguish between "drag to column" and "drag to position". This probably means that dragging a card near a column moves it to "the same place" in that new column, and dragging a card into a column moves it to a specific position, but maybe this actually needs to be more complicated and/or have preferences ("never drag a card to a specific column position in the priority view unless I hold shift"). In the "natural" ordering, these operations would be identical.
  • Add priority-level dividers to columns sorted by priority so that all priorities are selectable, per this mock: https://secure.phabricator.com/M10/10/

This represents a fair amount of work and only affects the priority ordering, which I believe is only lightly used after the introduction of the "natural" ordering, so it's hard to prioritize work here.

I tried carefully dragging a Low priority task from column A to the bottom of column B where the lowest priority so far was Normal. This still changed the priority from Low to Normal.

I believe this worked at one point, so I may have broken it (likely in connection with D12121) or there may be a later-introduced interaction complexity, like a lower-priority task in the column which wasn't visible in your current filter.

Broadly the way forward make sense to me.

and only affects the priority ordering, which I believe is only lightly used after the introduction of the "natural" ordering, so it's hard to prioritize work here.

I'm not sure what you mean by 'lightly used'. This install certainly doesn't leave everything in 'Needs Triage' and then just rely on natural sort ordering on workboards and @btrahan is a fan.

I tried to repro on this install with #cburroughs_personal_test_project so there are not a million spooky closed tickets. The starting position was a wishlist task in column A, and a Normal one in column B. I then dragged from A to the bottom of B.

I'm not sure what you mean by 'lightly used'.

Oh, I just mean "order by priority, on workboards", not priority as a whole.

chad added a subscriber: chad.May 14 2015, 2:29 PM

  • I had originally designed dividers into the columns for clarity. We removed them since typically they're clutter, but I wonder if we could instead just activate them when hovering a card over a column.

    In T8135#113908, @chad wrote:

    I had originally designed dividers into the columns for clarity. We removed them since typically they're clutter, but I wonder if we could instead just activate them when hovering a card over a column.

    I was thinking of just adding them unconditionally --but only when ordering by priority -- per above:

    Add priority-level dividers to columns sorted by priority so that all priorities are selectable, per this mock: https://secure.phabricator.com/M10/10/

    Do you think they're too cluttery to show by default even in the priority ordering?

    chad added a comment.May 14 2015, 2:34 PM

    haha, I didnt see your comment. I do think they may eat up space on active, large boards, but maybe it's not a problem. I thought you were the one to originally not want to build the indicators. Visually, we can reduce the UI a bit, no problem.

    Yeah, I think we can probably slim them down a hair and make them work. Installs that define 200 priorities will get questionable results, but I don't feel too bad about that.

    brablc added a subscriber: brablc.May 19 2015, 7:12 AM
    brablc added a comment.Aug 7 2015, 2:02 PM

    This was causing a lot of headache to our team, so we simply switched off change of the priority (by @erik.fercak), may be this would help someone too, until the problem is resolved:

    diff --git a/src/applications/project/controller/PhabricatorProjectMoveController.php b/src/applications/project/controller/PhabricatorProjectMoveController.php
    index a22050e..023b1c0 100644
    --- a/src/applications/project/controller/PhabricatorProjectMoveController.php
    +++ b/src/applications/project/controller/PhabricatorProjectMoveController.php
    @@ -130,7 +130,7 @@ final class PhabricatorProjectMoveController
             }
           }
    
    -      if ($pri !== null) {
    +      if (false && $pri !== null) {
             $xactions[] = id(new ManiphestTransaction())
               ->setTransactionType(ManiphestTransaction::TYPE_PRIORITY)
               ->setNewValue($pri);

    Every... day...

    angie added a project: Restricted Project.Sep 21 2015, 9:53 PM
    chr86 added a subscriber: chr86.Jan 11 2016, 10:36 AM
    epriestley moved this task from Backlog to v3 on the Workboards board.Feb 11 2016, 5:40 PM
    epriestley edited projects, added Workboards (v3); removed Workboards.
    cburroughs added a project: Restricted Project.Apr 20 2016, 3:51 PM
    cburroughs moved this task from Restricted Project Column to Restricted Project Column on the Restricted Project board.Apr 20 2016, 3:56 PM

    Could you please raise the priority of this issue? It's a daily nightmare for all folks here.

    chad added a comment.Sep 26 2016, 11:21 AM

    I consider this mostly resolved. Can you open a ticket with complete steps to reproduce per Contributing Bug Reports if you are still seeing issues. I honestly have no idea what "nightmare" or "here" means.

    Hi @chad , I'm talking about this issue : "drag & drop on a workboard sorted by priority behavior is surprising" which I understand to be the scenario where you move a task form a column to another in a board and if you're sorting by priority the task might have its priority changed depending on where on the column you drag it.
    This behaviour in completely insane - I understand that someone may have thought of this being a shorthand - but it's a very bad idea to implement this behaviour by default.
    Apart from this, Phab is awesome.

    chad added a comment.Sep 26 2016, 12:45 PM

    It isn't the default.

    chad added a comment.Sep 26 2016, 12:54 PM

    Natural sort is the default. If you switch sorting by priority, then this feature comes up. The only thing left on this task (since natural sort is now the default) is implementing a UI around the drag and drop for clarity. T10333 is that task.

    I do wonder @epriestley if we can out-right remove this feature from "sorting" and push it into T10333 under "grouping".

    @chad, T10333 may address this, but looks very complex for a very simple issue.
    Believe me, everyone using phab in my company complained about the priorities being automatically changed.
    Sorting by Priority is a very common/natural way of using boards.
    You should at least propose a setting in Phab to disable this feature - this would make everyone happy.

    I think of T10333 and what remains here as mostly the same task -- I don't plan to make sorting and grouping separate (offhand, I can't come up with much of a good reason to group + sort, and if we did support that it would recreate a small version of this problem within groups).

    We could replace the words "Sort by" with "Group by" in the menu after T10333 if that's clearer, but since "Natural" will remain ungrouped I worry that might be less clear.

    chad added a comment.Sep 26 2016, 1:09 PM

    I think my question is, maybe noone wants this feature.

    @chad Oh, maybe I'm misunderstanding. What are you proposing, specifically?

    chad added a comment.Sep 26 2016, 1:15 PM

    I assume "Group by" would have dragging support, so by assignee, I could easily re-assign tasks. With that in mind "Group by" and priority, you could drag and drop by priority, thus allowing us to remove the "automatic" feature we have today in the current priority sort.

    Sorry, I think I'm still not understanding. When the column is grouped by priority, I still expect the auto-reprioritize behavior to work more or less as it does today: if you drag a task into the "High" group, it will change to "High" priority. I don't think we can avoid that without greater confusion.

    That is, I think we must choose one of two confusing behaviors when a user drags a "Wishlist" task into the "High" priority group:

    1. Reprioritize the task.
    2. The task mysteriously vanishes (actually, is placed in the "Wishlist" group in the same column, but that group is offscreen some of the time).

    We could choose behavior (2) instead, but I think that may be worse overall. Is that what you're suggesting -- that we always do behavior (2)?

    chad added a comment.Sep 26 2016, 1:22 PM

    I'm suggesting removing it until T10333

    chad added a comment.Sep 26 2016, 1:22 PM

    I think I'm doing a bad job at saying that though.

    Oh. To me, that's sort of worse? You end up with "Sort by priority" and your tasks aren't actually sorted by priority if you've moved them between columns, and jump around if you reload, and other users won't see the same ordering if they're trying to follow along in a presentation or whatever.

    I mean, it's probably not worse-worse, and but it feels like trading one kind of confusion for possibly-moderately-less-confusion more than putting a reasonable stopgap behavior in place until we can fix it properly.

    chad added a comment.Sep 26 2016, 1:27 PM

    @olivier-squid is the main issue people don't know it's going to happen, or that we just get it wrong. Will the headers help or are you expecting this to just not happen at all when you drag (ie, no sort changes happen at all).

    Maaaybe Iam misinterpreting but if enabling sort by priority why not show in workboards something like

    LOW
    T1
    T10
    Normal
    T2
    T4
    HIGH
    T3
    T5
    T6
    UNBREAK
    T7
    T8
    t9
    In T8135#195971, @chad wrote:

    @olivier-squid is the main issue people don't know it's going to happen, or that we just get it wrong. Will the headers help or are you expecting this to just not happen at all when you drag (ie, no sort changes happen at all).

    Yes first issue is that people are unware of it. Then even when knowing it you tend to forget it (it's not intuitive).
    In fact the behavior I think users expect is that when move for a col to another the task just get placed at the right position according to its priority (if sorted by priority of course) and not the other way round (the position sets the priority as it is today).

    isfs added a subscriber: isfs.Nov 12 2016, 1:49 AM
    athulj moved this task from Backlog to Test on the Workboards (v3) board.Feb 10 2017, 11:13 AM
    athulj moved this task from Test to Backlog on the Workboards (v3) board.

    Maaaybe Iam misinterpreting but if enabling sort by priority why not show in workboards something like [...]

    Even though I understand your idea, it would not really help I suppose. The thing is, as @olivier-squid wrote in T8135#195980 people are not really aware of that feature. Having those columns is only a second way of showing priorities, it's redundant.

    Most of our users are developers and even they are not fully aware of all the magic that happens with them knowing about it. I mean, how often do you actually want to change the priority for a task that you move into progress or review? They are usually not connected. I can understand though that this might be a big feature for some people. Maybe a feature switch or something like that?

    Our developers keep changing priorities that the product owner set earlier and that's really not expected. 🙈 So, a big +1 from me on removing / reworking that feature. 👍

    hskiba added a subscriber: hskiba.Mar 19 2018, 1:56 PM
    pasik added a subscriber: pasik.May 12 2018, 1:49 PM
    epriestley closed this task as Resolved.
    epriestley claimed this task.

    Drag-and-drop between columns on a priority-sorted board no longer changes priority. See T13074 for continuing adjacent work.