Closed Bug 48436 Opened 24 years ago Closed 22 years ago

Change "Document: Done" to "Done"

Categories

(Core :: Networking, defect, P5)

defect

Tracking

()

VERIFIED FIXED
mozilla1.2alpha

People

(Reporter: bugzilla, Assigned: Biesinger)

References

Details

Attachments

(1 file, 2 obsolete files)

Some discussion began to emerge in bug 47128 about whether we should stick with 
4.x's silly "Document: Done" statusbar message.  Splitting this off to cover 
that issue.  Maybe we should give some other wording a test run in pr3 and see 
how users respond.
I bet they won't notice. But "done" is okay with me. (Or we could display random 
off-the-wall quotations. Maybe some haiku status messages.)
Document is done
But it's bad HTML
So it won't look right
I'm really liking Vera's haiku idea, and the sample one that Matt gave was 
great!

(Really, though, anyone strongly against or in support of making this change? 
Matt, Brendan, German, John, Vera...? 
Status: NEW → ASSIGNED
Target Milestone: --- → M18
Strongly in support
(In fact, I was the one who
Proposed the idea)

Perhaps on Unix, each time a page finishes loading, we could fire up a new 
instance of emacs in M-x zippy mode, to get a Zippy the Pinhead quote to use as 
status text. It wouldn't be that good performance-wise, but it would bring a 
whole new dimension to Web surfing.
I actually like Document: Done. I don't really care if it's changed though. Just 
giving my two cents while I cc myself to this (might as well make that useless 
cc email useful, huh?)
Priority: P3 → P2
and so for $1 mil, the final answer is...?
Going for one million dollars, going once, going twice ...

Done!

(By the way, the rest of Necko's status bar notifications could do with a lot of 
work, too ...)
Open a new bug to "review/revise status bar messages" and assign it to me! I can 
review them (and have the other writers and the editor look at them) as soon as 
we get past the current crunch.
Priority: P2 → P4
Target Milestone: M18 → mozilla1.0
I'm starting to think differently about this.  I know most of the majority of 
status bar messages are for the document loading in the content area, 
but "Done" doesn't seem very clear to me.
Priority: P4 → P5
Not sure I agree with this anymore...
Assignee: blakeross → ben
Status: ASSIGNED → NEW
So what should we use as a status message in the statusbar? anyone?
Depends on what the goal is. If you want to merely inidcate that the
(down)loading of the document has been completed , I think 'Done' something like
"Loading completed" is fine. This is not really something that can be usability
tested (by itself). Also please keep localization in mind, that is any changes
in structure of the statement (like adding new information) have to be reflected
in the 10+ or so languages that Moz/N6 get translated into.
perhaps:
Page: Downloaded (%X% elements remaining)
Page: Downloaded (%X% reflows expected)
Page: Refreshed (All page elements done refreshing)
Page: Loaded (Some objects are animating)
Page: Loaded (%X% script events remaining)
Page: Done (All page elements done loading)
Page: Done (All script events processed)
Page: Error (%X% errors encountered) [%lasterror%]
Summary: Change "Document: Done" to "Done" (or something else) ? → When is a document done? When is a door not a door?
I would like to replace "Page:" with "Document:" there, because not only pages
can be displayed with navigator.
I think the general idea is good but it is too technically worded. Who knows
what a reflow is? Not our general Netscape 6 user. Secondly I would stay away
from using a noun for the page altogether. That way it can be a plugin, a 3d
view or whatever document types get added later.
Also timeless, can you explain what you envision the different messages being
used for, and why you think it would be important for a common end user to have
all of these in there? Thanks.
I use page to mean the literal 'web page', whereas the document includes all of 
its dependencies.
in which case, for Page: Done, i guess it should say Document: Done.

elements/objects remaining, if you watch IE load a page it tells you how many 
items are left to load.  Basic items are images, but also java apps, objects 
css files, and iframes[?].

I'm not sure about reflows, but it would be nice if we could warn people that 
the page is likely to rearrange itself shortly.

The animations and script information is to explain why the stop button is 
enabled.

let's try a sample walk through.
<load http://localhost/mozilla/testSuite/>
Downloading Page: 50% of 100k (16bytes/sec).
Loading Document: 50 elements remaining. Loading Image: 90% of 16k (10k/sec).
...
Loading Document: 5 elements remaining, 1 reflow expected. Loading Style: 99% 
of 20k (50k/sec).
Loaded Document: Done. Scripts: 5 events queued.
...
Document: Done. Scripts: 1 scheduled (starts: 30sec). Animations: 5 (stops: 
45sec). 
<stop>
Document: Stopped. Scripts: Terminated.
<reload>
{page sent w/ errors}
Error loading page: Missing <html>. 50 errors encountered.
<reload>
{page sent w/o errors}
Loading Page: from cache (1 sec).
Loading Document: 50 elements remaining. Loading Image: from cache (5 sec).

-- I don't have a better term for reflow, i'm hoping someone else could offer a 
translation from en-Technical to en-US.

For one thing, we could have other details only display on mouse over (file/url 
names, transfer rates) or toggle what displays on mouse click.

original:
Loading Document: 50 elements remaining. Loading Image: 90% of 16k (10k/sec).
alternative:
index.html: 10/100 loaded. background.png: 14/16k.
index.html: 10% loaded. background.png: 90% loaded.
index.html: 10sec elapsed (unknown). background.png: 2sec elapsed (1sec 
remaining)
I really like the mouseover idea, that provides detail information on the item
being moused over.
I still think the scenario is way too verbose for the common user. I mean most
users do not even know what a script is or an event. They are not aware, because
that is not their mental model of how a page is displayed. To the extent where
we are talking only about a global number or items that are still loading that
is OK (like IE). Everything beyond that is a debugging aid for web developers
not a help for end users.
The other example were you are 'warning people that the page is likely to
rearrange itself shortly' is intimidating, even for me. Warning are issued where
you want to users to take preventive action or change the action they are
currently involved in, when in fact no such thing is required when loading a page.
I think we should keep things at a non-complex summary level for our end-users
rather than going into too many details.
For web developers a special browser pref could be added "Verbose status
messages", that could enable the rich detailed messages you are shwoing here.
Summary: When is a document done? When is a door not a door? → Change "Document: Done" to "Done" (or something else)?
This bug is just to change `Document: Done' to `Done'. Navigator's other 
progress text is just as sub-optimal as `Document: Done' is, but that should be 
the subject of separate bugs. (I have a spec for them lying around here 
somewhere ...)
Done is a waste of a status line. we should make it blank when we're done. If 
you have another bug that includes your spec please mention the number here and 
we can spam it with all of the comments you want deported.
I completely disagree. First of all, I need some indication that it's done. 
Second, where would we put that little clock?

As to removing "Document: ", I say leave it in. Is it really worth modifying?
The status bar should behave more like MSIE and NS4 while loading, e.g.:

Connecting to www.sitename.com
Transferring data from www.sitename.com
17/17 items remaining, transferring data from www.sitename.com
17/17 items remaining, 90% of index.html downloaded (8 seconds remaining)
17/17 items remaining, 97% of style.css downloaded (2 seconds remaining)
17/17 items remaining, 50% of picture1.jpg downloaded (1:15 remaining)
17/17 items remaining, 25% of picture2.jpg downloaded

For this last one it doesn't know how much time is left yet. It would loop
through all the different items one by one and come back to the original
"transferring data..." message.

...
1/17 items remaining, transferring data from www.sitename.com
1/17 items remaining, 75% of picture15.jpg downloaded (25 seconds remaining)
1/17 items remaining, 95% of picture15.jpg downloaded (5 seconds remaining)

And then, finally...

Done (17/17 items downloaded in 5:30)

For pages with only one item (e.g. downloading an image or plain text document),
the first part should be truncated unless or until another item is found. I
think the progress bar could be more accurate in this respect also, but I've
already gone too far off topic on this one.

Oh, and yes, of course the "Document: " should be dropped. In a sense, it could
actually be inaccurate since the progress indicator should also include things
outside of the document like the JS files and CSS files.
mass move, v2.
qa to me.
QA Contact: tever → benc
Status: NEW → ASSIGNED
Target Milestone: mozilla1.0 → Future
This should be done before 1.0, due to translation-freeze.
Can we nominate this for drivers and ADT ?
This patch changes the text from "Document: Done (%sec% secs)" to "Done (%sec%
seconds)".

This patch changes:
/xpfe/browser/resources/locale/en-US/navigator.properties
/xpfe/browser/resources/locale/en-US/navigator.dtd

I think the patch format is a bit cludgy, but it'll do.
ok, first of all, this patch isn't in the right format and i don't think it will
do. i will attach a cvs diff -u patch, i only want to know if we only change
this for navigator or also for messenger which has it's own "Document: Done"
entities (and i think we should change it everywhere, otherwise it's confusing).
Assignee: ben → rossi
Status: ASSIGNED → NEW
Attached patch patch for navigator & mailnews (obsolete) — Splinter Review
i made it for navigator and mailnews because i think you will all agree that we
should change it everywhere =)
obsoleting old patch, if you only want it for navigator i will attach a correct
format patch for navigator only.
Attachment #83516 - Attachment is obsolete: true
Comment on attachment 84038 [details] [diff] [review]
patch for navigator & mailnews

r=biesi
Attachment #84038 - Flags: review+
Summary: Change "Document: Done" to "Done" (or something else)? → Change "Document: Done" to "Done"
Comment on attachment 84038 [details] [diff] [review]
patch for navigator & mailnews

Why do we even have the Done (X.XX secs) in the first place?  Let's do what
this bug suggests and actually make it just plain "Done".
Why modify the message to show less information than it does now? I'm sure
someone could find a use for that time display. If the change eliminates bloat,
it's good, but otherwise no harm in leaving it alone.
I like comment 21, but shouldn't that be a separate bug as 
per comment 8?  

I agree with the sentiment in comment 29:  the time it took
the page to load is useful information, for web authors if
for nobody else, so unless removing it would noticeably 
improve clarity or performance, I would like to see it 
retained.  
hwaara... this bug is not about removing the time, afaict. It's about removing
the "Document: " part of the status message.

Can we get it in? rossi, can you ask for sr?
Please get rid of the time.  It's horribly inaccurate, and useless.  Find me on
irc if you want to know why.
Attachment #84038 - Attachment is obsolete: true
Comment on attachment 92717 [details] [diff] [review]
also removes the time

Looks safe and right.  I double checked that all instances are accounted for.

r=caillon.  (0.372 secs)
Attachment #92717 - Flags: review+
blake, could you super-review the latest patch here?
Assignee: rossi → cbiesinger
And just why should we remove the time ? I want it there.
One acceptable solution is to move it to the Page Info dialog, but then that
should be done /before/ checking this in.
> And just why should we remove the time ?

Because it's deemed useless.   I concur.

So the onus is on you: Why should we keep it?  Is there any good reason other
than "because it's cool"?  No, you aren't doing time analysis because if you
are, you wouldn't be trusting what we output.
Right.. I have no good reasons for keeping it, other than 'I want it' ;)
I just wanted some more discussion before it went in.
Attachment #92717 - Flags: superreview+
Comment on attachment 92717 [details] [diff] [review]
also removes the time

sr=blake (.0371 secs) (that's why I'm a super-reviewer, caillon ;-)
tm -> 1.2alpha because that's when it will be checked in :)
Status: NEW → ASSIGNED
Target Milestone: Future → mozilla1.2alpha
fixed
Status: ASSIGNED → RESOLVED
Closed: 22 years ago
Resolution: --- → FIXED
Keywords: verifyme
<sob> ... It's beautiful!

Verified fixed, build 2002081308, Mac OS 9.2.2.
Status: RESOLVED → VERIFIED
I miss the time display very much - I found it useful, in spite of it not being
totally accurate. If the lack accuracy was a reason to remove it, wouldn't it
have been enough to reduce the precision to, say, one tenth of a second, and 
call it an approximation?

I must say that IME the lack of accuracy never made a quick site look slow, or
vice versa, so it can't have been that bad, IMHO.
If you'd like that to be changed, maybe you can tell us what you do that
requires the time display? That would make it more likely to happen.
I totally loved the time display. Have used it quite a bit while developing 
phpBB (www.phpbb.com). I know, it's not very accurate, especially because it 
includes network/server delays but it does give you a ballpoint figure when 
trying different templates/stylesheets/JS code.

I would LOVE to have some kind of time statistics. It would be ideal if I could 
see:
- Time between request and first reply from the webserver
- Transfer time (including bytes/sec)
- Time for parsing HTML
- Time for running scripts
- Time for rendering the HTML
- Time that was needed for waiting on additional page elements (i.e. images).

Would be fun if there was some kind of pref that would output above info to 
some kind of debug console..
Any idea if this has been proposed before and if I should create a bug for this 
or if I should first put this in the newsgroups? Have proposed this before but 
didn't get any response on that. I really can't imagine that I'm the only 
developer that needs this kind of information. Or am I the only person on this 
world that is trying to optimize his web application for speed? :?
If you really want the time display back, open a new bug for it.  This bug has
been fixed.
Re comment 46: - see bug 175231
BTW I opened bug 170284 for comment 45 some time ago.
Keywords: verifyme
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: