GNOME Bugzilla – Bug 753728
Ongoing operations are easy to miss
Last modified: 2018-10-21 14:10:26 UTC
During the 3.17.x cycle, we changed the ongoing operations UI: the old dialog was replaced with a button in the header bar, and an in-app notification after the operation has finished. I was recently testing master, and copied a collection of photos to my laptop from an SD card. For a while I didn't think that anything was happening, and that the paste command hadn't worked. I actually ended up trying to paste twice. The reason this happened was that I hadn't noticed the button appear in the header bar. From my perspective, there hadn't been a visible response to the paste command. Ideally, when you paste files, you would see placeholder files appear in the grid/list. These would somehow indicate that they are being copied to. This would be enough to indicate that something was happening. If this isn't possible, we should probably try and find another way to make long running actions more visible. Showing an in-app notification at the beginning of the operation is one possibility.
Created attachment 309649 [details] [review] toolbar: improve operations button attention style Instead of using blue, use a white higligth with the same colors as the current button class of adwaita.
Created attachment 309650 [details] [review] toolbar: reduce operations button timeout to show it And instead increase the timeout to hide the button to allow not flash but don't take too much in provide feedback that and operation is being done
Created attachment 309651 [details] [review] toolbar: don't update style when not needed We were updating the operations button style always that update_operations was called. Thing is that is not necesary, and can cause some anoyances in patchs that are to come.
Created attachment 309652 [details] [review] toolbar: improve operations button first feedback Users weren't noticing that the button appeared, and tried to perform the same operation again. Try to catch their attention on the button with an animation on it when the button appears.
Created attachment 309653 [details] [review] toolbar: dont update operations when no necesary We were looping with a timeout to make sure we don't miss any operation that it's time remaning was not well calculated. But we were not stoping this loop when all the operations were took into account. So remove the timeout if all the operations are being show, cancelled, or finished.
Let's merge them and we can tweak css a little more after UI freeze withouth problems. Attachment 309649 [details] pushed as b8d76f9 - toolbar: improve operations button attention style Attachment 309650 [details] pushed as 1a8fd4c - toolbar: reduce operations button timeout to show it Attachment 309651 [details] pushed as d8c6ef7 - toolbar: don't update style when not needed Attachment 309652 [details] pushed as 3cd9096 - toolbar: improve operations button first feedback Attachment 309653 [details] pushed as 6594207 - toolbar: dont update operations when no necesary
I've tried this out. The animated button isn't very noticeable, and it didn't make much of a difference to the overall experience. To be clear - I'm not even sure that animating the button will be enough to resolve this issue.
While it works on the mockup -- http://jimmac.musichall.cz/stuff/button-reveal/ -- I have to admit it's much more subtle in the actual implementation. Even if you flash it multiple times (which feels quite odd).
Created attachment 310021 [details] [review] toolbar: adjust animation colors Make the highlight more apparent - it seems we can't do animation-direction so I've made the highlight last longer by using two keyframes, since we cannot do the classic ping-pong animation and adjusting the ease-out - colors are takend form the theme, not hardcoded Unfortuntaley the highlight at the end of the animation still feels awkward, being cut off and fading. Not sure where that's happening.
Created attachment 310024 [details] [review] toolbar: adjust animation colors Make the highlight more apparent - it seems we can't do animation-direction so I've made the highlight last longer by using two keyframes, since we cannot do the classic ping-pong animation and adjusting the ease-out - button gradient colors are still mostly hardcoded as no color ops available in css. :(
We're getting reports that the button is still being missed, so reopening.
An additional visual aid for the headerbar button changes could be this highlight slide: http://jimmac.musichall.cz/stuff/button-reveal2/ (click the blue button) It draws attention without being tacky.
*** Bug 757415 has been marked as a duplicate of this bug. ***
I fear the visual aid proposed in comment 12 will still be *way* too subtle. I will most likely miss it, and the casual users I'm dealing with will absolutely miss it. Have you considered either having a temporary (ex: 5 seconds, then fades out) popover "balloon" that indicates that hey, "Files have started transferring/copying/etc. in the background." pointing to the button in question? Or even bolder: not having that button in that colourless toolbar, but as part of a GTK InfoBar below it (above the contents view), which would be by definition impossible to miss, without forcing a modal workflow?
We are working on it
Created attachment 317349 [details] [review] toolbar: show operations popover at start It was not noticeable enough when a operation started. For 3.18 we don't have much more room to experiment ways to increase it, so go for the easier solution and show the popover when a operation starts.
Showing the popover at the start makes it noticeable enough. So mark as fixed. Maybe we can find more elegant solutions for 3.20. Attachment 317349 [details] pushed as 5ce09ad - toolbar: show operations popover at start
*** Bug 755452 has been marked as a duplicate of this bug. ***
*** Bug 755744 has been marked as a duplicate of this bug. ***
Because I seem to be the only supporter of the Konami™ reveal, here's an alternative attention-grabbing reveal based on a prototype by Christian Hergert. https://www.youtube.com/watch?v=ovajZQ8mxGY
+1 setting as per 3.24 and for newcomers with gtk+ experience
The ideal world for me would be having the popover shown at the start and have it gently "fold" into the button with an animation after 3 seconds so you clearly see where it's going.
(In reply to Jean-François Fortin Tam from comment #22) > The ideal world for me would be having the popover shown at the start and > have it gently "fold" into the button with an animation after 3 seconds so > you clearly see where it's going. I kinda like that idea. You'd need some extra smarts to avoid hiding the popover when someone is trying to interact with it though, like keeping it visible when the pointer is hovering over it, or even if the pointer is moving towards it.
Created attachment 345677 [details] [review] toolbar: add theatrics animation to the operations button We have been going back and forth of a solution to make the operations button noticeable enough once it appears. First we implemented a highlight inside the button. But that wasn't enough, so we had to show the operations popover at the start. That is not really good because it appears in every window, and the user has to explicitly close it, which is annoying. This patch implements another animation highlight, which is more visually bold to try to catch the attention, in order to not need to show the operations popover.
Let's close it as fixed for now with this new animation. Let's see how it works out. Attachment 345677 [details] pushed as 7f8cc0b - toolbar: add theatrics animation to the operations button
To be honest, I do not think that this is enough (if this has been tried to be resolved by the "popping" animation along the "ongoing operations" icon). I am on GNOME 3.28.2 and it took me some time until I realized where the state of extracting / copying things was going. Until I realized, I was firing off extract operations multiple times. Thinking that my parents will use the new GNOME some time as soon as it arrives in EL is a nightmare. I think that the "Ongoing Operations" dialogue should be expanded as soon as a relevant operation is ongoing. This would be much more clear + usable. It would be nice if there was a better solution.