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.
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.
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
