Quote:
Originally Posted by davidfor
There is added complexity in running jobs in the background. Whether it makes sense depends on exactly what is happening and what user interaction is needed. Plus, there are some things that cannot, or should not, be done in background jobs. How often something is expected to be run and how many changes it is expected to make also affects whether running in the background is worthwhile. For example, running the "Update progress" action in the background is probably not worth it. I rarely do this more than once a day for one or two books. The time taken to do this update is not enough longer than creating the job to make it worthwhile.
Which actions do you think should be run as jobs? I can look at them, but, it I'd need to be convinced of the benefit in doing it.
|
(And I should have acknowledged your work as well -- thanks also to you.)
IMO, and I'm clear that it's only my O -- for good UX, if the UI doesn't come back immediately (for human values of immediately, e.g 200mS or so) the task should be done in the background or it should be made obvious. So, I suppose that's the other approach: how about throwing up a progress/cancel popover to show that the app isn't locked up?
For example: I just did Sync from Shelves for my to-read: about 28 seconds during which the Select shelves dialog is still up and I'm unsure whether I actually clicked it, about a second of nothing, then the Sync from dialog. (The shelf I'm testing with has about 300 books; not sure if this gets worse with more.)
When I confirm this one, it disappears (so at least I'm sure I've clicked) but the app is now unresponsive for... 175 seconds, with no dialog, nothing in the status bar, etc.