buda-base / public-digital-library

http://library.bdrc.io
5 stars 6 forks source link

fix link in link for etext results #965

Open eroux opened 4 days ago

eroux commented 4 days ago

Follow up on https://github.com/buda-base/public-digital-library/issues/964

Currently when there are results in etext, the etext is really part of the tile of the result, for instance on

https://library-dev.bdrc.io/osearch/search?q=byang%20chub%20sems%20mchog%20rin%20po%20che%20ma%20skyes%20pa%20rnams%20skye%20gyur%20cig

we see

Capture d’écran de 2024-11-22 09-11-27

but there's two very different links: one to the catalog, one to the etext viewer. I think we could make the distinction more explicit by making a kind of sub-tile for the etext result. Claude did this, which is quite naive but goes more or less in the direction that I would like to propose:

Capture d’écran de 2024-11-22 09-20-43

@roopeux what do you think?

roopeux commented 4 days ago

In principle, a search result should link to one place. Traditionally BDRC has linked to many places from a single search result, and I have continued in this way thinking that users are used to it, but let's reconsider this.

It would make the results significantly faster to understand, and reduce the hesitation we observed in the user test, if we would adhere to the principle of one link per result.

This would mean that we remove links to the author, for example. If matches are in the etext, we would link to the first occurrence in the etext from the main title too, as well as from the snippet.

When we get the breadcrumbs done, it will be easy to navigate from the etext to the entity page if necessary.

If both metadata and etext match, we would link to the entity page and just say "3 matches in etext" without a direct link.

So to answer your question, I don't think layout will fix the issue because it is a bit deeper conceptual issue.

(There is sometimes a tendency to produce usability by reducing clicks, but often a better result is achieved with more clicks that are logical and easy, instead of one click that requires thinking.)

eroux commented 4 days ago

It would make the results significantly faster to understand, and reduce the hesitation we observed in the user test, if we would adhere to the principle of one link per result.

I agree, it's not an issue I was aware of but I realize it really gets in the way

This would mean that we remove links to the author, for example.

yes

If matches are in the etext, we would link to the first occurrence in the etext from the main title too, as well as from the snippet.

Wow, that sounds highly confusing to me... I think we should be consistent and have the main result always link to the book, formatted in the usual way (as we have now), otherwise in the same search you will have results where the main result links to the book (when there's a match in the title), others where it links to the etext viewer (when there's no match in the title), etc. I think even I would be very confused by this

When we get the breadcrumbs done, it will be easy to navigate from the etext to the entity page if necessary.

Right, that will make a big difference

If both metadata and etext match, we would link to the entity page and just say "3 matches in etext" without a direct link.

So to answer your question, I don't think layout will fix the issue because it is a bit deeper conceptual issue.

Let's discuss it if you want, I think we're on different conceptual planes

roopeux commented 4 days ago

Wow, that sounds highly confusing to me... I think we should be consistent and have the main result always link to the book, formatted in the usual way (as we have now), otherwise in the same search you will have results where the main result links to the book (when there's a match in the title), others where it links to the etext viewer (when there's no match in the title), etc. I think even I would be very confused by this

This looks like a misunderstanding. Could you check "Etext match only" in https://github.com/orgs/buda-base/projects/23/views/1?pane=issue&itemId=88272789&issue=buda-base%7Cpublic-digital-library%7C967

The idea is that we send the user where the match is, nowhere else.