:clock1030: Change tracker app, UX iteration 1

Hello everyone!

I just started working on a “Change tracker” app and I would love to have your feedback.

What is the “Change tracker” app?
“Change tracker” is a helper app that will allow users to keep track of all changes made to a record.

Below is a wireframe of the Users app with the “Change tracker” open:

Users%20app%20with%20change%20tracker%20app2560×1440 353 KB

How does it work?
When users edit a record, the “Change tracker” icon will appear next to both the edited field and the pane header title.

edit%20users%20page2560×1440 240 KB

After clicking on the “Change tracker” icon next to the edited field, a modal will appear stating what change was made to the field and giving users the possibility to add a note/reason why.

change%20tracker%20modal%20for%20a%20specific%20field2560×1440 261 KB

After clicking on the “Change tracker” icon next to the pane header title, a modal will appear with a summary of ALL the changes made to the record and the possibility to add a note/reason why.

change%20tracker%20modalfor%20the%20full%20record2560×1440 241 KB

Change tracker app full view
When full view, the change tracker app will have a search pane allowing users to search a specific change by keywords, time and/or apps name.

tracker%20app%20full%20view2560×1440 414 KB

When a search result is selected, a list of all changes related to the selected item will be displayed and the one selected will be highlighted. If the user is the one who made the change, he will be able to edit/add a “reason”.

change%20tracker%20with%20a%20item%20selected2560×1440 302 KB

Feedback
Please, feel free to share your questions, feedback and ideas in the comments below to help me improve it.

This looks potentially game changing.

How do we forsee change tracking being persisted on the back-end? Is there a standard interface that would need to be implemented? Or is that discussion outside of the scope of this app?

Thanks for you question, @Kurt_Nordstrom

The details of implementation have yet to be discussed and decided on, but the hope for this feature is that it would be available for anything that exists as an editable “record” in FOLIO. So I imagine we would want to prescribe a standard way of storing / logging / making information accessible for this sort of interface to reach its full potential for end users.

Am I correct in thinking that changes will be tracked automatically and users only need to interact directly with the app to either add/edit a reason or to view change history?

Yes @LauraW, it is what we envision. We would like changes to be tracked automatically, allowing users to have the full history of a record.

For Voyager bib records, I think we can see who originally created the record and the last person to edit. Sometimes it is frustrating to not be able to see beyond just the last edit, but is keeping track of every edit to every record feasible? Or useful? Serial bib and holdings records could see many, many changes in just a few years. For a library with millions of bib records could this become a server space issue?

That’s a great point, @PaulaSullenger! Thanks for sharing it!

@jakub, do you have any thoughts on this?

What is the intended scope of this - that is, which fields does it track changes to? I ask because some fields change frequently, like item status or a loan’s due date. From what I know, it’s useful to see changes to those types of fields over time & and it’s also helpful to see changes to other fields that don’t change as often, but I wonder if grouping those together when one is much more high-volume is going to be confusing, unless you could separate them out.

This also brings to mind the loan details page, and the action table that records renewals, claim return, changed due date, etc. - is the change tracker app intended to replace that, coexist with it, or not apply to that information at all?

We are working on an “actions list” in Requests. If there was instead a standard “change tracker” that we could plug in, that could be quite useful.

I’ve also heard from some SMEs that it would be very useful to see, when viewing an item, every change that the item has been involved in, such as “filled a request”, “barcode changed” etc. That seems like a big undertaking, but perhaps something like a Change Tracker would have easier access to all the pieces that would be needed to show that variety of information in one place.

I agree that a change tracker would be very useful in the world of circ transactions. I’ve always wished for an item status tracker, and it sounds like this tracker could be used for that. Showing the full date/time and operator ID would be very useful. Q: Would the tracker capture system-initiated changes (such as batch job record updates), or just operator-initiated changes? it would be useful to capture everything, and be filterable by date range or opid.

This looks like a great and very helpful feature! How about tracking automated changes too? Automated fees and fines are often questioned by patrons and a complete history of events and related fines would be very helpful.

Still privacy rules have to be taken care of… So perhaps when a “case” is done, patron information has to be anonymized/removed in historic records too.

I share @PaulaSullenger’s concerns. But I also think this functionality, if it can work, would be amazing. We currently use so many local notes that attempt (somewhat ineffectively) to do this. Would it be possible to select only certain types of changes to track? Or to periodically purge certain types of changes only?

Great point @schwill! I didn’t think about privacy. Do you have an idea of other fields that could have a privacy issue?
And yes, in our vision, not only manual changes will be tracked but automated changes as well

Thanks for your comment @ecboettcher @Joanne_Leary @taniafersenheim. We would like the change tracker app to automatically track every type of fields and changes (manual and automated). In our vision, users would be able to sort changes via the following filters: app name, category (made by the team, by you or automated), date range, keywords. @LauraW Are we missing a filter? What do you mean by types of changes? Could you give me an example?

An example of something we might not want to track (or might want to purge routinely) would be yearly resets of circ data. We might also want to purge acquisitions receiving changes after the end of a fiscal year.

I wonder where it is best to take care of privacy issues of records. Perhaps the app storing the record is the best place. If so, it should take care of the record history too. That way the tracker app could just display what is left after anonymization/pseudonymization/deletion…

If it is feasible, then i say do it! Currently Aleph retains all changes to item and order records, and a log of time/users who make changes to bib and holdings records (but not what the actual change was). I don’t know that we need to retain all the text that was changed, for example in a bib record, but knowing what element in an item or order for example is super helpful.

@Stephanie another filter to consider: by type of record, since there may be multiple record types within a particular app. Date range (which you already mentioned) will also be a useful one. Thank you!

