Uploader, the strange case of when Cancel is Done

[Justin]

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

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