Closed
Bug 48436
Opened 24 years ago
Closed 22 years ago
Change "Document: Done" to "Done"
Categories
(Core :: Networking, defect, P5)
Core
Networking
Tracking
()
VERIFIED
FIXED
mozilla1.2alpha
People
(Reporter: bugzilla, Assigned: Biesinger)
References
Details
Attachments
(1 file, 2 obsolete files)
6.74 KB,
patch
|
caillon
:
review+
bugzilla
:
superreview+
|
Details | Diff | Splinter Review |
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.
Comment 1•24 years ago
|
||
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.)
Comment 2•24 years ago
|
||
Document is done But it's bad HTML So it won't look right
Reporter | ||
Comment 3•24 years ago
|
||
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
Comment 4•24 years ago
|
||
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?)
Reporter | ||
Updated•24 years ago
|
Priority: P3 → P2
Reporter | ||
Comment 6•24 years ago
|
||
and so for $1 mil, the final answer is...?
Comment 7•24 years ago
|
||
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 ...)
Comment 8•24 years ago
|
||
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.
Reporter | ||
Updated•24 years ago
|
Priority: P2 → P4
Target Milestone: M18 → mozilla1.0
Reporter | ||
Comment 9•24 years ago
|
||
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
Reporter | ||
Comment 10•24 years ago
|
||
Not sure I agree with this anymore...
Assignee: blakeross → ben
Status: ASSIGNED → NEW
Comment 11•24 years ago
|
||
So what should we use as a status message in the statusbar? anyone?
Comment 12•24 years ago
|
||
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.
Comment 13•24 years ago
|
||
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?
Comment 14•24 years ago
|
||
I would like to replace "Page:" with "Document:" there, because not only pages can be displayed with navigator.
Comment 15•24 years ago
|
||
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.
Comment 16•24 years ago
|
||
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)
Comment 17•24 years ago
|
||
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.
Reporter | ||
Updated•24 years ago
|
Summary: When is a document done? When is a door not a door? → Change "Document: Done" to "Done" (or something else)?
Comment 18•24 years ago
|
||
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 ...)
Comment 19•24 years ago
|
||
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.
Comment 20•24 years ago
|
||
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?
Comment 21•23 years ago
|
||
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.
Updated•23 years ago
|
Status: NEW → ASSIGNED
Target Milestone: mozilla1.0 → Future
Comment 23•22 years ago
|
||
This should be done before 1.0, due to translation-freeze. Can we nominate this for drivers and ADT ?
Comment 24•22 years ago
|
||
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.
Comment 25•22 years ago
|
||
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
Comment 26•22 years ago
|
||
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
Assignee | ||
Comment 27•22 years ago
|
||
Comment on attachment 84038 [details] [diff] [review] patch for navigator & mailnews r=biesi
Attachment #84038 -
Flags: review+
Assignee | ||
Updated•22 years ago
|
Summary: Change "Document: Done" to "Done" (or something else)? → Change "Document: Done" to "Done"
Comment 28•22 years ago
|
||
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".
Comment 29•22 years ago
|
||
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.
Comment 30•22 years ago
|
||
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.
Assignee | ||
Comment 31•22 years ago
|
||
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?
Comment 32•22 years ago
|
||
Please get rid of the time. It's horribly inaccurate, and useless. Find me on irc if you want to know why.
Assignee | ||
Comment 33•22 years ago
|
||
Attachment #84038 -
Attachment is obsolete: true
Comment 34•22 years ago
|
||
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+
Assignee | ||
Comment 35•22 years ago
|
||
blake, could you super-review the latest patch here?
Assignee: rossi → cbiesinger
Comment 36•22 years ago
|
||
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.
Comment 37•22 years ago
|
||
> 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.
Comment 38•22 years ago
|
||
Right.. I have no good reasons for keeping it, other than 'I want it' ;) I just wanted some more discussion before it went in.
Reporter | ||
Updated•22 years ago
|
Attachment #92717 -
Flags: superreview+
Reporter | ||
Comment 39•22 years ago
|
||
Comment on attachment 92717 [details] [diff] [review] also removes the time sr=blake (.0371 secs) (that's why I'm a super-reviewer, caillon ;-)
Assignee | ||
Comment 40•22 years ago
|
||
tm -> 1.2alpha because that's when it will be checked in :)
Status: NEW → ASSIGNED
Target Milestone: Future → mozilla1.2alpha
Assignee | ||
Comment 41•22 years ago
|
||
fixed
Status: ASSIGNED → RESOLVED
Closed: 22 years ago
Resolution: --- → FIXED
Comment 42•22 years ago
|
||
<sob> ... It's beautiful! Verified fixed, build 2002081308, Mac OS 9.2.2.
Status: RESOLVED → VERIFIED
Comment 43•22 years ago
|
||
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.
Comment 44•22 years ago
|
||
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.
Comment 45•22 years ago
|
||
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? :?
Comment 46•22 years ago
|
||
If you really want the time display back, open a new bug for it. This bug has been fixed.
Comment 47•22 years ago
|
||
Re comment 46: - see bug 175231
Comment 48•22 years ago
|
||
BTW I opened bug 170284 for comment 45 some time ago.
You need to log in
before you can comment on or make changes to this bug.
Description
•