I would like to propose that we make the stub installer the default download
available from mozilla.com: my gut says that the sooner we can get some part
of the installer up in front of the user, the happier (and more likely to
complete installation) they are going to be.
The stub installer has the added advantage that we can ship a single stub
installer for all languages and select the correct locale files to download
at runtime.
Of course the full installer would still be available, and especially useful
for system administrators and others who want to make an installer available
locally.
--BDS
Back in the days when I didn't have broadband at home, I dropped any
software that didn't come with a complete installer (or whatever the
package is). And I still tend to not trust stubs, I prefer things to be
boxed.
It's like selling software and not telling the price, and it's really
ugly if something goes wrong on install.
I don't see us having such a broad set of options that a download app
really pays off, like for cygwin or such.
I do like the idea of being able to put such an installer on a CD
though, that's cool. But if I download software, I wanna know when I'm done.
Axel
What is the impact of this on MSI installs for corporate types?
--
Henrik Gemal
Mozilla Evangelist
Mozilla Blog with news, devinfo, links, etc:
http://gemal.dk
I get the feeling users prefer full installers. Once a stub installer
tries to connect, up comes the firewall, detecting 'setup.exe' trying to
connect to the internet.
--
Chris Ilias
mozilla.test.multimedia moderator
Mozilla links <http://ilias.ca>
(Please do not email me tech support questions)
I think this is a bad idea. The immediate result is that we lose one
metric of product quality - download size. I know you can measure it in
other ways, but it stops being something that marketeers can crow about,
and I think as long as we're not the default browser, that's important.
I also worry that this adds too much complexity to the installer. The
Firefox installer was designed to be as simple as possible from a user
interface point of view. There are very few pages to it, by design. This
needs to be considered if you're thinking of making changes. What
additional UI burden does any such change provide?
Stub/multi-language installers sound like a reasonable idea for CD
distribution, but I don't think those are where we get the most traction
from.
-Ben
> I think this is a bad idea. The immediate result is that we lose one
> metric of product quality - download size. I know you can measure it in
> other ways, but it stops being something that marketeers can crow about,
> and I think as long as we're not the default browser, that's important.
Since we will continue to support and ship the full installer, I don't see
how we lose the metric itself or the crowing rights that might go with it.
> I also worry that this adds too much complexity to the installer. The
> Firefox installer was designed to be as simple as possible from a user
> interface point of view. There are very few pages to it, by design. This
> needs to be considered if you're thinking of making changes. What
> additional UI burden does any such change provide?
At this point, beltzner's spec[1] has two additional pages: one
locale-selection page and one "downloading" page. I distributed a mockup
knocked together in XUL a while back that had even fewer pages, having
combined the "download" and "install" items on one page and put the
locale-selection as a dropdown on the "welcome" page; I will find and
redistribute it for discussion.
--BDS
1.
http://wiki.mozilla.org/User:Beltzner/Specification_of_Stub_Installer_User_Interface
You miss the point. The crowing rights are for the installation most
users will experience. Crowing about something only sysadmins benefit
from is being disingenuous. It's also hard to prioritize regressions in
an area that affects so few users (who are also usually on fast
connections).
> At this point, beltzner's spec[1] has two additional pages: one
> locale-selection page and one "downloading" page. I distributed a mockup
> knocked together in XUL a while back that had even fewer pages, having
> combined the "download" and "install" items on one page and put the
> locale-selection as a dropdown on the "welcome" page; I will find and
> redistribute it for discussion.
This seems reasonable for a stub, but my comments above still apply.
-Ben
Actually, it seems worse this way.
Right now, the website takes a "best guess" at your system language and
offers an installer for that. What you propose here is to offer a
generic installer and make the user do that work. Small though that may
be, you are introducing an additional level of complexity the user did
not have to deal with previously.
-Ben
Actually, it seems worse this way.
Right now, the website takes a "best guess" at your system language and
offers an installer for that. What you propose here is to offer a
be, you are introducing an additional level of complexity the user did
not have to deal with previously.
~Robert
as the old saying goes, "you can't have everything... where would you
put it?"
-Darin
> _______________________________________________
> dev-apps-firefox mailing list
> dev-apps...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-apps-firefox
>
-Robert
Darin Fisher wrote:
> Please note that there are many bugs with the old stub installer
> having to do with proxy server configuration. Does it support PAC?
> Does it support NTLM or Kerberos authentication? Modern web browsers
> do, and trying to put support for those things in a stub installer is
> non-trivial. Maybe you don't care about those features since they are
> mostly limited to corporate networks, but I think it should be kept in
> mind.
>
> -Darin
>
>
> On 2/21/06, Benjamin Smedberg <benj...@smedbergs.us> wrote:
>
Le 21/02/2006 17:58, Benjamin Smedberg a ecrit :
Personnally I never liked stub installers since I think they always end
up being more complex than traditional installers. I have a few concerns
about it :
- Does it mean that users will all have to download a stub installer in
English before they can choose their locale in this installer which will
then download the localised files including the localized strings for
the install process? it would be a big regression in the perception of
the product IMO since the install process would be partly in a foreign
language, particulary if you don't use a western alphabet (asian
languages, hebrew, arabic...).
- what happens to the installer if I download it to install it later?
Like I download it on the morning and decide to install it during lunch
time ? Do I have to follow the installer steps and leave the final
'install software screen' open until I decide to run it ? I think that
if people download an installer, they want to install it whenever they
want and not loose their download if they decide to install it a couple
of hours later, they will also want to transfer it to their USB key to
install it at home or on friends machines
- the fact that the installer connects to the internet to get files will
mean that many firewalls will block it. Firewalls blocking firefox is a
very common problem encountered by users, but currently they face it
once the browser is installed. Now they are going to face it also during
the installation process as well.
- Is it for all OSes? I am not sure that stub installers are commonplace
in MacOS space
- If the stub installer becomes the default one, does it mean that the
full installer will be hidden on the ftp? It's something UI hated in the
Netscape era, I always had to search their ftp site to find my installer
so as to install it on my three machines, I am no notwork administrator
but I am like most people, I have more than one machine at home.
Personnally I am not convinced, I think that people will prefer a simple
installer file in Windows since it is the way 99% of installers work,
it's a process they are used to.
pascal
These features are also very very common on college networks, actually. And I
bet college students are a nontrivial part of our user base...
-Boris
One other issue: For users who auto-update across major releases
(from 1.5 to 2.0), we probably want to be able to offer any new
optional components to them upon first-run. I wonder if it wouldn't
make sense to move installation of optional components to first-run,
so that the code path could be shared by auto-update and first-time
installation. Thoughts?
-Darin
On 2/21/06, Robert Strong <rst...@mozilla.com> wrote:
> I have an NSIS plugin that uses the MS Inet API (even works on Win95 SR2
> w/ I believe IE 5 installed) so it will utilize the current IE proxy
> settings including the authentication method used by IE. This doesn't
> mean I'll have time to do this for 2.0... just that this specific issue
> is important and has been thought of to some extent.
>
> -Robert
>
> Darin Fisher wrote:
> > Please note that there are many bugs with the old stub installer
> > having to do with proxy server configuration. Does it support PAC?
> > Does it support NTLM or Kerberos authentication? Modern web browsers
> > do, and trying to put support for those things in a stub installer is
> > non-trivial. Maybe you don't care about those features since they are
> > mostly limited to corporate networks, but I think it should be kept in
> > mind.
> >
> > -Darin
> >
> >
> > On 2/21/06, Benjamin Smedberg <benj...@smedbergs.us> wrote:
> >
-Robert
(This problem goes away if safebrowsing is built as a component of the
browser instead of as an extension, but let's ignore that possibility
for now for the sake of argument.)
Of those choices, I'm not sure what I prefer. Perhaps option #1, but
that's sort of avoiding the issue by making it a non-optional
component. So, how should we handle new optional components in the
context of software update? Option #3 seems like the best choice.
-Darin
-Robert
That is option #1 actually. MAR files can contain ADD/PATCH or
ADD-IF/PATCH-IF commands. The difference is that the latter only
adds/patches a file if the file already exists. Right now, anything
under the extensions folder is updated using an ADD-IF or PATCH-IF
command. So, if we want to make an extension unconditional during
update, then we can just use ADD commands instead of ADD-IF commands.
My point was that we may want to have the ability to ask the user if
they are interested in any new, optional components. So, I'm not sure
how that would be done. In many applications, that is accomplished by
re-running the setup program. Maybe we could support that ability as
well.
-Darin
-Robert
Then, given stub installer functionality, I think we could present
under the advanced installation dialog, the ability for users to
select from a variety of optional components that could be downloaded
and added on top of the standard edition.
This has several key advantages:
1) The majority of users only need to download one thing.
2) We can keep that one thng small by making things like DOM inspector
something that is optionally downloaded.
The optional components could even include popular extensions that we
have vetted.
How does this sound?
-Darin
-Robert
Great to me. It also frees up some more space for features most people
will use, like spellchecking dictionaries in form fields.
-Ben
-Darin
On 2/22/06, Robert Strong <rst...@mozilla.com> wrote:
> That is pretty much in sync with what I'd like to accomplish... I was
> planning on adding this functionality along with the ability to specify
> optional components in a distribution without having to repackage.
>
> -Robert
>
> Darin Fisher wrote:
> > On the issue of stub vs. full installer, IMHO, the default download
> > should be the complete standard edition of Firefox.
> >
How about also allowing the config file to define what "standard" means,
so that folk could create distributions a la the "Firefox w/Google
Toolbar" bundle?
-Ben
How about also allowing the config file to define what "standard" means,
-Robert
That sounds like a good idea to me. Best of both worlds?
Gerv
I'm not sure that's true. I think that once a user has decided to give
Firefox a go, they will mind less having to wait for it to download (as
that's something they are used to with software) than they would if the
installer came up, they got all excited, and were then faced with
another period of waiting.
Stub installers provide most value when there is a wide range of
different combinations of components a user might choose to download. In
this case, they save bandwidth. However, that's not true for us - almost
everyone wants the same thing.
> The stub installer has the added advantage that we can ship a single
> stub installer for all languages and select the correct locale files to
> download at runtime.
This would be great for CD-based distribution but (as others have said)
I'm not sure it's right for downloads.
Gerv
Everyone wants the DOM Inspector? Or the anti-phishing tool? A barrier
to entry for any piece of consumer software is the install experience,
which does include download time.
That said, I agree that the priority of all of this should be:
- move to new installer system
- get a basic stub installer working for CD based distribution
- look at a hybrid installer which serves as stub for optional
components as an optimization
Rob has told me that he's somewhat concerned about the time required to
deliver all of these things, and nothing beyond the basic stub installer
should block Fx2's release.
cheers,
mike
--
I'd like to reiterate that stub installers are only suitable for
broadband and CDs.
They suck for mouth-to-mouth and USB stick distribution.
Thus I'd say that nothing but the full installer should block fx2.
Axel
I think this is the priority order that Rob has been treating this as,
at the status meetings.
-Ben
-Robert
Phuuu :-)
Axel
I think no-one (to a first approximation) wants the DOM Inspector, and
everyone wants the anti-phishing tool.
That is, the anti-phishing tool should be in the download, along with
the rest of core Firefox, and the DOM Inspector should be downloaded on
demand.
Gerv
--
Vattitter
------------------------------------------------------------------------
Vattitter's Profile: http://forums.yourdomain.com.au/member.php?userid=91
View this thread: http://forums.yourdomain.com.au/showthread.php?t=60
--
DedAnydaypype
------------------------------------------------------------------------
DedAnydaypype's Profile: http://forums.yourdomain.com.au/member.php?userid=93
--
calpasteste
------------------------------------------------------------------------
calpasteste's Profile: http://forums.yourdomain.com.au/member.php?userid=107