247090 - Help Viewer should load documentation images from the web

Status: VERIFIED WONTFIX

(Documentation Graveyard :: Help Viewer, enhancement)

Description

[R.J. Keller]

Currently, 102K of the Mozilla Seamonkey build size is made up of the help
images. If these images were loaded off the web, we can loose this bloat.
Firefox Help currently loaded the images of the web and it works very well.

Comment 1

[Stefan [:stefanh]]

Hmm, suppose I'm offline or just use Mozilla in a local network?

Comment 2

[Giacomo Magnini]

I don't agree on what FF does, it's the wrong way to go IMHO.
I have checked the image files sizes: there are a few low hanging fruits to
collect if we convert just 3 images to png (saving around 12-13K--that's almost
10%!) and correct the links in just 3 files. Should I open a new bug for such
changes or could we morph this?

Comment 3

[Stefan [:stefanh]]

(In reply to comment #2)
> I don't agree on what FF does, it's the wrong way to go IMHO.
> I have checked the image files sizes: there are a few low hanging fruits to
> collect if we convert just 3 images to png (saving around 12-13K--that's almost
> 10%!) and correct the links in just 3 files. Should I open a new bug for such
> changes or could we morph this?

There's an old bug on converting GIF images to PNG: bug 107225.

Comment 4

[Giacomo Magnini]

Good. I knew something like that existed (but too lazy to search it on my own!
:) ), since everybody was concerned about gif/LZ patents. Now those are resolved
and moving everything to png doesn't make much sense (probably will end up
having a lot of slightly larger files). Again, the patch there has reviews but
hasn't been checked in, since it will break almost all of the online help
(break=images won't show up), and will need lots of more fixes. Here I stressed
that to save footprint, converting just three images, fixing both jar.mn and the
3 help files will free up 13Kb or 10% of so called bloat.
Benefits: smaller footprint, less time spent fixing everything everywhere, no
lose of functionality. Just my .02 cents.

Comment 5

[R.J. Keller]

(In reply to comment #1)
> Hmm, suppose I'm offline or just use Mozilla in a local network?

Then you don't get the images :). It's not that big of a sacrifice.

(In reply to comment #2)
> I don't agree on what FF does, it's the wrong way to go IMHO.
> I have checked the image files sizes: there are a few low hanging fruits to
> collect if we convert just 3 images to png (saving around 12-13K--that's almost
> 10%!) and correct the links in just 3 files. Should I open a new bug for such
> changes or could we morph this?

If we're to ship Firefox with the help images, its size would increase by over
600K. That is not acceptable. There is no way around it.

(In reply to comment #4)
> Good. I knew something like that existed (but too lazy to search it on my own!
> :) ), since everybody was concerned about gif/LZ patents. Now those are resolved
> and moving everything to png doesn't make much sense (probably will end up
> having a lot of slightly larger files). Again, the patch there has reviews but
> hasn't been checked in, since it will break almost all of the online help
> (break=images won't show up), and will need lots of more fixes. Here I stressed
> that to save footprint, converting just three images, fixing both jar.mn and the
> 3 help files will free up 13Kb or 10% of so called bloat.
> Benefits: smaller footprint, less time spent fixing everything everywhere, no
> lose of functionality. Just my .02 cents.

I know your point, but 102K is a lot more than 13K, and it's only a minor
inconvience for the user. If there is no network connection, then they won't see
images. It's not that big of a deal. If they're on a the internet, they see
images. It's not like we're loading the Help HTML files off the net.

IMO, the advantages greatly outweigh the disadvantages to having the images on
the web.

Comment 6

[Giacomo Magnini]

1) We're not talking about FF, but about the Suite: no need to shave off 100KB
of images on a 12MB archive.
2) Try to understand what the guide says about the sidebar handle with NO image...
Ok, I see the decision is already taken: Ben-mania is spreading like fire. Good
luck.

Comment 7

[R.J. Keller]

(In reply to comment #6)
> 1) We're not talking about FF, but about the Suite: no need to shave off 100KB
> of images on a 12MB archive.


Yes, you're talking about Firefox. 100KB is quite a bit to shave off of a 12MB
archive. Yeah, it's not as much as 600K, but it's a nice chunk.


> 2) Try to understand what the guide says about the sidebar handle with NO image...


Over time we'll make the help builds not rely as much on the images.

As I said, there are disadvantages, but the advantages outweigh them.


> Ok, I see the decision is already taken: Ben-mania is spreading like fire. Good
> luck.


Ben-mania? Maybe you need to realize the fact that ben is usually right :). If I
thought he was wrong, I wouldn't have moved Seamonkeys images on the web.

Comment 8

[Giacomo Magnini]

BTW, since you are going to shave off the images, at least close bug 107225
since it's not going anywhere...

Comment 9

[Robert Kaiser]

I think stressing a user's internet connection everytime he's using help is
unacceptable. If we do that, we should load off all help onto the web,
seperating images and help content is the worst option I can imagine. If we're
of the opinion that a user doesn't need good help conent, we can load it off to
the web, but don't expect usability in the user's eye to increase in any way.

<rant>This is another point why you're pissing off more and more serious people
from those apps. Don't wonder if some time you're left with the crazy and dumb
user base because all people who want serious development will be better off
taking KHTML into account very soon. Thanks ben, hyatt et al. for making this
more and more the better alternative.</rant>

Comment 10

[Daniel Wang]

I'm uncomfortable with loading remote content in Help Viewer. I don't know if
this will cause any security issue, but on the safe side let's not do it.

Comment 11

[R.J. Keller]

(In reply to comment #9)
> I think stressing a user's internet connection everytime he's using help is
> unacceptable. If we do that, we should load off all help onto the web,
> seperating images and help content is the worst option I can imagine. If we're
> of the opinion that a user doesn't need good help conent, we can load it off to
> the web, but don't expect usability in the user's eye to increase in any way.
> 


You act like there is no cache :). Note that it's only 100K worth of images
spread throughout all of the documents. On a dial-up connection, it isn't a huge
strain.

I did this for Firefox Help with over 600K worth of images and actually found
that it didn't effect the user experience at all, and that is over 6 times
bigger images to load (this is running on 28.8K, btw).


> <rant>This is another point why you're pissing off more and more serious people
> from those apps. Don't wonder if some time you're left with the crazy and dumb
> user base because all people who want serious development will be better off
> taking KHTML into account very soon. Thanks ben, hyatt et al. for making this
> more and more the better alternative.</rant>


