Re: web inherits UNIX console?

[Mouse <mouse%Rodents-Montreal.ORG@localhost>]

>> This reinvents some of the worst problems of GUI interfaces:
>> specifically, unscriptability and the inability to manipulate things
>> that cannot be displayed.
> Something that I can manipulate that I cannot display---is that a
> riddle? :-)  Seriously, I'm not sure I understand what you mean.

Anything that does not have a useful display form.  A compiled
executable and a multi-gigabyte file of pretty-much-anything are the
first two examples that come to mind.

Traditional Unix does not display such things without sokme kind of
explicit comkmand to do so; it displays references to them - most
often, names of files they are stored in.

> Regarding (1), the UNIX principles: you don't actually get to use
> your preferred tool, and lots of tools are less specialized than they
> may appear.  $EDITOR is a great example of this.  The essential
> $EDITOR functions (move cursor & viewport, insert & delete text) are
> replicated all over the system.

They are.  But rather than have a half-dozen editors, a few of which
you can replace and most of which are specialized to be especially good
at editing for a particular purpose, you propose to replace them all
with one editor which you can't replace at all and which, since it is
necessarily one-size-fits-all, is at best mediocre for most tasks.

> Everything from the shell to the web browser to your preferred
> $EDITOR embed one or more editors that are not $EDITOR, and usually
> you cannot replace those editors with $EDITOR.

This is one reason firefox drove me nuts (at work, that being the only
time I use GUI Web crap) until I discovered It's All Text, which _does_
let you use $EDITOR.  (So far it hasn't been worth it to me to hack
anything of the sort into lynx, that being what I use on the few
occasions I want to Web at non-work.  I certainly could if I cared to
bother.)

I'm not sure what I think of the shell issue.  One of my points in this
thread has been (and is) that no single editor is suited to all editing
tasks - my shell _is_ my preferred editor, for its tasks.

> $PAGER is a stripped-down $EDITOR, too.

You could look at it that way.  And, if you wanted to and your editor
supported it, there's no reason you couldn't set $PAGER to run $EDITOR
with the appropriate options to tune it for those tasks.

> A web browser contains two or three editors, at least.

This is a reason to fix (or not use) web browsers, not a reason to
repeat the mistake.

> Embedding editors with different powers and key bindings throughout
> the system leads to complexity, inconsistency, and user frustration.

