Re: Great SWT Program

On Sep 24, 11:36 am, blm...@xxxxxxxxxxxxx <blm...@xxxxxxxxxxxxx>
wrote:
Local config files .... Yeah well. That's good from a standpoint
of allowing different configurations for different machines, not
so good from a standpoint of letting users set configurations
once and use them everywhere.

Depends on which is more useful in your particular circumstances, and
thus needs to be decided on a case-by-case basis, I expect.

If incompatible versions of applications used different names for
configuration files, this problem would go away. But apparently
many don't. And I've found this to be much more of a problem with
"modern" applications than the old-time ones where you configure
things by editing text files.

A lot of Windoze apps don't play very nicely with copies of
themselves, mainly due to registry collisions. One more black mark
against the registry. But it's no reason to be requiring hand-hacking
config files manually -- an app could ask you to name its install, and
use that name for its configuration files and other stuff. On Windoze
the ideal would be to have the user pick a directory under "Program
Files" and stick a .ini file there along with everything else. It's
there if it wants manual editing, and it's out of sight and out of
mind if you just want to use the GUI. The practise is to use the
registry instead. Guess which would enable multiple instances to play
nice on the same system?

Yeah. So, not particularly relevant to a discussion of a multi-user,
multi-machine setup.

Au contraire; it demonstrates that it can be done -- having an app
coexist with different versions of itself, by each having its own
subdirectory to put things in. Of course with per-user stuff this
needs to go in the user's home directory in subdirectories, instead of
in Program Files or wherever.

The only commonality I recall observing is that they all deviate
equally from standard user-interface guidelines, key-bindings, and the
like.

"Standard" as defined by .... Yeah well.

As defined by what 90+% of computer users encounter with 90% of the
applications they use.

For suitable definitions of "never": F1 brings up help in mutt
(mail reader).

Really? This is the first I've heard of any unix app even knowing that
there is such a thing as a function key.

Again for suitable definitions of "never": Both of these keys
do what their names describe in mutt and in vim. The keys labeled
Home and End also do something related to their names.

Again, this I find hard to believe. Extraordinary claims require
extraordinary evidence, and all that.

Part of the problem (?) is one of maintaining backward compatibility.

Maintaining sideways compatibility with everything else people use
would be more valuable IMO.

Curiously enough, I just tried using OO Writer to write a fairly
simple document last week, and to me it seemed much like Word --
difficult to use in the style to which LaTeX has accustomed me
(logical structure rather than "just start typing"), full of
irritating behaviors, etc. <shrug>

I'm not aware of a WYSIWYG word processor with LaTeX-style logical
structure. Seems there's demand for such a thing though. Automatic
behaviors should all be turnable-offable someplace.

If it's a simple
program with limited functionality, then I'd be less inclined to
expect baffling behavior.

Basically that's what it is. And what it does do, namely basic text
editing (and it has search), it gets right. Nothing baffling. It's as
easy to pick up and use as a pen and paper, which can be damned
refreshing.

I don't know how to say it more clearly: To me, something about
the combination of a point-and-click interface and help written
in a "let's not scare the user with techical terms" style says
"hey! anyone can use this tool! no understanding of underlying
concepts required!" Of course that's not true, and the fact
that the interface makes me think the program is claiming it --
it may just be my biases showing.

I think there's two sorts of expertise at issue, and conflating the
two is going to confuse.

1. Domain expertise, relevant to the particular task the user is
accomplishing.
2. Expertise in the program's own internal workings.

1 will be required; this is unavoidable unless the domain expertise is
something completely automatable, which is as yet rather rare.
2 should not be required, to the extent that it doesn't overlap with
1.

So I shouldn't need to know anything about how Notepad works to use
it, but I will need to know something about text and files and such.

Your earlier example was a network/protocol configurator of some sort.
For that, networking expertise of a particular sort will be required.
Knowing implementation details of the system shouldn't be, though,
only knowing the standards governing whatever networking protocol is
at issue. For example a good Web server would not be able to avoid the
user having to know a fair bit about HTTP, but could avoid the user
needing to know a bunch of arcane stuff about the particular
implementation. If they want to configure complicated, scriptable
security rules (e.g. firewall rules) they need to learn the scripting
language though, of course.

Your original example was setting up an SVN client or similar.
Knowledge of SVN will be an unavoidable requirement there.

Help that "dumbs down" the expertise in category 1 won't be very
helpful. Help and a user-interface that minimizes the impact of
category 2 is another matter however.


I wonder whether your idea of a text editor differs from mine.

