Thanks for the explanation Stan. The web console uses a different paradigm then the other tools, and it does so on purpose. The result of what you describe would basically build on the "tree" paradigm and more or less expose the management functionality like the CLI and it's bigger cousin do. But it targets different persona and thus other needs. The console provides an interim information layer, that provides alternate conceptual views, that go beyond "trees". The biggest difference towards the other tools is that it tries to facilitate understanding of the underlying model. This includes arrangement, grouping and exposure of the underlying information aligned with the users tasks. You think of it too much in technical terms. Your approach is a valid one for people that can be considered "power users". Users that know the model. For them a "tree" paradigm work works well. The CLI GUI is a hybrid, but only serves former CLI users well. For them it might be an enhancement. But it's not serving the needs of the less experienced developer or administrator. A good comparison would probably be a data management tool. You can provide direct SQL access to the data or some web based interface that's much closer to business domain. The AS7 web console would be the later. > From my experience, people perceive the web interface as being simple and easy to get started. But designing for "simple" isn't easy. And it comes at a certain price. In our case we did sacrifice development time for user experience. Long story short: The management tools serve different audiences. Each audience brings their own experience, knowledge and skills. Building the web console on same paradigms the CLI tools would eliminate the for having it in the first place. /Heiko On May 18, 2012, at 1:53 PM, ssilvert(a)redhat.com wrote: > On 5/18/2012 5:56 AM, Heiko Braun wrote: >> >> Stan, >> >> you've said that you think the console project was going in the wrong direction. >> Can you elaborate on that? >> >> >> Regards, Heiko > > I didn't say it was going in the wrong direction. That's not how I > would put it. > > I think the project was architecturally wrong from the very beginning. > I know that's a strong statement and again I want to say that I'm proud > of what we accomplished. Hard work and clever programming can make up > for a lot of flaws. > > We couldn't be expected to make all the right choices at a time when we > didn't yet understand the management model that was still being > developed. And it is our misuse of the management model that > constitutes the fundamental architectural flaw. > > I think this is best explained with an example, so I'll give you the > same example I gave to Bruno yesterday. Open CLI GUI and navigate to > /subsystem=logging/logger=*. Right-click on the logger=* node and > select add. There you will see a fairly complex dialog with four types > of widgets. Also, the drop-downs are filled in with the proper values > and the required fields are marked appropriately. You can hover over > any field label to get context-sensitive help. > > I didn't write a single line of code to generate the "add logger" > dialog. It was all built from the metadata in the management model. > > This has tremendous implications on development time. Getting CLI GUI > to a point where it could do all this for every AS7 resource took about > two weeks. Yet, to develop the ability to manage just the logging > subsystem in the web console took months. And when the logging > subsystem changed on the back end I had to rewrite the front end over > again. > > Clearly, we are not leveraging the management model properly. > > I could go on and on about other technical issues. I'm sure we can get > to that in due time, but I've written enough for now. > > The last thing I want to make clear is that I'm not trying to replace > the web console with CLI GUI. We need a web console. But the > comparative ease with which functionality can be developed in CLI GUI > constitutes low hanging fruit that can't be ignored. > > I do have some ideas about how we can work together to leverage both > platforms in a mutually beneficial way. Because I think code speaks > louder than words, I'm working on a demo that shows how both platforms > might work together. I'm hoping to have something ready to show late > next week. > > Stan > > > > _______________________________________________ jboss-as7-dev mailing list jboss-as7-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-as7-dev

We still need a way for the web console to expose all management facilities that it does not yet know about.

> Like a niche toolset: the expert mode. Pretty much isolated from > everything else. But it should be possible to port it over. I absolutely agree any export mode tree-view should properly isolated, for the reasons discussed in your principles of user interface design link.

Heiko, I'd rather not present this as "Web console vs. CLI vs. CLI GUI". These should not be competing tools, but rather should be complimentary and integrated. CLI GUI is not just for former CLI users. It is also the perfect teaching tool for admins who want to learn and understand the management model. It will be a great tool for turning a novice into an expert. And experts tend to be great technology evangelists, so we want more and more of those. Concerning CLI GUI's development, my first inclination was indeed to write this into the web console. I concluded that it simply could not be done in a reasonable time frame. And it wouldn't turn out very good. At best, I might end up with something like the JMX console. We can do better than that. Sure enough, in only two weeks I had something that was, in Jason's words, "*#$%$ing Awesome!"

I agree that we need to be able to expose all of the management model in the web console. And that is what I am working on right now. I also agree that the web console, CLI, and CLI GUI serve different kinds of users. Experts will find CLI and CLI GUI to be more compelling, while your everyday admin will want to use the web console. So the question is, "If the everyday admin needs access to something the web console doesn't provide, what are his options?" If a user isn't ready to use CLI GUI then porting that to the web isn't going to help him. So my thought is to turn CLI GUI into a builder tool that defines views for the web console. With that, you can use a nice GUI builder tool to develop custom pages that present DMR data and operations in a nice user-friendly way.

