Skip to content

Conversation

@jqnatividad
Copy link
Contributor

By adding “Suppress search = FIELD1, FIELD2”, the app creator can
exclude FIELD1 and FIELD2 from Search results

By adding “Suppress search = FIELD1, FIELD2”, the app creator can
exclude FIELD1 and FIELD2 from Search results
@jqnatividad
Copy link
Contributor Author

This is especially useful if the Miga app is using fields with URLs (e.g. Video, Audio, Documents, URLs, etc.) because sometimes embedded strings within these URLs confuse non-technical users or are false positives.

@yaronkoren
Copy link
Owner

Would this be done only for URLs? If so, there are a few other options:

  • Exclude URLs from search
  • Make the display of URLs in the search results nicer: instead of displaying "http://abcdefghiSEARCH_STRINGjklmnopq", just display "...ghiSEARCH_STRINGjkl..." or something.
  • Don't display the URL at all in the search results; just show the page.

I guess a lot depends on whether the issue is more user confusion, or false positives. Do you have any thoughts on that?

Missed check in previous commit
@jqnatividad
Copy link
Contributor Author

In our case, its both, but more of a user complaint.

Right now, the search hit is shown in context, which is right and I would point the user to how Google does it. However, with URLs, the context display is long and shows url encoding characters, slashes, and directory structure which doesn't lend itself to word-wrapping in small displays, which also contributes to a less effective user interface.

Also, the directory structure of the rich media fields (Video, URL, documents, etc.) are in a multi-level directory with very expressive names which generates a lot of false positives on the directory names.

As for the options:

  • Exclude URLs from search: I hesitate from making it a universal setting. There may be times when the URL structure is pretty flat, and I would like to search on the media names (e.g. http://site/media/2012_annual_report.mp3 and I can search for "mp3", "report")
  • Nicer URL search display: its actually being displayed in context with the surrounding ellipsis, but it will still generate false positives on directory names.
  • Don't display the URL at all in search results, just show the page: what if the only hit is on the URL? When you click on the page, the user won't be able to see where the hit is if its a PDF file and the PDF is rendered visually.

I think we should keep the default behavior of Miga on searching on everything, unless its curated by the app creator who may have some special requirements. Configuration by exception - keeping with the "Keep It Simple" Miga philosophy.

@yaronkoren
Copy link
Owner

Well, the real goal of Miga (or one of them) is to keep configuration stuff to a minimum, by making the code as "smart" as possible; which keeps things simple on the user's side, but not necessarily on the code side.

The current solution isn't bad, but maybe there could be something a little smarter. The examples you give bring up an idea: what about only searching on the file name, i.e. ignoring everything before the last slash in the URL? That seems like it could be a reasonable compromise that keeps the search to only the relevant stuff.

@jqnatividad
Copy link
Contributor Author

That works! And since filenames are normally short, show the filename in its entirety, and do only context highlighting in the filename. Nice!

@yaronkoren
Copy link
Owner

Right, only show the filename part as well. clap clap yay!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants