Re: [whatwg] Form submission progress display by UA (incl. file upload)
On Thu, 24 Jan 2008, Mikko Rantalainen wrote: > > Consider a form with a file input. User selects a huge file and hits > submit. Most UAs do not display nothing but an animated throbber until > the full submit is done and the download progress bar only starts to do > anything after the full submit part is already done. An another example > could be a long blog article that is being sent over an GPRS mobile > connection (with common speeds around 9kbps). > > I think that WF2 section 5.6 > (http://www.whatwg.org/specs/web-forms/current-work/#methodAndEnctypes) > should be modified to say something along the lines > > "User agents with interactive user interfaces should inform the user > about the progress of the data submission. For example, an UA with a > graphical user interface could display a visual progress bar which would > be updated once every second; the bar would be initially displayed as > empty and would fill over time as the encoded form data set is > transmitted. For transmissions that take more than a few seconds UA > might in addition display estimated time before done." > > Rationale: Upload progress monitoring is becoming more important every > day as browsers are often used for content authoring, the digital > content gets bigger and common user connections are highly asymmetric > (e.g. 24mbps downstream, 1mbps upstream in case of ADSL2+). The delay > expected by the user for sending a 100MB file could be close to > downloading a 100MB which is not the reality. An user in a hurry would > hit stop button and retry again after waiting for some time without > knowing that upload is in progress. I don't think we really should be saying anything about UI to this level of detail. We don't say that there should be a progress bar when the page loads, either. I recommend petitioning your UA implementor to add this. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Form submission progress display by UA (incl. file upload)
On Fri, 25 Jan 2008, Mikko Rantalainen wrote: > > > > I'm not sure I see what value is added by somehow mandating this > > "feature". Evolving browsers will probably add this feature anyway > > through competition. > > If it will probably be added in the future anyway shouldn't the spec > recommend doing so sooner? I'm not saying that every UA MUST do so but > they should (unless they have a good reason not to). I don't think the spec should be mandating UI for this kind of thing. It doesn't affect interoperability. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Form submission progress display by UA (incl. file upload)
On Jan 25, 2008 2:48 PM, Mikko Rantalainen <[EMAIL PROTECTED]> wrote:
> It's wise to always trying to minimize the battery usage in a battery
> operated device. However, if the device is already using wireless or
> wired communication for transmitting the data set it cannot just do
> "nothing".
from my unfortunate experience in this area, timers cost extra. (even
above wifi cost.)
> Notice, also, that I wasn't suggesting that the above text is
> a "MUST" but instead just "SHOULD". Perhaps it could be even "recommended".
that's better :)
> How can the "file picker posting system" know something like actual
> bandwidth beforehand? Perhaps the user is using a mobile device that is
> currently on WLAN connection (say 54mbps) and the user starts sending
> the file. If the file picker has told the user that sending takes
> approximately 5 minutes for the selected file, how is the user supposed
> to know the actual sending time after he starts moving and the
> connection drops to 3G mobile network (around 0.5mbps) or GPRS or GSM
> data mobile network (around 0.001mbps).
i think we're supposed to send offline notifications, i'd assume that
network changes would trigger that.
whether they do or don't, your ip address will change (unless you have
a really magical vpn), and as such your connection will fail. without
some magical resume features (perhaps as i described below), you'll
have to start over. so no problem here.
> I cannot imagine anything but a
> progress bar displaying the current rate (or transfer rate for the
> previous 30 seconds if that's how often the progress can be updated
> because the battery must be conserved).
>
> > http://mxr.mozilla.org/seamonkey/source/content/base/public/nsIDOMFile.idl
> > lists a fileSize property. I think it'd be nice if gmail could tell me
> > that "this file will take an hour to upload". I also wonder if it'd be
> > a good idea to support getting chunks of a file, because if I had a
> > 4gb file, using DOMFile().getAsBinary() would probably crash my
> > browser. I'd kinda like for gmail to be able to do partial uploads
> > In order for this to work, there should be DOMString hash() which has
> > an optional argument for a hash algorithm ("md5sum", a const for
> > md5sum, or maybe an object { processBlock:function(data) {},
> > getHash:function() }. Otherwise a user could try feeding sequential
> > blocks from different files.
> I agree that something like that would be nice to have for some cases.
> However, I do not think that such behavior would make upload progress
> monitoring unneeded.
> The current "fix" for this problem is to connect
> the receiving server with HttpXmlRequest() and ask the server how much
> data the server has received. Then this result can be displayed somehow
> to the user.
implementation demos are probably a good thing before discussing a standard :)
> I don't think that IE has a working upload progress meter. I have always
> experienced IE just to simply slowly increase the progress meter until
> the page is done; it's advancing even if I disconnect the network cable
> during the progress... (just tried IE6 and IE7)
interesting (clever even)
> If it will probably be added in the future anyway shouldn't the spec
> recommend doing so sooner?
spec after implementation experience, not before. preferably including
experience with mobile devices.
> I'm not saying that every UA MUST do so but
> they should (unless they have a good reason not to).
Re: [whatwg] Form submission progress display by UA (incl. file upload)
timeless wrote:
> On 1/24/08, Mikko Rantalainen <[EMAIL PROTECTED]> wrote:
>> I think that WF2 section 5.6
>> (http://www.whatwg.org/specs/web-forms/current-work/#methodAndEnctypes)
>> should be modified to say something along the lines
>>
>> "User agents with interactive user interfaces should inform the user
>> about the progress of the data submission. For example, an UA with a
>> graphical user interface could display a visual progress bar which would
>> be updated once every second; the bar would be initially displayed as
>> empty and would fill over time as the encoded form data set is
>> transmitted. For transmissions that take more than a few seconds UA
>> might in addition display estimated time before done."
>
> My embedded device battery managers will complain about anything that
> happens more than once every 30s (they do).
It's wise to always trying to minimize the battery usage in a battery
operated device. However, if the device is already using wireless or
wired communication for transmitting the data set it cannot just do
"nothing". Notice, also, that I wasn't suggesting that the above text is
a "MUST" but instead just "SHOULD". Perhaps it could be even "recommended".
>> [an user uploading a huge file over slow uplink] in a hurry would
>> hit stop button and retry again after waiting for some time without
>> knowing that upload is in progress.
>
> I think a slightly more beneficial thing would be for the file picker
> posting system to be able to tell the user how big the file is and how
> long submitting a form should take at some transfer time. I'm not sure
> if anything like this is exposed.
How can the "file picker posting system" know something like actual
bandwidth beforehand? Perhaps the user is using a mobile device that is
currently on WLAN connection (say 54mbps) and the user starts sending
the file. If the file picker has told the user that sending takes
approximately 5 minutes for the selected file, how is the user supposed
to know the actual sending time after he starts moving and the
connection drops to 3G mobile network (around 0.5mbps) or GPRS or GSM
data mobile network (around 0.001mbps). I cannot imagine anything but a
progress bar displaying the current rate (or transfer rate for the
previous 30 seconds if that's how often the progress can be updated
because the battery must be conserved).
> http://mxr.mozilla.org/seamonkey/source/content/base/public/nsIDOMFile.idl
> lists a fileSize property. I think it'd be nice if gmail could tell me
> that "this file will take an hour to upload". I also wonder if it'd be
> a good idea to support getting chunks of a file, because if I had a
> 4gb file, using DOMFile().getAsBinary() would probably crash my
> browser. I'd kinda like for gmail to be able to do partial uploads
> In order for this to work, there should be DOMString hash() which has
> an optional argument for a hash algorithm ("md5sum", a const for
> md5sum, or maybe an object { processBlock:function(data) {},
> getHash:function() }. Otherwise a user could try feeding sequential
> blocks from different files.
I agree that something like that would be nice to have for some cases.
However, I do not think that such behavior would make upload progress
monitoring unneeded. The current "fix" for this problem is to connect
the receiving server with HttpXmlRequest() and ask the server how much
data the server has received. Then this result can be displayed somehow
to the user.
> Currently, file uploading is a kinda syncish process.
>
> As to your actual concerns, gmail already deals w/ uploading in the
> background fairly gracefully. And in IE6, there is a progress meter
> during the upload (Gecko doesn't show proper progress, but I believe
> that's a bug).
I don't think that IE has a working upload progress meter. I have always
experienced IE just to simply slowly increase the progress meter until
the page is done; it's advancing even if I disconnect the network cable
during the progress... (just tried IE6 and IE7)
> I'm not sure I see what value is added by somehow mandating this
> "feature". Evolving browsers will probably add this feature anyway
> through competition.
If it will probably be added in the future anyway shouldn't the spec
recommend doing so sooner? I'm not saying that every UA MUST do so but
they should (unless they have a good reason not to).
--
Mikko
signature.asc
Description: OpenPGP digital signature
Re: [whatwg] Form submission progress display by UA (incl. file upload)
On 1/24/08, Mikko Rantalainen <[EMAIL PROTECTED]> wrote:
> Consider a form with a file input. User selects a huge file and hits
> submit. Most UAs do not display nothing but an animated throbber until
> the full submit is done and the download progress bar only starts to do
> anything after the full submit part is already done. An another example
> could be a long blog article that is being sent over an GPRS mobile
> connection (with common speeds around 9kbps).
>
> I think that WF2 section 5.6
> (http://www.whatwg.org/specs/web-forms/current-work/#methodAndEnctypes)
> should be modified to say something along the lines
>
> "User agents with interactive user interfaces should inform the user
> about the progress of the data submission. For example, an UA with a
> graphical user interface could display a visual progress bar which would
> be updated once every second; the bar would be initially displayed as
> empty and would fill over time as the encoded form data set is
> transmitted. For transmissions that take more than a few seconds UA
> might in addition display estimated time before done."
My embedded device battery managers will complain about anything that
happens more than once every 30s (they do).
> Rationale: Upload progress monitoring is becoming more important every
> day as browsers are often used for content authoring, the digital
> content gets bigger and common user connections are highly asymmetric
> (e.g. 24mbps downstream, 1mbps upstream in case of ADSL2+). The delay
> expected by the user for sending a 100MB file could be close to
> downloading a 100MB which is not the reality. An user in a hurry would
> hit stop button and retry again after waiting for some time without
> knowing that upload is in progress.
I think a slightly more beneficial thing would be for the file picker
posting system to be able to tell the user how big the file is and how
long submitting a form should take at some transfer time. I'm not sure
if anything like this is exposed.
http://mxr.mozilla.org/seamonkey/source/content/base/public/nsIDOMFile.idl
lists a fileSize property. I think it'd be nice if gmail could tell me
that "this file will take an hour to upload". I also wonder if it'd be
a good idea to support getting chunks of a file, because if I had a
4gb file, using DOMFile().getAsBinary() would probably crash my
browser. I'd kinda like for gmail to be able to do partial uploads
In order for this to work, there should be DOMString hash() which has
an optional argument for a hash algorithm ("md5sum", a const for
md5sum, or maybe an object { processBlock:function(data) {},
getHash:function() }. Otherwise a user could try feeding sequential
blocks from different files.
Currently, file uploading is a kinda syncish process.
As to your actual concerns, gmail already deals w/ uploading in the
background fairly gracefully. And in IE6, there is a progress meter
during the upload (Gecko doesn't show proper progress, but I believe
that's a bug).
I'm not sure I see what value is added by somehow mandating this
"feature". Evolving browsers will probably add this feature anyway
through competition.