Coming back to this late, sorry - some other information that could be helpful to have would be the service point where the change was applied (e.g., to track down an in transit item that hasn’t arrived), the time (not just the date) of the change, or links to loans it’s been part of. (Some institutions that keep borrower history want to be able to get to the previous borrower for the item, for example.) Are those sorts of things out of scope for this app, or no? The last might be similar to what @taniafersenheim is saying for seeing whether the item has filled a request, but I’m not sure.

I’m particularly interested in the “scrollable table with recent changes related to Rosalyn Roman” in the fourth screenshot above. Does that only refer to the changes the user is presently making, or all changes in a certain time period? If the former, is there a way to see all the changes to an item record, starting from that item record? Or is it that you have to go into change tracker & search for your item?

Great feedback! Thank you @ecboettcher! For the scrollable table, it is only for changes presently made. If a user would like to see the change history of Rosalyn Roman record in the Users app, he would have to open the Change tracker app, select the Users app in the filters and type Rosalyn Roman in the search field (see 5th screenshot). So yes, users would have to open the change tracker app to search records and see the changes.

Thanks for clarifying! Reviewing this again, I realized I had lost sight of the first screenshot at the top - the rightmost pane looks like it shows all changes for a particular record within the Users app, without going into the Change Tracker and filtering/searching for the specific record. So are there two ways to see all changes for record X? Or is the thinking now that opening the full Change Tracker app is the only way?

My last replied was a bit confusing, let me rephrase it. To see all changes for record X, you could either click on the change tracker icon of record X or open the Change tracker app and look for this record.

The difference between both is that via the Change tracker app, users could easily see changes history for a specific field at a glance. For instance, if you look at the last wireframe, the status field of Rosalyn Roman has been selected and on the rightmost pane, you can see all changes related to this field only.

Will it make sense for you?

Hello guys @ecboettcher @Ann-Marie @Jessica @schwill @LauraW @Joanne_Leary @taniafersenheim @PaulaSullenger! Based on all your feedback, it looks like librarians shall be able to choose which fields shall be tracked to fit all workflows and address privacy issues. To do so, we could add the change tracker as a setting option for each app and allow users to unselect tracked fields. The wireframe below is an example of the Users app settings with the change tracker option selected.

Please let me know if this idea could address privacy issues and make the app more useful for all.

User%20settings2400×1262 116 KB

Hi Stephanie,

this is an interesting approach on reducing the information stored. The wireframe does not show “date of change” and “sourc of change (user XY, automatic etc.)”. Both are helpful with regard to qualtity management, but in some cases unions may raise their voice here too. So providing a checkbox for them too could help different institiutions (with different unions) to make their local choice.

From a GDPR point of view it can be really helpful to reduce the historical data using the checkbox-approch. Still I assume that “deleting” historical data also is quite relevant. Deletion could be

• time driven: remove patron information from loan record after 2 weeks - necessary to follow up on damaged items returned via automatic RFID shelves
• event driven: patron (lawfully) requests deletion
• or a combination of both: delete inactive patrons after two years, if there are no open loans…

Perhaps each app using “change tracker” knows best when to delete it’s current and historic records. Does this look like an API that “change tracker” could provide for other apps with complex data management like a loan app?

Thank you for your great feedback! I will look for a way to manage automatic data deletion based on a time range and/or events.

I am not sure I fully understood your comment about “date of change” and “source of change”. These two information are shown in the Change tracker and User apps wireframes. Users could search for a specific record based on the date and source of change.

Could you give me an example showing why those two data could be useful in the change tracker settings page?

Hi @Stephanie, some unions (=Gewerkschaften, Personalräte=staff council, Betriebsräte=workers council) are concerned with “performance monitoring” of staff. Here the result can be, that it is (locally) forbidden. So tracking staff activity (item, staff-id, timestamp) openly might not be an option. Disableing it’s recording can be a remedy or perhaps “read-protection” for normal mangers/users. In rare and specific cases it might be permissable to search this data perhaps “under the eyes” of a staff council member…

“Some” would be all here in Marburg University Performance monitoring or something similar would definitely challenge our “Personalrat”, the staff and the “Datenschutzbeauftragter” (Data Protection Officer). Hesse was the first German state that introduced a general Data Protection Officer and still has the toughest rules here. Perhaps this can help our colleagues [https://en.wikipedia.org/wiki/Bundesdatenschutzgesetz].

If the tracking feature could be turned off, would that satisfy the “staff monitoring” rules at certain institutions? Some of us would like to have this available, especially when FOLIO is new. Something goes wrong, how can you track the problem if you can’t see who has done what? Is there a problem with a person, or with a poorly designed process? For me, staff monitoring isn’t for punitive purposes.

From a professional point of view I absolutely agree with you Paula Perhaps I should go back to 1993/94 when Hesse introduced OCLC LBS (the first ILS ever here): when we realized that some kind of staff monitoring would be possible in RA/circulation both sides (aka directors/staff/staff council) decided that only … well … anonymous/general/impersonal accounts would be allowed. This means that the staff at the counter uses the same neutral account at all work stations. Of course this doesn’t make sense in acquisition/resource management where we have more specialized accounts. - I - can do some tracking and staff monitoring at circulation/RA of LBS (and really need it) but to this day I’m not allowed to create personal accounts for the staff at our lending department. It’s probably a very German thing to exclude the possibility that tracking isn’t for punitive purposes as we have a history here. But - and this is our common issue: we’ll need some proper tracking and when it’s controlled by systems librarians/systems managers in a clear defined frame everything will be fine (… we even had to drop the names at the library cards a few years ago here in Marburg and our students council still prevents the introduction of a students ticket that could be read via QR tag, RFID or barcode …)