FW: UI thoughts

[Chris Pressey]

On Wed, 5 Mar 2003 09:15:16 +0100 
"Vlad Dumitrescu (EAW)" <Vlad.Dumitrescu@REDACTED> wrote:

> Hi,
> 
> I will take the liberty to resend to the list the mail that Jay sent me,
> because I think it will be an interesting reading. I hope it's okay with
> you, Jay.
> 
> best regards,
> Vlad
> 
> -----Original Message-----
> From: Jay Nelson [mailto:jay@REDACTED]
> [...]

Hmmm... this is very interesting, but I don't want to be misunderstood
(well not in a bad way anyway...)

> Chris said a textbox cannot live independent of a password box,
> but classification systems are slippery slopes.  As soon as you
> choose one item to classify on (think Euclidean geometry) you
> have eliminated a whole realm of possibilities that are not only
> improbable, but impossible once you start (a great arc is a shorter
> distance than a straight line -- on a globe).
> 
> Both a text box and a password box are visual displays of
> an internal text string.  In one case the user needs feedback
> as he types, but no display; in the other he wants both feedback
> and display.  The processes that accept keystrokes, filter for
> validity, and store to the internal text string are separate because
> they may be recombined to create other chains of events.  The
> fact that the two screen representations are similar is of no
> consequence other than predictability on the part of the user.

(and ease on the part of the programmer - & both are good things)

> What is important is the task and the feedback.  A password
> box could just be a single block that changes color with each
> keypress and uses three different beeps -- one for characters
> and two for accept or reject.

I think my point was - once you have a textbox (behaviour or object or
widget or control or scomblonker or whatever you want to call the
classification/boundary that you've arbitrarily decided should surround
the activity of accumulating keystrokes into a bit of text) - you should
only need to make a small change to turn that into a passwordbox, since
they needn't differ in anything but the most marginal way.

If you're thinking in terms of objects, then it's not unreasonable to
think of the passwordbox being a subclass (specialization) of the textbox
(although it's also not unreasonable to think of it the other way around
too)

If you're thinking in terms of processes, then it's not unreasonable to
think of the passwordbox delegating to a textbox.  But when that's the
only function of the textbox - to be the 'back end' of a passwordbox -
then it seems like a bit of a waste, especially if the passwordbox has to
duplicate the textbox functionality anyway (like display area etc.)

>  > One process per real-world activity - the textbox underlying
>  > a passwordbox isn't *really*a discrete real-world activity
> 
> This is the atomic argument (as in physics) versus the quark
> argument.  Do you model physical real-world things, or the
> elements that combine to create different kinds of reality?
> Either is valid, they are just different views but they lead to
> drastically different explanations of the seemingly same
> external behavior.
> 
> jay

Yes... but there is a point of diminishing returns.  If you're simulating
an ideal gas it seems like a waste to simulate it down to the quark level,
when billiard balls will give you a result within 0.1%.  I mean, the
logical extension of the quark argument as it applies to GUIs would appear
to be that the best way to build a GUI in Erlang would be to *not* build a
GUI, thus allowing all programmers *full* control over the HCI without
introducing preconceived notions of 'widgets' that, despite how useful
they may be, could be deemed inflexible and stifling to creativity...

So - I don't see a problem looking at GUI elements as widgets, as long as
you can admit that those widgets are composed of sets of behaviours, and
that you can make those behaviours somehow 'rewirable' at a fine level of
detail - e.g. a textbox consists of a focusable area, visible text
display, a cursor, and sensitivity to keypresses.  To make a readonly
textbox, you'd take a textbox and remove the sensitivity to keypresses; to
make it into a passwordbox, you'd replace the visible text display with
visible *** display; etc.  To make a novel widget you'd combine a variety
of behaviours, possibly traditionally associated with a variety of
different widgets.

I still think that Erlang, in its honourable effort to subvert OO-mania,
is in danger of developing OO-phobia - but that is a more general subject
than GUI's and I'll try to address it in a future thread.

-Chris