Uploader requirements

[Eli Cochran]

I'm sorry to say that we don't.

The markup is the closest thing. Markup is king.

- Eli

On Oct 28, 2008, at 9:48 AM, Jacob Farber wrote:

> Do you have an in-depth map of how the selectors need to be nested?
> I cant scrub mutch from the docs, and I cant depend on the  
> uploader2.html example b/c it doest explicitly define whats  
> important and whats there just for show.
>
>
> On Tue, Oct 28, 2008 at 12:21 PM, Eli Cochran  
> <eli at media.berkeley.edu> wrote:
> Assuming that someone uses our markup, there really is only one  
> required selector and that is the container.
>
> That said, this is a complex component.
>
> Looking at it from another direction, it is three components: an  
> Uploader, a Progressor, and a Scrolling widget. Plus, we're also  
> trying to support a couple of different use cases which have  
> different behaviors: inline and dialog.
>
> Our goal in building it is to expose pretty much every element with  
> a selector so that a developer can use as diverse a markup as  
> possible. But it does make for a very dense API.
>
> The API will feel more simplified in Uploader2 by the way we're  
> breaking things up. Uploader will feel like a collection of pieces-- 
> making it much easier to customize just one part of the whole.
>
> But I'd love to look at simplifying it further, and as soon as we  
> have Uploader2 in good shape, it might be worth thinking of ways to  
> simplifying it with out sacrificing the user experience.
>
> - Eli
>
> P.S. I see one selector that we're not using anymore:  
> "osModifierKey". And Pause may or may not be going away. And we  
> added one: stateDisplay: "div:first". I'll stop now.
>
>
>
> On Oct 28, 2008, at 7:41 AM, Jacob Farber wrote:
>
>> Hi Colin & Eli,
>> Currently, the existing Uploader API docs list 25 different  
>> selectors that are required. I'm not sure if this holds true for  
>> Uploader 2, but if it does is there any way we could isolate what  
>> is absolutely required (e.g. a browse and  upload button) versus  
>> whats just nice to have (e.g. txtTotalFiles and txtTotalBytes), and  
>> if you don't include the niceties you simply don't get them? This  
>> way, people could build different levels of uploader functionality  
>> and experiences, as opposed to a single elaborate one.
>> Just a thought.
>> Jacob
>>
>> -- 
>> Jacob Farber
>> University of Toronto - ATRC
>> Tel: (416) 946-3002
>> www.fluidproject.org
>>
>
> . . . . . . . . . . .  .  .   .    .      .         .              .                     .
>
> Eli Cochran
> user interaction developer
> ETS, UC Berkeley
>
>
>
>
>
> -- 
> Jacob Farber
> University of Toronto - ATRC
> Tel: (416) 946-3002
> www.fluidproject.org
>

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

Eli Cochran
user interaction developer
ETS, UC Berkeley


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.idrc.ocad.ca/pipermail/fluid-work/attachments/20081028/c74f59ac/attachment.htm>