Line Eidstø
My feedback
15 results found
-
4 votesLine Eidstø
supported this idea
·
-
318 votes
An error occurred while saving the comment Line Eidstø
supported this idea
·
-
214 votesLine Eidstø
supported this idea
·
-
425 votes
Thank you for the suggested idea.
After reading it carefully, I understand that the main pain point here is the removal/fix of items already received.
To be more specific, the description of already received items should be updated to reflect the new pattern.
- Is this understanding correct?
- How often such change happens?
- Can you please add examples of the existing description and the needed update?
- Can the 'Update items using Excel load' CloudApp be utilized for fixing the description? see https://developers.exlibrisgroup.com/appcenter/item-updater-by-excel/
Thanks for the collaboration,
Tamar Fuches
Alma product
An error occurred while saving the comment Line Eidstø
commented
I don’t believe the cloud app “Update items using Excel load” would be helpful in this case. It appears to be yet another manual workaround, and not significantly faster or easier than the manual corrections we already perform.
As a national library, we manage prediction patterns and predicted items for approximately 4,000 journals. In our experience, publication frequencies often change during the year, requiring updates to the prediction patterns.
Here’s our current workflow when the publication frequency changes mid-year:
1. Delete all predicted items that haven’t yet been received.
2. Since we use two holdings for each journal, we must update the prediction pattern for both—either by applying a new template or manually adjusting the pattern. We usually use templates because it is seen as to difficult for everyone to be able to write their own prediction pattern.
3. We then need to update the “next predicted item” information for both holdings to ensure the correct year and volume are used.
4. We must open predicted items for each holding to trigger the generation of new predicted items.
5. After that, we have to delete the newly generated predicted items that correspond to issues we’ve already received.
6. Finally, we must manually update the description for each predicted item, as they do not automatically use the description template configured in our system. We typically use a cloud app for this step.This idea highlights a broader issue with the prediction pattern functionality. The entire process of creating and updating prediction patterns and predicted items is overly complex, time-consuming, and prone to error due to the high number of manual steps and clicks involved.
In my opinion, prediction pattern management should be integrated into the continuous POL, allowing prediction patterns to be created and applied across multiple holdings (all holdings connected to the POL) in a single streamlined process. While I’m not sure what the best solution would be for handling mid-year changes, I believe a major part of the problem lies in how labor-intensive it is to create and maintain predicted items in the first place.
Line Eidstø
supported this idea
·
-
36 votes
An error occurred while saving the comment Line Eidstø
commented
Thank you for your reply.
The update that allows opening the sliding panel in full view was not available when I submitted this idea. While this improvement helps somewhat, I still believe the current design is not optimal. It continues to require unnecessary clicks, makes navigation harder for users, and does not feel intuitive.
In the August release, the Quick Links menu was made persistent in the sliding panel view. However, this menu is less critical than the persistent main menu. In your response, you mentioned that the product team decided not to display the persistent menu because “the user is focused on the specific task” when using the sliding panel. I would argue that this is precisely why the persistent menu should remain visible: when users are focused on a specific task, they often need quick access to the cloud app menu to complete that task efficiently.
Line Eidstø
shared this idea
·
-
78 votesLine Eidstø
supported this idea
·
-
25 votesLine Eidstø
supported this idea
·
-
23 votesLine Eidstø
supported this idea
·
An error occurred while saving the comment Line Eidstø
commented
It would still be practical for the POL to link to the receiving workbench, especially for periodicals. For continuous orders only items in claim are possible to receive directly on the POL, in addition it is not practical to use the POL to receive periodicals when there are a lot of issues. In some instances for monographs it is not practical to use the new option for receiving in the POL, in regards to f example printing barcodes and additional functionality which is only available in the receiving workbench. A link from the POL to the receiving workbench would in these instances be a good option.
-
28 votesLine Eidstø
shared this idea
·
-
40 votesLine Eidstø
supported this idea
·
Line Eidstø
shared this idea
·
-
61 votesLine Eidstø
supported this idea
·
-
32 votesLine Eidstø
supported this idea
·
Line Eidstø
shared this idea
·
-
38 votesLine Eidstø
supported this idea
·
-
22 votesLine Eidstø
supported this idea
·
-
111 votesLine Eidstø
supported this idea
·
I work at the National Library of Norway, and we have the same need for improved support for born‑digital material in Alma. Today’s limitations make it difficult for us to track, follow up, and secure complete legal deposit of digital publications, and we can already see that this has led to gaps in our collection.
Current workflow
– We receive born‑digital files in an external system, outside Alma.
– The files are then imported into Alma as remote digital representations.
– Since Alma does not allow us to create a POL before a digital representation exists, we have no structured way to register expected deliveries, link vendors, or follow up missing content in advance.
– The lack of claiming functionality for digital POLs means we cannot reliably detect missing born‑digital publications—neither books nor journals.
Desired future workflow
– We need the ability to create a POL before any digital file exists, so expected deliveries can be tracked from the start.
– The digital POL must support a claim workflow, preferably similar to the workflow for printed material.
– Claiming must work for both born‑digital monographs and born‑digital journals.
– For journals, the subscription interval must be able to check whether a digital representation has been created on the bib record within the expected timeframe, or there should be some functionality for creating an expected digital “issue”.