New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Browse preview block Query input could use more explanation #1119
Comments
Additional thing. In the "Martha" example above, the search returns everything, which was also confusing. In the current/advanced situation, we should probably do some validation about whether it parses as a legit query, and signal that if not. |
A possible complication: the universe of things that techincally is a valid query string is pretty big so it might be tough to have that be both accurate and useful. We could report the number of results, maybe? And/or print out what filters are applied? (not sure how easy the second is but we have a helper for that) |
For the situation I saw today, it seems like just checking if the string in the input begins with |
For clarification: more explanation in the interface, but not in the documentation? Or does it need further emphasis there as well? |
It's clear in the documentation. Just not at all clear in the interface when people use Omeka S without -- shockingly! -- not having read through the documentation before using it. I strongly think that the bifurcation of simple and advanced searches is the way to go, but is too much for 1.0. |
We should make a link to https://omeka.org/s/docs/user-manual/sites/site_pages/#browse-preview |
Seems like lots of people expect the "Query" to accept a simple string, and look only for items within that site's pool. For example, in the sandbox within the Martha Washington site, a group at DCMI expected to be able to enter "Martha", and get the results of the search same as on the public side simple search.
The fact that it's really the query string from the url is documented, but that complication isn't really signaled in the interface.
We should either make that more clear in the admin interface or try to separate the simple and advanced types of search. Simple would just take the string and essentially assume its
/?search=martha
in the above example. Advanced would work as it does now, and we'd signal the difference better in the interface.The text was updated successfully, but these errors were encountered: