Re: web inherits UNIX console?

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

On Tue, Oct 04, 2011 at 11:05:34PM -0400, Mouse wrote:
> > You think that if emacs was less modal, it would necessarily be less
> > powerful?
> 
> Yes.
>
> Sounds to me as though you want modes, too, though you call them things
> like task-specific key bindings.

I don't think that I said task-specific key bindings.  I certainly did
not mean it.  Key bindings should not constantly be in flux.

> >> - 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.
> 
> To me, "document-centered" does not equal "can be viewed as a document
> if you squint your mind right".  IRC, to me, is communication-centered,
> not document-centered - that is, the central idea, the main focus, is
> not creation of a document of any kind, but communication with peers.

Rather than split hairs over terminology, I want to take a step back,
and look again at the chat user interface: it's producing a written
record of the conversation that may be short and ephemeral, or else
it may be saved to a file.  You're inserting & deleting text in order
to contribute your part of the conversation.  Meanwhile your peers
are editing & deleting text.  Typically you can roll the conversation
record up and down.  You may be able to search the record.  Virtually
all of the objects and actions in this interaction are the same as
in an interaction with any other text document.  Since it looks like
a document, and it acts like one, creating a separate UI for it is a
needless complication.

> >>> 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.
> 
> Here's what I'm getting at.  Consider:
> 
> > 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.
> 
> My point is that your "one editor" has to subsume text editing, xfig
> editing, bitmap editing, sound editing, MIDI editing, schematic
> editing, PCB editing, etc.  I don't think that's possible even in
> principle, with specialized file formats, er, document types, calling
> for specialized editors, being developed constantly.  (I've built at
> least two games which include their own specialized editors.)

I think that graphics editing will be challenging to implement, but
I don't see any problem in principle.  There are standard ways to
represent graphics content, and there are standard ways for user input
or software to indicate different objects or regions in a graphic for
commands to act on.

> >>> [...] just rejected at least 50 years' human-factors research and
> >>> industrial design experience.
> >> 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.
> > Sounds to me like you are badly informed.
> 
> Do you have a moment to correct that?  What should I read to correct
> this misinformation, to find human-factors studies focusing on, or at
> least paying attention to, usability by subject experts?

Sure.  Airline pilots are subject experts, and many human-factors
engineers are concerned with the design of aircraft controls.  Some
academic human-factors departments, including the one down the street,
<http://humanfactors.illinois.edu/research/focus.aspx>, seem to be
concerned almost exclusively with aviation.

If you have time to read only one very short book, I have just read
_Don't Make Me Think_ by Steve Krug, which is designed to be read
on a cross-country flight, and it I would say that it is so-so.  It
contains some valuable information, but it is mainly concerned with
current web convention, and it doesn't go deep into topics.  _The Design
of Everyday Things_ (Donald Norman) is illuminating.  _The Humane
Interface_ (Jef Raskin) contains a lot of applicable principles as well
as Raskin's unusual vision.

Dave

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