nrshapiro
commented
2 years ago I put this in quick very per the following change conditions:
We should ask how long it would take to add scrolling to specific infocards. If quick, then we should do that. If it's more involved, then we can add scrolling or paging to the infocards later.
But either way, as a very quick fix, we should have them change the call to the server to a limit of 50 for infocards:
- Favorites
- Read Later
If we don't have infocard scrolling, and the user's list get's long, they can scroll the whole sidebar.
@ocappello
SophieMBennett
ocappello
In response to user request: https://github.com/Psychoanalytic-Electronic-Publishing/Support/issues/295 it was discovered that there's no limit to the user bookmark type lists (e.g., read later) in the client, but the client, while supplying the entire list of IDs in a list (stored in PaDS), simply requests the first page of return items from the server, which is currently defaulted to 15, for all searches. So that sets the limit to 15.
The simple solution to this would be for the client, in the request for this data, to request a limit of X, where X is the number of items on the list, from the server.
That brings up another issue though: what happens when the list gets really long?
Answer 1: The infocard area scrolls, and each infocard can be folded, so it's just a user list management issue really. But see answer 2.
Answer 2: The infocards could implement paging, just like the search control, with controls at the bottom of the infocard, when needed, to go forward and back a page.
Answer 3: The infocards could implement scrolling.
While there's unfortunately no place I can find in the spec which explicitly says info cards should scroll or have a paging mechanism (like there is for user searches), they are supposed to open, zoom to fill, and restore which is meant to allow many items to be viewed in the control: "These info cards work like a standard Bootstrap accordion control, opening when you click on the header bar. In addition, there's an icon on the open one which lets one zoom in to fill the right panel (and clicked again, restores)."
I believe the best answer would be to implement scrolling or paging to fix this.
Temporary work arounds:
1) It is probably a very minor change to the server to set the request limit to X, where X is the number of items on the list, from the server. Then, as above, it's up to the user to keep the list manageable.
2) It's possible we could temporarily workaround this with a server default change from 15 to a larger number like 30. Since the server default of 15 matches at a time is for all searches, this could have implications for other areas in the client that would have to be investigated for ill effects. But even if there were no negative implications elsewhere, that would still result in a limit on these lists of 30, and since there's no zoom/restore, I presume the long size of these info cards would become an issue for users as well. So a scrolling or paging mechanism is better.