Mailing-List: contact user-help@geronimo.apache.org; run by ezmlm
Precedence: bulk
Reply-To: user@geronimo.apache.org
Received-SPF: pass (nike.apache.org: local policy)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
  s=dk20050327; d=earthlink.net;
  b=jE7zcodUkkdKsh5arxP2nqNClq2wJs8/rw5dXKCvEpDPgKLw/SsPPAnp4915CG2B;
  h=Received:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding:X-ELNK-Trace:X-Originating-IP;
Message-ID: <472B556E.9000408@earthlink.net>
Date: Fri, 02 Nov 2007 12:50:54 -0400
From: Joe Bohn <joe.bohn@earthlink.net>
User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070728)
MIME-Version: 1.0
To: dev@geronimo.apache.org
CC: user@geronimo.apache.org
Subject: Re: [DISCUSS/FEEDBACK] Usability improvements to Geronimo
References: <c278ac970711020837s61836b8fve66235b9fa165616@mail.gmail.com>
In-Reply-To: <c278ac970711020837s61836b8fve66235b9fa165616@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit


Prasad Kashyap wrote:
> As we get close to releasing Geronimo 2.1 and look beyond, I'd like to
> discuss a few usability improvements we can do to G. I am
> cross-posting this to the user-list so that we can get a direct
> feedback from our dear users.
> 
> 1. Dynamic status messages. Some operations may take a certain amount
> of time which could make the administrator uneasy as he waits. On a
> local machine, he has the luxury of tailing the geronimo.log or seeing
> the startup terminal. On a remote machine, he is almost flying blind
> in the absence of any dynamically updating status messages. It would
> be nice if we had another portlet at the bottom that showed status of
> the operation being performed. This is really useful for long running
> operations.

Can you be more specific here?  What operations and how does a message 
make things any more dynamic?  Is this a web console only concern or is 
it also a command line concern?

If we really begin to include multiple portlets on pages then it might 
get difficult to associate responses with porlets/actions that initiated 
them.  It might be more beneficial to provide some interactive feedback 
(dojo?) within the portlet.

> 
> 2. Geronimo Workbench. With the addition of features like "Plan
> Creator" and "Create Plugin", the Admin Console has slowly begun to
> tread into the domain of tooling. Now we are introducing features for
> monitoring the server. It's debatable whether such features should
> even exist in the console. Purists might want the console to be solely
> for configuration of the server. But given the fact, that they are
> already there, we should consider creating tabs at the top or
> sectional categories in the navigation menu. Since we have a
> navigation tree which does not collapse, we have already crossed a
> point where we have to scroll down to see all the links. This is a
> usability no-no. It's time to transform the Console to a Workbench as
> more Tooling and Monitoring features find their way in.

I agree that the plan creators are more in the domain of tooling and 
perhaps should not be part of the console.  I think of the web console 
as an "Administration Console" rather than just a configuration console 
so I think monitoring makes perfect sense to be included. That aside, I 
think it makes sense to make the navigation tree collapse.  I'd add tabs 
as a last resort because this is not always intuitive to the user.
Along with this I think it would be nice if we could enable the 
navigation and display area to scroll independently.

> 
> 3. Plugin Creator Enhancements: Our current "plugin create" feature in
> the console is limited to exporting an already deployed configuration.
> It does not even include the geronimo-plugin.xml inside the exported
> car. It would be nice to enhance this tool such that any plugin can be
> created based on a set of already existing plugins as dependencies.
> This should allow users to create simple plugins without having to
> learn maven or the car-maven-plugin.
Not sure if I follow this one.  You can export a deployed something as a 
plugin now without learning maven or the car-maven-plugin.

> 
> 4. Enhanced logging framework which can specify logging filters at the
> package level.
This has been proposed before and it is a good idea.  It would require a 
logging/trace strategy and architecture and a lot of leg work to 
implement it across the code ... but I think it would be worth the effort.

> 
> Please feel free to discuss the merits and demerits of these features
> and/or add to the list.
> 
> Cheers
> Prasad.
>