9fans - fans of the OS Plan 9 from Bell Labs
 help / color / mirror / Atom feed
From: W B Hacker <wbh@conducive.org>
To: Fans of the OS Plan 9 from Bell Labs <9fans@cse.psu.edu>
Subject: Re: [9fans] what a surprise
Date: Sun,  6 May 2007 05:13:35 +0800	[thread overview]
Message-ID: <463CF37F.5050808@conducive.org> (raw)
In-Reply-To: <8a9c0087a8daf8bbf071cec82a340899@proxima.alt.za>

lucio@proxima.alt.za wrote:
>>> - the more familiar with *any other* CLI environment, (possible exception of 
>>> Oberon/Aos) the *more difficult* it is to adapt to acme/rio.
>> i doubt this is the case.  it wasn't for me.
> 
> Not even as bad as getting used to VI. There lies a benchmark, if
> there was one.

ACK,

Best fixed with replacement of /bin/vi with the binary of an editor.

Any editor. Even those that lisp...

;-)


 >  And the fact that VI can become second nature is

I think the legal profession calls those 'repeat offenders', psychologists 
'masochists'.

:-)

> enough to persuade me that icon-lovers will simply never know what
> they are missing on the other side of the fence.
>

..'alternative lifestyle' for that one...

I don't really care one way or the other about 'icons', and I do see the merits 
of some of the initially off-putting anomalies - IF one cares to stay around 
long enough, read and listen - to find out the 'why' of them.

But by no means all of them make equal sense, even after research...

It would be 'nice', for example, to have a screen that defaulted to scrolling UP 
as it filled instead of printing off the bottom of the view window....

Or a slider-bar on the same side of the window as the mouse and cursor manip 
keys *commonly* sit.

Or an (optional?) CLi history buffer.

And even a hardware TTY is smarter than to run its paper bass ackwards, hiding 
what I haven't yet read while preserving what I have already read....

..have yet to grok the 'why' of that one...

Mind - not because these things are right, wrong, sideways, or mandated by the 
Gods somehow.

But because, like flush toilets, most folks *expect* them to act a certain way.

Hard to get onboard with a different - possibly better - way of working if the 
first thing the new environment does is confuse a person with contrarian responses.

Shouldn't be rocket science to provide a less hostile tolset, if only for 
transition.

Yet it seems to not have been done, lo thjese many years.

And the 'why' of THAT is even harder to grok...

> But the real crux lies in measurement and no one has yet suggested
> what it is that ought to be measured here,

Presence of waste motion. or NOT.

Excessive mental/physical 'context switching' in wetware. or NOT.

 >  nevermind how to measure
> it.

'Therbligs' applied to swapping mouse-kbd-mouse, hands for starters.

The 'mental side is harder... possibly a suite of diverse tasks to key-up - 
timed tasks exercising a wide range of input techniques.

But these would need to be such as can be done with *potentially* the same total 
key / click / drag count in either the Plan9 way AND various 'other' ways, not a 
test of 'plumbing' vs ifconfig _ /etc/<??> edits, NFS / SMBFS mounts & such.

Those measure the OS architecture and toolset, not the 'hmi'.

And, sorry - they are not really 'married' to each other.
If they were, shell scripts would not exist.

> If we could set down some criteria against which one rates a user
> interface (I seriously doubt that popularity should be such a
> criterion),

Not sure. 'Popular' designs got that way by being generally learnable/acceptable 
to a great many 'casual' users, not 'coz the 'pro' particulalrly cared for them. 
And at least part of that relates to manual dexterity or lack thereof.

Really 'focused' users very often prefer methods that the general public 
consider weird, 'coz there is a payoff  - center-mounted accelerator pedals on 
race cars for either-foot heeel-and-to control, for example.

And acme/rio have some of that sort of flavor - for coders anyway.

> at least we'd have the option of a meaningful discussion.
> But I suspect that we are all voicing subjective opinions on some very
> personal idea of "comfort".
> 
> ++L
> 

Doubt that part would *ever* change - regardless of testing. Habits die hard.
After all - people are still buying cigarettes. And worse.

While it could *be* tested, (Google 'therblig' and 'Industrial Engineering'), 
there is probably no gain in going there.

It isn't that hard to 'go thou and do *otherwise*'.

Love acme/rio and use it as-is or simple replace or re-code it to something you 
like better.

Personalization is one of the neater things about software...

Bill


  reply	other threads:[~2007-05-05 21:13 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-05-04 19:17 ron minnich
2007-05-04 19:32 ` erik quanstrom
2007-05-04 19:32 ` Paul Lalonde
2007-05-04 19:43   ` lucio
2007-05-04 19:58     ` Russ Cox
2007-05-04 20:07       ` lucio
2007-05-05  2:37       ` Kris Maglione
2007-05-04 22:47   ` Steve Simon
2007-05-05  3:06     ` W B Hacker
2007-05-05  5:08       ` Bruce Ellis
2007-05-05 19:08       ` erik quanstrom
2007-05-05 19:19         ` lucio
2007-05-05 21:13           ` W B Hacker [this message]
2007-05-06 20:10 ` Roman Shaposhnik
2007-05-06 20:28   ` Federico Benavento

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=463CF37F.5050808@conducive.org \
    --to=wbh@conducive.org \
    --cc=9fans@cse.psu.edu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).