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
[whatwg] Form submission progress display by UA (incl. file upload)
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. -- 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.
