Uploader, the strange case of when Cancel is Done

[Eli Cochran]

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 - fluid-work at fluidproject.org
>> To unsubscribe, change settings or access archives,
>> see http://fluidproject.org/mailman/listinfo/fluid-work
>

. . . . . . . . . . .  .  .   .    .      .         .              .                     .

Eli Cochran
user interaction developer
ETS, UC Berkeley


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://fluidproject.org/pipermail/fluid-work/attachments/20090313/4e313f1d/attachment.html>