When done wrong.  When done right, it leads to smooth integration,
similarities where they're useful and difference where _they_'re
useful.  Take, for example, the editor I use for composing email and
the editor I use for command lines.  In each case, a number of commands
perform close-to-identical functions (printing characters self-insert;
^B, ^F, ^K, ^A, etc, all work similarly).  Other characters perform
related but distinctly different functions (^P, for example).  Others
exist in one but not the other (for example, ESC-v does not do anything
in the shell and ESC-{ does not do anything when composing mail).  A
few exist in each but with dramatically different functionality
(RETURN and ^X come to mind).

> You can side-step all of that if you turn the programs inside-out:
> the editor is never embedded, but it is the shell inside which every
> other interaction occurs.

It's a potentially interesting idea.  Some people use GNU Emacs in much
that way; it's perhaps relevant to note that it's a fairly heavily
moded editor (in the sense of major modes and minor modes and such, for
editing email, editing programs, using shells, debugging, etc); this is
related to my "one size can't fit all" point.  (On a mud I co-run, one
person has a connection message something like "Emacs is a nice OS, but
it lacks a good text editor.  That's why I use vim.")

As I remarked upthread, it's quite possibly an experiment worth doing.
Perhaps the benefits would outweigh the problems I anticipate, at least
for some users.  Perhaps I'm wrong in anticipating them at all.  But I
think that, at the sort of experimental stage it's at now and
inevitably will be for quite a while to come, it has no business in
NetBSD per se.

> If you eliminate the duplication [of editor functionality], you
> eliminate the modes; eliminating the modes makes the system easier to
> operate.

Superficially easier to operate.  But less powerful.  As I remarked
above, I think it is significant that GNU Emacs, one of the most
tunable editors in existence, is heavily into modes that depend on the
task: experts are willing to track what they're doing and use different
gestures depending on the task for the sake of the task-specific power
doing so brings.

So am I.  I don't use GNU Emacs, but the "general-purpose" text editor
I do use is similar in this regard, and the special-purpose editors I
use (like my shell's) are also tuned to their tasks.  My shell and my
text editor are my own, in that I have the source to them and I
maintain my own fork of each, to the point where there is no meaningful
"upstream"; if I wanted to, I could hook the one up to the other.

> I think that there are very few important differences between editors
> that cannot be captured by key bindings and a rich set of commands.

Perhaps you're right.  Give it a try.

>>> The new interaction is more direct and document-centered.
>> Which is - or at least may be - fine, if you're doing something
>> document-centred.  It pretty much sucks for everything else.
> What is everything else?  It seems to me that most creative work on
> the computer---the work that a graphic designer, novelist, scientist,
> engineer, mathematician, or computer programmer does---is concerned
> with creating and manipulating documents.

Looking at my screen just now, I see

- Three IRC sessions
- A MUD session
- This email composition
- My music player
- Shell windows
-- One checking the progress of some background daemons on another
    machine
-- One updating the local copies of some stuff fetched by a cronjob on
    another machine
-- Two more doing miscellaneous short commands
-- Various others on various other machines, for when I want to do
    things on those machines

It seems to me that only the email composition is even vaguely
document-centered.  The "miscellanous short commands" would fit your
model, but there would be no semantic value to the resulting
"document", so I have trouble calling it "document-centered".

>>> It rolls into one web app the functions of an editor, a command
>>> shell, a terminal multiplexer, and a terminal.
>> Indeed.  But it does so at the same prices exacted by every other
>> "roll a bunch of stuff into one": it is difficult-to-impossible to
>> replace individual pieces, and it does a mediocre job at most-to-all
>> of those tasks, for some substantial fraction of the user base.
> This concern sounds rather abstract.  Maybe you can be more specific?

> The individual pieces are not replaceable because they are
> unnecessary, so they no longer appear in the system.

Rather, they appear integrated into your all-singing-all-dancing front
end.  Would you integrate xfig, so you could edit xfig "document"s?
bitmap (though I'd prefer my own bme - there's that replacability point
again) for editing bitmap images?  Gimp (or Photoshop - more
replacability) for full-colour images?  Some kind of sound editor for
sound samples?  GarageBand for MIDI files?  The list is effectively
endless.

>> (The latter is unavoidable because it is not possible for the same
>> interface to be good for everyone.)
> It seems that if I take your statement quite literally, you have just
> rejected at least 50 years' human-factors research and industrial
> design experience.  I'm not sure what kind of discussion can follow
> that. :-)

Take it how you like.  Most of that research - all that I've seen, at
least - has not been looking at good interfaces for individual experts;
it's been been looking at how best to accommodate most people, almost
all novices (explicitly all novices, sometimes) without being too
horrible for any of them.  Not how to be good, but how to be tolerable,
if you will.  It is no accident that the interfaces experts use, when
they have the choice, are not only heavily customizable but heavily
customized.  It is no accident that GNU Emacs, perhaps the single most
expert-popular text editor, has been described as "_all_ hooks": it is
damn near _nothing but_ customizations.

Human-factors research doesn't look at that.  It looks at what's good
for _non_-experts to use, what is most usable _without_ needing
adaptation of the user and the interfaec to one another (we call these
"training" for one direction and "customziation" for the other).
Industrial design is mostly about interfaces which in a computer
program would be ludicrously uncustomizable (because, in
industrial-plant human interfaces, such customization is ridiculously
expensive; it's cheaper to train the humans, or hire humans who can
deal with the interface, than to adapt the interface to the individual
user).

The tradeoffs are very different for computers.  Your design may indeed
be a good one for novices (I have my doubts about even that, but they
strike me as the most likely to be well-suited to it).  I predict it
will be intolerable for most experts; it certainly would be for me.

> I think that the interface of an automobile is good for almost
> everyone.

Given the cost of customizing it to individual users, it's probably
about as good as is practical.  For a computer, with far more protean
potential than steel and plastics - and far lower cost to actually use
that potential - the tradeoffs are all different.

>> The flip side of interactivity is unscriptability - another
>> deviation from a very important piece of Unix philosophy.
> Sometimes it sounds to me a little like you have drawn a line and
> said to yourself, on this side of the line are UNIX and I, on the
> other side are interactivity and GUIs and whatever it is that David
> is talking about. :-)

Sometimes it seems that way to me too, mostly when I reread what I've
written.  Part of this, I think, is because I'm focusing on the
problems I see in what you describe; there certainly are aspects of it
that sound attractive and/or interesting.  Part of it, I think, is
because I know how protean computer interfaces are; I've build many
(both the general-purpose text editor and the shell I mention above
have human interfaces I've written, or at least heavily modified, and
I've built numerous special-purpose interfaces, mostly in the form of
individual programs' user interfaces).  Knowing this, I refuse to
accept a mediocre fit between me and interfaces; I know how good I can
make them and I refuse to accept anything not at least that good.  Part
of it may be that I am, very roughly, as far off the mean in what I
find enhances a user interface as I am in many other respects; I tend
to laugh at people who cite usability studies and such, because "works
well for most people" means, in my experience, a better-than-half
chance it will actually get in my way rather than help me.  See my blah
post of 2009-10-25
(http://ftp.rodents-montreal.org/mouse/blah/2009-10-25-1.html); about
the second quarter of that is apropos here.

I recently tried to use a mostly vanilla Linux install.  It was
_amazing_ the number of times I ran into something that, if I didn't
know perfectly well it had been designed with no knowledge I even
existed, I'd swear had been designed to trip me up or pointedly
irritate me, or in some other way make the experience unpleasant and/or
unproductive.  And these were interfaces designed by, and at least
mostly for, geeks.  I've tried to use designed-for-the-mainstream
interfaces too, every once in a long while, and they are even more
impedimental to my getting things done (though, irontically, they
irritate me less, because they don't give me the feeling of having been
led down the garden path only to run into a brick wall; they don't even
pretend to be expert-useful).

> I am pretty sure that I have a foot on your side of the line!

Maybe.  But I'm having trouble seeing it.  I don't know whether that's
because you don't, or because I'm blind to it, or because I'm phrasing
what I see unhelpfully, or because I'm just too severe an outlier and
thus "my side of the line" is not where you think it is, or what.

> So, what do you think, do we have more or less common ground than you
> thought previously? :-)

I don't know.

I'd have to see a detailed design document, or try it out, to have
anything much more concrete to say than what I have.

I predict you will wind up with something novice-friendly and
expert-hostile, at best.

This is one case where I'd be delighted to be wrong: if I'm wrong, not
only will I learn something about a case where my expectations were
erroneous and thus have a better mental model of the world, I will
possibly have a better UI to use, and I will certainly have a new
mental model of HCIs to inform my use of, thoughts about, and designs
of user interfaces in the future.

I still don't think it belongs in NetBSD until it's gone through at
least three or four versions - maybe not even then, depending on what
it turns into.

> [1] BTW, one of my peeves with most shells is that if a foreground
>     command is taking longer than I expect to finish, while I *can*
>     type ahead (no thanks to the shell) while I wait, I have no use
>     of the shell's command completion.

This isn't really a peeve with the shell, but with the paradigm it's
embedded in.  When you type ahead, nobody, sometimes not even you and
almost never any piece of software, knows whether what you type will
be read by the shell, by the program you're running, or by some other
program yet to be started.  (Even when software does have that
knowledge, there is no way for it to be expressed.)

I've been surprised by that myself, in both directions - typing ahead
thinking it'll go to the program only to have it die unexpectedly and
have the shell read my input, and typing commands ahead only to have
some other program read them.

Also, traditional Unix blurs the distinction between "shell" and "other
program".  If I run "sh", am I then typing to "my shell", "the shell",
an "other program", or what?  I can think of cojntexts in which each of
those is a defensible answer.  (My usual shell is csh-family, not
sh-family; it is fairly different from what sh gives me.)

I'm not sure this is fixable without giving up serial-line use.  So far
I haven't been willing to do that and I don't think NetBSD *can* do it
without overtly dropping at least a handful of ports;

It's certainly something which could lead to interesting experiments.
I encourage the experiments.  I discourage doing them in the main
NetBSD tree.

/~\ The ASCII                             Mouse
\ / Ribbon Campaign
 X  Against HTML                mouse%rodents-montreal.org@localhost
/ \ Email!           7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B