I've already got a wizard that lets you choose resources and attributes for a table view. All I need to do now is query the server and spit out the table. From there it should be easy enough to upload the table definition to the server and let the web console generate the web UI. (The table definition turns out to be just a compound DMR operation.) If you like, I should be able to demo the view definition wizard late next week. Stan On 5/18/2012 10:01 AM, Heiko Braun wrote: > > Thanks for the explanation Stan. The web console uses a different paradigm then the other tools, and it does so on purpose. The result of what you describe would basically build on the "tree" paradigm and more or less expose the management functionality like the CLI and it's bigger cousin do. But it targets different persona and thus other needs. > > The console provides an interim information layer, that provides alternate conceptual views, that go beyond "trees". The biggest difference towards the other tools is that it tries to facilitate understanding of the underlying model. > > This includes arrangement, grouping and exposure of the underlying information aligned with the users tasks. You think of it too much in technical terms. Your approach is a valid one for people that can be considered "power users". Users that know the model. For them a "tree" paradigm work works well. > > The CLI GUI is a hybrid, but only serves former CLI users well. For them it might be an enhancement. But it's not serving the needs of the less experienced developer or administrator. > > A good comparison would probably be a data management tool. You can provide direct SQL access to the data or some web based interface that's much closer to business domain. The AS7 web console would be the later. > > > From my experience, people perceive the web interface as being simple and easy to get started. But designing for "simple" isn't easy. And it comes at a certain price. In our case we did sacrifice development time for user experience. > > Long story short: The management tools serve different audiences. Each audience brings their own experience, knowledge and skills. Building the web console on same paradigms the CLI tools would eliminate the for having it in the first place. > > /Heiko > > On May 18, 2012, at 1:53 PM, ssilvert(a)redhat.com wrote: > >> On 5/18/2012 5:56 AM, Heiko Braun wrote: >>> Stan, >>> >>> you've said that you think the console project was going in the wrong direction. >>> Can you elaborate on that? >>> >>> >>> Regards, Heiko >> I didn't say it was going in the wrong direction. That's not how I >> would put it. >> >> I think the project was architecturally wrong from the very beginning. >> I know that's a strong statement and again I want to say that I'm proud >> of what we accomplished. Hard work and clever programming can make up >> for a lot of flaws. >> >> We couldn't be expected to make all the right choices at a time when we >> didn't yet understand the management model that was still being >> developed. And it is our misuse of the management model that >> constitutes the fundamental architectural flaw. >> >> I think this is best explained with an example, so I'll give you the >> same example I gave to Bruno yesterday. Open CLI GUI and navigate to >> /subsystem=logging/logger=*. Right-click on the logger=* node and >> select add. There you will see a fairly complex dialog with four types >> of widgets. Also, the drop-downs are filled in with the proper values >> and the required fields are marked appropriately. You can hover over >> any field label to get context-sensitive help. >> >> I didn't write a single line of code to generate the "add logger" >> dialog. It was all built from the metadata in the management model. >> >> This has tremendous implications on development time. Getting CLI GUI >> to a point where it could do all this for every AS7 resource took about >> two weeks. Yet, to develop the ability to manage just the logging >> subsystem in the web console took months. And when the logging >> subsystem changed on the back end I had to rewrite the front end over >> again. >> >> Clearly, we are not leveraging the management model properly. >> >> I could go on and on about other technical issues. I'm sure we can get >> to that in due time, but I've written enough for now. >> >> The last thing I want to make clear is that I'm not trying to replace >> the web console with CLI GUI. We need a web console. But the >> comparative ease with which functionality can be developed in CLI GUI >> constitutes low hanging fruit that can't be ignored. >> >> I do have some ideas about how we can work together to leverage both >> platforms in a mutually beneficial way. Because I think code speaks >> louder than words, I'm working on a demo that shows how both platforms >> might work together. I'm hoping to have something ready to show late >> next week. >> >> Stan >> >> >> >> > > _______________________________________________ > jboss-as7-dev mailing list > jboss-as7-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/jboss-as7-dev _______________________________________________ jboss-as7-dev mailing list jboss-as7-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-as7-dev

CLI GUI is not just for former CLI users. It is also the perfect teaching tool for admins who want to learn and understand the management model. It will be a great tool for turning a novice into an expert. And experts tend to be great technology evangelists, so we want more and more of those.

Thanks for everybody's input and suggestions so far. Moving forward I think it's important to agree on a general strategy how we want the different tools to evolve. I think we agree that the CLI GUI functionality has it's benefits and is useful to certain types of users. I've asked this question in the past and I am still wondering about it: Why do we need a third, disparate tool on it's own to provide this functionality? Technically I don't see a reason why it cannot be provided by the web interface. I don't see the added value either: not from a usability point of view, or by looking at the potential target groups. But I can see how the generic approach provided by the CLI UI perfectly fits within the planned web interface improvements (keywords are: task based, customizable, expert mode, etc). However the fact that it's an isolated piece of work basically prevents these tools from building upon each other. I think before we talk about any future improvements to any of these tools, we should clarify this question. Currently the users choice is switching one tool for the functionality of another. But this difference will disappear in the future. Regards, Heiko _______________________________________________ jboss-as7-dev mailing list jboss-as7-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-as7-dev