Closed Bug 116008 Opened 23 years ago Closed 23 years ago

Default for "Save Page" is "Web Page, Complete"

Categories

(Core Graveyard :: File Handling, defect, P3)

Product:
Core Graveyard
Component:
File Handling
Type:
defect

Tracking

(Not tracked)

Status:
VERIFIED WONTFIX
Milestone:
mozilla0.9.9

People

(Reporter: Biesinger, Assigned: bugs)

References

(Depends on 1 open bug)

Details

(Keywords: dataloss)

Attachments

(1 file)

save as dialog
18.21 KB, image/png
Details 
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:0.9.6+) Gecko/20011218
BuildID:    2001121803

The default for saving a page should not be complete web page, but "Web Page,
HTML Only", because Mozilla should not mangle the file content.

This can cause nasty surprises (it did cause one for me).

Reproducible: Always
Steps to Reproduce:
1. Choose File/Save Page As or press Ctrl+S


Actual Results:  Default file type is "Web page, complete"

Expected Results:  Default type should be "HTML Only"
File handling.  To Ben.  ccing UI people who should make a call here.
Assignee: pchen → ben
Component: XP Apps → File Handling
not familiar enough with usability studies re: saving, but would saving only
html be more common than saving the complete web page?
OS: Windows 98 → All
Hardware: PC → All
another observation: since on Mac you cannot select anything other than complete
web page [for "save page"] due to bug 107521, would changing the default to save
only html be sensible?

then again, it depends on the response to my question in comment 2 --and how
soon bug 107521 can fixed. :)
Most users don't see Web pages as a HTML document, stylesheet and images - they
see them as single units. Saving the complete page seems to be the most logical
thing to do. But then I can also see the point about 'mangling' the HTML document.
Until recently, save as HTML was the only option, hence it is the logical
default until we get a compelling reason that the behavior should change.  Was
there an approved spec on this that specified otherwise?
I think Peter has put his finger on the spot.  The default behavior should not 
change (principle of least surprise for the user) unless we have a good reason 
to change it (and none has been cited at any point in the implementation of this 
feature).
The default was selected based on the default option used in Internet Explorer. 

When saving pages (*) you almost always want the content attached to it to come
with it. 

(* regular pages)

The only reason HTML only was the default before (in Mozilla and Netscape 4.x)
was that this functionality never existed.
Status: NEW → RESOLVED
Closed: 23 years ago
Resolution: --- → INVALID
Reopening. I don't see those as valid reasons, let alone compelling ones; better
to maintain consistency for our own users. We can easiliy change the default if
there is demand.  I'm not sure our users will know what this new feature is, and
they can't use the resulting file like they could before (for instance,  I can't
drop the file for this page on IE and it doesn't look right in 4.x), and they
will probably not know there is an associated folder (I was looking for it and
couldn't see it for quite a while). 

You also didn't answer my question: Was there an approved spec that called for
this change?
I also have another: What data do you have to backup your assertion that people
'almost always' want the content attached to come with it?
Status: RESOLVED → REOPENED
Resolution: INVALID → ---
"I can't drop the file for this page on IE and it doesn't look right in 4.x),
and they will probably not know there is an associated folder (I was looking for
it and
couldn't see it for quite a while)."

Why can't you drop the file for the page on IE? I've got IE configured as my
default browser and displays all pages I've saved with this function correctly. 

The IE desktop icon will not accept the drop.  I don't have IE set as default
browser.
I'm still waiting for answers to my questions.
Blocks: 115634
Ben: The Change of this behaviour is highly surprising and can be very annoying, if you're used to the fact that the default behaviour is to only save the current page. Most Mozilla users are used to this. IMHO, it's a bad idea to change this.
> I'm not sure our users will know what this new feature is

This is "save page as" whereas the old default behaviour was "save page text
as". I personally believe our users will understand this feature better than the
old one. (I have no evidence to back this.)


> and they can't use the resulting file like they could before (for instance,  I 
> can't drop the file for this page on IE

If you can't, then that's a bug (either in Mozilla or in IE, probably Mozilla).
Can you drag a page saved by IE onto IE?


> and it doesn't look right in 4.x

This would be seem to be a bug too, either in 4.x or Mozilla (probably 4.x).
Could you give an example of where Save Page As causes the page to change in
Netscape 4.x when compared to the original?


> and they will probably not know there is an associated folder (I was looking 
> for it and couldn't see it for quite a while). 

Windows (I don't know about other platforms) should treat the file and
associated directory as one unit. If it doesn't, then that's a bug (either in
Windows or in Mozilla, probably Mozilla).


> Was there an approved spec that called for this change?

(What is the process for getting specs approved? Who approves it?)


> I also have another: What data do you have to backup your assertion that 
> people 'almost always' want the content attached to come with it?

I don't know about Ben, but personally I have no evidence. However, it would
seem odd for a user to *want* Save Page As to lose formatting and images.


I assert that the current default is better suited to users who don't understand
computers well, while the non-mangling behaviour is better suited to users who
know what they are doing. Assuming we remember the user's selection (I'm told we
don't, if so this is a bug) then the current default seems best for the majority
of our users.
There was no prior discussion on changing the default to "save web page
complete." It just sprang out of nowhere. 

It is apparently now the practice for Netscape to just hand the Mozilla
community significant changes in browser behavior immediately before releasing a
new milestone, without any prior discussion, and before any serious discussion
can take place. This is not right.

This bug should be fixed for 0.9.7. 

At very least, the selection should be remembered. (filed bug 116263 for this)

But I still think that this bug should also be fixed.

Hixie: Good catch about IE, it won't accept drop of other HTML files to desktop
icon either, although will open and display 'save complete page' files. As I
said, the example I used was *this page*, which I know you all have access to
;-).   
I don't know why it isn't loading right in 4.x, but users assume
interoperability, and we sure can't fix it there.  
Windows may treat the file and folder as a unit, but users have no knowledge of
that, and makes this feature a bit weird.  
I'm guessing that the reason I'm not hearing any answer to my original question
is that there is no spec, and probably no UE involvement. If so, we have no
basis for changing the previous default.  We should involve UE, and consult
marketing to determine whether changing the default is appropriate. 
We are working on an official ownership and process model, which will cover spec
approval.
We should certainly remember the last setting used, which should satisfy
everyone here who wants either default.  
There was no formal UE spec for the content of this dialog. The contents of the
filter list as pertains to saving HTML pages is stated for the record however in
the MachV Plan:

http://mozilla.org/xpapps/MachVPlan/Context_Menu_Options.html

Speaking only for myself (as a user), I can say that IE's behaviour of saving
pages with attached objects is beneficial. I frequently save pages on websites
like theonion.com, cnn.com, etc, and when I do so I always want the images. Web
authors may have more trouble with this as they may want to save a page to edit
and thus not have the urls fixed up to local references. That concern would be
addressed by persisting the default filter selected as Peter suggests, which is
a slightly different bug to this but one that should be fixed. 

And please let's not turn this bug into a Netscape-Mozilla whine-fest. If you've
got concerns about ownership, send mail to staff@mozilla.org, or go join the
party in npm.general. 
trudelle: I don't have 4.x nor IE on my machine -- it's a Linux box only with no
commercial software beyond Pine, Pico and Return To Castle Wolfenstein. :-)

If you have problems with this feature, please file those bugs. My lack of 4.x
and IE means that I can't do any testing at the moment on these issues.

I don't think bugs in this feature should affect what the default is. What's the
process for getting an approved UI spec for the change?
Consider a user who is new to the Internet. He (our user happens to be male)
just got set up with Netscape 6.5 (or whatever) and decides to save a page he's
just found. So he does. He expects that when he loads the page up it will be
just like it was on the Web. I mean, that's how all is other applications work,
right? It will confuse him if it's missing the images. It will confuse him even
more if it's missing the external stylesheet because this will only manifest
itself with the fonts and colours being wrong. But if the page does look
identical then he's a happy bunny.

Now consider a user who's just upgraded to Netscape 6.5 (or Mozilla 0.9.7) from
4.x, 6.x or Mozilla. He's tearing around the Web, playing with all the new
features and saves a page. When he loads it up, he finds that the images etc.
have also been saved with the page. How cool, he thinks. And he's glad that it's
the default option because otherwise he wouldn't have found it. :-)

This is why I think saving the complete page should be the default option.

This could turn into one off those situations where the default behaviour is
different in Mozilla and Netscape 6 or even different depending on whether the
profile was converted from 4.x, 6.x or Mozilla or newly created (to avoid
confusing upgraders).
Since this is such a topic of debate, why not add a preference to distinguish
what is the default save-as option?  I'm not sure where to put that preference.
 (I personally heavily prefer just HTML.)

I'd also like to see an extra option to save as just html but with a new first
line containing a BASE tag <base href=url>.

Also note another possible option in the future will include rfc 2557 MHTML
(single file instead of file + folder of data), see bug 18764 and bug 40873.
I think the best idea here is to remember the choice. 'Complete' is much nicer
for typical users would don't understand news.bbc.co.uk is actually 46 separate
files. Advanced users are potentially more likely to want 'html only' the
majority of the time, so if they have to change it from 'Complete' every time,
they (I) will be annoyed by the default.

We should expect the advanced users to be knowledgeable enough to change the
save type, but not annoy them by making them do it again and again.

We can't expect the *typical* user to do so, so 'Complete' should be their (our)
default. Microsoft came to the same conclusion. (IE6 is complete by default)

Additionally, I feel this should be reworded to "Complete Web Page" or maybe
even "Entire Web Page", or "All content on Web Page".  "Web Page, complete"
looks and sounds incredible awkward.
Hixie: There is still no official process, but a spec that has been posted,
reviewed, and agreed on by the stakeholders is usually considered definitive.
BTW, I find Alex Bishop's scenarios quite persuasive. Perhaps we could try the
current default in upcoming usability tests.
trudelle: Just out of interest, who are these "stakeholders"?

I agree that we should try the current default in usability tests. In the mean
time, I propose that we mark this bug WONTFIX. It can be reopened if usability
tests indicate that the current default is, despite the many scenarios described
above, more unexpected than the old behaviour.
Whiteboard: WONTFIX? (usability tests suggested)
Wontfix is inappropriate, since if we decide not to change it then it should be
Invalid or WFM.  Let's leave it open to track the issue.  
Stakeholders vary depending on the situation, but in general are the people who
have a real stake in the work, either because they own affected code modules, or
the change affects a key derivative product they are responsible for, or they
are providing the resources needed to do the work.  For UI, it  should always
include the UE rep or other person responsible for the UI of the component.  For
any change, it should include QA, to ensure that the change is testable. 
Okay, I see the need to keep the masses happy.

I think we "power users" will be happy if we get the functionality of either: 

(1) remember whether the last save was "complete" or "HTML only" (this is bug
116263); or 

(2) a pref.

Once either of those goes in, we can resolve this bug as wontfix.
A pref is IMHO ridiculous. I'm sure any UI expert (qualified or self-claimed)
would back me on this.
*** Bug 116756 has been marked as a duplicate of this bug. ***
It isn't just experts vs masses, what about people who use Composer to edit
their local web pages?  (I don't know how common a scenario this is, but I've
been bit by it, and seen one other user perplexed by it.) Current Save-As
behavior facilitates saving and editing one HTML file at a time, wouldn't
Save-As-Complete's URL munging  be considered a critical data loss defect?  I
think this is related to Bug 115176, since in both cases users with the goal of
saving to view probably want something different from users saving to edit.
Adding dataloss (File contents are changed) and 4xp (4.x saved only HTML) keywords
Keywords: 4xp, dataloss
Uh, my use of the term dataloss was only if we tried to change the current
feature's behavior to this.  If we present this as a new feature, I don't think
there is dataloss any more than the current Save As HTML is dataloss due to its
not saving the images.  Both are valid, distinct features.
Peter, this bug does cause dataloss (I filed it because of the dataloss).

The file contents are changed when the file is saved; the original content

is lost. Doesn't this fit the definition of dataloss?
By that definition, you could call the delete feature dataloss, but it too is
just doing what it is designed to do.  The problem here is the expectation by
some that the HTML will be saved intact, and by others that the page they see
will be saved as is.  Each way of saving looks like data loss to one of these
groups.  I think we need to make the distinction clear, to set the proper
expectation.
trudelle: So for this bug the stake holders would be ben@netscape.com,
sairuh@netscape.com, mpt@mailandnews.com, and trudelle@netscape.com ?


Jeez, I was trying to ignore the question! ;-)  I'm not sure why you list MPT,
but otherwise that seems like a minimal set.  I'm hoping to get input from
Marlon too.  Are we missing anyone else?
I list mpt because you said that "for UI, it should always include the UE rep or
other person responsible for the UI of the component" and as far as I can tell
the only person who can be said to be responsibly caring for the browser's UI
design is mpt.

Since mozilla.org still haven't made any official statements about UI design
responsabilities, past performance is all we can go on.


Ok. Having gotten a candidate spec and a list of stakeholders (the module owner,
the QA contact, a representative from OEOne/Netscape/ActiveState/etc and the
relevant person for UI), how do these people get together to agree on the
candidate spec? Majority vote? Where are these discussions archived? npm.ui?
I know there is no formal process (yet -- we seem to be forever waiting) but I'm
curious how you think this bug should acquire an approved UI spec.
'the only person", eh?  I guess that makes the rest of us irresponsible or
uncaring.  :-(  I don't see any point in trying to hash out an ad-hoc ownership
and process model for this bug.  I asked about a spec to see what thought went
into this, I'm not sure we can afford to go back and write one now just to
settle this issue.  I think discussing this, and UI issues in general, is better
done on n.p.m.ui than in bugs.  In the absence of real ownership and process, I
think that the best way to settle this would be by unanimous agreement.  ;-)
Sorry, by "the only person" I was only referring to people actually doing
thorough UI design, not to all of us ordinary punters as well. :-)

> I asked about a spec to see what thought went into this, 

In that case you should have just asked "what thought went into this". :-)
I think the many comments in this bug have now answered this question -- namely,
a lot of careful thought went into the decision.


> I think that the best way to settle this would be by unanimous agreement. ;-)

Ok, so: who does not agree that the current default is the better default?
I don't have enough data to agree.  The currently released default may not be
ideal, but it is a known quantity.  I'm concerned the changed default will cause
lots of serious complaints and bug reports like this one.  
Hixie: Well, probably at least the 3 voters for this bug think that the current
default should be changed.

The question is: Do we want to be compatible to NS4 and earlier Mozilla versions
(people who are used to the default being "HTML only") or to MSIE (people who
will expect some things to be different, as Mozilla/NS6 is a completely
different product)?

People who do not know how the WWW works may also be surprised if the saved page
does not contain images & stylesheets; but for those, we could explain it in the
Help.
Christian: the answers to those questions are already discussed in detail in
this bug. See e.g. comment 4, comment 7, comment 13, comment 17, and especially
comment 19.

trudelle: It appears we have reached a stalemate then, since we have a group of
people convinced that the default is now the best (with lots of arguments
supporting that theory), and we have another (smaller) group of people convinced
that the old default is better (less surprise for our few existing users).

Are there any real plans to study this in usability tests soon?
Ben discussed this feature with me on IRC before it was checked in. I said that 
yes, I thought saving the complete page should be the default; I didn't 
elaborate on the reasons, but they're very well summed up by Alex Bishop in 
comment 19.

However, Ben also told me about bug 107251, and I said that until that bug is 
fixed, the default (i.e. only option) on Mac OS should be to save the plain 
HTML file, as before. Reason being that if the only save option is HTML only 
and you want to save the whole page, you can use the same `File' > `Edit Page' 
hack as you could in 4.x; but if the only save option is the whole page and you 
want to save the HTML only, you're screwed.

Further, and perhaps more controversially, I think that the default should be 
to save as HTML only, on all platforms and *especially* on Mac OS, until saving 
as a complete Web page is fixed to save a complete file in the standard MHTML 
format (bug 40873) rather than doing the `foo_files' folder thing. Most 
platforms on which Mozilla runs (even including early versions of Windows 95, 
IIRC) do not hide and handle the foo_files folder like newer versions of 
Windows do, so saving as a single file would be much more portable and robust. 
And the reason for my emphasizing Mac OS is that on that platform, putting 
unexpected folders (or files) anywhere is a Trashworthy offence, and both MSIE 
and iCab create single files (MSIE creates a MHTML file, iCab creates a StuffIt 
archive) when you choose the whole page option in their save dialogs.
(I meant bug 107521, not 107251. Sorry.)
Hixie: it isn't just our few existing users, although I sure don't want to
antagonize them by changing default behavior they are familiar with to something
that could be perceived as data loss. Many of our potential users are using
older versions of Netscape (mozilla too, thanks to RedHat), so upgrading would
give them a similar experience. Would setting the default to Complete only for
new profiles be a possible solution?

I'm not sure how testable or test-worthy this is.  cc'ing Lori to get it on her
radar.
Once bug 116263 is fixed, we could make the actual internal default be "save as
HTML" and make the profile creation set the default to "Save Complete".

HOWEVER. I don't think we should, because part of the reason to change the
default is so that existing Netscape and Mozilla users are introduced to the new
feature. Once bug 116263 is fixed, then changing the selection will persist, and
so the default should be chosen such that our users are exposed to our new
features. In addition, making new profiles have "defaults" that defer from our
internal "defaults" like this is just asking for trouble.
QA Contact: sairuh → ian
We now persist the selected conversion type. I continue to believe that the
default exposes users to the feature that performs the most meaningful
operation, whilst providing others with a system that respects their preferences
(remembering HTML-only save preference for next time)
Status: REOPENED → RESOLVED
Closed: 23 years ago → 23 years ago
Resolution: --- → WONTFIX
OK, maybe not.
Status: RESOLVED → REOPENED
Resolution: WONTFIX → ---
According to UI common practice, changing the default of a feature should only
be done when the benefit of new behavior far outweighs the the pain of learning
the new system. I don't think you can argue that in this case. As a matter of
fact the argument has been made that experienced, expert users will figure out
what to do to get the behavior they want and that new and unsophisticated users
will simply be confused. I think we should keep the established default, provide
the option to change it and definitely remember the state of the setting across
sessions so folks get what they expect based on their choice (or acceptance of
the default.) It is possible to test this behavior in our upcoming usability if
it's deemed essential to know. Seems like a small issue in the larger scheme. I
can also include a task to assess the expectations of users as opposed to
gauging their reactions to the implementation and probing on their expectations. 
> OK, maybe not. 

Persists for me, Ben. Linux 2002011606. Even through restarts. FIXED AFAIC.
Jeremy M. Dolan: The persistance of the setting is another bug (bug 116263).
This bug is for the default of the save page dialog.
> According to UI common practice, changing the default of a feature should

Lori, your whole comment was rather vague, as you never state which default
you're for. They've both been the default at one time or another, so just saying
"don't change it" doesn't say from/to what.

> Jeremy M. Dolan: The persistance of the setting is another bug

Ben marked it FIXED by saying "we now persist the selected conversion type".
Tell him not me. Christian Biesinger, and everyone else FOR html-only as the
default, I once thought the same. But now that we persist, it only takes YOU
(who knows the differance) one change ever, to save your grandmother from
wondering where the map went (half of the content) when she saves directions off
mapquest.
jeremy, he also said:
>I continue to believe that the
>default exposes users to the feature that performs the most meaningful
>operation, whilst providing others with a system that respects their 
>preferences

Which is, imho, the more important part of the comment.
Also, I just pointed out that this bug is not for remembering the selection, as
you stated. If it is decided that WONTFIXing this is the best solution, then so
be it (I personally think that if you read "HTML Only", you get the impression
that something will be missing. If you then see the list, you also see
"Complete", which is, well, for a complete page. Also note that NS4 didn't have
this feature either. Apparently, Grandmothers did not mind that much.
Further, users aren't stupid. If only parts of the page are saved, they are,
imho, likely to wonder what they did wrong. Thus, on next try, they would
probably search in the dialog if they might have overlooked something, and
choose the "Complete Page" from the dropdown. This is, of course, just my opinion.).
Lori: The arguments given above are that the old default is more confusing than
the new default for new users ("Why did it not save the page correctly?").
Experienced users will not be confused by either setting and will therefore be
able to pick the setting they want.

Here is a summary of the arguments so far:

                   Default to Save Complete Page      Default to Save HTML Page

New Users          Most users happy, some change      Many users confused. Few
                   the default. Users transitioning   users ever discover
                   from IE have no surprise.          new feature.

Experienced Users  Users introduced to new feature.   Users not introduced to
                   Some users change setting.         new feature. Some users
                                                      change setting.


As I see it, the current default (Save as Complete Page) is the one that will
lead to the most happy users.
How will new and unsophisticated users be 'confused' by a save system that
presents them a saved copy of a webpage that more closely resembles what they
saw whilst online? 

How is saving a version without associated data meaningful to them? 

I can see the ability to save without fixing up the document as being useful to
people managing websites, but is that really as frequent a task as simply
archiving a document? 
What if you include an option to change the default into one of the dialogs
appearing during the installation?
I believe the default behavior should be to save the complete Web page.  A 
novice user is more likely to be confused by the behavior of browser's like 
4.x, which offer to save a page that - when later viewed - is broken and 
incomplete because the objects thare are inherently part of the page were not 
also saved.

The implementation also creates an automatic association between the saved 
objects (the image files) and the saved HTML file.  A user who deletes the 
HTML file will also delete the image files.

I see no reason for the default to be the old behavior.  The new behavior is 
technically superior and provides a better user experience.

Errr, "browsers like 4.x".  Ignore my extraneous punctuation. :)

>The implementation also creates an automatic association between the saved 
>objects (the image files) and the saved HTML file.  A user who deletes the 
>HTML file will also delete the image files.

Really? Not when I last tried it on Windows 98 SE. The .html and the directory
had no such association, at least no visible one.

> The implementation also creates an automatic association between the saved 
> objects (the image files) and the saved HTML file.  A user who deletes the 
> HTML file will also delete the image files.

That is only true for some versions of Windows. On other operating systems,
including older versions of Windows, deleting the HTML file will *not* delete
the _files directory automatically.
>> The implementation also creates an automatic association between the saved 
>> objects (the image files) and the saved HTML file.  A user who deletes the 
>> HTML file will also delete the image files.
>
> That is only true for some versions of Windows. On other operating systems,
> including older versions of Windows, deleting the HTML file will *not* delete
> the _files directory automatically.

The feature (called 'linked files', I believe) is in 2000, Me and XP. I'm
worried it might confuse people though. What if a user decides that they don't
want the images any more so they delete them? S/he will be a bit miffed if the
HTML file goes as well. I read a letter in a computer magazine from someone who
was confused by this behaviour when saving complete pages with IE and then
deleting the images folder.
Folks, this is not about novice users, who are few, but would almost certainly
prefer the complete behavior, if they ever use this feature.  Nor is it about IE
users, of which we can expect but few, and in any case IE defaults don't really
apply here, since we have an HTML editor component that figures into the steps
to reproduce (rememeber, this is a defect report).  It is also not about how the
complete option is designed, nor whether the files are linked or not.  It *is*
about whether we should change an old default to new behavior.  While it would
admittedly be welcomed as an improvement by people who are saving the page to
view it, it is seen as data loss by some current users who expect current
behavior. In addition to the principal of making the most users happy, there is
also the principal of not knowingly causing data loss for existing users. A Save
HTML default at least doesn't harm anyone, as it is already behavior expected by
current users of the feature.  

Perhaps there are other options, such as offering a new menu item for one of the
behaviors (Save File As...?), or making the alternatives more visible, such as
by changing them in the dialog to be radio buttons rather than a popup menu? 
I'm pretty sure that won't go over here, but if both options were visible, we
could then set the default for typical users (save complete), and count on the
HTML folks to notice the changes.
Existing users will fall into two categories.

Those who actually care about keeping the original file: They will be
experienced enough to change the setting or, at most, make the mistake once.

Those who actually care about the content of the page: They will be happy to
discover that we now save all the images.
It is not a mistake to expect the same behavior you've had for years, and the
resulting data loss is considered a critical severity defect.
The one time minor dataloss is negligible.
Data loss is negligible?  And why do you assume it is one-time? How is it
obvious to these users that the new version is not just defective? 
If it's not obvious, that's a bug.
I suggest a compromise. Mark this bug as wontfix. Then, open a new bug, the
resolution of which would insert a comment in any altered HTML page saved to
disc as a "complete" web page. 

The HTML comment should indicate that changes were made in the file in order to
save the web page in complete form, and that the changes made were only of the
relative location of images, javascript, and other related files. The comment
should also say that if the user wants the original, unaltered HTML file, the
user should save the HTML file as "HTML only."

Any user who cares about the data loss would thus be informed how to avoid the
data loss.

Andrew: nice idea, but it is still data loss, just data loss that leaves a note
hidden inside itself, sort of like someone who hits your car in a parking lot,
then leaves a note saying you shouldn't have parked there. ;-) I wouldn't be
surprised if the Save Complete adherents considered that unnecessary alteration
of the original page too.

Hixie: yeah, unfortunately, it is *this* bug. :-(

Surely we can come up with a way to expose this that satisfies both target
users?  I mentioned a couple of alternatives, but from the total lack of comment
it seems nobody liked them.  How about some type of text or tooltip drawing
attention to the new choice?  It seems like the main argument I'm hearing now is
"screw the HTML authors, to hell with their dataloss, they'll figure out a
workaround (that doesn't involve IE), and adding pictures is worth it."  I don't
think that is compelling by itself.
Talking about IE, since their default is the same as our current default, I
wonder why Microsoft don't have any problems with their users suffering dataloss.

The feature not being obvious is _not_ this bug. This bug is about changing the
default to one that obscures this feature even more.

I think Andrew's suggestion is a reasonable one.

Please don't sing the dataloss song. This isn't dataloss of any serious kind.
The content is still there, the only things that are lost are the exact URIs
used for images. Big deal. An author who needed those URIs could either download
the file again, changing the save as settings, or just change the URIs back. If
you call Save As Complete dataloss, then I can just as easily call Save As HTML
to be dataloss: you lose the images, iframes, stylesheets and other important
content. In fact, that's more serious dataloss.

The amount of time lost through your so called "dataloss" is completely
overwhelmed by the amount of time that will be saved from people finding out
that we can now save the complete page, anyway.
When you first install a (Netscape) build, you get taken to a shiny What's New
page. Presumably one of the features that will be promoted on this page is the
fact that you can now save a complete Web page with images etc. Why can't this
page inform users that they can get the old behaviour by choosing 'Web Page,
HTML only' as the type to save as?

The number of people saving pages for Web development purposes will be tiny
compared to those who save pages for viewing offline. In addition, people who
save pages for Web development are likely to be far more tech savvy and able to
figure out how to get the old behaviour back. It seems crazy to choose a default
that serves the more advanced minority rather than the less advanced majority.

It's like there's this great new feature but we don't want anyone to know.
Status: REOPENED → ASSIGNED
Priority: -- → P3
Target Milestone: --- → mozilla0.9.9
*** Bug 122338 has been marked as a duplicate of this bug. ***
Just a thought, but when we introduce users to the forms prefill feature, 
we present  them with a dialog the first time they do something that 
triggers this feature and give them options as to what course of action to 
take next, and to possibly remember that course of action.

Could this not perhaps happen here?  The first time you "save as", it tells 
you that you could save as exact source (html) or as a whole page 
(html+images+etc.) and have a "remember this preference" checkbox.


I mostly agree with comments 19 and 42

The web has matured to a point where "HTML" is no longer the 
(consciously) manipulated datatype,  "content" is; despite user 
understanding what that technically means.  The save default should 
therefore be to save the a page intact with resources, and we should do 
so when we can provide an ideal solution such as RFC 2397, or .mhtml.    
We should also consider leveraging Acrobat PDF as a way to turn 
multi-resource served content into portable documents.  

Saving separate files and resouces to the desktop is getting us half way 
there, and is an acceptable default for us at the moment.   It also has the 
side benefit for those users who tend to save a page, simply to get an 
image(s).  With RFC 2397 or .mhtml, it makes it nearly impossible to 
retrieve images.

So while yes, it does make a minor mess of your desktop, saving 
separate files has the benefit of meeting the intent of the majority of our 
users.

Adding dependency to show what the ideal solution relies upon
Depends on: 121793
Attached image save as dialog — 
here's an idea using icons to illustrate saving entire page vs. HTML.
Ben, could you give a quick blurb/swag for Marlon's suggested solution?  I
assume it would require separate implementations on each platform?  cc tpringle
for input on how much more work this is worth.
Given that this work requires extending our built in file dialog widget (a
below-the-embedding-line component) with app level functionality using a
technique that exists (*) but which I do not know, I would say this feature is
unimplementable in MachV. Time to complete: 8 days. 


(* technique involves creating custom native file widget that embeds the Windows
file widget in a native form presenting additional non-XUL functionality. Note
that this is the Windows portion only. This technique may exist on other
platforms such as MacOS X, but I am even less likely to know how to implement it
there ;)
Hmmm, assuming this is not worth three more large tasks: Marlon, would you still
change the shipping default from HTML to complete if we could not implement the
'ideal' way to expose this? Are there any less-than-ideal, but implmentable
alternatives you'd consider an option? Also, you haven't directly addressed the
fact that some users who want the current shipping HTML default (no doubt a
minority) see the 'complete' behavior as a new data loss defect (which is why
this bug was filed).  

peter, i don't consider this dataloss.  the feature is functioning exactly as it
says, "Web Page, save complete".  by making "complete" the default we're
consciously making a decision to offer the largest chunk of users what they most
often need.  

those who need html, are more inclined to change the setting.  setting should
persist
 
This is not an entirely new feature, but rather new behavior for an old feature
(Save Page As).  Users who are accustomed to having the HTML file saved intact,
but now have it mangled without realizing there is a choice *do* consider this
to be data loss.  That's why we want to make the change in default behavior
obvious. 
dataloss aside, saving a file in this format is not a "permanent fatal error" in
terms of severity ->  open the file back up and save out as html.   again, this
transition impacts very few people. 

we could show an alert which say's "hi, the file format you selected will mangle
your data.  would you like to continue? do not ask me again [ ]" 

but i don't want to continually be throwing these alerts everytime to make
compromise because we can't make any decisions about our users.  Eventually the
UE will be so crowded with superior strength safety nets that will impede and
slow down users tasks, the bulk result of which forms a poor impression of the
product
>dataloss aside, saving a file in this format is not a "permanent fatal error"
>in terms of severity -> open the file back up and save out as html.   again,
>this transition impacts very few people.

<enter critic mode>

    Please don't apply the Windows-paradigm whereby if "the majority of users
are happy we can forget about everyone else" because this leads to very
inflexible software where you can do common tasks quite well but as soon as you
try to deviate from "normal behavior" it becomes very difficult to do what you
want to do. Plan for both normal and "abnormal" functionality side by side so
this doesn't happen.

<exit critic mode>

>but i don't want to continually be throwing these alerts everytime to make
>compromise because we can't make any decisions about our users.  Eventually the
>UE will be so crowded with superior strength safety nets that will impede and
>slow down users tasks, the bulk result of which forms a poor impression of the
>product

    Add a "Warning preferences" in the PREFERENCE dialog listing all supported
warning messages and at the top of each section (section being "Browser
warnings", "Composer warnings", etc) have a "select all", "deselect all" option
so, for example, you can disable all warnings for the Browser, for Composer,
etc.. all of this should be configurable in PREFERENCES. That way you have all
those warnings in place for the novice user (which is good) and still not ****
off advanced users. :)
Marlon, it is critical severity, there is data loss and potential interruption
in functioning of their web site.  It is possible to recover from this, but I
just want to ensure you understand that we do have  <some unkown number of>
current users depending on the current default behavior, and the new behavior is
a 'nasty surprise' that causes them extra work.  I completely understand the
desirability of the new behavior for most users most of the time, but I think
the severity of the consequences for existing users is worth making the change
in default obvious, though I also hate throwing up alerts.
Save As Complete simply makes more sense as the default.   It's what a 
majority of users are going to expect to happen.  By making this the new 
default, we're improving the user experience, not deproving it.  A feature 
that was always fundamentally confusing now works more as expected.

I agree with marlon and ben on this one.  Oh, and no alerts please. :)


The default should be the behaviour that the majority of users would want.
That's saving the complete page. I don't like alerts any more than the next guy
but I think that if it's the only way that 'Web Page, complete' can remain the
default then there should be an alert. The alert should be shown just once, the
first time the user tries to save a page with a new profile and should contain
some text to explain the change. Something like this:

"By default, Mozilla now saves the complete Web page, including images. This is
recommended for most users.

"Saving the complete page may require modifications to the HTML source. If you
need to preserve the original source (for example, for Web development) then
please ensure that 'Web Page, HTML only' is selected in the 'Save as type'
drop-down list."

Obviously, the wording would have to be written by someone with a better command
of the English language than I and would probably need to be platform specific.
Even if it's decided that no alert is needed, something like this should be in
the release notes.
Dave & Marlon: I don't think we need to rehash all the arguments, I have
certainly understood them all along, and I'm sure others do too.  I thought we
were past the question of which default to use, and are now trying to make the
change apparent enough to avoid the 'nasty surprise'. Are you guys saying we
should just 'wontfix' this, and let the HTML authors find out the hard way that
the default behavior now munges their pages?  That's what I'm not comfortable
with, and why I've been trying to get a solution that doesn't just give HTML
authors the shaft.
cc kmurray for input on the number of people who might be adversely affected by
the change in default, and how we might best help them avoid the problem.
after talking to peter and thinking this through further, i believe we should
either use a descriptive save dialog (costly), or provide an alert when trying
to save.  This is because we are localizing server data in a way which is not
reversible, nor is it any longer portable in the sense the HTML will abandon its
resouces when viewed anywhere else but users local harddrive.  my original
intention was to have some future "portable" format be set as default, and that
format should be reversible (i.e. could open back up and save out as the
original HTML).  However since we're not getting that in the next release, and
what we're actually debating over is whether or not to make localized html the
default, and since it's too costly to do the descriptive save dialog, we should
provide an alert. 

i propose we set the default to "complete web page", but provide an alert which
say something like:

"The file format you are about to save is fine for archival on your computer,
but it may not retain its resources if moved to another computer (or placed back
on a server). If you need the original file, please select "HTML" from the Save
as dialog."
Would this alert appear before or after the Save dialogue?
I'd propose changing 'complete' to 'packaged' for some reason 'complete' to me 
implies unchanged (unadulterated), whereas 'packaged' does not.

bz suggested 'with images' arguing that end users don't care about the other 
bits.  There's actually a discoverability point for using this.

If you see 'Save page with images' and 'Save html file' you'll probably figure 
out that the html file won't include them.... Unfortunately users will only see 
the default unless they click.
Cc'ing jatin for wording help.
alex - this would appear after you hit the "save" button.  (i forgot to mention
this would include "don't ask again" opt out)

i assume we copied the save as phrasing from IE,  which i don't feel is very
concise.  perhaps something like - "Localized HTML (includes images)" and
"Original HTML" 
I think IE's terminology is more understandable than the phrase "Localized HTML"

(HTML? Localized? huh?)
My suggested wording for an alert:

You are saving this page using the "Web Page, complete" option. Saving a page
using this option allows you to view it as originally shown with pictures, but
may not keep the structure of the original page. To save an HTML page in its
original format without pictures, please select "Web Page, HTML only" from the
"Save As" dialog box.
Not too sure about the use of the term "structure": it makes it sound as if the
layout of the page may be lost.

Personally I'm partial to the wording in comment 84 (or a derivative there of)
but then I would be. ;-)
I agree with Jatin's wording (it's clear - I understood what it meant) on the
proposed dialog, but we should also add a "Don't show this next time" checkbox -
which then begs the question on whether we add the corresponding toggle to
global preferences. However, I do not know where an appropriate place for such a
pref would be. (!)

FWIW - After reading this very lengthy bug, I believe that introducing the new
default (Web Page, Complete) is indeed a good thing to offer up as the *new*
default due to the benefit to the many in the long run (as pointed out by many
in this bug). 
nsbeta1+ per Nav triage team
Keywords: mozilla0.9.7, nsbeta1 → nsbeta1+
Whiteboard: WONTFIX? (usability tests suggested)
Jatin mentions "structure" in his original page. This would mean to the layman
the layout changes...instead, we should mention something to the effect that
"complete" attempts to save in a manner that will allow the page to display as
you see it currently on the web, but will require changes to the markup source.

The layman will recognize this as something he wants, and the advanced user will
understand what is going on clearly and can choose "HTML only" if they'd prefer.
Keywords: nsbeta1+ → mozilla0.9.7, nsbeta1
Whiteboard: WONTFIX? (usability tests suggested)
Is it really neccessary to show the alert every time someone saves a complete
Web page (even if there is the option to turn it off)? It's like saying, "Hey,
you've just chosen the default action. Hope you're sure about that." every time.

Would this dialogue be a straight alert or would it be a confirmation dialogue
(so the user could change their mind and save in another format)?
Keywords: mozilla0.9.7, nsbeta1 → nsbeta1+
Whiteboard: WONTFIX? (usability tests suggested)
This bug is getting morphed imto something about improving the UI of the save as
dialog. The UE-approved part of that morphing is bug 124996. Morphing bugs is
bad for many reasons.

Since it is agreed (by UE) that the default should remain as is, marking this
bug as WONTFIX.
Status: ASSIGNED → RESOLVED
Closed: 23 years ago → 23 years ago
Resolution: --- → WONTFIX
If "structure" seems ambiguous, I suggest "internal HTML."
what if the term was "link structure"?  

or how about, "will not preserve links"
This bug was just about the default, and is resolved. It sounds like you guys
may want to open a new bug report about the alert.
vrfy.
Status: RESOLVED → VERIFIED
*** Bug 138305 has been marked as a duplicate of this bug. ***
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: