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




Reply via email to