Re: web inherits UNIX console?

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

On 30 September 2011 06:22, Mouse <mouse%rodents-montreal.org@localhost> wrote:
>>> 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;

These is slip.

This could be actually quite elegant solution to the problem which
ties many systems to the teletype emulation.

On one side many systems lack graphics hardware. On the other, the
teletype emulation that works without graphics hardware cannot display
anything but text. No real alternative exists, terminals that can
display graphics also require graphics to run.

If the terminal output was exported through something that can work
with both text-only and graphics (html+js proposed in this case) you
can view the terminal either locally degraded to text only or on a
morecapable machine with graphics included.

Thanks

Michal