Re: web inherits UNIX console?

[Mouse <mouse%Rodents-Montreal.ORG@localhost>]

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

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

Otherwise, you either have uneditable files or you lose the "one
editor" commonality you make so much of.

>>> [...] 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?

> I will not hop into the "let's reject human factors" rabbit hole with
> you.

I'm not asking you to, at least I don't think so.

However, I draw a strong distinction between human factors in the
aggregate and human factors in the individual.  I'm particularly
acutely aware of the distinction because I've tried to use supposedly
good (based on doubtlessly well-done research) interfaces and been
driven nuts by them and their (un)usability - to me.

When the human factors studies try to tell me I'm wrong in what I find
usable and unusable, I think a certain degree of rejection of their
edicts, and interfaces based on them, is not unreasonable.  And that's
been my experience: when I try to use a new interface and find it
getting in my way, on the (relatively rare) occasions when I've been
able to get feedback from the designers, responses like "that's what
studies have indicated enhances usability" figure prominently in the
excuses they offer for the "features" that get in my way.

I'm perfectly willing to believe that the kind of interface you sketch
_is_ good, for some people, perhaps even some synthetic "average"
person.  Based on what I've read, I would expect it to be horrible.
For me.

That's why I want configurability, and why I am unimpressed by
appeal-to-authority arguments citing usability studies.

However, this is all speculating in...well, maybe not a _vacuum_, but
at least thin air, until at least a skeletal implementation exists.

/~\ The ASCII                             Mouse
\ / Ribbon Campaign
 X  Against HTML                mouse%rodents-montreal.org@localhost
/ \ Email!           7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B