Re: v1.x Installer comments - Long

[David Jencks]

I'm afraid that there is a temptation we might be succumbing to to  
gold plate the installer since only eric is actually doing the  
work.    We can easily turn the installer into a permanent full time  
job for as many people as we can get to work on it.

Working on the installer is no fun IMNSHO based on my experience.  I  
want this part of the project to end really soon so eric can do  
something a bit more fun.

My point of view about the function of the installer is that it is  
the primary means we can show the component oriented nature of  
geronimo and let people build their own server.  It is considerably  
harder to set up geronimo using the installer than to unpack one of  
the prebuilt servers, and nothing we can do can change that.

I want the installer to show that you can build a lot of different  
servers out of the configurations we supply.  This means to me that  
it should  include exactly the parts you specify and that the  
configuration options for those parts you specify should be able to  
be set in the installer.  One of those configuration options is very  
definitely whether the configuration is started, so IMO it should be  
shown in the installer.

My preference would be to fix the icons, make the changes so only the  
jars for the configs you select are installed, and declare victory.

If we want more, I would prefer to insert warnings rather than  
disable functionality.  For instance, put a divider in between the  
ports etc and the check boxes for activating the configs that says  
"ADVANCED FUNCTIONALITY KEEP OUT" (obviously bad wording) and perhaps  
a warning page if you select 2 web containers "YOU PROBABLY DON"T  
WANT TO DO THAT".

That's more than enough of a rant.  To me the only critical missing  
piece in the installer is including only the needed jars.

thanks
david jencks



On Jan 27, 2006, at 8:22 AM, Dave Colasurdo wrote:

David Jencks wrote:
On Jan 27, 2006, at 5:54 AM, Erik Daughtrey wrote:
Given the comments I've gotten, I'm going to change the installer  
and go back
to the behavior where it does not allow the selection of both web  
container
packs to install. I'm going to ditch the additional buttons which  
allow
selected features to be inactive at runtime.

We could put this up for a vote, but since there have been very  
few comments
on this topic, I assume that most folks just want an installer  
that works
well.

I pretty much strongly prefer the way the installer works now, I  
think I asked for it to be this way :-)
I won't stand in anyones way though.
My view is that the installer should present all the options  
reasonably available.  They are MUCH easier to configure in the  
installer than in any other way, and I think that the additional  
confusion while using the installer is minimal.
I think most folks agree that the vast majority of users will never  
want
to run with two web containers installed.  The exceptions that I can
think of are:

1) Geronimo developers - who most likely won't ever use the installer

2) Novice users who aren't sure which web container to use and want to
try them both out. Rather than confusing them with instructions on how
to setup ports for simultaneous containers or instructions on how to
switch between web containers (creating two separate config stores or
enabling the config to use just certain portions of the same
config-store). Isn't it just simpler/easier to have them lay down two
separate *isolated* installations for their comparisons?

IMHO, the confusion of someone accidentally laying down two web
containers outweighs any potential benefit.

Concerning the enable/disable of selected components.  It seems quite
strange to select installation options on panel 1 and then have  
panel 4
and panel 5 ask if you want the options that you selected on panel 1
enabled.  I would guess that an average user might think "Didn't I
already tell the installer I want these options installed?"

What is the common use case for someone wanting to install an  
option and
then disable it immediately in the installer?

Thanks
-Dave-

thanks
david jencks
regards,

erik

 On Wednesday 25 January 2006 21:53, Matt Hogstrom wrote:
David Jencks wrote:
On Jan 25, 2006, at 2:48 PM, Joe Bohn wrote:
I agree with Dave on the issue of multiple containers.  We had  
many
discussions on this list concerning the number of containers  
in an
image.  The result was that we agreed to deliver 2 different
assemblies rather than having multiple containers in one  
assembly.
If that was the decision for the assemblies then I would think it
makes sense to do the same in the installer.


+1 One container per instance will satisfy 99% of the users I  
suspect.

I also agree with Dave that we should revisit the issue of   
presenting
the list of components twice: once to include them in  the  
image and
once to activate them in the runtime.  I doubt that  most  
users would
understand this distinction when initially  installing  
Geronimo.  Most
other packages consider the activation/ inactivation of  
components to
be post-install setup and choose the  defaults that make the most
sense.  In our case I would expect that  all components selected
during install would be active by default.

I think that is what we have now.  I don't see why we shouldn't  
let
people turn them off if they want to.

I think for now we should dump them all to disk and then allow  
them to
assemble the user.  I don't think were sophisticated enough yet  
to help
users understand the difference.  One can refer to them as options
available for later configuration (disk bloat) and options for  
runtime
configuration (memory bloat). I'd leave it simple for now.

