search needs polishing

[butonic]

While we are planning to move to a filter philosophy for OC6, we still need to polish the search experience in OC5.

• text editor does not show the correct folder when opening a file from a search result master stable5
• the gallery is not integrated at all
• when in the gallery app css layout of search results is broken
• when in the gallery you cannot open text files from the results Uncaught ReferenceError: FileActions is not defined
• Long search results are not fully displayed due to missing scrollbar: Long search results are not fully displayed due to missing scrollbar; Ticket#2013072508000607 #4236 PR master stable5
• race condition when typing in the search bar causing multiple result panes to stack, mixing results and always leaving a result pane open. needs a page refresh to get rid of. seems to occur only when multiple search providers are used?
• implement search in shared files: Search function does not work on shared folders #744 PR master
• It is not clear when clicking a search result will open a special app and when it will open the files app. This is a problem when I want to share a text file, search for it and then have to navigate to the file to share it. PR: master

I would like to solve the problem in the following way, to unify the search experience: All search results for file resources should bring you to the files app, in the correct folder with the searched file highlighted and scrolled to the top. Then you can decide whether to share or open the file, image or audio file. (I have this working at a customer for OC4.5, so I just need to port it.)

Currently, ownCloud deals with files in the first place. A search result should therefore take you to the resource. @jancborchardt I know this is different than the "open in specialized app" approach, but I am trying to find an intermediate solution. Maybe we can add a folder icon to the search results that will always take you to the files app, while clicking somewhere else on the result will open the specialized app.

Have a look at this mockup:

The files should show the mimeicon instead of 'Music', 'Text', 'Calendar' or 'Folder'. Now that I look at it, the mp3 should show the song meta tags and the image exif data if available. The greyed out folder is only visible when hovering over a file and will take you to the containing folder, highlight the file and scroll it to top as described above. Clicking anywhere else in a result will take you to the specialized app if available. Also, I forgot to add a scrollbar to fix #4236.

This changes the way audio files are handled, because this would also show you all songs.

Contacts, calendar entries and similar are unaffected because no file based representation exists.

@karlitschek @jancborchardt @DeepDiver1975 @icewind1991 @bartv2 @Raydiation @andrewsbrown opinions? ideas? feedback?

[abrown]

@butonic, I'm definitely more concerned about the code behind the scenes. I agree with all of the cosmetic fixes/bug fixes, but would you consider adding stuff to your list above? Specifically I am talking about fixes I'm proposing to the internal search classes as described at #1473 (comment) (see last few comments). What do you think?

[butonic]

now that I had a good look at the current search code I better understand your proposal and wholehartedly agree. subclassing OC_Search_Result is a clean way of implementing it. Two notes: let us make it \OC\Search\Result and make it cleaner how they are searialized to JSON. Currently actions are added via JS. IMHO that is ok. For the current layoud I would actually like to alway show the folder and highlight the clicked file. that would make clear what the search results are for: finding stuff and not letting you decide what do to with it in the same step. For a gnome shell / unity style overlay search that is a different topic.

[abrown]

Putting off my search app idea for later is fine; as long as we upgrade the internal search code now I can easily build the app later. I'm concerned that changing things will break stuff, like all the apps hooking into the old system, and I don't want to get flamed for that. Should I just make the changes in a new pull request and hope no one flips out?

[butonic]

@andrewsbrown ok, let us discuss the internal search code in #1473

[lyallp]

This is a copy of a forum post I made for OC 5.0.6, but it is still applicable to 5.0.10 and is applicable to Firefox and Chrome.

I am unsure if this is an appropriate place to mention this but I figure rather than creating a new issue, I would add my voice to an existing one.

I find the search for contacts to be rather counter intuitive.

Firstly, it seems to take ages before showing anything. There is no visual indicator that anything is happening.
Secondly, it is not obvious if I need to press Enter, though it is not necessary, I am unsure if actually pressing ENTER will do anything additional or simply causes another pause and refresh of the search results.
Thirdly, once results start returning, the results repeat the same entry multiple times, sometimes 3 or more times, generally twice.
Fourthly, the search results 'pane' is partially obscured with the scroll up button completely missing
Finally, how in blazes do I closed the search results? There is no 'close' button or clearing the search entry box or pressing ESC does nothing. I have to navigate to calendar and back to clean things up.

I have turned off full text search app but contacts and calendar entries still show duplicate results. I really only use calendar and contacts, nothing too fancy.

[abrown]

@lyallp, I agree with you that the UI might need some tweaking: maybe a working/spinner icon to let you know it has made the request and a close X in the corner. I do remember that several of the search providers would return multiple results; after I finish #1473 I will look into fixing these.

[karlitschek]

@butonic What is the status here?

[karlitschek]

Removed from ownCloud 6 milestone and removed Engineering flag

[butonic]

closing because OC5 will only receive critical security updates. Future work is discussed in Design Forward: Search - redesign to filter in app + results from other apps.