Uploader, the strange case of when Cancel is Done

[Eli Cochran]

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


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