GNOME Bugzilla – Bug 698906
selection tooltip hides search progress indicator
Last modified: 2021-06-18 15:29:12 UTC
To see the problem, go to a large folder such as the WebKit source tree, and type a search term that will match many results (such as "ab" in WebKit). Nautilus will begin searching and will briefly display a tooltip "Searching..." with a stop button. Soon after the first results arrive, however, the first result will automatically be selected and the tooltip will be replaced by information about that result, e.g. '"tables" selected (containing 6 items)'. The user has no indication that the search is still progressing; I can tell that only by seeing the CPU pegged to 100% in System Monitor. If I select another search result or control-click the first result to deselect it, the tooltip does not update for many seconds (which is a problem in of itself), but even when it updates after deselecting the message "Searching..." does not come back. In my opinion a tooltip is not a great way to indicate to the user that a search is in progress. The user may legitimately want to select search results while a search is progressing, but still deserves to know that a search is happening and to have a way to cancel it. I think a progress spinner at the right side of the search box with a small cancel button beside it would be a reasonable choice here.
The general pattern for a busy app has been to append a spinner to the app menu, similarly to when it's launching. But for a multi-window app it might not be uncommon to have multiple windows pending to finish. So perhaps the place to put the spinner is the pathbar button. As for cancelling, hitting the Esc or clearing the searchbar with the backspace icon does that, unless you're asking for something like pause. Not sure about the use case there though.
It took me a while to figure out what this bug is about - for anyone who is interested, it's not a tooltip but the floating status bar on the bottom right hand corner of the window. A spinner next to the search bar would be a good solution, but that would require some other changes first. Specifically, we'd need to constrain the width of the search bar so that there is space to add the spinner. This would actually be desirable from a consistency point of view (since we don't tend to have an expanded search bar in the other applications), however it would leave the <this location>/"All Files" toggle in an odd position. As a result, my preference would be to look at bug 701413 before this one, with a view to obsoleting the <this location>/"All Files" toggle. Once that's done, we can reassess.
Allan, thanks for the terminology clarification. It looked like a tooltip, so I called it a tooltip. :) But yes, "floating status bar" would seem to be a more accurate term. Actually I don't see how obsoleting the <this location>/"All Files" toggle is dependent on bug 701413. If we don't want that toggle, we could simply remove it. Of course, then the user would have to navigate to the filesystem root and search from there if they wanted to match any file on the filesystem. That would be the case no matter whether (and how) we resolved bug 701413, as far as I can tell. I also don't really see how eliminating the toggle is necessary for fixing this bug. It seems to me that we could insert a progress spinner in any of several places: immediately to the right of the search box, or inside (or to the right of) the path bar button, or perhaps superimposed on (or replacing) the magnifying glass icon at the left side of the search box. I think any of those places could work even if the toggle were still in place.
(In reply to comment #3) > Actually I don't see how obsoleting the <this location>/"All Files" toggle is > dependent on bug 701413. It's not about the toggle itself, but we rely on the <this location> label as the only indication of the current location. In order to remove this toggle, we need to display location information somewhere else. That's where bug 701413 comes in.
Ah, okay, that makes sense. I still think we could quite possibly find a home for a progress spinner without removing the toggle, however.
I think that we should probably try to keep the progress spinner at or below eye level of the search box, otherwise it is simply too easy to not see it. While I understand that if we remove the toggle it will allow a more seamless way to show the progress spinner I wonder if putting it next to the search bar will not be visible enough. Rendering the spinner to the search icon of the search entry seems like a good way to have high visibility and avoid having parts of the interface move around due to visibility changes.
A progress spinner on the search icon sounds good to me. Garrett, do you know if that would be technically feasible?
Created attachment 248342 [details] Screencast showing the search entry with a spinner in action (In reply to comment #7) > A progress spinner on the search icon sounds good to me. Garrett, do you know > if that would be technically feasible? Yes, in the screencast I use a GtkOffscreenWindow with a spinner running. When the GtkOffscreenWindow's "damaged-event" is emitted I update the icon.
Thinking about this some more - why is it necessary to know that the search is still taking place? Results are appended to the top of the view - the only point at which you might need to know that the search results are incomplete is if you scroll down. One obvious way to handle this would be to use chunking when scrolling the search results.
(In reply to comment #9) > Results are appended to the top of the view Not always. Search results are sorted by Relevance, not by the order they are found and loaded. If a later result ranks higher than an earlier one, re-sorting happens. [To reproduce, go to '/' and search for '.'] Which is a problem in itself, if the user tries to select a result and things move around midway. Apropos: bug 689824.
(In reply to comment #10) ... > Not always. Search results are sorted by Relevance, not by the order they are > found and loaded. If a later result ranks higher than an earlier one, > re-sorting happens. [To reproduce, go to '/' and search for '.'] > > Which is a problem in itself, if the user tries to select a result and things > move around midway. Right, I think that there are probably several other bugs here that need fixing. The first is maybe the idea of "relevance". If you are doing a simple search for a short string that is contained within multiple files, I don't really know why one file would be more relevant than another. The other is the rearranging behaviour. While it might be appropriate to do this initially, we probably want to limit how long this goes on for, and try to append search results wherever possible. In general, I think that we should have a clearer idea of where we want to go in terms of nautilus search, rather than making small fixes without knowing the ultimate goal. To that end, I've created a set of wireframes for how search should work in general: https://raw.github.com/gnome-design-team/gnome-mockups/master/nautilus/search-wires.png Some of the bugs we have, like bug 701413 will get us closer to this, and if we go far enough down this road the bug that we are discussing here should go away.
(In reply to comment #11) > In general, I think that we should have a clearer idea of where we want to go > in terms of nautilus search, rather than making small fixes without knowing the > ultimate goal. To that end, I've created a set of wireframes for how search > should work in general: > > https://raw.github.com/gnome-design-team/gnome-mockups/master/nautilus/search-wires.png Allan, could you post this proposed design to nautilus-list? I'd be interested in discussing it more, but I'd rather do that where more users can join the discussion rather than on a bug which relatively few people will see. > Some of the bugs we have, like bug 701413 will get us closer to this, and if we > go far enough down this road the bug that we are discussing here should go > away. I think this bug impedes search usability enough that we should fix it in one way or another for 3.10. If we can reach consensus on a new design for Nautilus search as you're proposed above and implement it for 3.10, then I suppose that might solve this problem. But that seems ambitious to me, both because I'm not sure everyone will agree readily (I have reservations about the chunked search results, and I suspect I will not be alone) and because it seems late in the 3.10 cycle to be proposing major changes to the search interface. Instead, I think we could pretty easily find a place in the existing interface for a progress spinner, which would solve this bug adequately for now while still leaving the door open for future changes.
GNOME is going to shut down bugzilla.gnome.org in favor of gitlab.gnome.org. As part of that, we are mass-closing older open tickets in bugzilla.gnome.org which have not seen updates for a longer time (resources are unfortunately quite limited so not every ticket can get handled). If you can still reproduce the situation described in this ticket in a recent and supported software version of Files (nautilus), then please follow https://wiki.gnome.org/GettingInTouch/BugReportingGuidelines and create a new ticket at https://gitlab.gnome.org/GNOME/nautilus/-/issues/ Thank you for your understanding and your help.