Browse filter results on page

[litvinovg]

VIVO PR

What does this pull request do?

• new page content type "Browse search filter results" to display search results limited by selected filter. Also additional filters and sort options could be defined in custom page template (template example)
• new facet autocomplete input field that appears if number of facets in bigger than more limit defined for the filter
• new property to limit variables of document modifiers to be populated into search indexes

What's new?

Refactored PagedSearchController.
Added search filter option to ManagePageGenerator
Refactored ProcessN3GetterDataMap
Created new data getter class display:SearchFilterValuesDataGetter , java implementation in SearchFilterValuesDataGetter.java
Created object property search:direction to configure sort direction of filter values and search results.
Created filters to filter result in alphabetical indexes
:filter_label_regex - default regex filter that uses i18n field :field_label_display with name locale + _label_display
:filter_raw_label_regex - fallback regex filter that uses nameRaw search field for VIVO instances without i18n support
search:limitDisplayTo object property was created to limit user access to display of search groups, filters, values.
Resolved bug on search page which appears if user select too many filters. In that case search results are empty and selected filter values are not shown on the page, so the user can't unselect them.
Added options to sort results, number of results on page and "Download results" options on custom pages

Applied changes for search ontology (from ontology interests group meeting)
Removed search:isAscending boolean data property, new object property search:direction should be used instead.
(search:isAscending is still could be used for backwards compatibility).
Removed search:reverseFacetOrder boolean data property, new object property search:direction should be used instead.
(search:reverseFacetOrder is still could be used for backwards compatibility).
Renamed search:order integer data property into search:rank,
(search:order is still could be used for backwards compatibility).
Created class search:SortDirection and two individuals search-ind:ascending and search-ind:descending to be used with search:direction object property.
Added facet autocomplete input field that is being visible in case filter has number of values greater than limit of facets to be shown before "more..." button

How should this be tested?

How to test new page content type:

• Create a new page in Page management menu.
• For the content select "Browse search filter results", select a type and save it.
• To select custom template select Template option "Custom template requiring content" and enter filename of custom Freemarker template in input field (Optional).
• Open page, try selecting facets, alphabetical index, pagination
• Test above in VIVO with and without language filtering

How to test facet autocomplete input

• To test facet autocomplete input you would need a filter that doesn't use URIs to store in search index. An example of modification of organization filter
• Run full search re-index after filter modification.
• You can check how it work on /search page by selecting the filter and entering at least 3 characters in input field.
• Suggestions should appear. Select a suggestion and page should reload with applied selected facet.

Additional Notes:

Examples of customized templates, document modifiers
This change require documentation to be updated.

Interested parties

@hauschke @VIVO-project/vivo-committers

Reviewers' expertise

Candidates for reviewing this PR should have some of the following expertises:

1. Java
2. JavaScript
3. FreeMarker
4. SPARQL
5. Ontologies
6. Natural language knowledge
   1. English
   2. German
   3. Spanish
   4. French
   5. Portuguese
   6. Russian
   7. Serbian

Reviewers' report template

Please update the following template which should be used by reviewers.

General comment

A reviewer should provide here comments and suggestions for requested changes if any.

Testing

A reviewer should briefly describe here how it was tested

Code reviewing

A reviewer should briefly describe here which part was code reviewed

[chenejac]

@litvinovg I don't have any big complain on your code, the implementation is aligned with other Vitro DataGetters implementations. Please find a couple of my tiny comments.

The PR feature has been tested and it works as it is described with the exception of person's publications.

[chenejac]

@litvinovg please check my comments. Moreover, the search filter by publication year requests rebuilding search index in the case some record publication date has been changed? I was expected it might be automatically done in the background.

[chenejac]

@litvinovg well done. Thanks

[brianjlowe]

Well I'm not sure I understand exactly how this is intended to work, but I'm also seeing some strange things in my initial tests.

I deployed both the Vitro and VIVO companion PRs and went to Page Management. I thought I would create a /researchers page with search filter results where type == foaf:Person.

I added a new page with pretty URL /researchers and selected "Browse search filter results" as the content type. This resulted in an "undefined" heading as seen here:

I then selected "Type" and word undefined disappeared, but Type was not indicated:

I was then expecting to then select what type(s) should be included on the page but there was nothing else to select. So I "Save[d] this content" on the right and then saved the page.

Navigating to /researchers resulted in this:

[litvinovg]

@brianjlowe I have update test instructions, please try it when you have time.

[chenejac]

Looks good, I have noticed only one issue which I will state below, but I believe it is an edge case which can be issue only if VIVO is quite empty with data.

1. On a browse custom page if someone click on a letter (for instance G) and if there is no any facet on the left side, the layout is ruined.

[litvinovg]

Looks good, I have noticed only one issue which I will state below, but I believe it is an edge case which can be issue only if VIVO is quite empty with data.

1. On a browse custom page if someone click on a letter (for instance G) and if there is no any facet on the left side, the layout is ruined.

Should be fixed now.

[brianjlowe]

Thanks; the feature is now working for me, but I do see some UI issues that I think should be addressed before merging:

1. Lack of a "there are no results for ..." message when no results are returned.

When an alpha filter is applied, it should use the same language as the existing classgroup browse: "There are no entries starting with X.

Please try another letter or browse all."
There should also be a message if there are no results at all. (The main search page says "0 results found", which may be good enough.)

2. Confusing UI when an item is selected from the left column.

The black arrow widget that is added to the left of the selected item is similar to the green widget that is used in the classgroup browse but the behavior is quite different. The selected row in the existing classgroup browse is essentially a radio button because the only way to move the widget is to select something different, while on this new page the selected row is semantically a checkbox because it can be clicked again to be deselected and return the search to its previous filter state. If we want to display the selected filter values inline, I think it would be far better to use actual checkboxes to make it clear to the user what will happen if they click the values again.

It might be worth considering displaying the applied filter values above the list of remaining values and giving them obvious clickable Xs to show that they can be removed.

The secondary disadvantage of the arrow widget icon is that is looks like something that can be clicked to expand a tree. In fact, when I first looked at the page I thought clicking the row would turn the widget to a down-pointing arrow and reveal additional options below, and I was surprised when the row instead went away entirely.

Additionally, I think putting the filter name and colon ("Type:" in this example) is confusing because nothing else on the page says Type. Perhaps it would be useful if there were multiple filters on the page and one were labeled "Type," but then it should only be necessary if all of the applied values for all of the filters are grouped together at the top of the page, not displayed inline as they are now.

3. Extra space between results, ragged alignment of results per page option, and differing font

There is a double line and lots of wasted space between each search result. This differs from the existing classgroup browse, where only a single line and modest spacing is used.

It's a minor point, but it would be nice if the "30 Results per page" were aligned with the text in the two rows above it instead of sitting to the left of it. The number of results dropdown also uses a different font from the links around it. (**Edit: ** I guess that's not stylable since it's a native select list; perhaps the whole thing should be left unstyled as on the normal search results page.) The R in "Results" looks a bit odd capitalized, but perhaps that's a limitation in the i18n strings.

Overall, I think it would be preferable to have the results per page, sorting and download links look identical on the regular search results pages and these pages instead of making the user look for them in two different locations.

4. Inconsistent capitalization in page management options

It looks like "Select a type" (Only first word is capitalized) had already broken from the rest of the pack, but it would be good to align all of them now rather than propagating the inconsistency with the new option. I personally think changing the others to match the "Select a type" and "Browse search filter results" style would be preferable. (And while we're at it, the existing "Sparql" should be corrected to "SPARQL".)

5. Word "undefined" showing in page management.

There may be nothing to show in that heading at this moment, but if so it should just be blank; the "undefined" suggests to the user that something is broken.

[brianjlowe]

Looking very good now. I see just two tiny things: (1) Can some space be added above the "There are no entries starting with" message so that it looks balanced vertically in the frame? Right now it's pretty tight against the top border. And (2): Can we add a period after the first sentence "There are no entries starting with x**.**" so that it is parallel with the sentence below it?

[litvinovg]

Force-pushed to resolve merge conflict with recently merged PRs. No changes related to this PR added.

[chenejac]

@litvinovg thanks for this significant contribution.