I've already implemented this system and found that it works excellent. I don't
consider you a serious developer because your point is illogical. You feel that
wasting time with an additional download would be better than loading images off
the web (which doesn't effect the user experience)?

If you want to be illogical, go over to KHTML then. We don't want crap in Mozilla.

If you want to continue this discussion, email me. I'd rather not spam the
others in a long discussion over this.


(In reply to comment #10)
> I'm uncomfortable with loading remote content in Help Viewer. I don't know if
> this will cause any security issue, but on the safe side let's not do it.


No, there are no security issues. I know this for sure. All images are loaded
off of mozilla.org. This is already done with Firefox Help.

Comment 12

[Robert Kaiser]

> You act like there is no cache :). Note that it's only 100K worth of images
> spread throughout all of the documents. On a dial-up connection, it isn't a huge
> strain.

So what is this all about then if it's not much data? You're still forgetting
offline and/or intranet users, btw.


> I don't
> consider you a serious developer because your point is illogical.

And I don't consider you a serious developer because your point is illogical in
my opinion. We can do this game all day if you want.

> If you want to be illogical, go over to KHTML then. We don't want crap in Mozilla.

You don't consider me to give a serious answer, do you? Weel, it gets OT anyways.
 
> All images are loaded off of mozilla.org.

I consider this to be another problem. I drove e.g. the mail start page the
other way (off the web, into the code) because of mainly localization concerns.
L10n for Mozilla is enough to do already. Things like that make it much harder.
We see bricks and wall thrown/built into our way almost weekly around this time,
doing what this RFE calls for would be another one.
Pissing off developers and much more L10n guys in FF is one thing we're getting
used to. Doing the same with Seamonkey is something at least I will always
object to.

Comment 13

[R.J. Keller]

Attachment: Patch

kairo: I can tell you that everyone I've talked to on IRC disagrees with you.
If you feel that way, then fine. I could care less about arguing with you
anymore.

Comment 14

[R.J. Keller]

Comment on attachment 151054 [details] [diff] [review]
Patch

Neil: The images will be on the web once I get time. For now, assume the links
to the help viewer site work.

Comment 15

[Constantine A. Murenin]

I highly agree with kairo on this question. Where do you suppose localisers
shall place their localised images? On their own web-site? Who is going to pay
for traffic? Users are going to be happy with images being 404 when localisers
decide it's too much traffic from useless one year old help images? 

How are localisers supposed to get your original images in the first place?
Develop scripts for wget? 

What about privacy issues --- you have no right to know when I'm on the internet
and need some help, without my prior permission. 

And of cause, you don't even consider those people who still have nothing but
dial-up connections and pay for both traffic and time using it. 

Comment 16

[R.J. Keller]

If you have questions, complaints, or opinions on this bug, send them to
[e-mail]. Please don't spam the bug.

Comment 17

[[e-mail]]

In the mean time we can save 18K by removing the following unused images:
flag_column.gif
flag.gif
key.gif
mailicon.gif
newmail.gif
newmailicon.gif
read_column.gif
read.gif
sick.gif
smile.gif
taskbar-ab.gif
unread.gif

Comment 18

[Christian :Biesinger (don't email me, ping me on IRC)]

(In reply to comment #13)
> kairo: I can tell you that everyone I've talked to on IRC disagrees with you.
> If you feel that way, then fine. I could care less about arguing with you
> anymore.

fwiw. I was among the ones who discussed this bug with you on irc, and I
basically agree with kairo. refernece:
http://www.pseudorandom.org/irclog/mozilla/%23mozilla/%23mozilla.2004-06/%23mozilla.2004-06-17.log
at around 18:23

Comment 19

[Bugzilla FR]

(In reply to comment #18)
> (In reply to comment #13)
> > kairo: I can tell you that everyone I've talked to on IRC disagrees with you.
> > If you feel that way, then fine. I could care less about arguing with you
> > anymore.
> 

I was not on the irc, but I completly agree with Kairo.
This is a completly silly thing to make for mozilla AND ffx.

>
>If we're to ship Firefox with the help images, its size would increase by over
>600K. That is not acceptable. There is no way around it.
>

That's totally stupid.... The 600K will be downloaded at a time or another...
And I prefer download it only one time.

>IMO, the advantages greatly outweigh the disadvantages to having the images on
>the web.

IMO the disadvantages of the loss of my privacy without knowing it is much and
much larger than any advantage.... That's why I use mozilla products for a long
time.

>If you want to be illogical, go over to KHTML then. We don't want crap in >Mozilla.

This is crap....

[Localisation]
I understand now that you only care for english people... 
There is no effort in ffx and thb to help the localisation process, this is even
more inconstructive and it will touch the suite too... 
That's a fact I don't understand. 

Philippe

Comment 20

[Hugues Fournier (french l10n team)]

(In reply to comment #16)
> If you have questions, complaints, or opinions on this bug, send them to
> [e-mail]. Please don't spam the bug.

So... Expressing a different opinion is spam.. Err...

I think the the Foundation really has to learn to listen the people it is
working with. In fact when there was no official consideration (no l10n IRC
meetings every 3 months), mozilla.org/the Foundation was really more open to the
opinions of their l10n contributors.

Since January, there are meetings with us... and however, there is less and less
concern about us, and communication with us. Meetings seem only there to prevent
matters getting worse or to repair the damage, already done.

Loading images from the web will really discourage tje l10n work, and maybe,
just when the Foundation has some world ambitions, maybe it will start to lose
what is one of the most important things to get the product adopted, the l10n
teams (that often are making a huge evangelization work too)

However, to be constructive, 2 suggestions if this bug is accepted :
1) each l10n team has to get a FTP account from mozilla.org to load them in a
absolute free way to their language directory on the server (that allows no
delay, no wait, and a feeling of mutual confidence)
2) there is to cache them, once they are loaded once, not only in the cache, but
in chrome in a jar file

Hugues

Comment 21

[Benoit]

(In reply to comment #16)
> If you have questions, complaints, or opinions on this bug, send them to
> [e-mail]. Please don't spam the bug.

How would anyone know we disagree then? And what would be bug comments for?

This is indeed very bad for l10n, as we just discovered in Firefox. We
localizers  obviously don't have the space nor the bandwidth necessary to keep
all images from all versions. I share the same concerns as Robert, Constantine
and Christian. 

The solution, if initial download size is really the only concern here, would
IMHO be an optional help component downloadable with the stub installer, and/or
later as an extension. Not taking away useful parts of help when the user needs
them more (when in trouble).

Comment 22

[R.J. Keller]

(In reply to comment #20)
> (In reply to comment #16)
> > If you have questions, complaints, or opinions on this bug, send them to
> > [e-mail]. Please don't spam the bug.
> 
> So... Expressing a different opinion is spam.. Err...
> 

No, people are giving the same opinion over and over again. It's unproductive
and I really don't care to hear it again. I'd prefer to discuss views through
email but apparently people either can't read or can't send email.

> I think the the Foundation really has to learn to listen the people it is
> working with. In fact when there was no official consideration (no l10n IRC
> meetings every 3 months), mozilla.org/the Foundation was really more open to the
> opinions of their l10n contributors.

Ranting about it won't help. This isn't speaking to your specifically but to the
other people who have commented on this bug.

> 
> Since January, there are meetings with us... and however, there is less and less
> concern about us, and communication with us. Meetings seem only there to prevent
> matters getting worse or to repair the damage, already done.
> 
> Loading images from the web will really discourage tje l10n work, and maybe,
> just when the Foundation has some world ambitions, maybe it will start to lose
> what is one of the most important things to get the product adopted, the l10n
> teams (that often are making a huge evangelization work too)


Just so you know, this is already done in Firefox help. Nobody ever gave me a
problem with this over on that end. In fact, I was actually given the exact
opposite impression, that there would be an outrage over help's size with the
image shipped. I guess firefox and seamonkey live in different worlds.

> 
> However, to be constructive, 2 suggestions if this bug is accepted :
> 1) each l10n team has to get a FTP account from mozilla.org to load them in a
> absolute free way to their language directory on the server (that allows no
> delay, no wait, and a feeling of mutual confidence)

Couldn't we just post them to mozilla.org instead? I'm sure localizers have gila
accounts (and if they don't, I MIGHT be willing to be a voucher).

I'm not sure if mozilla.org would be willing to give FTP, but I can guarantee
site access.

> 2) there is to cache them, once they are loaded once, not only in the cache, but
> in chrome in a jar file
> 

I'm open-minded when you don't rant. If you rant, your comments will mean
nothing to mean (once again, not speaking to you but the other people posting to
this bug).

What do you think of deleting all of the help images and loading them from the
skin files? I'm not sure if it's possible to take a chunk of a toolbar button
image and use that to display the button. This might have advantages because the
images displayed would change depending on the skin.

Comment 23

[R.J. Keller]

(In reply to comment #21)
> (In reply to comment #16)
> > If you have questions, complaints, or opinions on this bug, send them to
> > [e-mail]. Please don't spam the bug.
> 
> How would anyone know we disagree then? And what would be bug comments for?
> 

fine, move it to the newsgroups if you want. It's just that the discussion is
not productive on this bug.

> This is indeed very bad for l10n, as we just discovered in Firefox. We
> localizers  obviously don't have the space nor the bandwidth necessary to keep
> all images from all versions. I share the same concerns as Robert, Constantine
> and Christian. 

Once again I ask, why can't you just put them on mozilla.org? I can get gila
acounts for some key localizers to post their images, or give them to me and
I'll post them. I can't see this being a problem for localizers.

> The solution, if initial download size is really the only concern here, would
> IMHO be an optional help component downloadable with the stub installer, and/or
> later as an extension. Not taking away useful parts of help when the user needs
> them more (when in trouble).

If help was an extension, nobody would use it. An optional component is an idea
but no end-user would do a custom install. end-user documentation is for
end-users and this documentation would probably never get to that crowd. Maybe a
better idea might be to make help optional but have it enabled by default.

Help is extremely bloated and it needs help. There are so many ways to reduce
the bloat and I'm trying a nice chunk of them.

Comment 24

[R.J. Keller]

(In reply to comment #21)
> IMO the disadvantages of the loss of my privacy without knowing it is much and
> much larger than any advantage.... That's why I use mozilla products for a long
> time.
> 

Loss of privacy? how?

> >If you want to be illogical, go over to KHTML then. We don't want crap in
>Mozilla.
> 
> This is crap....
> 
> [Localisation]
> I understand now that you only care for english people... 
> There is no effort in ffx and thb to help the localisation process, this is even
> more inconstructive and it will touch the suite too... 
> That's a fact I don't understand. 
> 
> Philippe

I could say that you care nothing about the end-user, but I'm not going to start
another flame war in this bug. If you're ranting, don't expect your comments to
be taken seriously.

Comment 25

[Robert Kaiser]

> No, people are giving the same opinion over and over again. It's unproductive
> and I really don't care to hear it again. I'd prefer to discuss views through
> email but apparently people either can't read or can't send email.

The downside of email is that it's closed discussion, while open source projects
do live of open discussion to make things as good as possible for many people
and not just one or two dictators. If you'd propose discussion on usenet, we'd
look forward to that.

> I guess firefox and seamonkey live in different worlds.

They actually do. Firefox is a dictatorship while Seamonkey is a democracy. I
don'Ät want to tell you one world is better than the other, but if you're acting
in one of them, you should do it in fitting style ;-)

> I'm open-minded when you don't rant. If you rant, your comments will mean
> nothing to mean (once again, not speaking to you but the other people posting to
> this bug).

I'm taking this personally ;-)
Anyways, I will not affend your believe of me being irrational, as you don't
know me personally. That's off-topic here though...

> What do you think of deleting all of the help images and loading them from the
> skin files? I'm not sure if it's possible to take a chunk of a toolbar button
> image and use that to display the button. This might have advantages because the
> images displayed would change depending on the skin.

For those images which are available in themes, that's a very good idea, IMO. I
already thought of that myself once but didn't take the timne to investigate. We
porbably can't do that for everything, but it may help a bit. Converting left
over images to formats taking up less space might be an addtional step. BTW, we
also should consider that step for themes, that will reduce "bloat" in themes as
well...

> Help is extremely bloated and it needs help. There are so many ways to reduce
> the bloat and I'm trying a nice chunk of them.

I second that being a godd idea. Not all possible ways are ways that are
acceptable for the Seamonkey community though, and you have to deal with that as
well. If you're attempting ways we all accept and where we can help, let us know
though. There might be some things we're proud to help :)

BTW, I'm sure help can use help in many ways, and it's good that some things are
really being worked on.

Comment 26

[Oscar Manuel Gómez Senovilla]

I just want to make sure I've understood correctly.

The summary says "Help viewer should load documentation images from the web". I
understand that as a request for enhancement, and then, as many feature
requests, can be marked as WONTFIX. If not, I ask: Why should? I think that, as
a very first point and without going deep, since the l10n contributors are who
have to work on this issue, it's their opinion what should be respected,
regardless or any other (possibly more or less selfish or serlf comfortable)
consideration.

The main argument is size. This can be taken in two ways: if you're worried the
bandwith in the user's side, it's ok, but I think that not download ¿600K? once,
can lead to download those ¿600K? over and over lots of times later, reducing
the later bandwith and user performance.

Then, the next recurred argument is cache. First, the cache is finite, and needs
to be filled, but it rotates, disappears and has to be downloaded again from
time to time. So, wouldn't be the best a fixed (and compresed!!) file instead of
all these files?

Another argument is that aren't any security (or privacy) issues. Well, when a
connection through internet between two computers is made, there are lots of
machines (routers, proxies, etc) that can sniff who connects to what, since the
ISP to the final point. If one only wants to look for a little help about an
option in his local machine and software, crossing the internet world,
broadcasting who knows how many servers, and taking that that could be
accomplished in a simple diskette, I'm sure the user will think it's a waste of
moz.org resources, apart from his time and his bandwith, without mentioning that
he finally could not get what he wanted. He might even think that at least he
could be asked or given the chance to choose the preferred method.

If there's an unmoveable strong decision on that contents will be hosted on the
web, then at least provide an scalable structure where all l10n teams can be
involved without having to make them dedicate more time than usual to extra
tasks, even transparently if you want, but never forcing them, because that's
just bad.

Taking all this (this is too much for the moment), I think that the intermediate
solution could be to give the _freedom_ to choose the access method for the user
on how to view the contents: a) if download once and store the contents in his
local machine, or b) download the same over and over until option a) is chosen
(if ever).

Don't ever forget: many eyes and brains can see and think more than just one or two.

Comment 27

[R.J. Keller]

This change has been put on hold until further notice and debate. Do whatever
you want with this bug but I'm probably not going to read the comments until later.

I know I'm going off-topic, but for those of you localizing Firefox Help,
mozilla.org said they're more than willing to hold the Help mages on
mozilla.org. If you have localized images for Firefox Help that you want on
mozilla.org, email them to me and I'll post them on the site.

Comment 28

[Vincent Béron]

(In reply to comment #25)
> > What do you think of deleting all of the help images and loading them from the
> > skin files? I'm not sure if it's possible to take a chunk of a toolbar button
> > image and use that to display the button. This might have advantages because the
> > images displayed would change depending on the skin.
> 
> For those images which are available in themes, that's a very good idea, IMO. I
> already thought of that myself once but didn't take the timne to investigate. We
> porbably can't do that for everything, but it may help a bit. Converting left
> over images to formats taking up less space might be an addtional step. BTW, we
> also should consider that step for themes, that will reduce "bloat" in themes as
> well...

We (French localization team) already tried for a couple images, but the image
files are not always named the same in different themes. Since the images are
displayed using css files which are also included in the theme, there's little
we can do to force a theme author to use the same filename as another author.
Even between classic and modern there are some differences.

Another way to reduce the number of image files in help: load a .xul file in a
iframe, but without any functionality (for buttons, etc.). That way, the
localization of the images would be automatic, and updates regarding the UI
would also be automatic.

Regarding the original issue of reducing the bloat at install time, take note
that some complex applications (Matlab, Catia to name a few I know) come with
CDs (note the "s") full of documentation. The help system of those are bigger
than the actual application, and not only because of the images.

Vincent

Comment 29

[R.J. Keller]

I posted a message to the l10n newsgroup for discussion on this topic.

Comment 30

[R.J. Keller]

WONTFIX