Mailing-List: contact geronimo-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: geronimo-dev@incubator.apache.org
Message-ID: <3FBDB21C.1090109@coredevelopers.net>
Date: Thu, 20 Nov 2003 22:35:08 -0800
From: Jeremy Boynes <jeremy@coredevelopers.net>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;
 rv:1.5) Gecko/20031013 Thunderbird/0.3
MIME-Version: 1.0
To: geronimo-dev@incubator.apache.org
Subject: Re: console design
References: <7E546A2B7994D3119A38009027D502CC05A7083E@WAS-XCHG1>
In-Reply-To: <7E546A2B7994D3119A38009027D502CC05A7083E@WAS-XCHG1>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Sonnek, Ryan wrote:

> I'm not even sure that the client app is needed (thus this thread), but I DO
> think that it is important IF one is used, that they are functionally and
> visually similar.  

This worries me a little. I have seen organizations try and reuse UI 
components between Web and GUI interfaces and it never seems to come out 
quite right. I think there is enough difference in the user interaction 
model that it is worth specializing.


As more and more things go into the web console, it
> doesn't make sense for the thick client to "rewrite" to stay current or vice
> versa.  I understand that JMX does not require the added abstraction, but
> for an enterprise system to have two separate views of the same information
> and same operation, it does NOT make sense to duplicate the coding effort.
> HTML or Swing or SWT or Twiddle should just be a view overtop of the same
> engine.  

The underlying data model would be the same, but the way it is presented 
would be different.

I do not know if this kind of thing is even possible (same logic
> with different presentation layers), but I would like to see the duplicate
> effort minimized at best.
> 

All for that, provided the resulting applications work.

If you look at the console for JBoss, then it exposes the raw MBean 
structure. This is useful to a container developer or experienced admin, 
but almost totally useless to a typical user. The Weblogic console, on 
the other hand, dumbs the configuration down to meet the needs of the 
typical user, but doesn't give enough utility to the experienced admin.

And, of course, neither works for shell-level access where you end up 
editing XML and copying files around.

I'm not really a UI person, but I would like to see us reach a 
compromise where the console is easy to use for a new or inexperienced 
user, but offers a way to expose the raw details to the experienced one.

For example, the 'basic' UI for creating a JDBC DataSource might prompt 
for the vendor type, and then offer a wizard to step through connection 
setup (properties like server name, username, password, ...); the 
advance version would allow for fine control over the pooling policy, 
choice between XA-, Local- and non- transactional, SQL to be issued, 
security (including reauthentication), ...

Another thing not to forget is the ability to import/export 
configuration details. For example, I would want to set up the above 
JDBC DataSource in my staging environment and then be able to 
export/import that exact configuration into production without having to 
type anything back in.

--
Jeremy