After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 698906 - selection tooltip hides search progress indicator
selection tooltip hides search progress indicator
Status: RESOLVED OBSOLETE
Product: nautilus
Classification: Core
Component: File Search Interface
unspecified
Other Linux
: Normal normal
: ---
Assigned To: Nautilus Maintainers
Nautilus Maintainers
Depends on:
Blocks:
 
 
Reported: 2013-04-25 22:45 UTC by Adam Dingle
Modified: 2021-06-18 15:29 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Screencast showing the search entry with a spinner in action (48.57 KB, video/ogg)
2013-07-03 18:09 UTC, Garrett Regier
Details

Description Adam Dingle 2013-04-25 22:45:41 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.
Comment 1 Jakub Steiner 2013-06-17 06:02:52 UTC
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.
Comment 2 Allan Day 2013-06-18 15:21:23 UTC
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.
Comment 3 Adam Dingle 2013-06-29 13:48:24 UTC
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.
Comment 4 António Fernandes 2013-06-29 15:45:35 UTC
(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.
Comment 5 Adam Dingle 2013-06-29 15:49:32 UTC
Ah, okay, that makes sense.  I still think we could quite possibly find a home for a progress spinner without removing the toggle, however.
Comment 6 Garrett Regier 2013-06-29 23:22:14 UTC
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.
Comment 7 Adam Dingle 2013-06-30 10:19:36 UTC
A progress spinner on the search icon sounds good to me.   Garrett, do you know if that would be technically feasible?
Comment 8 Garrett Regier 2013-07-03 18:09:11 UTC
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.
Comment 9 Allan Day 2013-07-04 16:44:44 UTC
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.
Comment 10 António Fernandes 2013-07-04 17:09:37 UTC
(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.
Comment 11 Allan Day 2013-07-05 11:03:11 UTC
(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.
Comment 12 Adam Dingle 2013-07-06 02:00:57 UTC
(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.
Comment 13 André Klapper 2021-06-18 15:29:12 UTC
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.