1127796 - Provide clearer success/failure feedback in the UI for retrigger/cancellation requests

Status: RESOLVED DUPLICATE of bug 1232535

(Tree Management :: Treeherder, defect, P3)

Description

[:gerard-majax]

There may be a quite long delay between the time the user clicks on "Retrigger" and the time the "retrigger sent" notification is displayed. This gets worse under bad network conditions, and made me missing several retriggers, leading to too much being sent.

Comment 1

[Ed Morley [:emorley]]

The retrigger success notification isn't shown until we get the 200 back from the API. This was presumably taking a while for you when on a slow network.

I think this is correct behaviour, however things that could help are:
* Make it clear that the retrigger button was pressed (turn it into a spinner or something)
* Make error messages persist for longer (or until closed)

Have I understood correctly? Which of those two suggestions (or both) would you find useful?

Comment 2

[Jared Wein [:jaws] (please needinfo? me)]

In my usage, I often click three times quickly to request three retriggers (when running Talos jobs to get an average or seeing if an intermittent orange is fixed).

Therefore, I would prefer not disabling the button but making it clear that a request has been sent. Three clicks on the button could show three "Request sent" notifications which can then change one-by-one to saying "Request successful".

Comment 3

[Wes Kocher (:KWierso) (Not reading bugmail; email directly if needed)]

FWIW, my usage is much like jaws's.

Comment 4

[:gerard-majax]

(In reply to Ed Morley [:edmorley] from comment #1)
> The retrigger success notification isn't shown until we get the 200 back
> from the API. This was presumably taking a while for you when on a slow
> network.
> 
> I think this is correct behaviour, however things that could help are:
> * Make it clear that the retrigger button was pressed (turn it into a
> spinner or something)
> * Make error messages persist for longer (or until closed)
> 
> Have I understood correctly? Which of those two suggestions (or both) would
> you find useful?

Persisting states would be a big help yes, especially for error cases. All will depend on your definition of "longer". I would rather see some kind of console dedicated to this, so we can append errors and leave them there until the user acknowledges it.

Remember, the bad usecase: trying to retrigger when in the train, with crappy network that will get down every minute.

Comment 5

[Ed Morley [:emorley]]

It sounds like we should:
1) Provide a clearer indicating that a retrigger/cancel click actually did something. ie: make the retrigger/cancel icon spin/change colour, or make the popup message on the top right hand side more obvious/add an animation/move the popup from the right hand side to the left or lower of the screen etc.
2) Whilst a request is still in progress, have a persistent "sending request 4 of 15" banner/progress text thing, a bit like we had for TBPL.
3) Make failure messages persist until an "X" is clicked for each (with a clear all button perhaps).

Comment 7

[Ed Morley [:emorley]]

s/indicating/indication/

Also if anyone has any other ideas beyond those in comment 5, I'm all ears :-)

Comment 8

[:gerard-majax]

I think if we have all that is documented in comment 5 it will be good :)

Comment 9

[Jonathan French (:jfrench)]

This all makes good sense to me in comment 5. Perhaps for 1) we might consider making those current "retrigger sent" balloons, "retrigger (n)" sent, if they aren't already? For 2) I wonder if we might present it in the resultset bar. eg. in a 5 job retrigger:

"5 re-triggered   99% - 5 in-progress"

or for a push which had 118 pre-existing running jobs:

"5 re-triggered   73% - 123 in-progress"

And then when everything is done, we go back to "- Complete -" as usual.

Comment 10

[Ed Morley [:emorley]]

(In reply to Jonathan French (:jfrench) from comment #9)
> or for a push which had 118 pre-existing running jobs:
> 
> "5 re-triggered   73% - 123 in-progress"

You mean just for the duration of sending the retrigger requests and waiting for the response? (ie not until the job actually runs, than completes)

Comment 11

[Jonathan French (:jfrench)]

(In reply to Ed Morley [:edmorley] from comment #10)
> > "5 re-triggered   73% - 123 in-progress"
> 
> You mean just for the duration of sending the retrigger requests and waiting
> for the response? (ie not until the job actually runs, than completes)

Initially I was thinking until the job completes, in case the user wasn't sure later on whether or not they had actually retriggered jobs in a given resultset.

But if you think only up until a response makes more sense, and then when the response comes back and the job starts it disappears that sounds good to me. Mostly I was just thinking of an economical way to present the information.

Comment 12

[Ed Morley [:emorley]]

That will be much more complicated to implement -  ie how do you associate the retrigger requests with the new jobs? Does someone's retrigger on another machine cause the notice on mine too? If we're displaying something special for these, should we also for retriggers that come from other places (eg the backfill script that Armen wrote)? </devil's advocate> :-)

Comment 13

[Jonathan French (:jfrench)]

1+ we should do whatever is easier and solves the user problem, I was thinking mostly about just where to present the information, ie. without creating more ui clutter. If it's a local request, I was thinking it might just be a local overlay element, but which cosmetically looks like its part of the resultset bar data.

Maybe that would be confusing if two users are comparing the same resultset, I dunno.

Comment 14

[Jonathan French (:jfrench)]

(In reply to Alexandre LISSY :gerard-majax from comment #0)

Fyi, we also now have a Recent Notifications history dropdown in the navbar so you can see what events have happened. But I think the presence of just-issued retriggers would not appear there any earlier than our regular retrigger notification.