I would suggest one important thing here, and that is "ask your users".
You can make it look great with cards and animations - but how do the users actually want to use it? What data to they need to see (e.g. see at all times) vs what they want to see (e.g. additional info they might want to see on a pop up, or tooltip etc.)
In many cases a simple list is the easiest way to look at a queue or at history - people to that every day in their email client, for example - as long as the amount of information they need to look at (i.e. the number of fields per item) isn't too large. Once it gets over a certain number of fields, table displays can be easier to manage.
We have managed large volumes of data queues in one case by moving queued/in process/errored/complete into tabs, with a counter on the tab itself so the users can see if there are any new items in any of the tabs.
Each item in each tab is shown as a card, in a list, with a pane to the right of the list that shows (and allows changes to) the currently selected item in the queue. (obviously this functionality differs on each tab - e.g. on the error tab the only option is to re-submit.)
I'd second that. "Ask you users" and "KISS" are really important principles and could help a great way, especially with the first and small application. Even more: instead of "asking users" what to do, it would be better to deploy really simple first version and ask for what's missing. :)
I would suggest one important thing here, and that is "ask your users".
You can make it look great with cards and animations - but how do the users actually want to use it? What data to they need to see (e.g. see at all times) vs what they want to see (e.g. additional info they might want to see on a pop up, or tooltip etc.)
In many cases a simple list is the easiest way to look at a queue or at history - people to that every day in their email client, for example - as long as the amount of information they need to look at (i.e. the number of fields per item) isn't too large. Once it gets over a certain number of fields, table displays can be easier to manage.
We have managed large volumes of data queues in one case by moving queued/in process/errored/complete into tabs, with a counter on the tab itself so the users can see if there are any new items in any of the tabs.
Each item in each tab is shown as a card, in a list, with a pane to the right of the list that shows (and allows changes to) the currently selected item in the queue. (obviously this functionality differs on each tab - e.g. on the error tab the only option is to re-submit.)
I'd second that. "Ask you users" and "KISS" are really important principles and could help a great way, especially with the first and small application. Even more: instead of "asking users" what to do, it would be better to deploy really simple first version and ask for what's missing. :)
Probably it's easier to build and deploy. Our users are internal so it's not too difficult to catch any of them and get the feedback. ☺️