Refine Searchbar & Searchpreview

[tbsbdr]

Replaces current filter & search

Initial state

Focused (empty / cleared)

Shows most recent search terms of the user; most recent on top.

• no "clear- ╳"
• no "enter- →"

Searching

shows search spinner + text "Searching ..."

if text is entered:

• show "clear- ╳"
• show Divider
• show "enter- →"

No results found

Recent-Suggestions

• Show 3 most recent matching suggestions
• Show "Searching-Indicator" if system is searching

Show Quick results

• Show 1-3 most recent matching suggestions 
• Show 1-4 best matching resource results
• Speed 🚀 up resource results: if the current folder contains matches (filter) those are shown first in the resource results (c.f. (FR) Change behaviour of Search Bar to list results from current folder listing first #7099)
• Show "Show all" option (same effect as <enter> or → )

Select results 1

• <Arrow down/up> browses through the result list
• If one of the "recent matching suggestions" is selected, the form text gets updated, but the Quickresults don't update! (why? user should be able to browse through a stable quickresult list)
• <enter> shows full search result page for the current searchterm

Select results 2

• If a resource is selected, the standardaction is executed on <enter>

Browsing ⬇️

Browsing ⬇️

Browsing ⬇️

Show all

• Show "Show all" option (same effect as <enter> or → )

[AlexAndBear]

A little note according to the screenshots: We have a hard limit of 200 search results, even in the list. So "Show all 849 results" is technically not possible.

[AlexAndBear]

Additionally: If this will omit the "Search in current folder" search provider, I would be more than happy.
We can also think about increasing the max search result limit of 5 in the preview search, as I don't think this is reasonable

[kulmann]

Additionally: If this will omit the "Search in current folder" search provider, I would be more than happy.
We can also think about increasing the max search result limit of 5 in the preview search, as I don't think this is reasonable

Yes, the idea here is to completely get rid of the filter search provider. User testing showed that it is really hard to understand when to search and when to filter with the current approach, so we wanted to go back to "only searching". Filtering will probably come back at some point in the future, but closer to the file list.

[kulmann]

@tbsbdr just to be clear, a search term history in focused & empty state would need to be solved via localStorage at the moment. We don't have a way to store such information in the backend. For the Recent-suggestions we'd have the same limitation.

[tbsbdr]

need to be solved via localStorage

totally fine - the recent suggestions is just nice-to have; I'm happy if we remove the current search all files and search current folder options and replace them with the behaviour described above.

[AlexAndBear]

Thanks for clarification. @kulmann Would you like to decide which features we like to implement until GA?

[kulmann]

I think the following work packages make sense:

1. remove the filter search provider entirely, but keep ui layout as is (including the "Search all files" list item, because otherwise there'd already be a lot of changes needed regarding keyboard interaction with up/down arrows and enter)
2. adjust search bar and list below as described in the ticket, but without the search history
3. search history (x recent terms if input is empty / x prefix-matching recent terms upon typing)

Having 1+2 for GA would be awesome. 1. is the minimum requirement. What do you think? If you can come up with a more fine grained approach for 2. I'd be happy as well. ;-)

[AlexAndBear]

100% agree, will do.
@tbsbdr Thanks for the work&mock ups, this will indeed improve the search experience for the user!

The only thing we need to have a look at, is that the backend might be able to handle the recent search results correctly. For me this means that the files in personal home will have a higher score than somewhere else.

Still don’t know what to do with the show 800 more results… As I mentioned before we have a hard limit of 200.

What’s about the search limit for the preview?
5 is IHMO a little to less

[AlexAndBear]

Action items:

• Add mark js
• Remove filter search provider
• Add Searching text to loading spinner
• Add 'Show all ... results link'
• Enable Keyboard navigation
• Default action / link on list element
• Close search on action (open folder / default action)
• x Button shoud not navigate to the last page
• Previews must be scrollable if view port is too small
• Remove user management provider, instead we use a second search filter input (Usermanagement Search is inconsistent / confusing #7613)

[kulmann]

The only thing we need to have a look at, is that the backend might be able to handle the recent search results correctly. For me this means that the files in personal home will have a higher score than somewhere else.

Regarding relevance score, In general the REPORT request is supposed to carry a property oc:search-score. Not sure if that's already implemented in ocis (in oc10 we have it if the search backend is search_elastic). If that exists you could use it to sort by relevance.
See here for oc10 reference: owncloud/core#38787

Still don’t know what to do with the show 800 more results… As I mentioned before we have a hard limit of 200.

Just show Show more results instead for now.

What’s about the search limit for the preview? 5 is IHMO a little to less

Let's play with that, I also think that something like 8-10 would be good. Just make sure that it's scrollable if we don't have sufficient viewport height.

[AlexAndBear]

Thx for clarification, can we please think again about clicking the x will redirect to the previous page?

It is awful… if I enter a search term and will be redirected to the search route, enter a new term and click x, I will be redirected to the previous search page. This feels pretty bad and confusing.

@kulmann mentioned already that a redirect to “/“ would be sufficient and I like to agree

[kulmann]

Thx for clarification, can we please think again about clicking the x will redirect to the previous page?

It is awful… if I enter a search term and will be redirected to the search route, enter a new term and click x, I will be redirected to the previous search page. This feels pretty bad and confusing.

@kulmann mentioned already that a redirect to “/“ would be sufficient and I like to agree

Yes, had the same impression, the UX on subsequent searches feels just wrong.
Another idea would be to use the closeApp function from the useAppNavigation composable that we're already using in apps like web-app-preview. As long as the origin route is provided in the URL (look for how we build the route query to editor apps in filesACtions.ts#$_fileActions__routeOpts) the closeApp function navigates you back to your origin. Must stay the initial origin on subsequent searches then.

[tbsbdr]

Update - added to initial post:

Speed 🚀 up resource results: if the current folder contains matches (filter) those are shown first in the resource results (c.f. #7099)

search currently feels quite slow but speed is really crucial for acceptance of a search function. The item above is a suggestion so that we can serve an appetizer for our waiting visitor until the main course (real search results) is served. what do you think? @kulmann @janackermann

looked fast enough on @janackermann local system. ignore the above.

[tbsbdr]

@janackermann @kulmann as we talked about the future of search in Infinite Scale I'm droping here a draft so that we have a foundation for discussion. I'll schedule a meeting so that we can cherrypick and slice:

[AlexAndBear]

Good idea to add markjs (yellow text background) added to tasklist.

Question: When no contacts are found, the whole section contacts should not be displayed, right?

[tbsbdr]

Jep, right