Re: ISSUE-112: Should progress run a UI or rely on other stuff too?

On Sat, 10 Feb 2007 14:39:13 +0530, Ian Hickson <ian@hixie.ch> wrote:

> On Sat, 10 Feb 2007, Charles McCathieNevile wrote:
>> >
>> > Are there any other actual use cases? What else would you use the
>> > progress events for if not a standard progress UI?
>>
>> Measuring how your network operations are going, whether to time them
>> out andswap to something else, ...
>
> Could you elaborate on this? It seems like this use case would need much
> stricter restrictions on frequency and timing of events.

I don't think so. It allows you to do opportunistic optimisation, same as a 
progress event that may or may not fire allows you to do opportunistic 
optimisation of the UI. (Since current UAs don't fire progress events, for all 
the time that they are in use you don't know if those events will fire).

> I didn't realise
> this was one of the requirements for this spec (and I definitely didn't
> realise it was the only requirement -- I'd assumed the intent was to do
> what Maciej described, but the existence of this issue clearly indicates
> that those use cases were not part of the initial requirements and
> research for this feature).

The use case of building UI widgets is clearly a requirement for this spec (and 
the primary motivator, IMHO). The question is whether progress should support 
that entirely on its own, or be an extension available for other specs.

>> The issue here though is actually whether you should be able to build
>> your entire UI on nothing but progress events, or whether you should
>> rely on other specifications for things like the start and end, and get
>> them to define that progress events can be fired.
>
> I think it's clear that interoperability will be best served by having the
> events for each load feature described in conjunction with that load
> feature's processing model. It is extremely difficult to write unambiguous
> and implementable abstract specifications. (Not to say it's impossible,
> but it is certainly not something I would recommend.)

I'm not sure here what you mean by load feature, which makes it hard for me to 
parse this... can you please expand?

>> In that scenario, if you build a UI element you would make a standard UI
>> widget that assumed no progress events, and a progress event extension
>> that, if it got them, would refine the UI widget by adding some sense of
>> progress. For example, a rectangular bar might normally have a cylon eye
>> effect, but if you get progress events that tell you how far along you
>> are you could change that to have a proportional progress bar.
>
> Maciej's model seems amenable to this too. I don't think Maciej is arguing
> that the existing events (namely, 'load', 'error', and 'abort') should be
> dropped, or made redundant; I would expect his proposed processing model
> to augment them.

My understanding is that they are made redundant by being replicated by events 
that are required to fire by the progress event spec, although I may have missed 
something there...

>> As Maciej points out, that means you have to write widgets for each type
>> of operation that might fire progress events. On the other hand it means
>> you aren't relying on progress events in order to have at least some UI.
>
> I don't understand why we can't leverage the existing event structure
> while still providing for Maciej's use cases, and get easily authored
> backwards compatibility at the same time.

Well, that is the alternative to specifying everything in the progress event 
spec itself as I understand it. I think - I'm still rattling some of this around 
my skull.

>> And it lightens the requirements on the progress event spec.
>
> Ease of spec writing should not be a concern here. There's an order of
> magnitude more implementors than spec writers, many orders of magnitude
> more authors than implementors, and yet more orders of magnitude more
> users than authors. Thus the needs of the users trump the needs of the
> authors, which trump the needs of the implementors, which trump the needs
> of the spec writers. We (the spec writers) are the slaves at the bottom of
> the chain -- on us falls all the hard work. 

Sure. But cutting down what the spec requires is about simplifying the 
implementation requirements, based on the idea that authors will write backwards-compatible 
code tailored to the kind of operation they are going to use, so that users get 
the widest choice of user agent that does something useful.

The alternative is to simplify the life of authors by allowing them to attach 
the same widget to anything that does progress events, although I am not sure 
what that means for anything that doesn't fire progress events - presumably 
there is no feedback at all, unless the author makes a second, redundant control.

Both of these possibilities strike me as legitimate choices - hence raising an 
issue and asking for feedback.

cheers

Chaals

-- 
Charles McCathieNevile, Opera Software: Standards Group
hablo español - je parle français - jeg lærer norsk
chaals@opera.com Try Opera 9.1 http://opera.com

Received on Saturday, 10 February 2007 09:47:39 UTC