Re: web inherits UNIX console?

[David Young <dyoung%pobox.com@localhost>]

On Fri, Sep 16, 2011 at 09:58:11PM -0400, Mouse wrote:
> > #1: the new web environment, unlike a CLI, is a *direct manipulation*
> >     interface.
> 
> 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.

> For exmaple, you appear to want to replace
> pipelines with massaging a section of the display with multiple
> commands.

Actually, no: I have deliberately glossed over implementation issues.
I fully intend for the implementation to be a pipeline, and for the
pipeline to be recorded in a script, and for that script to have an
inobtrusive on-screen representation with a one-to-one correspondence
with a simple shell script.

> This is fine, until one of those commands produces a half-gig of data
> which the next command distils down into something usably small.

Maybe this is what you want to manipulate that you cannot display?

This reminds me that several years ago I was doing something on a
UNIX terminal while a friend who was not a UNIX user watched over my
shoulder.  After he watched me type one command after another without
pause, seeing that each command produced copious amounts of scrolling
text, he made up his mind that I was performing Rain Man-like feats of
visual interpretation, and he asked me, "Whoa, Dave, how do you READ
all of that?"  The answer is, I didn't read all of that: either the
text of interest was all at the bottom of the scrollage, or else I was
performing the keyboard equivalent of scratching my head[2].

Anyway, today there are several ways for the system to cope, and to help
the user cope, with copious program output.  One of the traditional
UNIX ways is to cancel or pause the output or the program: when I am
overwhelmed by output, oftentimes I strike Control-C/Control-S/Control-Z
to get it under control.  Pagination with less(1)/more(1) is another
way.  If I anticipate a lot of program output, sometimes I pipe the
output into less(1).  Of course, less(1) doesn't read the entirety of
its input before showing you page one, but it lazily evaluates its
input.

I think that in the new environment, we should rely on lazy evaluation
to avoid boundless computation and on pagination to protect the user
from overwhelming output.  Multiple pages of output should form a stack
with page one on top.  At least as much output should be immediately
evaluated to fill page one, and the rest according to available system
resources, with priority placed on interactive performance.

> I also don't see how your proposal would handle backgrounded commands.

I don't think that command evaluation and input evaluation should be
synchronous.  That is, I don't think that while the computer evaluates
a command, it should be impossible to insert & delete text, or to
evaluate a second command.  To put it another way, every command is a
background command.  I consider it an open question how to represent
a command whose evaluation has not completed, yet---maybe it is a
beachball (haha!) or a read-only selection of the input---but I think
that whatever the representation is, you should be able to move it
around in your document, and you should be able to backspace over it,
thus erasing the output and cancelling the command.

I see it as a huge advantage that for every background command's output,
there is a particular character position reserved in the document
flow.  Because while I/O redirection is a splendid thing, it is rather
tedious to attend to when it's not directly related to your goal.  And
of course, if you don't carefully redirect the output of a background
process, it spews irritatingly into your terminal session.[1]

> > So you see that I do not propose to replicate the traditional
> > command-line conversation[12] in a browser window, but I propose to
> > reinvent the UNIX interaction style while sticking with UNIX
> > principles.
> 
> Actually, it seems to me you would be losing two of the most important
> and successful of those principles: "one job per program" and "run the
> user's preferred tool for $JOB" ($EDITOR is a simple example of this;
> $PATH is a more elaborate one).

I have two responses to this:

1) My proposal adheres more strictly to both of the UNIX principles
you mention than any system claiming today to be UNIX.

2) Other principles apply.

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.  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.  A modern
$SHELL is a stripped-down $EDITOR with keys such as Enter overloaded.
$PAGER is a stripped-down $EDITOR, too.  A web browser contains two or
three editors, at least.

Editing is fundamental: you have to do it in all kinds of programs,
and in many creative computer activities, you're spending most of
your time operating an editor of some kind.  Embedding editors
with different powers and key bindings throughout the system leads
to complexity, inconsistency, and user frustration.  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.  Lots of user-interface problems shake
out when you do that: for example, you can eradicate the dreadful
scrollbars-within-scrollbars(-within-scrollbars) plague if there is just
one editor viewport and one set of viewport-motion commands.

Regarding (2), additional human-factors principles apply[3].  By
replicating an editor's functions all over the place, you create
inconsistencies and you introduce zillions of operating modes.  Instead
of acting automatically, a user constantly has to evaluate his goal
against the system state in order to do a simple thing like "replace
the word at the beginning of the line with 'ls'."  If you eliminate the
duplication, you eliminate the modes; eliminating the modes makes the
system easier to operate.

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

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

> > 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.  The car does not have a
gasoline engine & transmission any longer, it has an electric motor.
That means that you cannot switch to synthetic oil or replace the spark
plugs.

> (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. :-)

I think that the interface of an automobile is good for almost everyone.
I think that it is a little bit worse for everyone than the interface we
can imagine.  For some people it is very, very bad.

> > You can use the new interface to build sophisticated functions from
> > simple functions, and the power and interactivity of composite
> > functions is greater than in traditional UNIX.
> 
> 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. :-) I am pretty sure that I have a foot on your side of the line!

If you want to write a script, write a script.  Select and evaluate it
or, if you want to, give it a name to refer to it by and evaluate with
the name-this-script command.

If you have stacked a bunch of filters over some text, and you want to
apply the stack[4] to some other text, move the stack to the second
text.  If you want to make the stack a script, select it and evaluate
with the name-this-script command.

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

Dave

[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.  I understand what's going on under
    the hood that makes this an easy and consistent design choice for
    a shell's author to make.  It just seems to me that this design
    ignores usability precepts such as the one saying that the user
    should control the pace of interaction.

[2] I have found out that I have lots of ways of scratching my head.
    One way is to type some command, like 'ls', clear the screen right
    afterward by typing Ctrl-L, and repeat.  I don't know if it helps to
    jog my memory better than scratching my head or rubbing my chin, but
    letting someone watch me do it is an excellent way to cultivate an
    image that is, ummm, eccentric.

[3] There are many similarities between the principles in the UNIX
    philosophy as described by _The Art of Unix Programming_ and
    principles of good interaction design.

[4] When I talk about a stack I have a particular picture in mind that
    it is hard to describe, but I will try.  Every filter applied
    to a text should have a handle or a tab that sticks out from
    the boundary of the text either all of the time or when a hot
    key is held down---a design decision is necessary.  Take away
    the menu bar, scroll bars, and bottom bar from the picture at
    <http://www.ecademix.com/JohannesHofmann/flimp.html>: you are left
    with a set of tabs whose function and appearance are closest to the
    picture that I would draw you.

-- 
David Young             OJC Technologies is now Pixo
dyoung%pixotech.com@localhost     Urbana, IL   (217) 344-0444 x24