I don't see how; a text editor is an application for editing ASCII
files (or, perhaps nowadays, also unicode files). The basic goal:
enable the user to put any desired string of printable characters,
tabs, spaces, and linefeeds together and store them to and retrieve
them from files. Anything else is window dressing, really.

(*) IDE-like features such as syntax highlighting and automatic
indentation / reformatting of source code. I almost switched to
emacs some years ago just to get access to these features. Then
I discovered that vim had them too.

The usual unix editor syndrome: the editor tries to be a jack of all
trades; hence, master of none, and a baffled user too. A specialized
IDE makes more sense than a supposedly generic text editor for this
purpose; and on Windows, you'd use Eclipse rather than Notepad here,
instead of trying to make Notepad into Eclipse.

(*) Interoperability with other tools. I don't know how to say
this better, but some examples: vim makes it easy to import the
output of a command-line command (such as ls), or run selected
lines of a file being edited through an external command (such
as sort). "No one wants to do this"? I dunno. I seem to find
it useful pretty often.

This begs for a better interactive command processor rather than more
features in the text editor. On Windows, you'd want a souped up
command.com box with full-screen instead of line editing and an
immediate-mode prompt, not unlike the old QBasic in some respects,
rather than cramming a bunch more stuff into Notepad. (With Eclipse
and a command shell jammed in there, your ideal for Notepad is now
starting to resemble some kind of feeping creature already!)

A subset of this functionality is also found in specialized IDEs, such
as Eclipse.

(*) vimdiff, which shows differences between two files in a way
that's sometimes easier to grasp than the output of diff.

This might actually be sensible as a text editor feature, but is
especially so as an IDE feature.

(*) Ability to record and play back macros. This also is
something I seem to find useful pretty often.

This might actually be sensible as a text editor feature.

[snip]

AFAICT, you're really looking for an IDE, not a plain old text editor,
here.

Maybe I felt like that when I first started using these tools.
Now, however, when I'm editing text with vim, I perceive myself
to be "editing text" rather than "using vim". The keystroke
sequences for actions I do often -- I don't think about them
any more than I think "I need to turn the steering wheel now"
when I'm driving a car and want to turn.

That's the oft-noted human capacity to get used to anything. Prisoners
of war in the Koreas even got used to torture, chronic sleep
deprivation, and other stuff. Kidnap victims sometimes form a bond
with the kidnapper. It's called Stockholm syndrome; see a doctor. :)

Thing is, the interface for "normal" stuff gets out of the way more-or-
less immediately, unless what you're doing actually is rocket science.
(Editing levels for 3D games for example, rather than typing your
resume. And I think the level editors could probably be improved in
usability even so, though only up to a point.)

Now, I *do* have that feeling when I'm trying to edit text in
some other interface.

But it won't last long if the interface is simple and straightforward.

If the task is complex, the interface is going to be complex.
If the task is simple and the tool is a normal Windows app, the
interface is going to be simple.
If the task is simple and the tool is a normal unix app, the interface
is going to be complex.
If the interface is simple, it will be easy to use.
If the interface is complex but you've spent years with it, it will be
easy to use.
If the interface is complex and you've not spent years with it, it
won't be easy to use.

So when is it unavoidable that the interface not be easy to use?
When the user is not massively experienced and either the task is
complex -- or unix is involved. :P

As previously noted, I'm happier driving
from the keyboard than using a mouse, and while a lot of actions
(selecting text, for example) can be done that way, I usually
have to consciously think about which keys are needed. I'm
sure practice would help, just as did with vi(m), but -- why?

Think about which keys are needed? It's completely intuitive with,
say, Notepad; shift+navigation keys moves one endpoint of the
selection (the other being wherever you were when you first started
holding down shift). (This is assuming you have no desire to use the
mouse, where typically it's just click at one spot, and hold the
button to move the other endpoint.)

The problem being that you really *can't*, save perhaps with a live
tutor, as near as I can figure.

A live tutor is probably useful in learning the first few tools.
After that, not so much, again in my experience. I figured out
bash (a command shell) without a live tutor, but then I already
knew another Unix command shell ([t]csh). I think I learned
most of what I know about some of the other tools (sed and awk)
without a local expert to help. <shrug>

The latter are noninteractive tools. But you should really not need a
live tutor at all. A decent help system would obviate the need, but
tends to be lacking on such systems as you seem to be describing.

It's not so much that I think the GUI tools come up short, as
that they encourage people who don't know what they're doing to
try anyway, and they present concepts in a way that I think is
confusing to the expert. I can't give specific examples; it's
more of that "don't scare the user with technical terms" stuff.

This is not, however, an intrinsic, unavoidable trait of GUIs, though
it may be a common flaw in particular instances.

