#374 AJAX for actions

[Lee Worden]

Actions like "set source file location" and such (all the buttons on ManageProject, and the "click here to add the source file to the project" links) should be done in place using AJAX, instead of carrying the browser away to an invocation of ManageProject that will redo the action if reloaded. This would simply produce a small message reporting whether the operation succeeded, without leaving the current page.

[Lee Worden]

I've created an svn branch for developing AJAX features and the custom api.php actions that they will call on: https://workingwiki.svn.sourceforge.net/svnroot/workingwiki/branches/api

It's got some prototype code checked in that does successfully provide an API action and jQuery/ResourcesLoader code that makes an AJAX call to it, though it doesn't do anything nontrivial yet.

[Lee Worden]

bug reports related to this item:

unintentionally redoing actions
https://sourceforge.net/tracker/index.php?func=detail&aid=3173098&group_id=366300&atid=1527385

bad gateway
https://sourceforge.net/tracker/index.php?func=detail&aid=3473526&group_id=366300&atid=1527385

[Lee Worden]

Another thought: I wonder if I could get asynchronous making and loading of project files using iframes? It wouldn't give us the other benefits, like doing WW actions by clicking without leaving the page, and having the list of background jobs update itself without reloading the page, but it might be fairly easy.

[Lee Worden]

This is probably a good place to keep track of the different things that could be implemented using jQuery and/or api calls, so I don't forget them.

• The different operations on source files and project descriptions that are currently done by pushing a button to submit a POST action on ManageProject.

• "Click here to add/remove/relocate this file" in WW messages inserted into wiki page output.

• Filling and reloading the list of background jobs. We can also do notification when a background job completes.

• Operations on background jobs.

• dynamically loading project file contents. This allows WW to parse and return the wiki page quickly and postpone make operations until each project file is retrieved successively. I imagine placing a box in the place of each not-yet-made project file, which includes a message "Waiting for project file to be made", and a "stop making" link. The stop-making operation would also be implemented using ajax.

• [log] and some other view-project-file actions could be implemented by popping up the file contents in a panel in front of the current page, as an alternative to navigating away to a GetProjectFile page.

• The [log] link and/or the filename in the dotted border around a project file could be augmented with a dynamic pull-down menu with options like make, rm/make, sync, make in background, go to pages where the file is archived, etc. There should be a similar menu at each source file.

• The project name in the left sidebar could be augmented with a pulldown menu for project operations like clear directory, browse directory, import files, export, go to project description, etc. Even more advanced would be to pop up a fuller manage-project interface with the lists of file locations and everything, sort of like how you can pop up an interface to browse your posts and comments on google+...

[Lee Worden]

• After a page is open in the browser, it could update the project files displayed in the page if they change on the server. Not clear whether this would be necessarily desirable for the user (what if you want to open a copy of the page and keep it the same to compare against a newer version in a different tab?) or for the software (too much of an imposition on user's processor, network bandwidth and server load?)

[Lee Worden]

But there are cases where you would want the display to update: for instance if you run a background job that updates certain figures (that is, submit the job, track its progress and merge it into the project without leaving the wiki page) you almost certainly want to see the updated figures.

[Jonathan Dushoff]

Automatic updating of project files would be a nice feature on some occasions, but it's not clear that it's worth it. In the example you give, needing to refresh the page would not be an undue burden on the user.

[Lee Worden]

There could also be a 'refresh' control on each project file.

[Lee Worden]

This can only be done (in a sane way) in MediaWiki 1.17 and later, so it would require abandoning support for older versions of MW.

[Lee Worden]

(Thought I posted this comment already, but now I don't know where it went.)

It might be good to pursue putting each project file into an <iframe> element, so it can make and load after the containing wiki page is already served, rather than doing all the making while putting the wiki page together and giving the user no feedback about what's taking so long. I've created a separate ticket for that: https://sourceforge.net/p/workingwiki/feature-requests/57/

[Lee Worden]

Ticket moved from /p/workingwiki/feature-requests/7/

[Lee Worden]

Making some progress on adopting jQuery features, though haven't abandoned MW 1.13 yet.

Attached is a glimpse of the AJAXy future...

[Lee Worden]

I have an Ajax version of the destroy-background-job link working in WW now, which should serve as a model for the other actions.

[Lee Worden]

Oh, but while the destroy-background-job action is usable (and very convenient) it need a confirm popup before it goes ahead, and it needs help with reporting errors if they happen - the error part's written but not working in 1.19 and not tested in 1.20+.

[Lee Worden]

Has a confirm now and at least a basic version of error reporting. It's reporting errors as it's told of them, but the messages it's getting might need some expanding on.

It also has a custom tiny spinner now, that fits next to the link, and the background jobs box has a reload button in the top right, and it updates itself every 60 seconds (it was already doing that part).

[Lee Worden]

Note that when there are no jobs, the box goes away, so you can't press the reload button to update the list when you think there is a job now - you have to wait until it updates itself. Could be annoying to an impatient user.

Maybe in a future redesign the list of jobs will be in the sidebar with the job info in some kind of popup thing - in that case the reload interface could always be there.

[Lee Worden]

And here's a video, which is weirdly jerky, Keystone Kops-style. The actual wiki isn't jerky like that.

[Lee Worden]

It looks like these Ajax controls aren't getting activated on Special pages, only on mainspace pages right now.

[Jonathan Dushoff]

The video shows no content for me (all black, or all gray). One of the things I tried was totem 3.0.1

[Lee Worden]

Argh, I'm sorry. It plays for me in mplayer. I'll convert it to a
different format and reupload.

On 10/11/2013 05:58 AM, Jonathan Dushoff wrote:

The video shows no content for me (all black, or all gray). One of the
things I tried was totem 3.0.1

[Lee Worden]

This version plays for me in totem.

Note, as I sort of mentioned, the video seems to play a little faster than real life, and the motion stops and starts. The little spinners don't stop and start in real life.

[Lee Worden]

For Ajax programming in general: I'm going to want to be very intentional about making it responsive and informative. My main objective in adopting Ajax for actions, before its general attractiveness to users and the perception that they have come to expect it, is to give them good feedback about what's happening when, and why.

So it's very important that:

• every click get an immediate response. If nothing else, start a spinner.
  • I'm considering an alternative to spinners, where I open a notification balloon for that action, saying "contacting server" or whatever, and update it as often as possible until it becomes "did XXX action" and then fades away.
• all notifications be clear and specific. This may take some work because it looks like the Ajax framework gives some vague messages, for instance right now the ww-list-background-jobs action is saying something like "Couldn't reload list of background jobs: http" when the computer isn't on the network. Obviously "http" isn't an adequate explanation.
• it not over-notify. The ww-list-background-jobs action happens automatically every 60 seconds, and it should not generate a 20-car pileup of dialog boxes if the user walks away while the network is down for 20 minutes. Actions that happen automatically in the background need to give feedback differently than explicitly-requested actions.
• also, though this item probably needs to be filed somewhere else - when I get to making and loading project files asynchronously after the page load, I want to provide absolutely as much real-time information as possible - if I can, a scrolling view on the make log as it's happening, plus updates about what happens before and after the make log. This will take some doing technically - I might need to switch from Ajax to Comet, or something (when I get to this I'll probably ask the wikitech-l list if anyone's done something similar).

Also:

• Every action, and every confirm/cancel button on a popup, should have a keyboard shortcut.

[Lee Worden]

Improved reporting of the cryptic error 'http' by having it display a broken reload icon when I get this error (i.e. when the network seems to be down).

[Jonathan Dushoff]

That's funny. I logged in to ask what the "stop" at the end was about, but I got it :-).