----- "John Verhaeg" <jverhaeg(a)redhat.com> wrote:
On Mar 23, 2010, at 1:39 PM, John Doyle wrote:
JDoyle-I think we would benefit from a more nuanced view of
'user' and 'task', that's kind of my central point. What's needed
for a new user and what might be efficient for a knowledgeable long-term user are not
necessarily the same thing. What's the efficient way to change a name or binding is
not necessarily a good way to remove a model. I work in eclipse all day, and on some
occasions I fire up vi and mvn to make a one line change when I ||'d and I should have
&&. It's not a question of the UI being a PITA or not, we're not going to
make a perfect UI, but we can shoot for one that satisfies more modalities.
But you've just validated my point. If you want a super-quick
change without the need for the UI, then you won't use the UI, you'll just open up
your favorite text editor and change it directly. In other words, you're not going to
open up Eclipse either just so you can get to some text editor.
JDoyle- Sorry, if it weren't in a archive I would agree with you, but I'm not
going to unzip it, edit and rezip, I would use eclipse.
Regarding the "perfect" UI, of course we won't
be perfect, but it is the point of the UI to be THE efficient way of doing things, without
having to spend brain cycles on remembered syntax, dependent information, etc. Much of
people's use of text editors from the command line is indeed because the UI is a PITA.
They may not call it that because it still is useful and actually used for much of their
work, but it still falls short in several areas. The real distinction between when I use
command-line vs. the UI is always going to be driven by the speed of the UI startup;
that's the only modality that should come into play.
JDoyle- We're getting a little esoteric here but seriously, your don't recognize
this as your personal preference?
If Pages or Word started just as easily and quickly as Notepad AND they were as easy to
use and noise-free as Notepad, Notepad wouldn't exist. The former we'll never be
able to do much about (and in fact usually contribute towards making worse), but the
latter we should definitely be able to address. The UIs can be better, and we should
strive for that from the outset rather than putting in a stop-gap solution that bypasses
the whole point of the UI. And don't lose sight of the repercussions behind the
"direct" editing you're suggesting - it's also very, very dangerous
unless you really know what you're doing AND complete all the side-work that must go
hand-in-hand with those changes, such as adding/removing models, updating indexes, etc.
JDoyle-It's not a stop gap, it's another option. Believe me, I'm not against
good tooling. I've been working with Hibernate Tools lately and have no time to learn
what needs to be in a hibernate.config.xml or a reveng.xml, I use the UI to create them.
That said, if I need to edit the username and pw for the DB connection, I'm going to
edit the xml in my eclipse project. And as for the side effects, isn't this what the
validation is for? Why can't validation happen and the indexes be updated on
notification that the file has changed? These seem like technical challenges to me.
JDoyle-It seems to me that if we are moving to a world where
the server doesn't need the tooling, then our artifacts are going to have to get a lot
more user fiiendly, or what a user will be able to accomplish w/o tooling will be very
limited. I know that the plan for bindings is to simplyfy to just a name, and I think we
should push the rest of the artifacts in the same direction.
Whether the server team decides to ensure the artifacts are
easy to directly manipulate or not is up to them, but the whole point of having tooling is
so they don't have to worry about that. We want the tooling to not be an absolute
requirement because of exception scenarios where we don't want the lack of tooling to
be a show-stopper, such as a server admin without access to tooling correcting a simple
problem in a configuration or the tooling not being available until a few days/weeks after
the runtimes are. But we and the users always still want the tooling; if not, we're
wasting out time. It doesn't take much experience manipulating the multitude of XML
and other text-based configuration files on a server to know we're not wasting our
time.
JDoyle-I'm not arguing against the current tooling, I'm suggesting an addition.
And as far as text based configuration files go, they don't undermine the value of
good UI, here again Hibernate Tools are a good example. JBoss's success has been fed
by (and limited by) it's use of text based configuration. Anyway, I acknowledge this
suggestion as DOA.
If the startup time of the UI really is the tipping point that
creates this modality, then maybe we have an argument why the parts of our file that
don't have other external implications, or dangerous impact in the case a value is
entered incorrectly (the connector and binding properties I'd assume), should go in a
separate file that is intended to be directly manipulated via a simple text editor. Did we
not get enough feedback on this? Should we keep all of the information in that was in the
VDB manifest in a separate file? But even if that's the case, then I expect the
"direct manipulator" of the other information to manipulate it in the most
direct way possible - via the command-line; there's no reason to assume he'd take
the time to wait for the tooling to start, find the correct VDB in the tree, open its
editor, and finally open the correct text editor tab just so he can make that "quick
fix".
Thanks,
JPAV