Re: Great SWT Program

On Sep 17, 6:18 am, blm...@xxxxxxxxxxxxx <blm...@xxxxxxxxxxxxx> wrote:
I wouldn't put it that way. The way I remember the discussion, you
said you had observed real-world damage resulting from something
that happened in Usenet, without providing any details. To me
that sounds like your saying "I can't provide details, but take
my word for it, it can happen." Given how frequently I disagree
with your summaries of what other people say, I wasn't willing to
do that. I'm not saying you're not right to not share details,
just that without them .... <shrug>

In other words, either I break a confidence or you assume I'm lying.
Nice. :P

It occurs to me that in writing the above paragraph I may have
grouped together an assortment of bad experiences with vaguely
GUI-related things, none of which are really related to using a
GUI to configure something. The bad experiences that come to mind
mostly have to do with trying to switch back and forth between
different versions of some GUI-ish program (GNOME and OpenOffice
are the examples that come to mind). What seems to happen is
that the newer version silently changes configuration files in
a way that presumably reflects changes from the older version.
Sometimes these changes break things.

Well, duh. Running two different versions of something sharing one
configuration file or one of almost anything else is just *asking* for
trouble. Each of them should be installed separately, with its own
version of the configuration file. Or you should pick a version you
prefer and stick to it.

I have multiple versions of one tool over here (GTKRadiant, a 3D-game-
level editing tool; versions 1.2ish and 1.5ish IIRC) but they are
installed in separate directories, each with its own copy of its
settings files; they appear not to clobber anything important
belonging to one another.

Okay: Your mileage varies from mine. (It sounds like you might
be basing what you say on bad experiences with some text-based
newsreader. Care to say which one? Just curious.)

More a made-up example. ALL unix commandline apps appear to behave in
a similar fashion. Error messages are terse and cryptic where they
aren't absent. Doing anything nontrivial requires multiple trips to
the help. Even navigating the help requires trips to the help!
Something as basic as browsing some hypertext should be obvious right?
Arrows/pgup/dn/home/end to navigate, select links, etc. and enter to
follow links, backspace to back out of them, assuming the help viewer
was designed before the invention of the mouse that is; scrollbars and
clicks working in addition if it was designed subsequently. But
nooo ... each one has its own idiosyncratic navigation. Some use + and
- and have some arcane form of search that is bound to almost any
conceivable key OTHER than ctrl+F. Some use space and -, or the arrows
actually behave as expected but nothing else does, or ... Of course
lots of times the functionality is totally hidden as well. Is there a
search at all? Logic says there should be. Ctrl+F doesn't work. Ctrl+S
doesn't work. F3 doesn't work. OK -- if there's a search, I'll never
find it without searching the help on the help viewer. Eh, now there's
a bit of a problem...

Of course your fumblings might provoke unexpected behavior that's
worse than just a beep or no-effect or an error message. Ctrl+F might
activate some arcane mode for doing some unspecified thing from which
there's no obvious escape except Ctrl+C and start all over, for
instance.

Basically, none of the stuff, not even the help viewer, works until
you've actually read the help for everything in advance as one might
the manual for hooking up a stereo. Help is for reference and advanced
how-to stuff; if the user needs it to even do the basics then there's
a problem. If the help browser itself isn't dead easy to use and
"normal" in behavior then the user is sunk from the get-go. Only the
guys who designed the system and whatever elite and cloistered guild
has descended from them through chains of apprenticeship can do more
than get the thing to run and then boggle in puzzled annoyance when it
won't do anything useful. Indeed, in any system with idiosyncratic
help (or none at all) the guild mentality is evident -- the only way
in being apparently to apprentice with a live tutor. Is this a tool,
or is it an exclusive club? Is its design based pragmatically around
getting a useful task done, or around the same philosophy that informs
signs on treehouses saying "NO GIRLZ ALOWD -- GURLS SUC!" ... (you may
have been on the receiving end of that a time or three when you were
younger, so hopefully you can relate!)

In any event, configuration done by hand-hacking (hidden functionality
again -- nothing in the program UI indicates that you can change
behavior XXX!), cryptic error messages, unsearchable help, help that
provides no how-to information, help that reads like stereo
instructions, etc. all clearly indicate a lack of attention to
usability. Hidden functionality itself does so. Apps that are terse
and uncommunicative combined with help that is either likewise, or
very verbose and still uncommunicative, are unfriendly and needlessly
difficult to use. Of course, a better interface requires more code,
more text strings, etc. and back in the bad old days memory and
suchlike were at a premium. Of course, the ability to actually see
what you're doing and visually browse through the available options
and use them on the spot requires better video hardware than they had
then. Back then there was an excuse for these designs. Now there is
none.

Ultimately, even if you get semi-proficient, and the help is of the
verbose variety these applications basically provide a thousand
drawers full of various tools, all with opaque fronts and cryptic one-
letter labels, and somewhere a manual describing which one is in which
drawer, where a modern one just lets you see and reach for the tools
you want when you want them. If you want the drill you reach for the
drill, rather than the manual which says there's a drill in a drawer
labeled, for some reason, J. If you want to see what's available you
look over all the tools and if you want to use one you use it right
there, rather than having to look through a *catalog* of tools and
then switch to another task and place an order for one there. :P

Of course, the catalog still needs to be there, especially if you want
to support automation; but for hands-on use for heaven's sake allow
actual hands-on use! I much prefer software that's like a vehicle I
can directly pilot to software that's like being chauffeured around by
a driver that speaks only Swahili and requires me to learn it before
he can even tell me which street I'm at, let alone drive me to the
corner store...and that other one speaks only Bantu...and that one
Tagalog...and not a one English or even French or Spanish! :P

Of course the fact that the chauffeur can apparently see out the
windows but forces me to ride blindfolded doesn't help. You can't even
get oriented in those old interfaces; you must have a precise memory
of exactly what state the software is in or nothing will work as
expected.

No, I don't really use many of those -- I use a lot of text-mode
tools, but since one of the things I like about them is that they
*are* text-mode, why would I use a GUI-fied version of them?

I suppose you also prefer rotary-dial phones? :P Seems silly to eschew
great advances in user-interface technology that can make things a lot
easier.

Specific tools I can remember having trouble with are mentioned
earlier. Maybe they *are* poor GUI tools; I'm certainly not the
best person to judge.

Well Eclipse certainly isn't. I don't know why it got hosed to the
point of needing hand-hacking some files to get it working again. Oh,
wait, I *do* have a pretty good guess: hand-hacking of the same files
messed them up in the first place, perhaps. :)

If that's true you're probably not too familiar with the basics of
operating whatever GUI this was (Windoze, Mac, or some X WM I guess).
The good news is you only have to learn one of these once, and the
knowledge can be used to operate every native application (YMMV with
dodgy ports, though).

Could be. I've had enough practice that I don't have a lot of
trouble with the mechanics (and have been very happy to discover
that many of these GUI things are a lot more keyboard-drivable
than they at first appear to be).

Why? Is your mouse really that unreliable? For a lot of things (e.g.
navigating to an arbitrary point in a document) the mouse is way
faster than keyboard navigation, or *shudder* using the search-n-pray
method.

I think what I'm not so good
at is guessing where to find, in a complicated menu structure,
something useful for the task I have in mind. Online help is
sometimes excellent, sometimes frustratingly inadequate.

This problem plagues help systems in general. Often they lack how-to
information and provide either very little, or a ton of reference
information useful for someone who already knows the how-to stuff.

That said, at least a gui lets you browse around and find whatever you
are searching for, and you can easily remember where it is. It's much
easier to remember a *place* than it is to remember "Ctrl-Meta-H, X,
Z, Q, <enter>" and *** like that!

A decent gui also puts obvious/frequent/contextually relevant stuff in
easy reach (e.g. toolbar) and has a logical organization to its menus.
Document saving and loading, printing, and other stuff like that goes
in File, etc.

Well, yeah, kind of .... A lot of them these days provide
some kind of text menu to help new users, and there are a
lot of keystrokes that do the same thing in many applications.

That's like putting the little numbers onto a formerly-blank stick
shift instead of noticing that a few decades ago they invented this
nifty thing called an "automatic transmission". :P

Typical old-skool unix software: stick shift with the groove pattern
on the head of the stick, but no labels there. There's a 500-page
behemoth of a manual in the glove compartment with a labeled version
of the groove pattern on page 217. The table of contents lists "Shift
diagram" in between "Starter" and "Tire rotation" but does not give
page numbers for anything, just the list of things contained, in
alphabetical order. Riffling through the whole thing is needed to find
anything. There's probably some kind of arcane indexing system you've
overlooked, but you'll at least need to riffle through the whole thing
to find *that*. The actual contents are not in any obvious (e.g.
alphabetical) order so binary search isn't an option. (The computer
version: you have a page down command, and, if you're lucky, a page up
command. There may be a search command but you're damned if you know
of it; it certainly isn't reached via any of the usual suspects like
ctrl+F. And since you can only go one page at a time, binary search
isn't an option, however it's organized.)

What you just described: the diagram is directly on the stick head.
There is still a 500-page manual with no page numbering.

What was invented about 25 years ago and is used on every sane
operating system and even on the Macintosh(!): an automatic shift --
just put the darn thing in drive and hit the gas. No need to worry
your head about the internals. The manual is 150 pages and has a TOC
and index of the normal sort; you can actually find stuff in it in
under an hour and even in under a minute!

Poorer GUI systems: there's an automatic shift, but the transmission
grinds and breaks down sometimes. The manual lacks a TOC or an index
because it's only 15 pages long and basically says "fiddle with the
stick and the pedals to make it go". It still works, though, and
intuitively, and when the transmission goes, you just push a button
for an instant free replacement, although you also mysteriously find
yourself back at the last major intersection you'd crossed.

.