monotone-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Monotone-devel] Re: user-friendly hash formats, redux


From: Nathaniel Smith
Subject: Re: [Monotone-devel] Re: user-friendly hash formats, redux
Date: Thu, 9 Dec 2004 14:45:43 -0800
User-agent: Mutt/1.5.6+20040907i

On Thu, Dec 09, 2004 at 04:42:24PM -0500, graydon hoare wrote:
> well, I said earlier that I've "been resisting" this, and I meant it. we
> talked about it, njs implemented a little prototype demonstrating it,
> and I decided I really didn't like it. I really do resist the idea that
> a non-numeric quasi-random number is any friendlier than a numeric one.
> it's more rememberable, yes. but it's also *weirder*.

That makes sense.  Just to state what the other side of the argument
is... it's not exactly about memorability, per se.  The fact is, we
have brains that work in a certain way -- they're really good at some
things, not so good at others, the process information in quirky ways.
Humans have weird interfaces.  But we can't change that, so instead
we have whole fields like "HCI" and "usability" that are all about
trying to figure out these interfaces and make computers fit them
better.

So the thing is, humans have special hardware for dealing with
auditory information.  There are studies showing that the number of
digits you can remember at once has very little to do with how many
digits there are, but how long it takes you to pronounce them -- it
turns out that in order to deal with strings of digits in our short
term memory (when I say short-term memory, think the brain's version
of registers), we generally have to do a format conversion, to some
sort of verbal code, and basically repeat the numbers to ourselves
over and over.  While hex is a very compact encoding visually, it's
actually really poor verbally.  Phonetic ambiguity also matters here
-- the whole "read ids over the phone" thing is a real example, I
guess, but eh, it's kind of a lame one.  But you don't have to read
things out over the phone for phonetic ambiguity to be important -- I
regularly look at a hash on the screen, move my eyes down 10 lines to
the prompt, and try to type in the first few letters... and even
though it's only been 0.5 seconds since I looked at the hash, I do
things like type "f" instead of "5", because they sound similar.

There are other short-term memory processes that aren't auditory
based; some of these are more based on being able to keep track of,
oh, say, 4-5 discrete things at once.  The interesting thing about
these is that there's this phenomenon called "chunking", where it's
just as easy to hold onto n big chunks of information as n little
chunks of information -- so 2 words might be as easy to store, and
provide as little interference with all the _other_ things you're
trying to do while programming, as 2 digits, because we're good at
thinking of words as single units.

And, FWIW, I actually recognize the bubblebabble encodings of the ssh
keys of several hosts I deal with, which really shocked me, since
I only see them once, briefly, every few months at most -- it's an
absolutely terrible condition for memorization -- and I have never had
the _slightest_ idea whether the random strings of number it used to
spit out at me are any good :-).  So, basically, bubblebabble has made
my computing is more secure, with no effort whatsoever on my part.
Part of the deal here seems to be that we're highly trained to read
language -- you can't _not_ read letters put in front of you.  So even
if you're just glancing at ids, you'll be far more likely to recognize
them later if they were pronounceable.  Hex my eyes just refuse to
look at unless I force them to.  So having pronounceable strings means
you get this automatic, effortless effect of being more likely to
recognize things later.

This automatic pre-conscious processing is useful in other places
too -- if someone mentions an id on IRC, and I want to find it on my
monotone-viz graph, it takes his horrible, effortful search, where I
systematically have to focus on each node and check to see if it's the
same as what they said.  Scanning a list for something pronounceable
is miles and miles easier, and it makes things more efficient on a
second-to-second level throughout the day.

Okay, so that's the long rant :-).  Basically comes down to, boring
is good, but aggravation and inefficiency is bad, and that's why I
haven't just thrown out the whole idea.  Now, the caveat, obviously,
is that I'm just making stuff up here; it sounds plausible, thinking
about cognitive processing is my day job, but: software engineering is
about trade-offs, and your points aren't crazy.  Which is why I had
that silly idea of actually running tests on people... that way we'd
actually have some idea of how real this effect I'm arguing for is,
and how strong, and something to better base a decision on.

Perhaps I should take my half-finished experimental thingie and stick
it in a repo somewhere, since there seem to be other people interested
in whether this is a good idea or not who might want to help finish
it?

-- Nathaniel

-- 
So let us espouse a less contested notion of truth and falsehood, even
if it is philosophically debatable (if we listen to philosophers, we
must debate everything, and there would be no end to the discussion).
  -- Serendipities, Umberto Eco




reply via email to

[Prev in Thread] Current Thread [Next in Thread]