Vocab search field in header bar

[joelit]

Description of the enhancement

PR #1470 contains the first implementation of vocabulary search results page. This needst to be built upon, before we have a demo-ready feature for the search in whole.

Who are the users that would benefit from the enhancement and how?

Getting this ready would be one of the first Skosmos demos, so the users would be testers and the audiences interested in Skosmos 3.0 development

What new functionalities would the enhancement make possible?

Vocabulary search field specification

1. General functionality

• 1.1 Twig-templates, Bootstrap-layout and CSS
• 1.2 Search field can be emptied by clicking X
• 1.3 Search can be executed with a chosen content language, or with all languages (cypress tests for this)
• 1.4 Dropdown menu styling should match design expectations (Bootstrap, if possible)
  • 1.4.1 Dropdown menu scroll bar can be styled to colour scheme?
  • 1.4.2 Menu item highlight elements should be designed according to unified scheme
• 1.5 Once user has stopped typing after 300 ms, submit the search
• 1.5.1 Process the search results into a stored object that facilitates caching and interrupting
• 1.6 Append an asterix after the search term, if the search term does not contain an asterix at some point
• 1.7 Once the search results are calculated, dispaly the dropdown menu
• 1.7.1 If there are no results, show the dropdown with no results -message
• 1.7.2 If the user writes more text in addition to previously given input, show the result of the latest input
• 1.8 Hide the dropdown list, if the user:
  • 1.8.1 Clears the text box from the clear-button
  • 1.8.2 Deletes the contentents of the input field
  • 1.8.3 Clicks on somewhere outside of the search result dropdown

2. Language options

• 2.1 Default language is chosen from a cookie (cypress tests for this)
• 2.2 Changing the search language changes the content language
  • 2.2.1 Udpating the content language updates the cookie (cypress tests for this)
  • 2.2.2 Updating the content language executes a partial page load (cypress tests for this)
• 2.2 Contents for the language menu are defined in the SKOSMOS JS-object (cypress tests for this)
• 2.3 All UI text is in English (in the form of translation message IDs)
• 2.4 Dropdown menu language codes should be translated to the UI language
• 2.5 The translation component provides the translated UI messages (cypress tests for this)
• 2.6 Language option should perform the autocomplete search in chosen language
  • 2.6.1 If the autocomplete search is performed in all languages, display the foreign language hits with the language in parenthesis

3. Autocomplete

• 3.1 Matches prefLabes (cypress tests for this)
• 3.2 Matches altLabels (cypress tests for this)
  • 3.2.1 AltLabels should be in cursive
• 3.3 Matches hiddenLabels (cypress tests for this)
  • 3.3.1 HiddenLabel hits that are duplicate results to other labels are filtered out with search parameter
• 3.4 Matches notation codes (cypress tests for this)
  • 3.4.1 The notation code can be hidden with a configuration parameter
  • 3.4.2 The configuration for this is read from the vocabulary config (cypress tests for this)
• 3.5 Shows the concept types (cypress tests for this)
• 3.6 Additional information for each search result can be shown according to vocab config
  • 3.6.1 Labels for search result types should be provided by the backend in the SKOSMOS object and displayed in search results
• 3.7 The matching part of the text is highlighted for each search result (cypress tests for this)
• 3.8 Autocomplete should fire if there is at least two characters in the input string
• 3.9 Caching
  • 3.9.1 When a search result is recieved, it is cached with the search string to a dictionary
  • 3.9.2 When a multipage result is recieved, it should be flagged as not-to-filter further
    • 3.9.2.1 Alternative option would be to load the rest of the pages of the result in asynchronous manner
  • 3.9.3 When more characters are added to a search string (no delay), apply a new filter to the raw result data
  • 3.9.4 When characters are erased from the search string (no delay), apply a new filter to the raw result data

4. Accessibility

• 4.2 HTML-content shown in other languages are tagged with lang-attribute
• 4.3 Language menu, search field, autocomplete list and search button are structured together
• 4.4 Screen reader needs to be tested
• 4.5 HTML element structure should be semantically meaningful for the menus (e.g. Bootstrap list-group)
• 4.1 Search bar can be operated with keyboard, which key can be used for each sub-element
  • 4.1.1 Language can be chosen with keyboard
  • 4.1.2 Search input field can be operated with keyboard (and enter goes to search result page)
  • 4.1.3 Autocomplete list can be operated with keyboard (and enter goes to the chosen search result)
  • 4.1.4 Clear button can be operated with keyboard
  • 4.1.5 Search button can be operated with keyboard

5. Additional menus

• 5.1 The maximum length of the language dropdown and the autocomplete list is limited to set element height (in rems)
  • 5.1.1 The maximum length should be configurable
• 5.2 Lists longer than the maximum element height get a scroll bar
• 5.3 'Search tips' menu in similar manner to Skosmos 2.x
• 5.4 Should there be an indication with the total number of search results displayed shomewhere when the dropdown menu is shown?

[joelit]

The choice of the autocomplete component can be a ready component that fills our requirements, one written from the scratch, or a vue component that has some of the functionalities ready but can be expanded to meet our needs:

Short requirement list:

1. Autocomplete matches search terms as you type
2. Additional information for each search result can be shown according to vocab config
3. The matching part of the text is highlighted for each search result
4. Autocomplete should chache initial results and filter the result list when more text is typed

Found solutions:

• Take a ready JS Component that can handle autocomplete usecases in an elegant manner
  • Vueify autocompletes ✅
    • Used by 270k, daily updated
    • https://vuetifyjs.com/en/components/autocompletes/
    • https://vuetifyjs.com/en/api/v-autocomplete/
    • Comments:
      • A bit too general
  • vue3-autocomplete
    • 3 maintainers, last update 3 years ago
    • https://github.com/Takachi67/vue3-autocomplete
    • "Vue3 component used to search and select an item in a custom list."
  • Primevue autocomplete ✅
    • Used by 15k, daily updated
    • https://primevue.org/autocomplete/
    • Comments:
      • Still needs match highlighting (req. 3)
  • Vue 3 autocomplete
    • https://github.com/Venegrad/vue3-autocomplete
    • 1 maintainer, 1 update
  • vue-simple-suggest
    • 1500 users, updated 3 years ago
    • https://github.com/KazanExpress/vue-simple-suggest
    • Demo https://madewithvuejs.com/vue-simple-suggest
  • vue3-simple-typeahead
    • Used by 250, last updated 2 years ago
    • https://github.com/frikinside/vue3-simple-typeahead
• Write the autocomplete component from scrarch
  • https://stevencotterill.com/articles/how-to-build-an-autocomplete-field-with-vue-3
  • https://www.digitalocean.com/community/tutorials/vuejs-vue-autocomplete-component
  • https://runthatline.com/vue-3-autocomplete-how-to-build-a-reusable-composable/
  • https://youtrack.jetbrains.com/issue/WEB-54413/Autocomplete-using-vue3-typescript-for-components-props
• Build autocomplete by expanding existing components
  • Bloodhound
    • https://github.com/swiftcarrot/bloodhound
    • Broad user base, but no updates in 5 years
  • Take a fork from one of the smaller repositories mentioned above and expand it to meet our use-cases

[miguelvaara]

(refers to the section 1.4 and the idea mentioned in the sprint design regarding changing the color of the dropdown menu)

It is true that a white background in the dropdown menu creates some cognitive load because the menu does not sufficiently stand out from the background of the page. On the other hand, too strong background in the dropdown menu could make the menu text appear a bit "blurry" and the readability of the text may decrease.

In our tabs on the left side of the page, we already use a lighter gray, but not just white eithe. According to the browser inspector the lighter gray is #f2f5f7 (I did not verify this in the CSS).

WCAG defines the contrast requirement for text like this at level AA as a contrast ratio of 4.5:1 for the given text size. If the contrast requirement becomes an issue, the visual impression can be adjusted by modifying, for example the text size or weight.

In any case, a suitable color is likely already available among the existing colors used on the page and in Hahmo's template (if color is used to improve differentiation instead of relying on border modifications).

Original

Modified

@joelit @MikkoAleksanteri