Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add UI feedback when loading the list of workers #23

Open
ralienpp opened this issue Dec 6, 2022 · 1 comment
Open

Add UI feedback when loading the list of workers #23

ralienpp opened this issue Dec 6, 2022 · 1 comment

Comments

@ralienpp
Copy link
Contributor

ralienpp commented Dec 6, 2022

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
@netmackan
Copy link
Collaborator

Hi,

That is a great suggestion.

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants