Re: [DISCUSS/FEEDBACK] Usability improvements to Geronimo
On 11/2/07, Prasad Kashyap <[EMAIL PROTECTED]> wrote: > > 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. 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/[EMAIL PROTECTED]/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/[EMAIL PROTECTED]/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. > > > > >
Re: [DISCUSS/FEEDBACK] Usability improvements to Geronimo
On Nov 2, 2007, at 1:35 PM, David Jencks wrote: 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. The console already provides this type of feedback while installing a plugin. Downloading JDBC drivers using the db wizard provides it as well. It should be pretty straightforward to use that same ajax widget to show progress info in the deployment portlet if that's desirable. I can't really think of any other console actions that take a non-trivial amount of time to complete. Maybe start/stop components in some cases. I think more important than dynamic feedback is accurate feedback on whether the operation failed. Maybe things have gotten better lately but my expectation honed through years of frustration is that to really find out if a console operation succeeded I have to look in the cli console or logs for the pages of stack trace that were suppressed in the admin console. Oh, well, you're right. The console does a poor job of surfacing error messages and diagnostic feedback in many cases. I would actually consider the lack of good error handling as a separate issue from progress info. Sorry if I am splitting hairs. Anyway, let's make sure that "better error handling and diagnostic feedback" is represented in some form on the list. Best wishes, Paul
Re: [DISCUSS/FEEDBACK] Usability improvements to Geronimo
On Nov 2, 2007, at 10:27 AM, Paul McMahan wrote: On Nov 2, 2007, at 1:13 PM, Prasad Kashyap wrote: 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. The console already provides this type of feedback while installing a plugin. Downloading JDBC drivers using the db wizard provides it as well. It should be pretty straightforward to use that same ajax widget to show progress info in the deployment portlet if that's desirable. I can't really think of any other console actions that take a non-trivial amount of time to complete. Maybe start/stop components in some cases. I think more important than dynamic feedback is accurate feedback on whether the operation failed. Maybe things have gotten better lately but my expectation honed through years of frustration is that to really find out if a console operation succeeded I have to look in the cli console or logs for the pages of stack trace that were suppressed in the admin console. thanks david jencks Best wishes, Paul
Re: [DISCUSS/FEEDBACK] Usability improvements to Geronimo
On Nov 2, 2007, at 1:13 PM, Prasad Kashyap wrote: 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. The console already provides this type of feedback while installing a plugin. Downloading JDBC drivers using the db wizard provides it as well. It should be pretty straightforward to use that same ajax widget to show progress info in the deployment portlet if that's desirable. I can't really think of any other console actions that take a non-trivial amount of time to complete. Maybe start/stop components in some cases. Best wishes, Paul
Re: [DISCUSS/FEEDBACK] Usability improvements to Geronimo
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. > > >
Re: [DISCUSS/FEEDBACK] Usability improvements to Geronimo
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.
