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