Yeah .... I actually find some of Eclipse's "let me help you"
features more intrusive than helpful. Maybe you get used to them,
but for a first draft, I'd rather rough it out with vim, which
doesn't get in my way, and then start up Eclipse and let it help
me with what it does well, such as generating import statements.
(Somebody may well have written a vim plug-in for that. I should
look around for one sometime!)

I don't find Eclipse bothersome in that regard at all; especially as
it doesn't change anything without my permission; just highlights
various things. I can tell it to generate or fix the import statements
and it does, though.

The one major nuisance is that sometimes when the autocomplete kicks
in with a suggestion some of the navigation keys stop working and the
mouse must be resorted to if you don't want to actually autocomplete
there. :P

The other is when I actually want it to suggest a completion and it
stubbornly doesn't, though there's a key that can coax it. Sometimes
also it won't update the highlighted identifier occurrences until you
hit ctrl+S to save for some reason.

Sure. Have you ever encountered a GUI tool that *wasn't*
implemented in the "don't bother your little head about where
things are" style, though?

Yes, but not frequently.

My mileage varies -- I think it takes me about as long to remember
the location and/or appearance of one of those poorly-designed icons
as it does to remember a keystroke sequence. <shrug>

At least you can just browse until you see the icon, and recognize it
once you find it. There's only so many places it can be hiding.
Whereas there are potentially infinite keystroke sequences, and the
only way to browse those is to actually enter them, and doing so will
have consequences you probably don't want for the document you're
editing!

Forget where icon is -> start looking.
Forget key sequence -> exit, fire up the help/man page/whatever, ...,
restart, find your place again ...
(Inbuilt help saves the task switching, but runs afoul of "if a key
sequence needed to use the help is forgotten, you're sunk")

Sure. Of course, most of those old-style tools seem happy to
take advantage of the bigger-than-80x24 windows possible with
most terminal emulators.

But still have a legacy philosophy of let's-keep-the-user-disoriented-
in-the-dark because they originated in an era when they really had no
alternative to that.

It depends. In a constrained-width environment, with a deeply-nested
directory structure, I prefer the latter. If I forget where I am,
I can find out with pwd.

Should rename that to "pwned", since that's what you are if you are in
a constrained-width environment in this day and age. :P

I observe that the default configuration for the GNOME terminal
emulator, at least on the system I'm using now, seems to put the
full path of the current directory in the title bar, where it can
provide useful information without getting in the way.

Another benefit of the GUI way -- information can be stuck in various
places about the screen to be referred to, without being in the main
task area, and there's room for a lot more of it besides. :)

What I'm thinking is that some people seem to have no trouble
remembering shortish strings of meaningless data, such as phone
numbers, while others apparently would have to work hard to do
that.

It's designing software to cater to the type of autistic savants that
can memorize *a whole damn phone book full of such numbers* and
remember exactly who each one calls that bugs me. The UI for emacs
appears to be designed for autistic savants, in particular. :P

Could be. But speaking as someone who might have leanings in the
"autistic savant" direction, I'll say that I rather like software
that suits my way of thinking.

That doesn't stop it being completely unsuitable for the vast majority
of the population of this planet, though. :P

[ snip -- it's not that you're not making some good points, but
apparently there's a limit after all to how much time I'm willing
to spend, even though this is a subject I can get worked up about ]

Evidently. :P

A Windows program is apt to be all-or-nothing: Either it "just
works" (which admittedly is wonderful), or it fails in some
way whose cause and resolution aren't obvious to a novice user,
and there don't seem to be many tools available for diagnosing
what's wrong, and there seems to be more of an unbridgeable gap
between novices and experts.

Versus a unix program, which is apt to be nothing-or-nothing: it "just
doesn't work" out of the box, and fails in some way whose cause and
resolution aren't obvious to a novice user, and if there are tools
available for diagnosing what's wrong, their very existence is also
not obvious to a novice user...and there's an unbridgeable gap between
novices and experts, because if you can't even get the blasted help
viewer to work right, how are you ever going to read all of that
technical crap and become one of the latter? :P

An old-style Unix program is more of a continuum: Even simple
things may not be doable without some learning, but if something
goes wrong, you have better prospects of figuring out what,
and novices and experts are the ends of a continuous spectrum
one can hope to move along.

That's not my observation. See above. Hell, when "something goes
wrong" on Windows 90% of the time it's fixed with a reboot, or a
reinstall of the offending app, or both. When "something goes wrong"
on Unix 100% of the time it's fixed with voodoo, for which your local
witch-doctor will probably charge money. If you can even find one. :P

I'm not expressing this idea very well, but the key distinction
I'm trying to make is between a mindset that seems to have only
novices and experts, with no clear path from one to another, and
one that's more of a continuum.

Experts and bigger experts, near as I can figure. No novices
though. :P

Huh? Say I want to learn more about the cd command. I type "man
cd" and get a long page about bash (since cd is actually a shell
builtin). Now I type "/cd<return>" to search for cd

