You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When I go to signserver/adminweb/workers.xhtml on my test instance of SignServer, the list loads slowly and there is no indication of the fact that the system is busy doing some work.
From a usability perspective, the best practice is to show some indication of "hey, I'm still alive!" if it takes more than 250ms to provide the result. It could be a progress bar, or an indeterminate progress bar if there's no reliable way of estimating how long the process will take. Otherwise users think their input was not received, so they click again.
This is not a big deal, but it would be a nice touch for improving usability a bit.
My test environment has 117 workers.
SignServer 5.10.0.Final
The text was updated successfully, but these errors were encountered:
We have also noticed the slowness of the workers page and have tracked down the issue to be because of the checking of the worker status of each worker when they are listed. Checking the worker status involves a lot of checks including the configuration but also more slow ones like testing that it is possible to sign with the configured crypto token. I believe there is a lot that could be done here to improve that.
One thing we have been exploring is to change so that the list of workers is first displayed without the worker status as that should be much faster and then the statuses would be queried in the background and displayed first when they are available. That way the page is usable almost directly but the status info may come later.
Combining all of this with also the progress information as you suggest might be even better.
When I go to
signserver/adminweb/workers.xhtml
on my test instance of SignServer, the list loads slowly and there is no indication of the fact that the system is busy doing some work.From a usability perspective, the best practice is to show some indication of "hey, I'm still alive!" if it takes more than 250ms to provide the result. It could be a progress bar, or an indeterminate progress bar if there's no reliable way of estimating how long the process will take. Otherwise users think their input was not received, so they click again.
This is not a big deal, but it would be a nice touch for improving usability a bit.
The text was updated successfully, but these errors were encountered: