In Deducer, Ian developed the Dialog object and I thought we might use that basic framework for configuring analyses: specifying the DV and IVs, for example, and selecting options.
Default behaviors:
A dialog should have memory. Every time a user chooses options in the dialog, even if they do not "run" the dialog, the dialog records those changes. If it is closed without the user running it, it can repopulate those options when it is reopened.
When a dialog is called, it can be called with no parameters (in which case it is repopulated with its last state, or with no entries), or it can be called with parameters that represent each of the possible options in the dialog. That way, we could attach a dialog button to a particular output element and the user could click the button and receive a dialog that is configured to produce the output that was displayed.
Standard buttons for every dialog, which can be turned on or off, would be Run (calls the function associated with the dialog, using the current values of the dialog), Cancel (closes the dialog, but first records all the options so they will appear the next time it is opened), and Reset (clears all the options in the dialog, as well as any preview windows.)
Preview. Whenever possible, a dialog should permit a user to preview the output of the dialog as soon as enough options have been selected to permit the preview. This would encourage more exploration with analysis and allow the user to immediately see the consequences of different options, facilitating learning. This may not be practicable for time-consuming analyses. If Preview is enabled on a dialog, we could replace the "Run" button with something like a "Print" or "Post" button that would make the current preview into an Output Element and add it to the Output Navigator.
Multiple Instances? Should multiple instances of a dialog be permitted? If a user is setting up one dialog, should they be permitted to open a new dialog? If yes, which one becomes the "default" settings for the next time it is opened?
Separate Windows? Would it be possible for the dialogs to be separate, pop-out browser windows? That has some advantages. Or will dialogs need to be embedded in a single webpage?
Where to store behavior? In Deducer, developers "registered" an R function to each dialog, so that when the user pressed "Run", the function was executed using values in the current state of the dialog. It might be parsimonious to make any javascript or R function a part of the dialog object. When a developer added a component to a dialog, they would need to specify a variable name (or names) that the component would become when the dialog was run.
In Deducer, Ian developed the Dialog object and I thought we might use that basic framework for configuring analyses: specifying the DV and IVs, for example, and selecting options.
Default behaviors:
Multiple Instances? Should multiple instances of a dialog be permitted? If a user is setting up one dialog, should they be permitted to open a new dialog? If yes, which one becomes the "default" settings for the next time it is opened?
Separate Windows? Would it be possible for the dialogs to be separate, pop-out browser windows? That has some advantages. Or will dialogs need to be embedded in a single webpage?
Where to store behavior? In Deducer, developers "registered" an R function to each dialog, so that when the user pressed "Run", the function was executed using values in the current state of the dialog. It might be parsimonious to make any javascript or R function a part of the dialog object. When a developer added a component to a dialog, they would need to specify a variable name (or names) that the component would become when the dialog was run.