On 11/2/07, Joe Bohn <[EMAIL PROTECTED]> 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. 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. > > >
