Re: web inherits UNIX console?

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

On Fri, Sep 30, 2011 at 12:22:49AM -0400, Mouse 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.

Ok, that's what I thought you meant.

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

One editor plus your preferred key bindings plus command evaluation plus
type-through filters equals any specialized editor that you could name,
AND a consistent user interface.

Another way to think about this is that the one editor contains only the
editor universalities, and not the specialties.

> > 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've seen It's All Text.  Interesting hack, but it doesn't get us where
we need to go.  I count at least three editors in Firefox.  It's All
Text replaces only one, it adds a lot of extraneous work (activate It's
All Text, possibly rearrange windows, locate the text you want to edit
again) and it removes the editing task from its context by switching you
to a different window.

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

Avoiding modes is important.  That's why Emacs is not the solution.

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

You think that if emacs was less modal, it would necessarily be less
powerful?

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

Three documents.  You and the people in the same channel are editing
a record of a conversation together.  Some type-through filter
intermediates.

I don't know how many times I have wished for the same search, paging,
selection, editing, copy and paste commands in ircii or iChat as I'm
used to in $EDITOR!

> - A MUD session

I used a MUD for a little circia 1993.  I don't remember drastic
differences from a command line or a chat session.

> - My music player

I don't know what you use.  I use iTunes: rows and rows of songs.  In
columns: song name, album, performer, duration, genre, track number.
Looks like a document to me.  One or more sorts and filters apply.
There's some "dressing up" of the columns (rows alternate colors,
columns line up).

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

I think that you're taking "document" to mean a finished product (an
album, a technical report, an email) instead of something that is
possibly a record of a work in progress.

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

I don't think I understand what you're getting at.  You seem to think
that I have incorporated, whole, all of the pieces that were mentioned
up-thread and called it something different than what it is.

Anyway, I think that photo editing, etc., would fit nicely into
the framework of key (and mouse) bindings, command evaluation, and
type-through filters.

> >> (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.
*snip snip*
> 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
*snip snip*

Sounds to me like you are badly informed.  I will not hop into the
"let's reject human factors" rabbit hole with you.

Dave

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