And hit something that I'm sure is not F3 to jump to the next
occurrence, and the next, and eventually to the 500th or so, which is
the first that actually references the "cd" command instead of being a
random occurrence of those two letters side by side as part of
something else.

Search queries only a couple of letters long are well-nigh unusable.
So is any interface that depends on your using such to navigate.

(Admittedly the use of "/" and "n" to search aren't intuitive
the first time you encounter them, but a lot of text-mode tools
use them, so .... <shrug>)

Given that the other 90% of the world uses Ctrl+F and F3, it's not
just "not intuitive", it's downright perverse. And let me guess, it's
also undocumented -- at least, anywhere you would likely stumble upon
without having already successfully performed a search?

In practice I don't find that that happens, except with typos, in
which case one tries again.

If you search for a common word, you get a trillion hits. If you
search for a rare word or a phrase, you get zero to a handful. The one
is simply useless; it's either a slightly faster or a slightly slower
page down, depending. The other requires you to know a fair amount
about the target already, likely only if you've already been there.

If you get the
mousing slightly wrong you end up near where you wanted to go and it's
easy to nudge it the rest of the way where it should go. The GUI way,
you miss your exit and take the next and circle back and get there a
bit later. The unix way, you miss your exit and the next exit is
somewhere between Omaha, Nebraska and fucking Timbuktu, or even a
great-circle all the way around to back where you started from. :P

That's not my experience.

Well that's the difference between being able to navigate visually and
having to guess at search queries to get anywhere quickly.

Quite. I guess the point I was trying to make is that reference
documentation has its place, and some GUI programs don't seem
to provide it at all, focusing instead on doling out information
in little dumbed-down snippets. Not that those snippets aren't
sometimes exactly what one wants. It's just that sometimes
they're not, and if that's all that's available, it's annoying.

What's needed is reference documentation and tutorial documentation,
both, and neither of them dumbed-down OR over-complicated relative to
the inherent complexity (however small or great that value is) of the
problem domain. As for the implementation details for a particular
tool, they should be of interest only to hackers changing/debugging
the tool or scripting/automating it somehow, and also available, at
least in the source part of the distribution.

Probably this marks me as terminally pack-rattish, or otherwise
weird, but I'm apt to accumulate version after version of those
configuration files, accumulating them in one location with names
that show the order in which they were created/saved. So the
problems you describe don't really arise.

Only in the specific case of someone doing the sort of thing you
describe. Requiring careful record-keeping and cataloguing by the
whole user-base strikes me as foolish and needlessly user-hostile.

And if configuration edits are rare, this is nearly moot, but if they
are common, then finding anything in that back-catalogue will be like
finding a needle in a haystack. Unless you have an automated search
tool that's AI-complete, anyway.

Huh? If I want to find an old copy of my .vimrc file .... Even
if I didn't remember my scheme for saving things, searching for files
with names containing "vimrc" seems like a fairly logical thing to
try, and is easy enough ....

That finds you the 350 files. Now which of them has the information
you're looking for? Even if you look at the timestamps -- was that
edit you want to recreate made in December of 1995, or was it 1996? It
*was* just before Christmas, that much you recall...

Over 20 of the files meet these criteria. Now what? Examine each one
by hand? And if none particularly jogs your memory?

Storing vast amounts of data is overrated, unless you have a way to
find a particular piece later, quickly and certainly.

And, of course, once you DID, by some miracle, find it,
what you DON'T have is a diff between the two versions showing exactly
what you'd changed.

What, the system doesn't have a diff command? though I like vimdiff
better for most things now.

Well you could MAKE a diff -- if you found BOTH versions that are
involved ... your search job just doubled in size, complexity, and
effort required. Congratulations!

I think you're onto something here. (And your use of the word
"micromanage" -- you're onto something there, and if in fact you
wanted to say "control freak", that wouldn't be out of line!)

Hrm. It seems to appeal to a certain personality type too, though not
the pragmatist that just wants to get sat down before the keyboard and
get things done by suppertime, and who certainly finds no room in
their schedule to cram in an extra seven-week training seminar or two.

Unix (command-line): Getting to the files is a chore, and a long
arcane command must be typed to rename a file once there. However,
this command can be generalized or a script file easily used to rename
the whole lot in one shot.

