Changes to the NavigationHistory feature.

[jesperlauridsen]

Hey @VictorHarbo / @jorntx / @thomasegense.

I didn't get to review the NavigationHistory, but I looked through it after the merge, and was puzzled by the way of handling storage of the history count. (I also still don't quite understand the feature, but that's on me ;-))

The way it currently works, as I understand it, is that you push changes to the backend, and then every 2 seconds asks the backend for a new object containing the count. This is done regardless of any chances made.

I would recommend that this should be rewritten so a store on the frontend keeps track of everything, and when a change is made, it's pushed to the backend while keeping track at the frontend aswell. We can then ensure that on a fresh load of the page / or a reload, we ask the backend for the count object, and load it into the store, and keep track of it there once again.

That way, we avoid asking for updates (and often just getting the same object with no changes) from the backend. The current appoarch doesn't really scale, imho, if we some day have an instance of solrwayback deployed somewhere with alot of concurrent users.

Also, I think the button should either be renamed to something along the lines of "Download navigation history", or instead open a modal of the navigation history with the option to download it. Right now you just suddenly get a json file thrown into your download folder. :-)

[VictorHarbo]

Hi @jesperlauridsen

Nice to have your frontend experienced eyes looking at the feature! Thank you!

First of all, the purpose of the feature is for users to be able to document their discovery pathways through the archive. In our project, this has already proven useful in multiple ways. First of all, having the navigation history available makes it possible for researchers to pick up their research where they left off during an earlier session. The navigation history also serves as documentation for how a specific source has been found in the archive, as one of the biggest challenges in such big collections is to keep track of how a specific resource has been found, as this is crucial for academic transparency and reproducibility.

Regarding the implementation, it probably shines through that I am a bit more comfortable handling things on the backend. Your store-based approach seems solid and is probably a good improvement. For me, it would make sense if the button opened a modal showing the history, but also still included the possibilities for download, for storing the history as documentation.

[VictorHarbo]

Also, going forwards, how are your time prioritised at the Library. I have assigned Thomas as reviewer for everything as that has been how we've normally done it. But would love to assign you to frontend reviews if you are available for this?

[thomasegense]

@VictorHarbo Just assign me as always and I will give it to Jesper if some part of the review is frontend. Last time was just to squeeze it into the release I was making, so it would not have to wait many months for next release.

But a few comments from me.

Feature improvement:
When clicking the history I would like to see a modular pop-up with the data showed nicely. And then the user can
decide if he want to download. Also I would like number of hits to be listed as well. (I know this can change over time, and this is a way to detect it).

Backend:
As Jesper say the 2 second service call does not scale for installations with many users. Actually I see no need for any backend services to be involved in this. The frontend can save all data in the frontend app and this way would also get number of hits for free.

[jesperlauridsen]

@VictorHarbo I havent officially been given any time on this, but I make time where I can. Would you or Jørn be able to give the rewrite of this a stab, or is this out of your scope?

Also, did you write this as a backend feature because you want it to persist between sessions - or was this purely because you didn't feel like writing it as a vue feature? Because if it's not needed to be persistent between sessions, it becomes even easier to implement as a frontend feature.

[VictorHarbo]

@jesperlauridsen We can probably give it a go at some point. We will definitely not get it done before IIPC WAC in April, but we might have time to develop the feature further in the spring/summer.

[VictorHarbo]

@jesperlauridsen: @thomasegense and I have discussed that the feature cannot be moved completely to a VUE store, as the service also tracks when a link has been clicked during playback of sites, which all happens on the backend.

We also discussed that a way to remove the excessive pinging of the backend for the count() method is to not show the counter as part of the button and instead open up a modal with some key information on the navigation history for the user. Effectively making the button open up a modal showing navigation history count + maybe a rendering of the file + a download button.