I presume AWB makes users wait while it saves articles. Why not save them in the background? This would make AWB more pleasant to use. @Unforgettableid 20:02, 22 January 2008 (UTC)
@Reedy, 20:51, 22 January 2008 (UTC) wrote:
Migrate to API? will allow us to complete this much more easily. With the current way, we'd have to be faffing about with multiple browsers (which we already do do...)
@MaxSem, 20:57, 3 March 2008 (UTC) wrote:
What shall we do if the save is aborted for some reason and user input is needed? All UI will already be diplaying the next page.
@Penguin, 16:41, 21 May 2009 (UTC) wrote:
How about a visualization like the pre-parse mode? Pages that are saved without problems are just removed from the list and pages with errors, conflicts and so on are just marked with orange or red background and kept in the list. This way errors are handled gracefully and the fast workflow without delays is still preserved.
@Reedy, 16:28, 20 June 2009 (UTC) wrote:
It will happen, just i've been busy for the last few months. Its on my summer todo list, most of the stuff IS implemented, its just making AWB fully use the API for editing.
@Manishearth, 18:37, 19 January 2011 (UTC) wrote:
What I suggest is to bunch up this request and the top request into a server request queue sort of thing. As in, let the user queue up some pages for processing and generating diffs. The user then can do something else, while it queues. Then, the user comes back, and queues up the saves after checking each page. The queue will empty itself '''as''' the user is checking the page. That way, your diffs preload, and your saves get executed a bit later, but then you get a continuous stream of pages, instead of a broken one.
@Penguin, 20:23, 24 October 2011 (UTC) wrote:
I could still use this feature. When doing typo work with hundreds of articles (which I do at dawiki on a regular basis) the small delays between every save really slows down the process. There are three methods that I want (maybe in combination): 1. Preload the next page (so I don't have to wait for it to load). 2. Background save of article (so I don't have to wait for it to save), 3. Create some kind of bulk save in the end. The revision conflict risk is already there even if we don't pre-load/pre-save. It should just be marked in a sensible way (for bulk saves an option to add conflicts to the could be fine - for background saves a conflict save or otherwise server error could just keep the article in the list with a "notice/warning" background color, just as with pre-parsed links).
@Stevietheman, 14:18, 30 August 2014 (UTC) wrote:
I was about to add this suggestion and found it here already. Sometimes the saves are just brutal, taking 5-10 seconds each. If they could be queued, that would be a huge time-saver. I think though that there should be a (1 sec?) time delay built into the save (move to save queue) to help prevent machine-gun/asleep-at-the-wheel saves. And the user should be able to stop saves in the queue before they are executed. Perhaps also have an option to "Stop and move back into the list" where the user wants to re-do their work.