You do know about filename completion, right? so getting to
the files is not, IMO, more of a chore than it would be in a GUI,
except that there are fewer visual cues.

It's worse than "fewer visual cues"; if you have the file you want in
front of your eyes on a GUI, unless you do something dumb, like close
the window, it will remain within easy reach. In any commandline
environment, one wrong move and you start all over; although you can
keep the path part around by cd'ing to the file's immediate parent
directory. With the GUI, in other words, you only need to "find" the
file *once* and then make sure a window is kept open to a position in
which the file is visible. With a command line, you need to "find" it
for each occasion where its name is needed, plus any time you mistype
anything, etc.; so even if the "find" bit is no harder, instead of
"find" once, "specify" many, you need to "find and specify" whenever
you want to "specify". This may mean doing the "find" bit, say, ten
times instead of once, depending.

Even window managers these days aren't what they once were, but
are apt to be run in conjunction with a "desktop environment"
such as GNOME or KDE. I'm not sure I completely understand the
distinctions myself. But the idea of having separate mix-and-match
pieces is very Unix-y.

The window manager presumably provides the basic GUI API for
applications. The desktop environment provides a graphical shell for
the user, so they aren't staring at a blank screen with the GUI API
available but no way for the user to start something that'll invoke
it. (Well, short of getting back to a command-line shell prompt and
launching something from there, anyway.)

With Windows, one application (Explorer) provides the shell and a file
manager; there's a GDI.exe buried somewhere in the system that
performs the "window manager" function to provide access by other
applications, including Explorer.

So two of the three things are still technically separate with
Windows.

There's a lesson here. Perhaps that we need a kind of visual or
gestural language capable of the rich semantics of a scripting
language.

Yes! One of the problems I perceive with people accustomed to
GUIs is that they don't even imagine the possibilities of the
kind of automation possible with the old tools.

And yet the old tools can't even do something fairly simple and not
needing automation without wizardry involved. The automation of course
also requires developing a small program, in effect, and generally
with drastic consequences to getting it wrong. (Windows apps often
have a search-and-replace which can likewise have drastic
consequences, but at least there's an Undo command available -- though
some boneheaded app designs treat each replace done automatically as a
separately undoable action! Morons.)

It's something
I do my best to show my students .... Perhaps one of them will
come up with something along the lines of what you describe.

Or I will...

To find something in alphabetical/whatever order, given the absence of
a (known) way to automate the search, but a way to scroll decently
rapidly through the document.

I still can't imagine this actually being useful in practice. It's
more or less how one looks something up in a (paper) phone book or
dictionary, but if one can search instead, what's the point ....

Exactly. It's just that all too often crummy help tools provide "none
of the above" as options. The subject matter isn't organized in a way
amenable to manual searching, plus there's no way to navigate more
than a page at a time, plus there may be no way (or at least, no self-
evident way) to navigate more than a *line* at a time, plus there
almost certainly is no self-evident way to search, and of course you
may not yet know the best query terms to find whatever it is you're
looking for anyway. Which leaves reading the whole damn document cover-
to-cover.

Ouch.

Consider it shorthand for "you can actually see what the hell you're
doing and where the hell you are, and what tools are sitting on the
workbench in front of you" then. :)

Except, of course, that some of the tools are collected in boxes
with labels (some text, some icons) that might or might not allow
you to guess which box a particular tool is in.

At least you can see the damn boxes and read the labels, and remember
what's where; bumping into them in the dark is going to be largely
accidental, by contrast.

Does the ":P" mean you know you're exaggerating for effect?

Yes, but it's still basically true.

But you claimed you could learn something useful and transfer the
knowledge to another application. That's impossible if they don't both
adhere to *some* standard, but rather each does everything in a
totally idiosyncratic way. There isn't even a real standard for
*documentation* over there in nixland; there's man pages (with a
crufty, nigh-unusable browser tool required to read them, as they're
binary -- at least, they were on the system I am recalling), plain
text, and even .ps and .html; even using the latter is nontrivial if
you haven't got a working GUI and a copy of Firefox installed yet, and
I purely *hate* messing with postscript in any way, shape, or form,
mainly because the format was designed for transport between a
computer and a printer, not for storage/online viewing (the huge size
and total lack of compression -- they're highly repetitive ASCII text
inside, if you ever looked -- is another symptom of this, as the
designers expected this stuff to be short-lived as it rushed along a
100MBit parallel cable to a printer, rather than to sit around on a
disk drive taking up space, or even get downloaded over a paltry
5-10MBit cable or DSL connection from the Internet or, worse, dial-up
(eek!)).

.

Quantcast