geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Shiva Kumar H R" <shiv...@gmail.com>
Subject Re: [DISCUSS/FEEDBACK] Usability improvements to Geronimo
Date Mon, 05 Nov 2007 15:14:30 GMT
On 11/2/07, Prasad Kashyap <goyathlay.geronimo@gmail.com> wrote:
>
> On 11/2/07, Joe Bohn <joe.bohn@earthlink.net> wrote:
> >
> >
> > 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?
>
> Yes. Let me give you an example. Recently I was deploying a
> configuration. For a while the wheels turned and then I received an
> operation successful message. However, the deployment had spewn a
> boatload of stack traces to the geronimo.log file.
>
> In another example, the Websphere App Server shows informational
> messages as an app is being deployed. That is quite reassuring to an
> administrator.
>
> For now, this is a console-only 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.


Initially I too was of the same opinion thinking that wizards like "Plan
Creator" should be part of Devtools like Eclipse-Plugin. However when I
posted the idea to user@ list, I received a feedback saying:

"A template system that incorporated creation of the container specific
configuration based on the web.xml and ejb-jar.xml would be a valuable tool
within the server administration tool set.  I would expect a tool like this
to be available within the management console in direct proximity to the
deploy application tool!  Setting deployment specific environment values
falls within this scope as well."
Please see
http://www.mail-archive.com/user@geronimo.apache.org/msg06409.html

There were also concerns about using Eclipse plug-in just for the sake of
deploying apps into Geronimo saying "...many of us don't use Eclipse and
don't want to be forced into it". Please see
http://www.mail-archive.com/user@geronimo.apache.org/msg06412.html

All this lead me thinking in the direction of adding a new portlet to the
Admin Console. I also later saw that existing Portlets in Admin Console like
"Database Pools, JMS Resources, Security Realms etc" are nothing but wizards
to generate Geronimo deployment plans. So I thought a Plan Creator wizard
would be a logical continuation of those existing wizards.

And yes it's definitely a usability no-no for having to scroll down to see
all the links. +1 for collapsible navigation sections and/or scrollable
navigation frames.

Sure. Collapsible navigation sections and/or scrollable navigation
> frame are great improvements.
>
> Also, I wonder if plugin creators also fall under the under the domain
> of tooling along with plan creators.
>
> >
> > >
> > > 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.
>
> So today you can create a plugin only by exporting an already deployed
> "something".  It would be nice to assemble a simple plugin with other
> available artifacts.  Again, a tooling feature.
>
> >
> > >
> > > 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.
>
> Yes. Worth the effort.
>
> >
> > >
> > > Please feel free to discuss the merits and demerits of these features
> > > and/or add to the list.
> > >
> > > Cheers
> > > Prasad.
> > >
> >
>



-- 
Thanks,
Shiva

Come to OS Summit Asia 2007 and learn about
"Java EE 5 App Development on Geronimo 2.0 simplified using Eclipse"
http://www.ossummit.com/2007/program/talk/16

Mime
View raw message