rism-digital / rism-online-issues Goto Github PK

Currently the facets are limited to showing the first 10 values. This behaviour can be flipped with the 'expanded' value on the Facet, but we currently do not have this hooked up to the views.

To fix this, we should send a Msg that will expand / collapse a specific facet block.

Docs are outdated, update to new methods.

A request from musicians: Often looking for pieces that might be in the same voice range for an ensemble, but not necessarily the same instrument. Would be nice to figure out a way to allow users to input a pitch range and then to find matching works with matching voice ranges.

Unsure how to represent that data, though, nor how to support performing force queries... "find me pieces with voice X from pitchA to pitchB, voice Y with pitchB to pitchC, and voice Z with pitchC to pitchD"

Due to wonky file paths, the local development server crashes if you even look at it wrong.

Some notes have raw HTTP links embedded in them. These will only come through as plain text, which will be frustrating for users.

Options:

1. Detect the links and render them client-side. (Elm)
2. Detect the links and convert them to HTML server-side (API Server)
3. Detect the links and store them at indexing time (Indexer)

Considering the following steps from the home

• Make a query "Bach"
• List the results
• Select a facet

When I click "Home", the query term remains. I am not sure I would expect this. More problematic is that if I search the query again, the facet remains selected - even with a new term. This later situation is problematic

IPv6 is more consistent internally than the IPv4, which may or may not have a hostname, or may or may not be publicly routable. For services in the stack to talk to each other we should use the IPv6 addresses throughout the stack.

https://dev.rism.online/search?q=462100600

An incoming feature request:

"One thing that would be really great so see in RISM in the future interface is the ability to download results –

• Inventories (with no and p/fol no)
• All the sources for one text incipit within a date range
• All the books printed in a particular year"

The app should remember a user's selected language when they set it.

The Solr index supports range searches for years; the API for these searches needs to be implemented in the application server, and the appropriate facet response delivered to the UI.

Currently the top bar of the search results has a 'type' filter. It will filter the results just by the type of the record.

This should be changed slightly. A type value of 'all' should be added that will show all the results in a mixed list. Clicking on one of 'source', 'person', 'institution', or 'incipit' should return a list filtered to only search on this type of data.

This will need some work in the Server API, since it's the thing that actually handles filtering and the values in the filter. This issue is specifically about altering the UX behaviour of the facet.

A good model to use is the search type filters on Google, where you can flip between 'Web', 'Images', 'Videos', or 'Maps'.

Note that when you switch to 'maps' the UI changes dramatically -- possibly a good example of how we might want to tackle incipit searches? Change the UI completely?

Implement a control for sorting results in searches.

Options

• Relevance
• Alphabetical A-Z
• Recently added

Use case: When searching, the 'current search' should be kept while browsing the records in the search, so that users can navigate between them without going back to the search page.

Open questions:

1. How 'deep' should it go? If a user navigates to a source, and then to a person, and then to another person through the 'related links' in the record, should we keep the navigation? NB: Muscat does not do this -- when you navigate to another record the results navigation goes away.
2. If we keep a search around until it has been explicitly cleared, this may cause confusion. (It does for me in Muscat when using the record searches -- I can come back hours later and my last search is still applied...) When/how should the current search be cleared? In what cases would we assume that a user is no longer interested in a previous search. For example, if they navigate to an external page? After a period of inactivity? (shades of '15 minute session timeout' here...)
3. What should the UI look like? A simple 'next/previous' navigation? A pop-out sidebar showing the results on the current page? Something else?

Do a search for 'carlos', click a record, then go back. Shows route not found.

For the indexing machine to talk to the MySQL server, a MySQL user for the indexer should be created on deployment.

When selecting a facet, it is added to the list of selectedFacets. However, the facet that is added contains the count of the facet before the filter was applied. This means that after the filter is applied, the checkbox no longer appears to be selected, since the new count of filters does not match the count in the selected facets.

To fix this, the list of selectedFacets should be changed to have selectedFilters, and the checkbox matches done on whether the values of the facet match up with the data in the current filters.

Tagging @lpugin as he discovered this bug.

Index and link source titles to standard titles.

e.g., 1001100274

Possibly use an Elm module, or drop out to a port to render a custom element?

As for APIs, Mapbox looks cool. OpenStreetMap API access is a bit funny "Our API is mainly intended for the use of map editor software. It is not suitable for inclusion in your production-release software." Google Maps? A bit boring...

Would be nice to have synonyms for instruments so that 'pf' could be expanded to 'pianoforte' and 'piano' to allow users searching by those terms to find matching instrumentation.

Query-time implementation?

Would probably want to add it to a separate field type so that not all fields get processed with the same synonym filter, e.g., text_instrumentation_synonyms might have the instrument-synonyms.txt file added to it, and then instrumentation_sm would do a copy field to instrumentation_ftis (or something like that), then add instrumentation_ftis to the qf config.

The institution records are currently empty

The labels in the facet configuration is currently hardcoded to English values. This should be changed to take the values from the locales so that the headings of each facet can be translated in the UI.

