Progress indication and sorting options for long record lists

mih commented

2025-04-23 15:01:15 +00:00

Owner

https://annotate.inm7.de/s/simplesubmit/?sh%3ANodeShape=inm7si%3AJournal will load 200+ journal records. This can take a bit. A progress indication (that something is still running, not necessarily a prediction how much more will come) would be helpful to distinguish incoming data from no data.

The long list is sorted by pid (right?). With prefLabel set, this pid is actually nowhere rendered on the page, so the list appears to be unsorted.

It would be nice to have the option to sort by a particular property. Alternatively, it could be sorted by the effective record title in the list.

https://annotate.inm7.de/s/simplesubmit/?sh%3ANodeShape=inm7si%3AJournal will load 200+ journal records. This can take a bit. A progress indication (that something is still running, not necessarily a prediction how much more will come) would be helpful to distinguish incoming data from no data. The long list is sorted by `pid` (right?). With `prefLabel` set, this `pid` is actually nowhere rendered on the page, so the list appears to be unsorted. It would be nice to have the option to sort by a particular property. Alternatively, it could be sorted by the effective record title in the list.

jsheunis commented

2025-04-23 18:38:14 +00:00

Owner

Good point, i agree that a "busy indicator" would be a good idea here.

FTR, there is an existing feature that could be useful here. Via configuration, with the service_fetch_before option, one can specify if any records should be fetched up front, on app startup. See for example how it is used in the TRR379 annotation app: hub.trr379.de/q04/annotate.trr379.de-demo@8bb91abff0/config.json (L46-L52)

    "service_fetch_before": {
        "get-record": [],
        "get-records": [
            "https://concepts.datalad.org/s/roles/unreleased/Role",
            "https://concepts.datalad.org/s/social/unreleased/Person"
        ]
    },

IIRC I implemented this because the order in which records are required for seamless UX in shacl-vue is not easy to predict, or at least not always convenient for whichever steps the user is following. There is also a feature that, by design, intercepts multiple requests to the same endpoint if they are found to be unnecessary. But I do not think the current logic for determining whether a specific request is necessary is fool-proof, so this needs to be revisited.

Note to self, check whether this might have any influence on #11

The long list is sorted by pid (right?). With prefLabel set, this pid is actually nowhere rendered on the page, so the list appears to be unsorted.

It would be nice to have the option to sort by a particular property. Alternatively, it could be sorted by the effective record title in the list.

I can't remember off the top of my head, will have to check the record ordering. But i agree, a default ordering based on prefLabel/title would be good, and then followed by the ability for the user to set the ordering. Search-as-you-type filtering would also be good for such long lists. And pagination, eventually...

Good point, i agree that a "busy indicator" would be a good idea here. FTR, there is an existing feature that could be useful here. Via configuration, with the `service_fetch_before` option, one can specify if any records should be fetched up front, on app startup. See for example how it is used in the TRR379 annotation app: https://hub.trr379.de/q04/annotate.trr379.de-demo/src/commit/8bb91abff0eb3b3708df8119465b208a8a700443/config.json#L46-L52 ``` "service_fetch_before": { "get-record": [], "get-records": [ "https://concepts.datalad.org/s/roles/unreleased/Role", "https://concepts.datalad.org/s/social/unreleased/Person" ] }, ``` IIRC I implemented this because the order in which records are required for seamless UX in `shacl-vue` is not easy to predict, or at least not always convenient for whichever steps the user is following. There is also a feature that, by design, intercepts multiple requests to the same endpoint if they are found to be unnecessary. But I do not think the current logic for determining whether a specific request is necessary is fool-proof, so this needs to be revisited. **Note to self,** check whether this might have any influence on https://hub.psychoinformatics.de/inm7/annotate.inm7.de-simplesubmit/issues/11 > The long list is sorted by pid (right?). With prefLabel set, this pid is actually nowhere rendered on the page, so the list appears to be unsorted. > > It would be nice to have the option to sort by a particular property. Alternatively, it could be sorted by the effective record title in the list. I can't remember off the top of my head, will have to check the record ordering. But i agree, a default ordering based on prefLabel/title would be good, and then followed by the ability for the user to set the ordering. Search-as-you-type filtering would also be good for such long lists. And pagination, eventually...

jsheunis commented

2025-04-23 19:01:27 +00:00

Owner

Looking at the code, I already implemented a busy indicator a long time ago. But it seems not to be working as intended. Let's debug...