Execute dialog redesign

[mthuurne]

The Execute dialog is not a great user experience. However, it is also one of the more complex pieces of user interface we have, so it's not trivial to improve it significantly. The dialog will probably need to be redesigned from the ground up at some point. This issue is to track problems and potential solutions so we don't forget about them when the time comes to do the redesign.

One thing that's confusing is that the same dialog is used for creating ad-hoc jobs, creating new configurations, editing configurations and customizing configurations to be run ("load"). We could lock the dialog in a particular mode, or if that is too inflexible, make the mode switch more explicit.

On a technical level, the dialog is implemented by doing an HTTP POST for each dialog step. This makes a bit of a mess of the browser history. It would be cleaner to have one history item for the entire dialog and only do a POST at the very end, when starting a job or saving a configuration. Note that the amount of state in the dialog can be too large to pass in a GET query, so to get by with one POST we'd have to avoid reloading the page and instead use XMLHttpRequest to fetch new data.

The dialog is currently set up in a wizard style, with one question leading to the next. This works reasonably well for ad-hoc jobs and new configurations, but for editing and customizing a non-linear approach would be better. A complication is that some choices affect what other choices are available, for example the selection of tasks will determine which inputs need to be specified.

Descriptive text from the task definition could be used to help the user fill in parameters. Maybe parameter definitions should include a description field, but showing the task description of selected tasks might be a workable alternative.

The approach to notifications is likely going to change, see #10. So this part of the UI can be dropped in an Execute dialog redesign, or perhaps it will already have been removed by then.