Re: web inherits UNIX console?

[Michal Suchanek <hramrach%centrum.cz@localhost>]

On 29 September 2011 23:56, David Young <dyoung%pobox.com@localhost> wrote:
> 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.

I would disagree with that. It suffers from the same issue as the
QWERTY keyboard. It is traditional, developed without much thought for
the design, probably mirroring a physical layout of one of the first
automobiles which was built that way because of construction
considerations, not operation consideration.

Sure, it has been smoothed out a bit but it is generally the same in
all cars for the same reason most devices that have an alfanumeric
Latin keyboard use the QWERTY layout. It is well established and many
people already know how to operate it and even if other designs would
provide improvement in the long run face adoption costs that are just
too high. Further the car has much fewer controls so there are not
*that* many possible layouts and redesigning it would possibly not
bring as much benefit as redesigning the keyboard does.

Of course, any redesign of anything (eg. the user interaction with a
computer) will face much of the same issues.

However, due to the inconsistency of the multitudes of user interfaces
present on an average user's system you are more likely to convince a
user to use one more than in the case of cars or keyboards which are
already unified.

Thanks

Michal