geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dave Colasurdo <davec...@earthlink.net>
Subject Re: v1.x Installer comments - Long
Date Tue, 24 Jan 2006 22:04:58 GMT
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-
> 


Mime
View raw message