Justin,
That's a great question and one that I've been pondering.
We envision a number of different scenarios in which the Uploader
could be integrated: on a page by itself as part of a multi-step
workflow, embedded inline in a page with other content -- either in a
portlet or not, in a pop-up DHTML dialog or pop-up window. In all but
"embedded inline in a page" the Done and Cancel buttons would be
needed to complete the workflow.
So in most cases we really feel that the Done and Cancel buttons are
part of the basic workflow. (The embedded scenario actually needs a
slightly tweaked Uploader anyway, one that needs a little design work,
that probably will not be done for 1.0)
So given that Done and Cancel are part of the workflow it seems
important for them be there so that an implementor will not forget to
add them. Also I can't really provide the correct hiding and showing
action without them displayed.
- Eli
On Mar 13, 2009, at 5:48 AM, Justin wrote:
Hi Eli,
Sorry, I don't have any answers for you, but more questions.
If the default action for the buttons are null, if an implementor
uses the defaults, will the buttons be displayed?
Thanks
Justin
On 13-Mar-09, at 12:18 AM, Eli Cochran wrote:
I'm in the middle of implementing the Done and Cancel buttons for
Uploader Storyboard - Simple Upload and
Uploader Storyboard - Upload and Cancel.
For the Simple Upload storyboard this seems really straight
forward. The Done button needs a done action -- proceed to the next
thing, and the Cancel button needs a cancel action -- go back to
the previous thing.
So I defined two actions:
- options.actions.done
- options.actions.cancel
The default action for each is null, since we can't predict what an
integrator will want to do with the buttons, but there they are
ready for a developer to do the right thing. And the Uploader
displays the right button at the right time in the life cycle of
the component. I'm happy, but...
Looking at the storyboard for Upload and Cancel and it gets a bit
more interesting.
On the final screen, the Cancel Remaining Uploads button isn't
really a cancel action at all, it's a done action, or maybe it's a
done action. This is what I'm trying to figure out.
Seems to me that in most cases this button would probably do
exactly what the Done button would do. Examples: close the dialog,
go to the next screen, refresh the page, send a message to the
server to do the next things, etc.
Can I just map the done action to that button and be done with it?
Can we imagine another action, a different action, for the button?
Or perhaps we should provide another action even if we can't
imagine one, because someone using the Uploader might?
The options I've considered:
Two actions, cancel and done. That's what you get.
Three actions, cancelBeforeAnyUploads, cancelAfterAnyUploads and
done. If there isn't a cancelAfterAnyUploads then we use done.
Three actions, cancelBeforeAnyUploads, cancelAfterAnyUploads and
done. We make no assumptions about done filling in for a missing
cancelAfterAnyUploads.
(Suggestions for better naming will be gratefully accepted.)
If you followed all this you're a better man than I, even those of
you who are not men.
Thank you and good night,
Eli
. . . . . . . . . . . . . . . . . .
.
Eli Cochran
user interaction developer
ETS, UC Berkeley
_______________________________________________________
fluid-work mailing list - [email protected]
To unsubscribe, change settings or access archives,
see http://fluidproject.org/mailman/listinfo/fluid-work
. . . . . . . . . . . . . . . . . .
.
Eli Cochran
user interaction developer
ETS, UC Berkeley
_______________________________________________________
fluid-work mailing list - [email protected]
To unsubscribe, change settings or access archives,
see http://fluidproject.org/mailman/listinfo/fluid-work
