Improve overall Nextcloud Search experience

[jospoortvliet]

Hi,

Right now, we have a few issues with the search, some of the main ones are:

1. it is slow
2. the dialog is too small for all but the most trivial searches
3. it shows a lot of irrelevant results

To deal with this, we now have a work-around in the app store and Files app, as well as in Deck.
Files and the app store have implemented a filter in the UI, showing search results there while the universal search pop-up is still doing its thing:

Deck just implemented a second, direct search:

Discussing it today with Andy, perhaps there is a good way we can solve all three problems in one.

We make 2 changes:

• The search is first only in context. That is, if in Talk, it shows only Talk results, in Mail shows Mail results, in Deck only Deck results and so on. This solves problems 1 (performance) and 3 (showing irrelevant results). Apps can still do a quick filter in the main dialog, but Deck, Files etc should have no more need to show the 'results from other boards' (Deck) or 'results from other folders' (Files).
• Below the results is a button: [search everywhere] This opens up a modal with results from all apps. Being a bigger modal and perhaps filters on top and some advanced search options, it should solve problem 2 quite well.

Best part is that this is probably not too crazy much work.

What do you think, @nextcloud/designers ?

[juliusknorr]

In addition we should consider always showing the current search input then if some local filtering applies, otherwise users might be confused by a filtered view when there is no clear indication where to reset or change that filter.

[solracsf]

This is directly tied to
problem 1) #23835
problem 3) #24056

[Spartachetto]

The second change proposed deals with the suggestion in #27078

[bes1002t]

Very good proposal. :)

Only question is, how sophisticated and complex could be the modal filters? But probably this is another issue to address.

[putt1ck]

Q. isn't the slow performance directly related to the number of items (in the file search at least)? If so while "de-universalising" the output is great for non-files search, how does it improve performance for file search (which I'd guess was the most common requirement for search outside of Deck-heavy installs)

[pmarini-nc]

Copy/pasting my thoughts on #29989, inappropriately marked as duplicate:

Is your feature request related to a problem?

Sometimes the user knows the search scope in terms of where he/she wants to search (e.g the App) and when (e.g the time period, for example a file created in the last week). Currently the App (or Apps) can be selected once the search has been already launched and no possibilities are given to the user to select the period.

The ability to pre-filter the search before launching it, would lead to a generally shorter search time and less load on the server, ultimately bringing an improved user experience.

This pre-filtering capabilty is already present in other mainstream collaboration platforms and can be also enriched with other items atributes, for example the owner.

Describe the solution you'd like

• Make the three-dots menu available before launching the search
• Add to the three-dots menu the option to pre-filter based on last modification date and creation date.

[jospoortvliet]

Q. isn't the slow performance directly related to the number of items (in the file search at least)? If so while "de-universalising" the output is great for non-files search, how does it improve performance for file search (which I'd guess was the most common requirement for search outside of Deck-heavy installs)

Yes, but this isn't a regression - search for all files became no slower since the introduction of universal search. If anything, it got faster. But much of the time you want to filter in the current folder, and suddenly you always had to wait for the full search. which is fixed with 23 already. With my proposal we lower the server load from search and focus on the common case of app-specific search. That does indeed not fix slow all-files search.

[solracsf]

Adding this #30311 here as it also improves it in some way.

[brtptrs]

@jospoortvliet For us the universal search meant a huge regression. In the last couple of versions we always hat to deactivate the file search on code level.
If a user with many files (many GBs ) does a search it causes huge db loads. A single users doing many searches in a short time could (and has on our system) brought down the whole system. At the moment on NC22 the file search is still deactivated for the whole system.
We have a support request on this open for a long time.

[Aeredren]

@bes1002t

Only question is, how sophisticated and complex could be the modal filters? But probably this is another issue to address.

I'll be working on search modals for the next month and a half, I'll have more info then on how difficult it is : https://help.nextcloud.com/t/looking-forward-to-develop-sorts-files-visualisation-improvement-and-filters/128314

[jospoortvliet]

Hi @Aeredren any update perhaps?

[pmarini-nc]

There's a very good application that can be taken inspiration from.

Sorts, developed by Framasoft, the code repository is here and a short demo is here

[XueSheng-GIT]

Just want to reference #35776 (comment) which shows an alternative approach by @Mer0me.
Being able to put a lot of information/files into a cloud is great. But not being able to find this info afterwards (in a quick way) is really annoying. Searching for files on my productive server (NC25) takes more than 30 seconds as detailed here #35776.

[marcoambrosini]

Some considerations on this:

1. I would advise against trying to mix the in app search with the global search

We've kind of done that that in a few apps and ended up with a bit of a usability blunder: filtering app content with an overlaying tooltip that in several cases obstructs the view of the actual search results.
See for example Deck, App Store and Tasks as an example for this. As you start typing you’ll see search results being displayed and changing underneath the search dialog.
Every app needs a slightly different interface for search. For in app search we should carefully consider those needs and have a tailored solution for each scenario.

2. Move the global search to a big dialog or full screen

Currently the global search is relegated to a very small area of the screen. If we properly address the previous point, which is a bug anyway, there is no need to keep the app UI in sight while searching.
What matters here is the search field, the filters, and the results. If we had a big dialog or the entirety of the screen for this, we could display the search app filters as buttons. This would make filtering the search and going straight to what you need much faster. Moreover:

1. once we have a filter active, we could implement lazy loading with scrolling nicely
2. Having more space would allow us to display actions on search results

here's an idea of how this could look

@nextcloud/designers thoughts on this?

[juliusknorr]

Let's focus on the UI side of this, possible performance or search backend integration should be a different issue.

[gennaios]

2. Move the global search to a big dialog or full screen

I think full screen is preferred. As one could potentially have thousands or tens of thousands or more files, and search result count could be any number, full screen would be better suited. The filter buttons in your screen shot could be moved to some sidebar similar to categories in Settings.

Concerning the previous comment about search performance, such I think goes together and was part of the original comment for this issue. Think of any search of any large web site, database, or desktop/mobile app (e.g. contacts, mail, calendar, tasks, music, etc.), none use LIKE searches. Isn't it about time Nextcloud also abandons such?

[marcoambrosini]

closing in favor of #39162