[MUD-Dev2] [DESIGN] Turn Around Time On Experimentation (Was: A rant against Vanguard reviews and rants)

[Sean Howard]

"Adam Martin" <adam.m.s.martin at googlemail.com> wrote:

>>From personal experience of long years of writing GUI's and GUI libs
> I'm afraid I disagree; I think there are reasons that people make more
> progress with text, but that turnaround time isn't the main one.

It's not so much just the turn-around time as it is the price of change.
Turn-around time affects that cost, but it by no means the only thing. It
only matters during change or after failure, while something like being
smart might affect all costs at every level. However, what I was saying is
that one of the benefits text has over GUIs, more than anything else, is
the quick turn-around time. There are benefits to both approaches, but
text has that one down.

> I used to have problems similar to those you described, but once I
> (eventually - it wasn't hard, it just took me a long time to get
> there) properly understood the mental models that underlay the GUIs I
> was working with, and changed the object models (or equivalent in
> non-OO langs) to suit, the turnaround time both for major (wide) and
> fundamental (deep) changes to GUIs became vanishingly small.

I do most of my coding in Java, and the Java GUI is a very broad and
powerful framework - but this has a cost in complexity. More often than
not, what the GUI is doing is taking a complex series of actions and
reducing it to a single command. There are hooks to delegate this command
to various places, but ultimately, it can be represented just as easily as
a text command.

But with the GUI, there's a lot of maintence beyond that. I was creating a
multi-functional extendable resource editor, similar to something like
ResEdit. I was monkeying around with a simple tree - requiring models,
nodes, listeners, and a whole host of things - to do the simple act of
listing what resources are available and opening an editor for it...
something I decided could be just as easily accomplished with a console
and /list and /edit <resID>.

Ultimately, it is an editor, and I would rather spend my time working on
non-editor stuff. Don't get me wrong. I'm glad GUIs are out there and
that, for instance, tables can sort each column, and highlight each row,
but sometimes, that's overkill and learning how to use those features (if
only to learn how to NOT use them) and then implementing dozens of classes
to pander to those features can be far more trouble than it's worth.

> My vague, unscientific conclusion was that the biggest problem is
> simply that the vast majority of programmers (and hence teachers,
> courses, and programmer-teams) still haven't really learnt how/why
> GUIs work conceptually. But I've long had a pet peeve about how much
> of the really useful HCI research routinely gets by the development
> community, sometimes for many many years, so that conclusion may be
> personal bias more than anything else :).

My experience with GUIs is fairly significant. It's not about a lack of
willpower, motivation, or knowledge - it's about priorities. When I want
to make something, it would be foolish to do more work than is needed or
wanted.

-- 
Sean Howard