david jencks

Joe

Dave Colasurdo wrote:
Erik Daughtrey wrote:
Dave, Thanks for the comments...

I made comments below.  Would you create installer  
component  JIRAs
for the items that make sense?

Yep.  BTW, has it been decided if the installer is a 1.0.1 or  
1.1
item?

 On Thursday 19 January 2006 17:02, Dave Colasurdo wrote:
Looks like the Installer has made quite a bit of  
progress.   Thanks
Erik!!

I'd like to suggest a few Usabality changes to the current
installer..
I'm sure you are already aware of many of these and have  
plans  to
update
them.  Just wanted to provide some input based on my first
impression.
BTW, I've attempted to provide input based on my thoughts  
on how
this would be perceived from the perspective of a first  
time user.

*Package Selection Panel*
1)The available selections are really a hierarchy
  -Server
  --J2EE Features
  ---Jetty Web Container
  ----Jetty Sample Applications

  ---Tomcat Web Container
  ----Tomcat Sample Applications


Does Izpack allow you to capture the hierarchy graphically?

Not that I've seen.  It looks like it's strictly a list box.

If not, anyway to insert padding to the front of entries to  
show  the
hierarchy to the user?  I think this would be a better  
solution
than the

Inserting spaces is something worth trying.

I experimented with inserting spaces in front of the pack  
names  and it
seemed to work fine. As expected, this also requires that all
references
to the pack name in geronimo-izpack.xml, izpack-process.xml and
izpack-user-input.xml need to be updated.  This results in a  
panel
that seems to show the hierarchy visually.  Though adding  
the  spaces
for each element in the xml files is a real hack and does  seem
troublesome. There should be an easier way to accomplish this
without  unnaturally padding or creating a custom panel.   
I'll  post
a question on this subject on the izpack mailing list.

"Dependencies" box and would more clearly convey the  
relationship
between selections.  Also, we should remove the  
dependencies box
and the

I don't think it's possible to remove the dependencies box  
and  keep
the overall look and feel.

Will also post this on the izpack mailing list.  Are they   
responsive
to suggestions?

other righthand box that contains the Logo.  The  
description box
should

I agree that the 2nd graphic is redundant at this point.    
However,
one thing we have not explored is the fact that the  graphic  
on the
right is actually different for each pack although  for now  
each is
a distinct instance of the same bitmap.  There is  the  
potential to
enhance each bitmap - possibly by making the  Geronimo image  
subdued
while overlaying something related to the  pack.  I have not  
tried
removing the graphic, but I don't think  it's possible to  
remove it
and keep this look and feel.

be located directly to the right of the main selection box OR
below it
on the left.

I doubt that this is easy to change.  We can look into  
making  some
of these changes in more detail at some point.  Anything is
actually possible depending on the capabilities of IzPack  
itself
and how much we're willing to diverge the Geronimo installer  
from
the IzPack codebase.  It may actually be possible to make  
some of
the changes without changing IzPack, but based on what I  
know  right
now, I don't think so.
We've already diverged from the IzPack codebase and we need to
factor these changes into IzPack as we move forward or we  
may run
into problems related to these changes later as IzPack itself
diverges.  I'm struggling a little with this at this point  
given
that IzPack is a generalized installer and some of the  
changes  made
are specific to Geronimo.  I tried to keep the changes   
separated,
but our requirements are reflected in code I wanted to  keep
generalized anyway. I don't want to boil the ocean, but I'd   
also
like to minimize problems occurring from the two distinct   
dev paths
as much as possible.  Graphical look and feel changes  might  
be less
painful to push back into IzPack, but it's still a  little  
worrisome.

I like the way the dependant boxes interact (turning off   
something
at the top of the hierarchy automatically trickles down to the
dependant choices)..

2) It seems that we are allowing the user to choose two web
containers?
    I thought we would limit the choice to just one?

The operator can install both containers, but they cannot   
activate
both at runtime.

For simplicity, I'd prefer to limit them to one web  
container.  I
would think this is what 95% of users would want. I think it is
confusing for a user to install two web containers and keep one
disabled.  Isn't  the installer targeted for a novice user  
and not a
sophisticated user  that wants to swap containers on the  
fly.  Awhile
back we had binary images with multiple web containers and it  
caused
lots of  confusion with users.

3) It seems that it is currently possible to pick-and-choose
selections
that result in a server that won't start.  We need to  
decide which
choices are valid and assure that the resulting  
installations  all
work.
   Flexibility is great, but we don't want to give users the
ability to
choose non-working installations.

The intent is to prevent the building of a non-working server.
There's only one instance I'm aware of that will result in   
problems
and it will be fixed soon.  If daytrader is selected,  with no
database, then obviously there will be problems.  David   
Jencks has
suggested that we just go ahead and install Derby when  the  
J2EE
Features are selected -- and I plan to do this.
If you're aware of other instances please enumerate them...

My initial selections produced a server that wouldn't start.
I'll go back and retry a few permutations to see if it is   
different
than
what you described.

4) The available disk space seems to only be specified for
"Server".  I
assume the other selections will eventually be updated.

IzPack only displays this for packs which have files  
associated.
This is one of the current issues about the installer. It   
installs
everything.  This will be addressed.

5) Should the "Server" selection  be re-labeled as  
Geronimo  kernel
or Geronimo base infrastructure or something to better  
reflect what
it is?

I don't have a real opinion on this.

6) The "Greyed out packs are required" comment is somewhat
confusing..
Perhaps just adding the word (Required) next to the server
selection and
removing the other comment would be clearer.

IzPackism. Fixing this would require overriding the  
ImgPacksPanel.

*Base Configuration Panel/Web Container Panel*
7) Not sure I understand the "Active at runtime" selections  
and
how they
differ from the selections I've already made on the "Package
Selection
Panel".. Is the idea that the package selection identifies  
which
packages get physically laid down on the target machine and
"Active at
runtime" determines which of these are configured as initially
enabled?
Not sure how common it would be to select a component and then
specify
that it is disabled.  Is it more appropriate to assume all   
choices
are
enabled at installation and any disabling shoud be done  
directly
in the
resulting installtion (perhaps via the admin console).

The installer is reflecting some some of the capabilities of
Geronimo.  I posed this question to the list a while back. The
response I received was that this type of behavior would be
desirable.

I think we should discuss the issue a bit more with the   
community.
From a *user  perspective* , how common will it be to  install a
component (aka pack) and then want it disabled in the  resulting
installation. Installation should be about installing a  simple
working configuration.  Uncommon configuration options   
(install and
disable) shouldn't be a mainline choice in the  installer.   
Advanced
configuration should be done after the server  is installed  
(e.g via
the adminconsole or by updating xml files).   I found the  
separate
"active at runtime" panels to be a bit  confusing and suspect  
it will
cause confusion with novice users.

7.5) The Web container "Active at runtime" selections are  
greyed
out by
default when the Tomcat container is selected.  Seems the   
default
should
be enabled.

Bug. Fixed now. JIRA 1505.

*Configuration Checkpoint Panel*
8) Is it possible to place a confirmation summary of all the
selections
and their size on this panel?

The summary is possible. The sizes might be interesting.

*Installation Progress Panel*
9) Probably want to pretty this Panel up with a Title such as
"Installing Geronimo components".

I figured this panel needed a little work.

10) The installation panel seems to hang for awhile even  
after the
progress bar indicates completion.  Eventually the "next"
selection is
available.  Is this a pblm with izpack?  Any chance of  
getting a
"completed message" in Big letters on the panel?

Packs installation?
It would not be trivial to change the packs installation panel.

*Processing Panel"
11) I had initially assumed the installation was now done  
and was
surprised that there was still more installation steps to  
be done.
Perhaps just a title on this Page "Installing Geronimo
configurations".

Processing Panel is an IzPackism.  Changing the title is not
trivial. It's possible that something might be done though.

12) Would be nice to have "Configuration completed  
successfully" or
"Configuration failed" message at the end of the output.  
Perhaps
this is
just adding the word "successfully" to your existing message.

That's easy to add to the text being inserted into the  
processing
panel text box by the ConfigInstaller run.

13) I see that the installer allows a user to create an  
automatic
installation script.  Is this a response file that can be  
used  to
invoke
the installer silently?

Yes, just supply the name of the xml saved as an argument to  
the
installer.

14) I like the fact that you provided a default  
installation that
doesn't require any selections other than accepting the   
license.
Just
hitting next->next->next..  Joe's mom will appreciate  
that.  :)

I want to cruise Joe's mom's web site when she's done :)

Hope these comments aren't too nitpicky..  I think the  
installer is
really shaping up nicely. Sometimes minor changes to panels  
make  big
differences in a user's first impression..

Thanks
-Dave-

--
Joe Bohn
joe.bohn at earthlink.net

"He is no fool who gives what he cannot keep, to gain what he   
cannot
lose."   -- Jim Elliot

--
Regards,

Erik