The facet "Hide item records" makes somehow sense, but "Include item records" not really because they are already included. I would suggest

• Collection records only
• Items records only

Or

• Hide item records
• Hide collection records

with a preference for the first one because a facet is usually about selecting a subset and not about deselecting a subset. Also, in the first proposal, "only" might be superfluous?

API server logs should be written to /var/log.

One idea for the facets to show on the "Everything" tab could be to have a couple of the most important facet for each category (whatever that means - probably the the top two on each category) and to separate them visually. Something like:

• Sources
  • Source type
  • Filter item records
• People
  • Role
  • Gender
• Institution
  • Institution type

I would imagine that selecting a facet item would take you to the category tab when other facets would show up

Probably needs a refactor of the pagination updates.

See: https://package.elm-lang.org/packages/elm/browser/latest/Browser-Dom#setViewportOf

The server should send facets back to the client in the order they should appear. This should be configurable in the server app.

Allows countries to link to their national collections

e.g., /sigla/GB

Top-level /sigla would have a sigla search page.

By default facet should be ordered by number of matches. Eventually, when we have a way to see more / all of them, ordering alphabetically might be desirable too

Every record response should have 'created' and 'updated' on the response indicating when the record was first created, and when it was last updated.

Perhaps in a separate block?

recordHistory: { 'created': DATETIME, 'updated': DATETIME }

Later we could determine whether we want to show any further details, like who did the last update, or what was changed.

When on a record view, click the 'search' in the top -- an error will be raised because the Records app is trying to parse a Search response.

To fix this the records app needs to treat '/search' as an external url, not an internal one.

Currently the translation mechanism for choosing the translated label is:

1. Match the language to the user's selected language
2. (if not found) Match the language to the value in the None label
3. (if not found) return a string with the value "[No language value found]".

While this is useful for seeing what labels are still outstanding, it's not very user friendly to translations that currently do not have 100% coverage.

Instead, we should probably return the English label in stage 3 (since this is the most likely to be present), perhaps enclosed in square brackets to indicate that we recognize that it's not necessarily the best thing to show.

The incipit search should support:

• Beginning only with transposition
• Beginning only without transposition
• Anywhere with transposition
• Anywhere without transposition

The UI repo currently has two applications, a records viewer and a search app. As we move towards integrating search into the records view (for showing the source attached to a person / place / institution), and towards providing search result navigation in the records view (#15) it will likely be easier to accomplish this if the application was consolidated into an SPA.

This will also help with routing, etc on the server-side.

Currently dev.rism.online/ Should be RISM Online. Maybe can be changed depending on the results or record being looked at?

The person records are currently empty.

When a result is loading we should show better loading visuals.

Particularly interesting is the Facebook-style "grey boxes": https://codepen.io/brucevang/pen/qZOPwR

The related key on sources should match the same data structure being delivered on people and institutions, and run through the same shared serializers.

It would be useful to see the number of results in the tabs for a query. Problems to consider

• do we want to show a tab when there are no results?
• what should happen to other tabs when facets in a tab (e.g., people)?

Since we rebuild on deployment anyway, there's no need to store the dist and dev compiled code in the repo.

Solr Learn-To-Rank can be used with features from our records, as well as click results. A rough sketch:

• Select features for LTR. This can be things like number of sources attached, length of record, etc.
• Implement a click tracker for results in the UI. This can be a simple GET request to the server that encodes the query parameters and the document ID, and returns a 301 to the record. The GET request parameters are parsed and stored in a solr index.
• A 'learning' service can coalesce these results, as well as other features, into a LTR model.
• Implement a rq parameter that can influence the ranking of results based on the LTR model.

Still need to determine how people will find them, i.e., a text search will return things with the text incipit, but we may need additional Solr magick to make the music incipit search work.

There are a couple of problems when searching by library sigla.

• It does not retrieve all the sources we would expect. For example: "CH-E" retrieves 11815 sources when Muscat shows +12900 (https://muscat.rism.info/admin/institutions/30000006) - For some reasons, Muscat opac shows +26k https://muscat.rism.info/catalog?f%5B852a_facet_sm%5D%5B%5D=CH-E&q=CH-E&search_field=any_field and so does the BSB OPAC
• Searching for a sigla ("CH-E") does not retrieve the institution

Wildcards can be useful in may cases, but particularly for library sigla. I would intuitively search for

• CH-* (all libraries in Switzerland)
• CH-BE* (all libraries in Bern)

For manipulating range searches (see #41) a UI for the range search needs to be implemented.

Records should have a “send feedback” form where individuals can raise issues about a record.

To be discussed

Currently, incipits IDs are of the for 452016330_incipit_3. I think it would be preferable to have something that relates to their id in the source. Something like 452016330_1_1_3 or 452016330-1-1-3. Of course, that would imply that we have no duplicate in the data, which probably needs to be checked.

It currently remains at the bottom

In addition to standard titles (#1) works should also be indexed.

Relationships are now on people, institutions, etc. and linked to place records, but there is no view for these.