Web console vs. CLI vs. CLI GUI

classic Classic list List threaded Threaded
12 messages Options
Reply | Threaded
Open this post in threaded view
|

Web console vs. CLI vs. CLI GUI

Heiko Braun


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, [hidden email] 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
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
Reply | Threaded
Open this post in threaded view
|

Re: Web console vs. CLI vs. CLI GUI

Heiko Braun


Here's an excellent resource that I recommend to anyone that want to chime into this discussion:


Read through the core principles outlined in this article. Then compare the tools we have to each other and you'll begin to the see the different value propositions.

/Heiko

On May 18, 2012, at 4:01 PM, 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, [hidden email] 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
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev


_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
Reply | Threaded
Open this post in threaded view
|

Re: Web console vs. CLI vs. CLI GUI

jtgreene
Administrator
We still need a way for the web console to expose all management
facilities that it does not yet know about. Some kind of advanced mode
if you will.

Unlike the CLI, web interfaces offer a gui canvas which can be used from
any system with a web browser. No special tools need to be installed.
This is kind of tool is very userful and certainly desired (note the
users out there still wanting jmx-console to come back even though
jconsole exists).

It is certainly true that a key Andiamo goal was making the web console
be the target interface for new beginning users, and so the UI focus is
important, but we also had the unified management interface goal, where
you weren't forced to switch to a completely different tool to execute
any particular function. We largely achieved that but as long as we lack
a dynamic mode then there will always be a few gaps that will lag behind
the full capability set.


On 5/18/12 9:18 AM, Heiko Braun wrote:

>
>
> Here's an excellent resource that I recommend to anyone that want to
> chime into this discussion:
>
> http://bokardo.com/principles-of-user-interface-design/
>
> Read through the core principles outlined in this article. Then compare
> the tools we have to each other and you'll begin to the see the
> different value propositions.
>
> /Heiko
>
> On May 18, 2012, at 4:01 PM, 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, [hidden email]
>> <mailto:[hidden email]> 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
>> [hidden email] <mailto:[hidden email]>
>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>
>
>
> _______________________________________________
> jboss-as7-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev


--
Jason T. Greene
JBoss AS Lead / EAP Platform Architect
JBoss, a division of Red Hat
_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
Reply | Threaded
Open this post in threaded view
|

Re: Web console vs. CLI vs. CLI GUI

Heiko Braun

Yes, I completely agree. It's already on the roadmap. 
In my opinion, and I said that in the past already, the CLI UI would be more beneficial if it had been done in the web interface right away. Like a niche toolset: the expert mode. Pretty much isolated from everything else. But it should be possible to port it over. 

@Stan What is your opinion on that? 

Regards, Heiko

On May 18, 2012, at 4:51 PM, Jason T. Greene wrote:

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


_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
Reply | Threaded
Open this post in threaded view
|

Re: Web console vs. CLI vs. CLI GUI

Brian Stansberry
On 5/18/12 11:11 AM, Heiko Braun wrote:
>
> Yes, I completely agree. It's already on the roadmap.

Good, I'm glad you feel that way. I wasn't sure earlier in the thread.

> In my opinion, and I said that in the past already, the CLI UI would be
> more beneficial if it had been done in the web interface right away.

Absolutely. The web console should be the primary graphical interface.

> 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.

>
> @Stan What is your opinion on that?
>
> Regards, Heiko
>
> On May 18, 2012, at 4:51 PM, Jason T. Greene wrote:
>
>> We still need a way for the web console to expose all management
>> facilities that it does not yet know about.
>
>
>
> _______________________________________________
> jboss-as7-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev


--
Brian Stansberry
Principal Software Engineer
JBoss by Red Hat
_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
Reply | Threaded
Open this post in threaded view
|

Re: Web console vs. CLI vs. CLI GUI

jtgreene
Administrator
On 5/18/12 12:16 PM, Brian Stansberry wrote:
>> 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.

Same here.


--
Jason T. Greene
JBoss AS Lead / EAP Platform Architect
JBoss, a division of Red Hat
_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
Reply | Threaded
Open this post in threaded view
|

Re: Web console vs. CLI vs. CLI GUI

Stan Silvert
In reply to this post by Heiko Braun
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, [hidden email] 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
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev

_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
Reply | Threaded
Open this post in threaded view
|

Re: Web console vs. CLI vs. CLI GUI

jtgreene
Administrator
On 5/18/12 1:53 PM, [hidden email] wrote:

> 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!"

Right I was very excited to see a quick freetime project produce a
decent prototype of GUI representation of the management tree. That said
I think we should still evaluate how all of these things fit together.
Can we do something as rich in a browser? If it's too much of a PITA
should it just be a standalone gui? Should the CLI be a center point of
the GUI (executing commands and so on - norton commander), or should it
be completely graphical. I think we really need to look at this
carefully and get some usability feedback.

>
> 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.

That's an interesting idea. Although, I'll let Heiko give his thoughts
on that one.

>
> 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, [hidden email] 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
>> [hidden email]
>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>
> _______________________________________________
> jboss-as7-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev


--
Jason T. Greene
JBoss AS Lead / EAP Platform Architect
JBoss, a division of Red Hat
_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
Reply | Threaded
Open this post in threaded view
|

Re: Web console vs. CLI vs. CLI GUI

Stan Silvert
On 5/18/2012 3:05 PM, Jason T. Greene wrote:
>  That said I think we should still evaluate how all of these things
> fit together. Can we do something as rich in a browser? If it's too
> much of a PITA should it just be a standalone gui? Should the CLI be a
> center point of the GUI (executing commands and so on - norton
> commander), or should it be completely graphical. I think we really
> need to look at this carefully and get some usability feedback.

All are good questions that I've thought about at length, but I don't
claim to have the final answer.

I will say that if we completely hide the operation commands in CLI GUI
then we lose a lot of the teaching aspect that the tool provides.  I
think that's really important.  We want more and more people to learn
how to use the commands and eventually create scripts.  Once they feel
the power they will be totally dedicated to AS7.

Stan
_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
Reply | Threaded
Open this post in threaded view
|

Re: Web console vs. CLI vs. CLI GUI

Misty Stanley-Jones
In reply to this post by Stan Silvert

On May 19, 2012, at 4:53 AM, [hidden email] wrote:

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.

I'd like to add a data point to this discussion. The Documentation team have used the CLI GUI extensively to quickly build CLI commands for the documentation, because we have found the CLI difficult to intuitively understand and document. Before the CLI GUI, we had to use the XSD files to build up the XML by hand, paste it into the standalone.xml, and fix things until the server started cleanly. The model did not always follow the XSD files exactly, and it was a challenge.

The CLI GUI is a great tool for building a "cheat sheet" or learning about all of the different settings that are available. For instance, when documenting the operations available for manipulating the Transaction Manager, I started with what was exposed in the Console, then went to the CLI GUI to see what I'd missed. I was then able to ask intelligent questions about those extra operations, and document them as being CLI-only. 

So whatever persona matches most closely with "technical writer" (probably somewhere between Admin and Developer, but more closely aligned with Admin) benefits greatly from the CLI GUI. The same paradigm integrated into the web Console would be even more convenient.


_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
Reply | Threaded
Open this post in threaded view
|

Web console vs. CLI vs. CLI GUI: Moving forward

Heiko Braun

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
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
Reply | Threaded
Open this post in threaded view
|

Re: Web console vs. CLI vs. CLI GUI: Moving forward

Lincoln Baxter, III
Hi Folks,

I'd like to add that Forge also has an interest in this functionality, since it is possible that users may wish to use or write Plugins for Forge to manipulate their AS7 configurations.

~Lincoln

On Tue, May 22, 2012 at 9:25 AM, Heiko Braun <[hidden email]> wrote:

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
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev



--
Lincoln Baxter, III
http://ocpsoft.org
"Simpler is better."

_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev