I've been working with TCL/tk and I'm struck at how messy graphical
languages are. Before anybody jumps on TCL/tk, or starts advertising
their solution I don't think that it is *that* language that is
specifically to blame. I'm seeing the same thing in Visual Basic and
in CLIM and indeed in every GUIL I've looked at.
I was explaining to my friend Willi what I was experiencing - a
profound sense of intellectual dissatisfaction. The problem is that
there is a real contrast here between the economy and elegance of
functional programming and what I am experiencing here. In
functional programming there is an important idea - Turing equivalence
- which is well defined and can be captured in a remarkably small set
of primitives. FP allows to combine these primitives into complex
functions by means of a small but powerful set of combinations. So
the elements in the 'right thing' are:
FPLs
1. A well defined theory of Turing equivalence
2. A small number of primitives and
3. A powerful means of combination
When you come to GUILs the position is reversed. You have this vaguer
idea of computational adequacy which means that the GUIL can do the
things you want. But the primitives are nowhere in sight
and what you are given is a grab-bag of tools for making buttons and
various widgets. Since the user's wish list is indefinitely large,
GUILs become bloated and you end with 1000 page manuals of commands,
hacks and hooks of every descripton. Reminiscent of PL/1 actually.
So what you have is 'the wrong thing'.
GUILs
1. A vague idea of computational adequacy.
2. A huge number of primitives.
3. A weak means of combining together.
Now I sat down and wondered why that was. Was the field inherently
just a big intellectual hack, or have human beings made a mess of it.
I decided that was probably more that human beings made a mess of it
and that there was a much more elegant approach. We had to begin with
a formal theory of widgets and by asking dumb-sounding but actually
deeply serious questions like 'What is a window'?
Now without weighing you down with my projected solution, when I began
to think about it, I realised that my ideas required command of the
low level substrate of my computer and that a lot of work was involved
here because the low level primitives I envisaged would have to
execute very quickly. I also realised I probably would not have the
time to do this work. And I think that this is not only a shame but
indicative of a problem with FP in general. Its not so much that the
FP paradigm is weak and incapable of doing the task, it is that as
functional programmers we're very much boxed in by the decisions of
the people who designed the environment within which our work is
embedded. It's very very difficult to do the right thing when
everything around you is doing the wrong thing.
Mark
Mark Tarver <··········@ukonline.co.uk> writes:
> When you come to GUILs the position is reversed. You have this vaguer
> idea of computational adequacy which means that the GUIL can do the
> things you want. But the primitives are nowhere in sight
> and what you are given is a grab-bag of tools for making buttons and
> various widgets. Since the user's wish list is indefinitely large,
> GUILs become bloated and you end with 1000 page manuals of commands,
> hacks and hooks of every descripton. Reminiscent of PL/1 actually.
> So what you have is 'the wrong thing'.
>
> GUILs
> 1. A vague idea of computational adequacy.
> 2. A huge number of primitives.
> 3. A weak means of combining together.
>
> Now I sat down and wondered why that was. Was the field inherently
> just a big intellectual hack, or have human beings made a mess of it.
> I decided that was probably more that human beings made a mess of it
> and that there was a much more elegant approach. We had to begin with
> a formal theory of widgets and by asking dumb-sounding but actually
> deeply serious questions like 'What is a window'?
You might be interested in Brad Myers's take on this and related
issues:
http://www.cs.cmu.edu/~amulet/papers/futureofhciACM.pdf
For what it's worth, I've talked with a number of people who work in
the area of model-based user interface generation, which has to
address the issues you raise, and I think there's general agreement
that some of the subtleties in the ways that users want to interact
with GUIs are too difficult to capture, in practice, with existing
formalisms. That is, conceptually, GUIs are models of the real world,
and we still don't have languages that make it easy to model arbitrary
objects (and agents), relationships, and processes at the "right"
level of abstraction.
From: Robert Maas, see http://tinyurl.com/uh3t
Subject: Re: on the strange weakness of Graphical User Interface Languages
Date:
Message-ID: <rem-2007oct18-001@yahoo.com>
> From: ·······@ncsu.edu (Rob St. Amant)
> conceptually, GUIs are models of the real world, and we still
> don't have languages that make it easy to model arbitrary objects
> (and agents), relationships, and processes at the "right" level of
> abstraction.
It seems to me that Java's GUI package (either one, AWT or swing)
partly does it right:
- There are container objects which hold other GUI objects.
- There are controls that fit in containers.
- There are toplevel objects that define region of the scree (which
may be foreground, or partly hidden), and which are containers
themselves.
- Each object can execute code locally, including painting its
visual presentation, as well as send and receive messages.
- Local execution includes things that happen whenever the object
needs to be redrawn, things that happen when various kinds of
messages arrive, and things that run continuously in
backgraound, and things that happen directly as a result of a
local GUI event.
- The code that is executed, in any of those modes/circumstances,
has the full power of Java available, hence is Turing complete.
- For the most part, the "messages" above are actually method
calls, per various registries of "listeners" for various kinds of
events, but this is just a implementation detail which doesn't
affect the abstract model.
Now that doesn't seem too complicated an abstract model, does it?
The various specific kinds of GUI objects such as groups of radio
buttons and sliders and menus etc. are simply library functions
following the above model. You can write brand-new GUI objects any
time you want. The stadard GUI objects provided by Sun shouldn't be
considered "more right" than those you write yourself or get from a
third party, except of course that Sun has a pretty good standard
of quality so you might trust their GUI objects sooner than you'd
trust Crazy Eddie Widgits or Robert Soloway Wormies-Are-Fun-For-Us.
What am I missing here? Enlighten me!
(I have never had access to any Common Lisp in GUI environment,
except Macintosh Allegro Common Lisp 1.2.2, so I can't comment on
any standard CL GUI module such as CLIM or whatever they're using
these days. All I know about high-level GUI programming, except
MACL, are HyperCard/HyperTalk, VB, and Java.)
·······@yahoo.com (Robert Maas, see http://tinyurl.com/uh3t) writes:
>> From: ·······@ncsu.edu (Rob St. Amant)
>> conceptually, GUIs are models of the real world, and we still
>> don't have languages that make it easy to model arbitrary objects
>> (and agents), relationships, and processes at the "right" level of
>> abstraction.
>
> It seems to me that Java's GUI package (either one, AWT or swing)
> partly does it right:
> - There are container objects which hold other GUI objects.
> - There are controls that fit in containers.
> - There are toplevel objects that define region of the scree (which
> may be foreground, or partly hidden), and which are containers
> themselves.
> - Each object can execute code locally, including painting its
> visual presentation, as well as send and receive messages.
> - Local execution includes things that happen whenever the object
> needs to be redrawn, things that happen when various kinds of
> messages arrive, and things that run continuously in
> backgraound, and things that happen directly as a result of a
> local GUI event.
> - The code that is executed, in any of those modes/circumstances,
> has the full power of Java available, hence is Turing complete.
> - For the most part, the "messages" above are actually method
> calls, per various registries of "listeners" for various kinds of
> events, but this is just a implementation detail which doesn't
> affect the abstract model.
>
> Now that doesn't seem too complicated an abstract model, does it?
> The various specific kinds of GUI objects such as groups of radio
> buttons and sliders and menus etc. are simply library functions
> following the above model. You can write brand-new GUI objects any
> time you want. The stadard GUI objects provided by Sun shouldn't be
> considered "more right" than those you write yourself or get from a
> third party, except of course that Sun has a pretty good standard
> of quality so you might trust their GUI objects sooner than you'd
> trust Crazy Eddie Widgits or Robert Soloway Wormies-Are-Fun-For-Us.
> What am I missing here? Enlighten me!
Those are good observations and a good question at the end; what I
wrote was a bit vague and flippant. I don't have a good answer in
general, but I'll ramble a bit on some examples that might be
interesting:
1. Say you're building an interface that allows users to configure
some piece of hardware; you have a potentially large set of loosely
couple parameters that the user will examine and possibly change.
They fit onto a single 1024 by 768 screen, fortunately, so you design
a window to hold the text boxes, spin boxes, pop-up menus, and so
forth. It works fine. Now your customer tells you, "We'd like to do
the same thing on a mobile device, either a cell phone or maybe a
Palm." The abstract problem hasn't changed, but a great deal of the
work you've put into the implementation needs to be revised: the
container relationships between the widgets and the top-level window
need to be broken up into a finer grain to fit on multiple screens,
with ordering considered; long menus may become too inefficient; text
input may have to be reconsidered. The port may not be feasible at
all. This isn't entirely a problem with interface toolkits, but my
point is that this isn't an easy problem to solve in general because
of the distance between the abstract decision problem and the software
implementation.
2. Say you're building a drawing application; you want to allow users
to draw freehand, rotate and align their results, and so forth,
something along the lines of the original MacDraw. A few years ago
some of my students built such an application for a medium-sized
two-handed table-top device with touch input. It turns out that you
can do quite a bit if you take cues from how people work in a physical
environment, and little of it depends on the interface conventions
developed for standard drawing applications: no palettes of types of
shapes to draw, no orientation and alignment menus, etc. I won't
claim that the application is better than existing ones for drawing
(it's not--it's much less comprehensive), but it does rely on a
completely different set of primitives. I've got a couple of old,
low-quality videos halfway down on my home page:
http://www.csc.ncsu.edu/faculty/stamant/
Again, this isn't necessarily an issue of the limitations of interface
toolkits, but I think it may illustrate [sic] the idea that much of
the work that goes into designing an interface for a given set of
tasks is based on familiar conventions. The resulting design isn't
"necessary"; it just represents one point the design space, with other
very different points being reasonable alternatives.
From: Ken Tilton
Subject: Re: on the strange weakness of Graphical User Interface Languages
Date:
Message-ID: <5rMPi.79$8E5.45@newsfe12.lga>
Mark Tarver wrote:
> I've been working with TCL/tk and I'm struck at how messy graphical
> languages are. Before anybody jumps on TCL/tk, or starts advertising
> their solution I don't think that it is *that* language that is
> specifically to blame. I'm seeing the same thing in Visual Basic and
> in CLIM and indeed in every GUIL I've looked at.
>
> I was explaining to my friend Willi what I was experiencing - a
> profound sense of intellectual dissatisfaction. The problem is that
> there is a real contrast here between the economy and elegance of
> functional programming and what I am experiencing here. In
> functional programming there is an important idea - Turing equivalence
> - which is well defined and can be captured in a remarkably small set
> of primitives. FP allows to combine these primitives into complex
> functions by means of a small but powerful set of combinations. So
> the elements in the 'right thing' are:
>
> FPLs
>
> 1. A well defined theory of Turing equivalence
> 2. A small number of primitives and
> 3. A powerful means of combination
>
> When you come to GUILs the position is reversed. You have this vaguer
> idea of computational adequacy which means that the GUIL can do the
> things you want. But the primitives are nowhere in sight
> and what you are given is a grab-bag of tools for making buttons and
> various widgets. Since the user's wish list is indefinitely large,
> GUILs become bloated and you end with 1000 page manuals of commands,
> hacks and hooks of every descripton. Reminiscent of PL/1 actually.
> So what you have is 'the wrong thing'.
>
> GUILs
> 1. A vague idea of computational adequacy.
> 2. A huge number of primitives.
> 3. A weak means of combining together.
>
> Now I sat down and wondered why that was. Was the field inherently
> just a big intellectual hack, or have human beings made a mess of it.
> I decided that was probably more that human beings made a mess of it
> and that there was a much more elegant approach. We had to begin with
> a formal theory of widgets and by asking dumb-sounding but actually
> deeply serious questions like 'What is a window'?
>
> Now without weighing you down with my projected solution, when I began
> to think about it, I realised that my ideas required command of the
> low level substrate of my computer and that a lot of work was involved
> here because the low level primitives I envisaged would have to
> execute very quickly. I also realised I probably would not have the
> time to do this work. And I think that this is not only a shame but
> indicative of a problem with FP in general. Its not so much that the
> FP paradigm is weak and incapable of doing the task, it is that as
> functional programmers we're very much boxed in by the decisions of
> the people who designed the environment within which our work is
> embedded. It's very very difficult to do the right thing when
> everything around you is doing the wrong thing.
>
> Mark
>
<sigh>: http://www.tilton-technology.com/cello-shot-05.jpg
> FPLs
>
> 1. A well defined theory of Turing equivalence
I'll leave that to you smart people. All my theorys are about meeting
girls. Or does this count: declarative and functional. As in Cells.
> 2. A small number of primitives and
Two classes, Image and Control. Combine with Family and... can you say
"Lego"? Sher ya can.
> 3. A powerful means of combination
Dataflow? As in... oh, what's the use?
You have nothing to fear but cellsophobia itself.
kenny
--
http://www.theoryyalgebra.com/
"Mother always told me, if you tell a lie,
always rehearse it. If it don't sound good
to you, it won't sound good to no one else."
- Satchel Paige
I'm slightly confused after reading that. Is the problem that graphical
toolkits are clumsy to work with in general? Or that making good, usable
interfaces isn't as easy as it could be.
If it's the former, have you looked at all at functional reactive
programming? A lot of work has been done in Haskell on it, but there are
other areas it's been looked at (I think there was a Scheme FRP library,
and the Flapjax JavaScript library incorporates ideas from FRP).
Conal Elliott is also doing work that looks interesting on "tangible values"
in GUI programming. The idea, from what I can see, is that you have values
that, at the same time, correspond to GUI elements, but can be operated on
applicatively by functions.
Of course, no FRP toolkit has made it very far out of research phases, to my
knowledge (Flapjax might be the closest, but even it's probably stuck at MS
research), and Conal's stuff isn't finished yet. So as of today, you're
probably stuck with more traditional GUI frameworks if you want to build a
working Haskell GUI application.
If the latter problem above is the real issue, I'm not sure a solution is
even possible. (Some) Big GUI projects spend lots of time/money doing
studies and tweaking their interface designs in various ways that make them
more usable. I don't foresee anything in the near future coming along and
automatically generating an optimally usable interface for some underlying
model. But, I suspect that's not the end you're worried about currently.
-- Dan
From: Ken Tilton
Subject: Re: on the strange weakness of Graphical User Interface Languages
Date:
Message-ID: <aJMPi.83$8E5.8@newsfe12.lga>
Mark Tarver wrote:
> I've been working with TCL/tk and I'm struck at how messy graphical
> languages are. Before anybody jumps on TCL/tk...
Actually, I was going to defend it. Nowhere in your treatise do you
define and/or justify the charge of messy. Tk has a dozen or so widgets,
the same attributes for all of them where appropriate, the same
semantics for those, and even automatic dataflow to support the
dependencies one finds between GUI components (this thing should reflect
the position of the slider, eg).
But it is fine if you want to define "messy" and then apply to Tk or my
living space, but until you do the discussion will be meaningless with a
600lb undefined term sitting in the middle of it. Of course why bother?
Here you ban any challenge to your premise...
>..., or starts advertising
> their solution I don't think that it is *that* language that is
> specifically to blame. I'm seeing the same thing in Visual Basic and
> in CLIM and indeed in every GUIL I've looked at.
Fine, you have now declared that all GUILs are messy and that in
principle no GUIL can be non-messy, this a priori determination being
the only justification you might have for not wanting to hear about any
you might have missed.
Meanwhile users of Cello and Cells-Gtk and Adobe Adam/Eve and some
FrTime thingy are having a ball with GUIs while you will be moderating
this closed-minded thread. Just peachy.
So when are you announcing.... QUIL?
:)
kt
>
> I was explaining to my friend Willi what I was experiencing - a
> profound sense of intellectual dissatisfaction. The problem is that
> there is a real contrast here between the economy and elegance of
> functional programming and what I am experiencing here. In
> functional programming there is an important idea - Turing equivalence
> - which is well defined and can be captured in a remarkably small set
> of primitives. FP allows to combine these primitives into complex
> functions by means of a small but powerful set of combinations. So
> the elements in the 'right thing' are:
>
> FPLs
>
> 1. A well defined theory of Turing equivalence
> 2. A small number of primitives and
> 3. A powerful means of combination
>
> When you come to GUILs the position is reversed. You have this vaguer
> idea of computational adequacy which means that the GUIL can do the
> things you want. But the primitives are nowhere in sight
> and what you are given is a grab-bag of tools for making buttons and
> various widgets. Since the user's wish list is indefinitely large,
> GUILs become bloated and you end with 1000 page manuals of commands,
> hacks and hooks of every descripton. Reminiscent of PL/1 actually.
> So what you have is 'the wrong thing'.
>
> GUILs
> 1. A vague idea of computational adequacy.
> 2. A huge number of primitives.
> 3. A weak means of combining together.
>
> Now I sat down and wondered why that was. Was the field inherently
> just a big intellectual hack, or have human beings made a mess of it.
> I decided that was probably more that human beings made a mess of it
> and that there was a much more elegant approach. We had to begin with
> a formal theory of widgets and by asking dumb-sounding but actually
> deeply serious questions like 'What is a window'?
>
> Now without weighing you down with my projected solution, when I began
> to think about it, I realised that my ideas required command of the
> low level substrate of my computer and that a lot of work was involved
> here because the low level primitives I envisaged would have to
> execute very quickly. I also realised I probably would not have the
> time to do this work. And I think that this is not only a shame but
> indicative of a problem with FP in general. Its not so much that the
> FP paradigm is weak and incapable of doing the task, it is that as
> functional programmers we're very much boxed in by the decisions of
> the people who designed the environment within which our work is
> embedded. It's very very difficult to do the right thing when
> everything around you is doing the wrong thing.
>
> Mark
>
--
http://www.theoryyalgebra.com/
"Mother always told me, if you tell a lie,
always rehearse it. If it don't sound good
to you, it won't sound good to no one else."
- Satchel Paige
In a one-sentence Nutshell, I think the problems with most GUIs
reflect the endless search for the "Do what I meant command."
From: Ken Tilton
Subject: Re: on the strange weakness of Graphical User Interface Languages
Date:
Message-ID: <nyOPi.109$8E5.8@newsfe12.lga>
CDon wrote:
> In a one-sentence Nutshell, I think the problems with most GUIs
> reflect the endless search for the "Do what I meant command."
>
The Unbearable DWIMness of Dataflow-enabled GUI authoring (thx to
whoever mentioned Flapjax, the latest/closest thing I have seen to the
package no longer dares to speak its name) is precisely what has its
practitioners turning backflips while building GUI circles around the
rest of you yobbos with one hand tied behind their back, which is why
this thread has been deprecated as hopelessy uninformed and out of date.
Maybe the moral of the story should be the same problem No Silver Bullet
has, and the same problem anyone has who says COBOL or C++ or Java or
Python has won: who says we're through? Stop whining (or celebrating)
and get back to work.
kt
--
http://www.theoryyalgebra.com/
"Mother always told me, if you tell a lie,
always rehearse it. If it don't sound good
to you, it won't sound good to no one else."
- Satchel Paige
> Nowhere in your treatise do you define and/or justify the charge of messy.
Messy for the reasons I gave. In Lisp, I used to introduce students
by showing them CAR, CDR, CONS and a few other functions and showing
how Turing equivalence could be gained in an instruction set of about
half-a-dozen functions - everything else that was thrown in, I told
them, was often about convenience and speed.
In contrast my 802 page *partial* spec of TCL/tk includes a wealth of
detail without any guiding idea of what would correspond to the vital
primitive instruction set. Because of this, and because I have no
idea what the primitives are in that system that constitute a
computationally adequate set, there are certain questions I cannot
answer with confidence.
For example, could I produce a window with bevelled edges in TCL/tk -
or a triangular window or .... fill in your outlandish request. Well
maybe, but I'd have to check it out. In contrast if I'm asked to
write a prime number program in Lisp I don't have to think 'Does Lisp
have a prime number recognisor?'. I know I can do it because prime
recognition is effectively computable and Lisp incorporates a Turing-
equivalent set of functions. I can't say the same in TCL/tk because
the theory is not there.
Have a good set of primitives in a well-defined theory not only allows
you to approach programming tasks with confidence, it also allows
system programmer to develop tight, reliable and efficient
implementations because they can focus on hard-coding these primitives
to run efficiently. Applications people can then develop libraries
for standard apps.
> < http://www.tilton-technology.com/cello-shot-05.jpg
People show me stuff. GUIL designers like to show off with 'Look Ma,
no hands examples' - examples that pander to the preprogrammed
functionality thats incorporated into the system. It doesn't do much
for me. Nice picture of your hand though.
> Fine, you have now declared that all GUILs are messy and that in
> principle no GUIL can be non-messy,
No, I asserted the contrary w.r.t. the last part. I think that GUILs
can be made elegant but stuff needs refiguring. Its not trivial.
> Meanwhile users of Cello and Cells-Gtk and Adobe Adam/Eve and some
> FrTime thingy are having a ball with GUIs while you will be moderating
> this closed-minded thread. Just peachy.
>So when are you announcing.... QUIL?
Well Qi/tk first ran in *2002* and I used it to produce a moving
histogram to plot traffic for a multi-agent model of a transport
system. You can read about the model here and it was all type secure
back then.
http://www.lambdassociates.org/webbook/chap17.htm
http://www.lambdassociates.org/webbook/chap1.htm
section 1.8 mentions this work.
When I got over the thrill of being able to write 'Hello World' in 3
inch high yellow letters in type secure code, I put it away. I had
more important things to figure on - for example, correctness proofs
for Qi (no point having a system that produces wrong answers). I
resurrected Qi/tk recently and cleaned it up and its coming out in
installments on qilang (I'm nearly there). Its slow because I fell
ill in 2005 and have many things to do (my book 'Functional
Programming in Qi' comes out next year), but also because I find the
whole field of GUILs intellectually depressing. The fun is not there.
To put it in perspective you can divide things in life according to
two criteria (a) elegant and (b) useful; that gives 4 categories.
1. Elegant and useful - functional programming, types, sequent
calculus, logic programming and a whole lot of other stuff.
2. Elegant and not useful - I'd probably classify program synthesis
using Martin-Lof type theory in this category. very elegant but not
much practical use. However, maybe one day it'll get to category 1.
3. Inelegant and useful - lots of things here - GUILs, brushing your
teeth etc.
4. Inelegant and useless - the worst, voting for any major party in
the UK ;(, filling out assessment forms, and a mass of meaningless
stuff.
I've spoilt myself disgustingly in category 1, dabbled happily in
wasted hours in 2. with resolution theorem-provers and synthesising
programs that add 2 and 2 together in 3 seconds ;). But what I find
is that when I go into category 3. the fun does go. And 4. is
unspeakably awful although many people seem to live in that country.
so I guess I'm hooked on beauty and GUILs ain't it.
Mark
From: Ken Tilton
Subject: Re: on the strange weakness of Graphical User Interface Languages
Date:
Message-ID: <WyQPi.101$ow2.26@newsfe12.lga>
Mark Tarver wrote:
>>Nowhere in your treatise do you define and/or justify the charge of messy.
>
>
> Messy for the reasons I gave.
Ah, I see it now, sorry, I am too much of an applications guy, I look at
a big GUI manual and worry about whether it offers enough hookns that I
can make things even bigger and hairier. You are looking for that seven
functions thing to make a Lisp or whatever the angels on the head of a
pin crowd likes to go on about.
Fine, your definition of messy is locked in. We proceed.
> In Lisp, I used to introduce students
> by showing them CAR, CDR, CONS and a few other functions and showing
> how Turing equivalence could be gained in an instruction set of about
> half-a-dozen functions - everything else that was thrown in, I told
> them, was often about convenience and speed.
>
> In contrast my 802 page *partial* spec of TCL/tk includes a wealth of
> detail without any guiding idea of what would correspond to the vital
> primitive instruction set. Because of this, and because I have no
> idea what the primitives are in that system that constitute a
> computationally adequate set, there are certain questions I cannot
> answer with confidence.
You wouldn't happen to be working on a type-inferencing static thingy
would you? <g> It's the root of all evil! I digress. We proceed.
>
> For example, could I produce a window with bevelled edges in TCL/tk -
> or a triangular window or .... fill in your outlandish request. Well
> maybe, but I'd have to check it out. In contrast if I'm asked to
> write a prime number program in Lisp I don't have to think 'Does Lisp
> have a prime number recognisor?'. I know I can do it because prime
> recognition is effectively computable and Lisp incorporates a Turing-
> equivalent set of functions. I can't say the same in TCL/tk because
> the theory is not there.
>
> Have a good set of primitives in a well-defined theory not only allows
> you to approach programming tasks with confidence, it also allows
> system programmer to develop tight, reliable and efficient
> implementations because they can focus on hard-coding these primitives
> to run efficiently. Applications people can then develop libraries
> for standard apps.
>
>
>>< http://www.tilton-technology.com/cello-shot-05.jpg
>
>
> People show me stuff. GUIL designers like to show off with 'Look Ma,
> no hands examples' - examples that pander to the preprogrammed
> functionality thats incorporated into the system. It doesn't do much
> for me.
Then I am so fucking happy that that is not what I just showed you. Of
course you could not know I was not showing you that because you already
knew what I was showing you so you had to see that. Sure, I /told/ you
there were only two classes Image and Control, but when has the human
mind ever had a problem blocking out information inconsistent with what
it knows?
Cello makes all its own widgets out of Image and Control. Where those
are (OK, I confess) subclassed it is just syntactic sugar. Anyone who
does not like my Slider widget will look at the code and say, that
sucks, and build their own slider out of the same GUI control and image
primitives.
A good example (Why am I bothering?) of the sugar thing is my stack and
row gui container classes. They let you control spacing, frame,
surrounding margin, and alignment (say, for rows) of left right or
center. Individual children are free to specify their own relative
horizontal position, but not their vertical. Preprogrammed! you are
bellowing already, and again you guess wrong, but I understand how that
saves you from actually having to learn something new. In fact it turns
out the whole thing is just more sugar, leveraging the kid-slotting
capabilities of the Cells Family class, which is allowed to supply rules
for kids's slots (with an option to force the rule in or add it only if
the child has left the slot unbound). Uh, in this case it is supplying
rules for the x and y coordinates.
I guess the big problem then is what Qi will think of slots whose type
is "anything any rule any programmer wants to supply for any slot", and
I guess t is an unsatisfactory answer.
> Nice picture of your hand though.
You have a penchant for mistaken assumptions. No wonder you need static
typing. :)
>
>
>>Fine, you have now declared that all GUILs are messy and that in
>>principle no GUIL can be non-messy,
>
>
> No, I asserted the contrary w.r.t. the last part. I think that GUILs
> can be made elegant but stuff needs refiguring. Its not trivial.
Do what I did, start with OpenGL and the Glut. The former will let you
play with a rectangle of values, RGBA, ignore all the other stuff (what
is it, gluOrtho2D to duck the third dimension and perspective?) unless
you find the OpenGL model elegant. Small, no, but you might find it
elegant. Me, I am just a simple application programmer, I cannot
understand a word of it. But I sees lotsa math in there, that's elegant,
right?
The Glut will give you your GUI primitives: mouse buttons up and down,
key up and down, over to you. Freeglut or Openglut, pick yer poisson.
If you want to do text, cheat a little and use FreeType, or cheat a lot
and use FTGL, it will handle the xlate to OpenGL.
>
>
>>Meanwhile users of Cello and Cells-Gtk and Adobe Adam/Eve and some
>>FrTime thingy are having a ball with GUIs while you will be moderating
>>this closed-minded thread. Just peachy.
>
>
>>So when are you announcing.... QUIL?
>
>
> Well Qi/tk first ran in *2002* and I used it to produce a moving
> histogram to plot traffic for a multi-agent model of a transport
> system. You can read about the model here and it was all type secure
> back then.
>
> http://www.lambdassociates.org/webbook/chap17.htm
>
> http://www.lambdassociates.org/webbook/chap1.htm
> section 1.8 mentions this work.
>
> When I got over the thrill of being able to write 'Hello World' in 3
> inch high yellow letters in type secure code, I put it away. I had
> more important things to figure on - for example, correctness proofs
> for Qi (no point having a system that produces wrong answers). I
> resurrected Qi/tk recently and cleaned it up and its coming out in
> installments on qilang (I'm nearly there).
Cool, good luck with that,
> Its slow because I fell
> ill in 2005 and have many things to do (my book 'Functional
> Programming in Qi' comes out next year), but also because I find the
> whole field of GUILs intellectually depressing. The fun is not there.
Get the Togl widget. OpenGL made me young again, and OpenAL has its
moments. Yeah, this means sticking with Tk, but make the whole window
one Togl widget and have Glut on steroids.
>
> To put it in perspective you can divide things in life according to
> two criteria (a) elegant and (b) useful; that gives 4 categories.
>
> 1. Elegant and useful - functional programming, types, sequent
> calculus, logic programming and a whole lot of other stuff.
>
> 2. Elegant and not useful - I'd probably classify program synthesis
> using Martin-Lof type theory in this category. very elegant but not
> much practical use. However, maybe one day it'll get to category 1.
>
> 3. Inelegant and useful - lots of things here - GUILs, brushing your
> teeth etc.
>
> 4. Inelegant and useless - the worst, voting for any major party in
> the UK ;(, filling out assessment forms, and a mass of meaningless
> stuff.
>
> I've spoilt myself disgustingly in category 1, dabbled happily in
> wasted hours in 2. with resolution theorem-provers and synthesising
> programs that add 2 and 2 together in 3 seconds ;). But what I find
> is that when I go into category 3. the fun does go. And 4. is
> unspeakably awful although many people seem to live in that country.
>
> so I guess I'm hooked on beauty and GUILs ain't it.
Guess again: http://www.tilton-technology.com/cello-shot-06.jpg
kt (greatly looking forward to being complimented on my girlfriend)
--
http://www.theoryyalgebra.com/
"Mother always told me, if you tell a lie,
always rehearse it. If it don't sound good
to you, it won't sound good to no one else."
- Satchel Paige
On Oct 12, 4:12 pm, Ken Tilton <···········@optonline.net> wrote:
> ...
> Cello makes all its own widgets out of Image and Control. Where those
> are (OK, I confess) subclassed it is just syntactic sugar. Anyone who
> does not like my Slider widget will look at the code and say, that
> sucks, and build their own slider out of the same GUI control and image
> primitives.
> ...
Has anyone created Cello widgets with a native look & feel for XP/
Vista and/or Mac OSX ? Have you experienced much demand for that?
I've been developing web apps for years, so I'm out of touch with
current GUI demand, but when I developed Java GUI apps, the customers
didn't seem to be as excited as we were that the app ran on Windows,
Mac & *nix - they just wanted it too look good on their particular
platform.
From: Ken Tilton
Subject: Re: on the strange weakness of Graphical User Interface Languages
Date:
Message-ID: <qc8Qi.2530$5x4.1116@newsfe12.lga>
Brian Adkins wrote:
> On Oct 12, 4:12 pm, Ken Tilton <···········@optonline.net> wrote:
>
>>...
>>Cello makes all its own widgets out of Image and Control. Where those
>>are (OK, I confess) subclassed it is just syntactic sugar. Anyone who
>>does not like my Slider widget will look at the code and say, that
>>sucks, and build their own slider out of the same GUI control and image
>>primitives.
>>...
>
>
> Has anyone created Cello widgets with a native look & feel for XP/
> Vista and/or Mac OSX ? Have you experienced much demand for that?
>
> I've been developing web apps for years, so I'm out of touch with
> current GUI demand, but when I developed Java GUI apps, the customers
> didn't seem to be as excited as we were that the app ran on Windows,
> Mac & *nix - they just wanted it too look good on their particular
> platform.
>
>
I think for the native thang you want Celtk and the Tile package of Tk,
which tries harder on native look and feel. Gets good press, anyway.
Cello is for them's that have not much need for standard widgets and so
they really just get in the way -- I toyed with mixing Tk widgets with a
Togl OpenGL subpane or two and realized right away that it was not just
widgets I was mixing, I was now dealing with two frameworks
simultaneously. Ewww, as the kids say.
What one could do is use Celtk and then have a Togl pane for a killer
view-only purpose.
kt
--
http://www.theoryyalgebra.com/
"Mother always told me, if you tell a lie,
always rehearse it. If it don't sound good
to you, it won't sound good to no one else."
- Satchel Paige
> Ah, I see it now, sorry, I am too much of an applications guy, I look at
> a big GUI manual and worry about whether it offers enough hooks that I
> can make things even bigger and hairier.
That is indeed the opposite of what I look for. If that has driven
your development of Cello, then we're not in the same ball park at
all.
> Then I am so fucking happy that that is not what I just showed you. Of
> course you could not know I was not showing you that because you already
> knew what I was showing you so you had to see that. Sure, I /told/ you
> there were only two classes Image and Control, but when has the human
> mind ever had a problem blocking out information inconsistent with what
> it knows?
Well actually I saw the picture of a hand - which doesn't really tell
me much! The image and control sounds interesting, but is too
programmatic for anyone to respond to other than by saying 'sounds
interesting' without references.
> I guess the big problem then is what Qi will think of slots whose type
> is "anything any rule any programmer wants to supply for any slot", and
> I guess t is an unsatisfactory answer.
Well such a slot can be given the type A for some A which just means
that the type checker will know that something well-typed is in
there. The problem will be that in such a situation the type
constraints will be so weak that you won't be able to do much with
that rule in a type secure manner. I think in the individual case it
would be possible to be more forthcoming than that. Cells might
benefit from an injection of type theory in its constraint propagation
system. (Probably should not have said that ;))
> kt (greatly looking forward to being complimented on my girlfriend)
Now that is a screen shot ;). My compliments.
Mark
From: Ken Tilton
Subject: Re: on the strange weakness of Graphical User Interface Languages
Date:
Message-ID: <_aWPi.68$5Y5.65@newsfe12.lga>
Mark Tarver wrote:
>>Ah, I see it now, sorry, I am too much of an applications guy, I look at
>>a big GUI manual and worry about whether it offers enough hooks that I
>>can make things even bigger and hairier.
>
>
> That is indeed the opposite of what I look for. If that has driven
> your development of Cello,...
Lessee, you read what I look for in off-the-shelf GUIs which I cannot
change and thus might find myself unable to use in some way I need to
use and worry I would have the same attitude towards something I am
writing from scratch. Hmmm....
> then we're not in the same ball park at
> all.
Well I described my ballpark in enough detail for you to understand that
what I have instead is the legendary Seven Pillars of Primitiveness...
could someone tell me why I even bother trying? This makes my Freecell
obsession look reasonable.
>
>
>>Then I am so fucking happy that that is not what I just showed you. Of
>>course you could not know I was not showing you that because you already
>>knew what I was showing you so you had to see that. Sure, I /told/ you
>>there were only two classes Image and Control, but when has the human
>>mind ever had a problem blocking out information inconsistent with what
>>it knows?
>
>
> Well actually I saw the picture of a hand - which doesn't really tell
> me much!
Actually, I was wondering how you (mis)concluded from the screenshot
that you were looking at a classic preprogrammed widget set that did
exactly what it wanted and nothing more, now we learn it did not tell
you much. I detect progress!
> The image and control sounds interesting, but is too
> programmatic for anyone to respond to other than by saying 'sounds
> interesting' without references.
Here is a tip-off: I no longer have to write paint methods for custom
widgets, I build anything I like up out of (wait for it) graphical
primitives and a bit of a DSL to orchestrate them all, with scripts
appearing in the "layers" slot.
the neat thing is that this all evolved on its own. I started with
layers for just the background color and frame, boom!, out burst a DSL
that just took over the painting and pushed custom paint methods into
the sea.
And really there are no methods specialize on Image and Control, they
are authored with cells and then functions can handle any widget cuz...
well, it's like building CL out of seven functions or one or however
many angels are on the head of the pin.
>
>
>>I guess the big problem then is what Qi will think of slots whose type
>>is "anything any rule any programmer wants to supply for any slot", and
>>I guess t is an unsatisfactory answer.
>
>
> Well such a slot can be given the type A for some A which just means
> that the type checker will know that something well-typed is in
> there. The problem will be that in such a situation the type
> constraints will be so weak that you won't be able to do much with
> that rule in a type secure manner. I think in the individual case it
> would be possible to be more forthcoming than that. Cells might
> benefit from an injection of type theory in its constraint propagation
> system. (Probably should not have said that ;))
But different instances can have different rules for the same slot, and
in fact this is precisely why a big hairy GUI can be built from two
classes, Image and Control, so I think you are still stuck trying to
prove anything more than (typep everything t).
>
>
>>kt (greatly looking forward to being complimented on my girlfriend)
>
>
> Now that is a screen shot ;). My compliments.
Thx, I'll tell her you said that.
kt
--
http://www.theoryyalgebra.com/
"Mother always told me, if you tell a lie,
always rehearse it. If it don't sound good
to you, it won't sound good to no one else."
- Satchel Paige
On 13 Oct, 03:36, Ken Tilton <···········@optonline.net> wrote:
> Mark Tarver wrote:
> >>Ah, I see it now, sorry, I am too much of an applications guy, I look at
> >>a big GUI manual and worry about whether it offers enough hooks that I
> >>can make things even bigger and hairier.
>
> > That is indeed the opposite of what I look for. If that has driven
> > your development of Cello,...
>
> Lessee, you read what I look for in off-the-shelf GUIs which I cannot
> change and thus might find myself unable to use in some way I need to
> use and worry I would have the same attitude towards something I am
> writing from scratch. Hmmm....
>
> > then we're not in the same ball park at
> > all.
>
> Well I described my ballpark in enough detail for you to understand that
> what I have instead is the legendary Seven Pillars of Primitiveness...
> could someone tell me why I even bother trying? This makes my Freecell
> obsession look reasonable.
>
>
>
> >>Then I am so fucking happy that that is not what I just showed you. Of
> >>course you could not know I was not showing you that because you already
> >>knew what I was showing you so you had to see that. Sure, I /told/ you
> >>there were only two classes Image and Control, but when has the human
> >>mind ever had a problem blocking out information inconsistent with what
> >>it knows?
>
> > Well actually I saw the picture of a hand - which doesn't really tell
> > me much!
>
> Actually, I was wondering how you (mis)concluded from the screenshot
> that you were looking at a classic preprogrammed widget set that did
> exactly what it wanted and nothing more, now we learn it did not tell
> you much. I detect progress!
>
> > The image and control sounds interesting, but is too
> > programmatic for anyone to respond to other than by saying 'sounds
> > interesting' without references.
>
> Here is a tip-off: I no longer have to write paint methods for custom
> widgets, I build anything I like up out of (wait for it) graphical
> primitives and a bit of a DSL to orchestrate them all, with scripts
> appearing in the "layers" slot.
>
> the neat thing is that this all evolved on its own. I started with
> layers for just the background color and frame, boom!, out burst a DSL
> that just took over the painting and pushed custom paint methods into
> the sea.
>
> And really there are no methods specialize on Image and Control, they
> are authored with cells and then functions can handle any widget cuz...
> well, it's like building CL out of seven functions or one or however
> many angels are on the head of the pin.
>
>
>
> >>I guess the big problem then is what Qi will think of slots whose type
> >>is "anything any rule any programmer wants to supply for any slot", and
> >>I guess t is an unsatisfactory answer.
>
> > Well such a slot can be given the type A for some A which just means
> > that the type checker will know that something well-typed is in
> > there. The problem will be that in such a situation the type
> > constraints will be so weak that you won't be able to do much with
> > that rule in a type secure manner. I think in the individual case it
> > would be possible to be more forthcoming than that. Cells might
> > benefit from an injection of type theory in its constraint propagation
> > system. (Probably should not have said that ;))
>
> But different instances can have different rules for the same slot, and
> in fact this is precisely why a big hairy GUI can be built from two
> classes, Image and Control, so I think you are still stuck trying to
> prove anything more than (typep everything t).
>
>
>
> >>kt (greatly looking forward to being complimented on my girlfriend)
>
> > Now that is a screen shot ;). My compliments.
>
> Thx, I'll tell her you said that.
>
> kt
>
> --http://www.theoryyalgebra.com/
>
> "Mother always told me, if you tell a lie,
> always rehearse it. If it don't sound good
> to you, it won't sound good to no one else."
> - Satchel Paige
Sound and bombast aside I'm not sure much of what you've said has
addressed anything in my original post. Perhaps under the self-
advertising there is a reference but I've yet to receive it. So why
should I or anybody roll over and be impressed? What has a picture of
a hand or your girlfriend going to do for me?
You mock the idea of a proper theoretical study and a canonical
set of GUI primitives and means of combination as a search for the 7
Pillars. That makes me think 'He hasn't done this work'; but from that
to infer that it cannot or should not be done is a leap of what? Logic
it is not.
Elsewhere you hint that in some fashion you have that very theory
yourself. But where is it - have you written it down and if so
where is it? Is there an existence proof and don't point me to 30,000
lines of your code lashed on to another 30,000 lines of somebody
else's code as a substitute. What we are needing is a profound
theory of space, state and time. I don't see evidence of that in
your posts (and papers, not posts are where such a theory belongs).
Things that are built on a firm foundation of theory do last. Lisp
lasted because under the later accretions of gunge there ws something
profound and perennial. Prolog and ML too. Software built on the
foundations of eternity does last. Stuff that is cooked up or lashed
together on the whim of the inventor may survive for a time as useful,
but its existence is numbered.
At a mundane level, I'm pragmatic enough to realise that what I have
in Qi/tk is probably enough for most people to do the things they want
and probably more than many people get. Buttons, sliders etc. etc -
yeah I can do that. And I'm not going to be the guy who does this
work on the theory of SST because in the remainder of my life I want
to do other things. But that mountain is there for somebody to climb
- one day.
Mark
From: John Thingstad
Subject: Re: on the strange weakness of Graphical User Interface Languages
Date:
Message-ID: <op.tz4s7odspqzri1@pandora.upc.no>
>
> Sound and bombast aside I'm not sure much of what you've said has
> addressed anything in my original post. Perhaps under the self-
> advertising there is a reference but I've yet to receive it. So why
> should I or anybody roll over and be impressed? What has a picture of
> a hand or your girlfriend going to do for me?
>
> You mock the idea of a proper theoretical study and a canonical
> set of GUI primitives and means of combination as a search for the 7
> Pillars. That makes me think 'He hasn't done this work'; but from that
> to infer that it cannot or should not be done is a leap of what? Logic
> it is not.
>
> Elsewhere you hint that in some fashion you have that very theory
> yourself. But where is it - have you written it down and if so
> where is it? Is there an existence proof and don't point me to 30,000
> lines of your code lashed on to another 30,000 lines of somebody
> else's code as a substitute. What we are needing is a profound
> theory of space, state and time. I don't see evidence of that in
> your posts (and papers, not posts are where such a theory belongs).
>
> Things that are built on a firm foundation of theory do last. Lisp
> lasted because under the later accretions of gunge there ws something
> profound and perennial. Prolog and ML too. Software built on the
> foundations of eternity does last. Stuff that is cooked up or lashed
> together on the whim of the inventor may survive for a time as useful,
> but its existence is numbered.
>
> At a mundane level, I'm pragmatic enough to realise that what I have
> in Qi/tk is probably enough for most people to do the things they want
> and probably more than many people get. Buttons, sliders etc. etc -
> yeah I can do that. And I'm not going to be the guy who does this
> work on the theory of SST because in the remainder of my life I want
> to do other things. But that mountain is there for somebody to climb
> - one day.
>
> Mark
>
You seem to miss the point that flow controled IO is a established
approach to UI design.
It is based on the old flow charts you may remember from 'software through
pictures' (or not).
User IO is never going to be beautiful. It never was and it never will be.
My solution is to use designers and to focus on the program domain code.
For some people the way it looks is far more important than how it got
there...
On 13 Oct, 11:39, "John Thingstad" <··············@chello.no> wrote:
> > Sound and bombast aside I'm not sure much of what you've said has
> > addressed anything in my original post. Perhaps under the self-
> > advertising there is a reference but I've yet to receive it. So why
> > should I or anybody roll over and be impressed? What has a picture of
> > a hand or your girlfriend going to do for me?
>
> > You mock the idea of a proper theoretical study and a canonical
> > set of GUI primitives and means of combination as a search for the 7
> > Pillars. That makes me think 'He hasn't done this work'; but from that
> > to infer that it cannot or should not be done is a leap of what? Logic
> > it is not.
>
> > Elsewhere you hint that in some fashion you have that very theory
> > yourself. But where is it - have you written it down and if so
> > where is it? Is there an existence proof and don't point me to 30,000
> > lines of your code lashed on to another 30,000 lines of somebody
> > else's code as a substitute. What we are needing is a profound
> > theory of space, state and time. I don't see evidence of that in
> > your posts (and papers, not posts are where such a theory belongs).
>
> > Things that are built on a firm foundation of theory do last. Lisp
> > lasted because under the later accretions of gunge there ws something
> > profound and perennial. Prolog and ML too. Software built on the
> > foundations of eternity does last. Stuff that is cooked up or lashed
> > together on the whim of the inventor may survive for a time as useful,
> > but its existence is numbered.
>
> > At a mundane level, I'm pragmatic enough to realise that what I have
> > in Qi/tk is probably enough for most people to do the things they want
> > and probably more than many people get. Buttons, sliders etc. etc -
> > yeah I can do that. And I'm not going to be the guy who does this
> > work on the theory of SST because in the remainder of my life I want
> > to do other things. But that mountain is there for somebody to climb
> > - one day.
>
> > Mark
>
> You seem to miss the point that flow controled IO is a established
> approach to UI design.
> It is based on the old flow charts you may remember from 'software through
> pictures' (or not).
> User IO is never going to be beautiful. It never was and it never will be.
> My solution is to use designers and to focus on the program domain code.
> For some people the way it looks is far more important than how it got
> there...- Hide quoted text -
>
> - Show quoted text -
Yes, end users sans CS experience don't care about how things are done
but just how it looks at the end. But I didn't start this thread from
their angle. You may be right that this field is never going to be
beautiful - that means its inherently category 3 in my list. Still
thats a shame if true.
Right now I am focussing on something on category 1 - useful and
elegant - its not in GUILs though, but in automated reasoning.
Mark
Mark Tarver <··········@ukonline.co.uk> writes:
> Yes, end users sans CS experience don't care about how things are done
> but just how it looks at the end. But I didn't start this thread from
> their angle. You may be right that this field is never going to be
> beautiful - that means its inherently category 3 in my list. Still
> thats a shame if true.
>
> Right now I am focussing on something on category 1 - useful and
> elegant - its not in GUILs though, but in automated reasoning.
>
> Mark
>
Well, being able to do nice GUIs with a nice language (being based on
formal theory and on a minimal set of primitives) may be a category 1
thing to you - but:
GUIs in general today lack a set of features that IMO get more and
more important:
* Present the /information/ I, the user, need
* Present it in a way I can /easily/ get the essence of the
information
* Adjusting itself to the usage model I, the user, am applying to it
So we want to have primitives that let us express these points rather
than specifying where a button is to be placed...
An example going somewhat in that direction is:
http://www.radar.cs.cmu.edu/image.jsp?eid=75
As for Kenny's Cello I can conform that I have been doing
"traditional" GUI programming for more than 15 years. Preprogrammed,
you say - and you're right for anything else than Cello. Cello let me
reuse code from Kenny to come up with cute new widgets and ways of
displaying easily (well, after having a nice time reading Lisp code
and learning a lot during that mediation ;-)
See here: (not very impressive, yes, but hey it's a completely
unforeseen usage of Image and Control - ah, no, no types there)
http://web.mac.com/frgo/iWeb/frgo-web-presence/Cello%20Widgets.html
I am currently subclassing Image and Control into a 3D Studio Model
Display Widget ... Some real fun! (Use Google to find some examples).
Correctness proof? Wow! Does it replace testing? No. Wow! Or?
Frank - Intentionally ignoring some aspects of your OP ;-)
--
Frank Goenninger
http://www.goenninger.net
frgo(at)mac(dot)com
"Don't ask me! I haven't been reading comp.lang.lisp long enough to
really know ..."
On 2007-10-13 15:04:34 +0100, Frank Goenninger DG1SBG
<·············@nomail.org> said:
> Well, being able to do nice GUIs with a nice language (being based on
> formal theory and on a minimal set of primitives) may be a category 1
> thing to you - but:
>
> GUIs in general today lack a set of features that IMO get more and
> more important:
>
> * Present the /information/ I, the user, need
> * Present it in a way I can /easily/ get the essence of the
> information
> * Adjusting itself to the usage model I, the user, am applying to it
>
> So we want to have primitives that let us express these points rather
> than specifying where a button is to be placed...
>
> An example going somewhat in that direction is:
> http://www.radar.cs.cmu.edu/image.jsp?eid=75
I like this "PAL" idea (though not necessarily its demonstrated
use...)
Methinks, we've all been busy specifying the means of user
interaction ("I need a combo box there") while ignoring the
fact that we had chosen to handle the goals by ourself "present
the data in a user meaningful and operable way in context so and so".
Though, I wouldn't know where to start in order to go from a high level
goal directed specification towards an on the fly computer generated
set of input/displays/knobs meant to answer those goals ... Quite
far from the pixel drawing primitive ...
--
JFB
On 13 Oct, 16:02, verec <·····@mac.com> wrote:
> On 2007-10-13 15:04:34 +0100, Frank Goenninger DG1SBG
> <·············@nomail.org> said:
>
>
>
>
>
> > Well, being able to do nice GUIs with a nice language (being based on
> > formal theory and on a minimal set of primitives) may be a category 1
> > thing to you - but:
>
> > GUIs in general today lack a set of features that IMO get more and
> > more important:
>
> > * Present the /information/ I, the user, need
> > * Present it in a way I can /easily/ get the essence of the
> > information
> > * Adjusting itself to the usage model I, the user, am applying to it
>
> > So we want to have primitives that let us express these points rather
> > than specifying where a button is to be placed...
>
> > An example going somewhat in that direction is:
> >http://www.radar.cs.cmu.edu/image.jsp?eid=75
>
> I like this "PAL" idea (though not necessarily its demonstrated
> use...)
>
> Methinks, we've all been busy specifying the means of user
> interaction ("I need a combo box there") while ignoring the
> fact that we had chosen to handle the goals by ourself "present
> the data in a user meaningful and operable way in context so and so".
>
> Though, I wouldn't know where to start in order to go from a high level
> goal directed specification towards an on the fly computer generated
> set of input/displays/knobs meant to answer those goals ... Quite
> far from the pixel drawing primitive ...
> --
> JFB- Hide quoted text -
>
> - Show quoted text -
What you're looking for here is a *planner*. AI stuff. You begin
with a formal description of the actions that the machine can do and
then specify what you want it to achieve as an end state. The machine
deduces the steps necessary to achieve the end state and voila you
have a program for doing what you want. Ahem ;).
All this is of course seriously hard, but first of all you need a
formal description of your problem domain as as sort of abstract
machine. This formal description is very much mixed in with the
theory of SST
(state space time) which I think is needed to put GUIs on a sound
theoretical footing.
So what you want is actually a superset of what I want. Its the
stuff of the AI labs.
Mark
On 2007-10-13 11:39:14 +0100, "John Thingstad" <··············@chello.no> said:
>> At a mundane level, I'm pragmatic enough to realise that what I have
>> in Qi/tk is probably enough for most people to do the things they want
>> and probably more than many people get. Buttons, sliders etc. etc -
>> yeah I can do that. And I'm not going to be the guy who does this
>> work on the theory of SST because in the remainder of my life I want
>> to do other things. But that mountain is there for somebody to climb
>> - one day.
>>
>> Mark
>>
>
> You seem to miss the point that flow controled IO is a established
> approach to UI design.
> It is based on the old flow charts you may remember from 'software
> through pictures' (or not).
> User IO is never going to be beautiful. It never was and it never will
> be. My solution is to use designers and to focus on the program domain
> code. For some people the way it looks is far more important than how
> it got there...
What Mr Tarver seems to be after is a theory. How well does
an "approach" qualify? It would perhaps help if "User IO" and
the older MVC "approach" were disqualified on the ground of the
"7 missing primitives". While I do have a feel of what Mr Tarver
is after, I'm not sure I really understand it.
For example, all GUIs have graphics primitives of some sort.
This doesn't qualify as a whole nor complete set of fundation;
most notably, user input and event handling are not addressed.
But nowhere in the (quote atom eq car cdr cons cond) set was
the idea of DSL (let alone macros) or currying or whatnot
explicitely present either. Not even the REPL! (But we're
back in GUI^H^H^HCLI land again, I suppose :-)
Or are we all stuck in "the state of the art", without any
clear insight of what generative principles could be unearthed?
--
JFB
On 13 Oct, 12:10, verec <·····@mac.com> wrote:
> On 2007-10-13 11:39:14 +0100, "John Thingstad" <··············@chello.no> said:
>
>
>
>
>
> >> At a mundane level, I'm pragmatic enough to realise that what I have
> >> in Qi/tk is probably enough for most people to do the things they want
> >> and probably more than many people get. Buttons, sliders etc. etc -
> >> yeah I can do that. And I'm not going to be the guy who does this
> >> work on the theory of SST because in the remainder of my life I want
> >> to do other things. But that mountain is there for somebody to climb
> >> - one day.
>
> >> Mark
>
> > You seem to miss the point that flow controled IO is a established
> > approach to UI design.
> > It is based on the old flow charts you may remember from 'software
> > through pictures' (or not).
> > User IO is never going to be beautiful. It never was and it never will
> > be. My solution is to use designers and to focus on the program domain
> > code. For some people the way it looks is far more important than how
> > it got there...
>
> What Mr Tarver seems to be after is a theory. How well does
> an "approach" qualify? It would perhaps help if "User IO" and
> the older MVC "approach" were disqualified on the ground of the
> "7 missing primitives". While I do have a feel of what Mr Tarver
> is after, I'm not sure I really understand it.
>
> For example, all GUIs have graphics primitives of some sort.
> This doesn't qualify as a whole nor complete set of fundation;
> most notably, user input and event handling are not addressed.
As I remarked in the post to Mr Gould - selecting the right primitives
(whilst important) is half the story - probably less.
> But nowhere in the (quote atom eq car cdr cons cond) set was
> the idea of DSL (let alone macros) or currying or whatnot
> explicitely present either. Not even the REPL! (But we're
> back in GUI^H^H^HCLI land again, I suppose :-)
Um, well you know that McCarthy said somewhere that he really didn't
understand Church's work that well when he built Lisp.
Actually skimming McCarthy's paper on the History of Lisp, I find
no mention of Church at all. This does not detract from his
achievement though.
Also Lisp picked up a lot of destructive stuff partly because
at the time it was designed, people didn't know much about how
to compile FPLs and the computers were about 10^5 times slower than
now (at a guess).
>
> Or are we all stuck in "the state of the art", without any
> clear insight of what generative principles could be unearthed?
> --
Thats what I think.
Mark
From: Ben Rudiak-Gould
Subject: Re: on the strange weakness of Graphical User Interface Languages
Date:
Message-ID: <feq97v$ldb$1@gemini.csx.cam.ac.uk>
Mark Tarver wrote:
> For example, could I produce a window with bevelled edges in TCL/tk -
> or a triangular window or .... fill in your outlandish request. Well
> maybe, but I'd have to check it out. In contrast if I'm asked to
> write a prime number program in Lisp I don't have to think 'Does Lisp
> have a prime number recognisor?'. I know I can do it because prime
> recognition is effectively computable and Lisp incorporates a Turing-
> equivalent set of functions. I can't say the same in TCL/tk because
> the theory is not there.
I can't make any sense of your analogy. Turing completeness is easy. All
general purpose programming languages are Turing complete, but you wouldn't
say that any one is as good as any other. If you just want a general set of
GUI primitives, that's easy too: setting screen pixels and getting keyboard
and mouse state change events. But that can't be what you want.
Ken Tilton wrote:
> http://www.tilton-technology.com/cello-shot-05.jpg
It actually wasn't until I read further in the thread that I realized that
this was supposed to be a positive example. I originally took it to be an
illustration of what's gone wrong with GUI design -- the same basic widgets
we had on the 128K Mac, but now in garish colors with pointless 3D.
I know this is just a demo app, but I still feel justified in complaining
that it doesn't do anything interesting. A user interface, to me, is a way
of visualizing and possibly modifying some form of structured data. This
example is a degenerate case of that: a single object whose properties are
all real-valued or enumerated, and few enough that they can all be put on
screen at once. It doesn't begin to touch on what makes UI design
interesting or difficult. You seem to be saying that there's a very general
framework under the hood; okay, but do you have any examples where it serves
some purpose? I'd be interested in seeing an interface to a relational
database or a function of one complex variable that had some advantage over
existing software, by being more flexible or, failing that, at least being
easier to implement.
-- Ben
On Oct 13, 7:12 am, Ben Rudiak-Gould <·············@cam.ac.uk> wrote:
> Ken Tilton wrote:
> >http://www.tilton-technology.com/cello-shot-05.jpg
>
> It actually wasn't until I read further in the thread that I realized that
> this was supposed to be a positive example. I originally took it to be an
> illustration of what's gone wrong with GUI design -- the same basic widgets
> we had on the 128K Mac, but now in garish colors with pointless 3D.
I think you're confusing the user's perspective with the programmer's
perspective. This thread is all about the latter, and you're asking
for trouble by bringing the former into it.
On 13 Oct, 12:12, Ben Rudiak-Gould <·············@cam.ac.uk> wrote:
> Mark Tarver wrote:
> > For example, could I produce a window with bevelled edges in TCL/tk -
> > or a triangular window or .... fill in your outlandish request. Well
> > maybe, but I'd have to check it out. In contrast if I'm asked to
> > write a prime number program in Lisp I don't have to think 'Does Lisp
> > have a prime number recognisor?'. I know I can do it because prime
> > recognition is effectively computable and Lisp incorporates a Turing-
> > equivalent set of functions. I can't say the same in TCL/tk because
> > the theory is not there.
>
> I can't make any sense of your analogy. Turing completeness is easy. All
> general purpose programming languages are Turing complete, but you wouldn't
> say that any one is as good as any other. If you just want a general set of
> GUI primitives, that's easy too: setting screen pixels and getting keyboard
> and mouse state change events. But that can't be what you want.
>
Actually setting screen pixels and keyboard events is not absurd.
I would not reject, out of hand, somebody who began there. But there
is more to the story.
If you look at the COND CAR CDR CONS ... primitives of Lisp they are
pretty low level. *The power comes from the ability to set barriers
of abstraction through the powerful means of combination.*
So if you have even a very low level set of primitives then provided
(a) your encoding of these primitives is fast and (b) your means of
combination is very powerful, you can get somewhere fairly quickly.
The problem with weak Turing-equivalent languages like Turing machines
is that their abstraction building powers are very limited and they
never gravitate far from their origins. Its not enough to throw a set
of primitives - you have to set up the primitives so that you can
marshal them effectively into larger wholes.
This philosophy, somewhere, is in SICP.
Mark
From: Jon Harrop
Subject: Re: on the strange weakness of Graphical User Interface Languages
Date:
Message-ID: <13h1l1133dajucd@corp.supernews.com>
Mark Tarver wrote:
> On 13 Oct, 12:12, Ben Rudiak-Gould <·············@cam.ac.uk> wrote:
>> I can't make any sense of your analogy. Turing completeness is easy. All
>> general purpose programming languages are Turing complete, but you
>> wouldn't say that any one is as good as any other. If you just want a
>> general set of GUI primitives, that's easy too: setting screen pixels and
>> getting keyboard and mouse state change events. But that can't be what
>> you want.
>
> Actually setting screen pixels and keyboard events is not absurd.
Actually, I think it is absurd to set pixels. If you want to write a GUI
library from the ground up then at least start with something like OpenGL
so you can exploit hardware acceleration where it is available.
I would actually recommend building on top of a general purpose vector
graphics library like Smoke:
http://www.ffconsultancy.com/products/smoke_vector_graphics/?clf
--
Dr Jon D Harrop, Flying Frog Consultancy
http://www.ffconsultancy.com/products/?u
On 13 Oct, 15:11, Jon Harrop <····@ffconsultancy.com> wrote:
> Mark Tarver wrote:
> > On 13 Oct, 12:12, Ben Rudiak-Gould <·············@cam.ac.uk> wrote:
> >> I can't make any sense of your analogy. Turing completeness is easy. All
> >> general purpose programming languages are Turing complete, but you
> >> wouldn't say that any one is as good as any other. If you just want a
> >> general set of GUI primitives, that's easy too: setting screen pixels and
> >> getting keyboard and mouse state change events. But that can't be what
> >> you want.
>
> > Actually setting screen pixels and keyboard events is not absurd.
>
> Actually, I think it is absurd to set pixels. If you want to write a GUI
> library from the ground up then at least start with something like OpenGL
> so you can exploit hardware acceleration where it is available.
>
> I would actually recommend building on top of a general purpose vector
> graphics library like Smoke:
>
> http://www.ffconsultancy.com/products/smoke_vector_graphics/?clf
>
> --
> Dr Jon D Harrop, Flying Frog Consultancyhttp://www.ffconsultancy.com/products/?u
'P is not absurd' is in my terms a very weak assertion (just as 'P is
absurd' is a very strong one). Saying something is absurd means for
me it is so obviously wrong as not to countenance any consideration.
'P is not absurd but P is wrong' is not inconsistent. So don't take
my weak assertion to be an endorsement - it is not.
Mark
From: Ken Tilton
Subject: Re: on the strange weakness of Graphical User Interface Languages
Date:
Message-ID: <AsaQi.3740$5x4.994@newsfe12.lga>
Ben Rudiak-Gould wrote:
> Mark Tarver wrote:
>
>> For example, could I produce a window with bevelled edges in TCL/tk -
>> or a triangular window or .... fill in your outlandish request. Well
>> maybe, but I'd have to check it out. In contrast if I'm asked to
>> write a prime number program in Lisp I don't have to think 'Does Lisp
>> have a prime number recognisor?'. I know I can do it because prime
>> recognition is effectively computable and Lisp incorporates a Turing-
>> equivalent set of functions. I can't say the same in TCL/tk because
>> the theory is not there.
>
>
> I can't make any sense of your analogy. Turing completeness is easy. All
> general purpose programming languages are Turing complete, but you
> wouldn't say that any one is as good as any other. If you just want a
> general set of GUI primitives, that's easy too: setting screen pixels
> and getting keyboard and mouse state change events. But that can't be
> what you want.
>
> Ken Tilton wrote:
>
>> http://www.tilton-technology.com/cello-shot-05.jpg
>
>
> It actually wasn't until I read further in the thread that I realized
> that this was supposed to be a positive example.
No, it was supposed to be a funny way of bringing up a library that is
counterexample to the OPs conviction that all GUIs are limited to that
which has been preprogrammed.
I realize it looks like a Users Guide and complete specification
justifying you and the OP delivering variously long lectures on how evil
they are... hang on, no, it is just a screenshot. Confused.
> I originally took it to
> be an illustration of what's gone wrong with GUI design -- the same
> basic widgets we had on the 128K Mac, but now in garish colors with
> pointless 3D.
You don't like orange? Meanwhile, some of us think it is pretty cool
that the 3D effect EVERY FUCKING GUI USES comes from 3D things lit at an
angle. Fine, you do not like 3d effects, make a black and white 2D
interface or go for the gold and do a 24x80 ascii interface if that is
your preference, but don't run around saying standard GUI decorations
are "pointless".
>
> I know this is just a demo app, but I still feel justified in
> complaining that it doesn't do anything interesting.
We call those self-ignoring acknowledgments. Try changing the comma to a
period and deleting the rest.
> A user interface,
> to me, is a way of visualizing and possibly modifying some form of
> structured data. This example is a degenerate case of that: a single
> object whose properties are all real-valued or enumerated, and few
> enough that they can all be put on screen at once. It doesn't begin to
> touch on what makes UI design interesting or difficult.
See, this is where you needed that insight about it being "just a demo".
> You seem to be
> saying that there's a very general framework under the hood; okay, but
> do you have any examples where it serves some purpose? I'd be interested
> in seeing an interface to a relational database or a function of one
> complex variable that had some advantage over existing software, by
> being more flexible or, failing that, at least being easier to implement.
What an obnoxious way to lead up to a question. Nowhere do you manifest
any awareness of the rest of the thread, which elucidated the lego-like
nature of the underlying system, which is about being able to do
anything you like with 3D graphics, 3D sound, QuickTime, antialiased
text, GraphicksMagick, and lowlevel access to the mouse and keyboard
allowing you to design any interface you like. The above makes it sound
like you want me to conceive your relational DB interface for you. No,
that is still your job. Cello just says there is nothing you can
conceive that you cannot also implement. Easily.
kenny
--
http://www.theoryyalgebra.com/
"Mother always told me, if you tell a lie,
always rehearse it. If it don't sound good
to you, it won't sound good to no one else."
- Satchel Paige
On 2007-10-13 22:07:33 +0100, Ken Tilton <···········@optonline.net> said:
>> I originally took it to be an illustration of what's gone wrong with
>> GUI design -- the same basic widgets we had on the 128K Mac, but now in
>> garish colors with pointless 3D.
>
> You don't like orange? Meanwhile, some of us think it is pretty cool
> that the 3D effect EVERY FUCKING GUI USES comes from 3D things lit at
> an angle. Fine, you do not like 3d effects, make a black and white 2D
> interface or go for the gold and do a 24x80 ascii interface if that is
> your preference, but don't run around saying standard GUI decorations
> are "pointless".
Pointless as in "not adding value to the task at hand".
You see, Sir K, either you have something called taste,
or you don't. And when you don't, not only can you NOT
see that you don't, but this allows you to push the
ridicule in making yourself the fool to the eye of those
who can see. Buy glasses, some wine, talk to your girl
friend-the-beautiful and give us a break.
Whether "cell" is, or not, an interesting development
has nothing to do with th hideuous color scheme that
you have used to show-case its strength. No wonder there
is such a large following behind it! :-)
--
JFB
From: Ken Tilton
Subject: Re: on the strange weakness of Graphical User Interface Languages
Date:
Message-ID: <pvrQi.76$Gh6.74@newsfe12.lga>
verec wrote:
> On 2007-10-13 22:07:33 +0100, Ken Tilton <···········@optonline.net> said:
>
>>> I originally took it to be an illustration of what's gone wrong with
>>> GUI design -- the same basic widgets we had on the 128K Mac, but now
>>> in garish colors with pointless 3D.
>>
>>
>> You don't like orange? Meanwhile, some of us think it is pretty cool
>> that the 3D effect EVERY FUCKING GUI USES comes from 3D things lit at
>> an angle. Fine, you do not like 3d effects, make a black and white 2D
>> interface or go for the gold and do a 24x80 ascii interface if that is
>> your preference, but don't run around saying standard GUI decorations
>> are "pointless".
>
>
> Pointless as in "not adding value to the task at hand".
You don't like 3d buttons? Who does not like 3d buttons? Or is it that
you think they do not offer any useability value, such as cueing the
user that "you can mess with this if you like"? Or "this control is
enabled now"? Or a stronger cue than a plain 1-pixel frame that "these
things go together? In brief, nonsense.
> You see, Sir K, either you have something called taste,
> or you don't. And when you don't, not only can you NOT
> see that you don't, but this allows you to push the
> ridicule in making yourself the fool to the eye of those
> who can see. Buy glasses, some wine, talk to your girl
> friend-the-beautiful and give us a break.
Believe me, if that was my girlfriend I would not be talking with you guys.
>
> Whether "cell" is, or not, an interesting development
> has nothing to do with th hideuous color scheme that
> you have used to show-case its strength. No wonder there
> is such a large following behind it! :-)
OK, you are completely confused and reading too fast, upthread I have
already excoriated the yobbos for looking at screenshots and reacting
only to my choice of skins, now you come along to complain about my
choice of skin. Juuust peachy.
kt
--
http://www.theoryyalgebra.com/
"Mother always told me, if you tell a lie,
always rehearse it. If it don't sound good
to you, it won't sound good to no one else."
- Satchel Paige
From: Didier Verna
Subject: Re: on the strange weakness of Graphical User Interface Languages
Date:
Message-ID: <muxprzgvktz.fsf@uzeb.lrde.epita.fr>
Mark Tarver <··········@ukonline.co.uk> wrote:
> Messy for the reasons I gave. In Lisp, I used to introduce students by
> showing them CAR, CDR, CONS and a few other functions and showing how
> Turing equivalence could be gained in an instruction set of about
> half-a-dozen functions - everything else that was thrown in, I told
> them, was often about convenience and speed.
>
> In contrast my 802 page *partial* spec of TCL/tk includes a wealth of
> detail without any guiding idea of what would correspond to the vital
> primitive instruction set. Because of this, and because I have no
> idea what the primitives are in that system that constitute a
> computationally adequate set, there are certain questions I cannot
> answer with confidence.
Well, that's not a problem with the GUIs, that's a problem with your
documentation (who wants to learn GUI programming by reading a *spec*
anyway?).
The X11 Intrinsics for instance have a small set of primitive widgets,
and you can do all you want on top of them. Even this old and
oh-so-crappy toolkit named Motif (yes, it's based on Xt, but...) have 3
fundamental bulding blocks: the Primitive, Gadget and Manager widgets.
Everything else is based on it, and as you know, 3 is less than 7 ;-)
So to paraphrase your own argument: Motif is really 3 fundamental
widgets. Everything else is pretty much here for convenience.
But what's convenience? Well, I don't want to recode a push-button each
time I write a new application. But I'd also like built-in push-buttons
to have borders, and hell, wouldn't it be neat if I could have not only
text, but a big blinking Mickey Mouse in it?
So the problem with GUIs is that people don't want to reinvent the
wheel, and/but people also want different wheels, and expect a GUIL to
provide just the wheel they had in mind. Or at least ways to customize
the provided wheels (hence the complexity). The success of such or such
GUI[L] doesn't lie in its conception, but in whether it has a "neat"
look'n feel.
In a way, it's no different from the complexity of Common Lisp. Of
course, I might be glad to know that the core of Lisp is small, clean
and simple, but oh boy, am I glad to have a 1000 pages standard on top
of it with plenty of built-in functions, and a bunch of third-party
packages that I can use.
If there's a real problem with GUILs being a mess, it's not in the
building blocks they provide. It's rather in the inadequacy of the
chosen implementation language. The two perfect examples of this are
Motif and Gtk (admitedly, the X11's Intrinsics themselves) trying to
express OO concepts in C...
--
New @-quartet featured CD Review !!
http://www.indie-music.com/modules.php?name=News&file=article&sid=6457
Didier Verna, ······@lrde.epita.fr, http://www.lrde.epita.fr/~didier
EPITA / LRDE, 14-16 rue Voltaire Tel.+33 (1) 44 08 01 85
94276 Le Kremlin-Bic�tre, France Fax.+33 (1) 53 14 59 22 ······@xemacs.org
On 15 Oct, 09:33, Didier Verna <······@lrde.epita.fr> wrote:
> Mark Tarver <··········@ukonline.co.uk> wrote:
> > Messy for the reasons I gave. In Lisp, I used to introduce students by
> > showing them CAR, CDR, CONS and a few other functions and showing how
> > Turing equivalence could be gained in an instruction set of about
> > half-a-dozen functions - everything else that was thrown in, I told
> > them, was often about convenience and speed.
>
> > In contrast my 802 page *partial* spec of TCL/tk includes a wealth of
> > detail without any guiding idea of what would correspond to the vital
> > primitive instruction set. Because of this, and because I have no
> > idea what the primitives are in that system that constitute a
> > computationally adequate set, there are certain questions I cannot
> > answer with confidence.
>
> Well, that's not a problem with the GUIs, that's a problem with your
> documentation (who wants to learn GUI programming by reading a *spec*
> anyway?).
>
> The X11 Intrinsics for instance have a small set of primitive widgets,
> and you can do all you want on top of them. Even this old and
> oh-so-crappy toolkit named Motif (yes, it's based on Xt, but...) have 3
> fundamental bulding blocks: the Primitive, Gadget and Manager widgets.
> Everything else is based on it, and as you know, 3 is less than 7 ;-)
>
> So to paraphrase your own argument: Motif is really 3 fundamental
> widgets. Everything else is pretty much here for convenience.
>
> But what's convenience? Well, I don't want to recode a push-button each
> time I write a new application. But I'd also like built-in push-buttons
> to have borders, and hell, wouldn't it be neat if I could have not only
> text, but a big blinking Mickey Mouse in it?
>
> So the problem with GUIs is that people don't want to reinvent the
> wheel, and/but people also want different wheels, and expect a GUIL to
> provide just the wheel they had in mind. Or at least ways to customize
> the provided wheels (hence the complexity). The success of such or such
> GUI[L] doesn't lie in its conception, but in whether it has a "neat"
> look'n feel.
>
> In a way, it's no different from the complexity of Common Lisp. Of
> course, I might be glad to know that the core of Lisp is small, clean
> and simple, but oh boy, am I glad to have a 1000 pages standard on top
> of it with plenty of built-in functions, and a bunch of third-party
> packages that I can use.
>
> If there's a real problem with GUILs being a mess, it's not in the
> building blocks they provide. It's rather in the inadequacy of the
> chosen implementation language. The two perfect examples of this are
> Motif and Gtk (admitedly, the X11's Intrinsics themselves) trying to
> express OO concepts in C...
>
> --
> New @-quartet featured CD Review !!http://www.indie-music.com/modules.php?name=News&file=article&sid=6457
>
> Didier Verna, ······@lrde.epita.fr,http://www.lrde.epita.fr/~didier
>
> EPITA / LRDE, 14-16 rue Voltaire Tel.+33 (1) 44 08 01 85
> 94276 Le Kremlin-Bic�tre, France Fax.+33 (1) 53 14 59 22 ······@xemacs.org
CL is overblown; but thats not the point. The point I am making goes
back to the lack of substantial theory under GUILs. The lack of a
definition of computational
adequacy and the resulting uncertainty about the exact powers of the
system and what the exact primitives are or should be. Add to that
the weak means of combining and you have a recipe for bloat.
CL is different, the bloat is partly historical. Its old and its been
around a long time and its picked up many influences along the way.
But these observations are not true of CL for anything like the same
extent.
Mark
On 2007-10-15, Didier Verna <······@lrde.epita.fr> wrote:
>
> So to paraphrase your own argument: Motif is really 3 fundamental
> widgets. Everything else is pretty much here for convenience.
>
> But what's convenience? Well, I don't want to recode a push-button each
> time I write a new application. But I'd also like built-in push-buttons
> to have borders, and hell, wouldn't it be neat if I could have not only
> text, but a big blinking Mickey Mouse in it?
>
> So the problem with GUIs is that people don't want to reinvent the
> wheel, and/but people also want different wheels, and expect a GUIL to
> provide just the wheel they had in mind. Or at least ways to customize
> the provided wheels (hence the complexity). The success of such or such
> GUI[L] doesn't lie in its conception, but in whether it has a "neat"
> look'n feel.
These are all "design" considerations - in the cosmetic, aesthetic
sense of the term rather than a technical or engineering sense.
Like the OP, I've looked at various GUI programming packages and
always thought "what a mess" for some reason or other. As others
have noted, the problem is usually the level of abstraction - it
is either too high limiting flexibility or too low meaning I have
consider too many details that I don't care about.
Speaking personally, I don't want _any_ of this crap polluting my
code. I'd rather separate out the aesthetic elements from the code
entirely, and be able to say in my code "this setting is alterable
by the user" and have a UI that was created seperately, preferably
by someone who both knows and cares about the subjects of visual
design and human-computer interaction.
For example, if a setting is a number I just want to open that
number up for setting by the UI. My code shouldn't need to know
or care whether it is obtained by numeric entry, scroll bar, spin
box or whatever, nor on what dialog it appears and its precise
on-screen co-ordinates. That can be delegated to a visual designer
using a seperate interface design tool. I would just say "This
setting controls that", or "Execute this function to perform that
function". As far as possible, the structure of the code and the
UI would independent of each other, unlike many of the existing
interface design tools that implement each dialog as a class and
direct the programmer to structure the code in a particular manner.
Visual design is a complex area with its own conventions and
methodologies - IMHO this is complexity code can do without and is
best seperated out as far as pratical. As a side effect, creating
a new 'skin' for a different language or the latest new "improved"
user interface from Microsoft would result in minimal code changes.
--
Andrew Smallshaw
·······@sdf.lonestar.org
Andrew Smallshaw wrote:
> On 2007-10-15, Didier Verna <······@lrde.epita.fr> wrote:
>> So to paraphrase your own argument: Motif is really 3 fundamental
>> widgets. Everything else is pretty much here for convenience.
>>
>> But what's convenience? Well, I don't want to recode a push-button each
>> time I write a new application. But I'd also like built-in push-buttons
>> to have borders, and hell, wouldn't it be neat if I could have not only
>> text, but a big blinking Mickey Mouse in it?
>>
>> So the problem with GUIs is that people don't want to reinvent the
>> wheel, and/but people also want different wheels, and expect a GUIL to
>> provide just the wheel they had in mind. Or at least ways to customize
>> the provided wheels (hence the complexity). The success of such or such
>> GUI[L] doesn't lie in its conception, but in whether it has a "neat"
>> look'n feel.
>
> These are all "design" considerations - in the cosmetic, aesthetic
> sense of the term rather than a technical or engineering sense.
> Like the OP, I've looked at various GUI programming packages and
> always thought "what a mess" for some reason or other. As others
> have noted, the problem is usually the level of abstraction - it
> is either too high limiting flexibility or too low meaning I have
> consider too many details that I don't care about.
>
> Speaking personally, I don't want _any_ of this crap polluting my
> code. I'd rather separate out the aesthetic elements from the code
> entirely, and be able to say in my code "this setting is alterable
> by the user" and have a UI that was created seperately, preferably
> by someone who both knows and cares about the subjects of visual
> design and human-computer interaction.
I've tried a wide collection of GUI toolkits. Many have their good
points, but most are incomplete or painful.
I've almost always been happy with Qt. The programmer sets up
functions to receive values, the GUI designer does his thing in a
point-n-click GUI, and asynchronous "signals and slots" connect
everything together. This keeps things loosely coupled, but its easy
to get under the hood if you have to. And with 4.3.2, it just keeps
getting better.
http://trolltech.com/developer/downloads/qt/index
- Daniel
Andrew Smallshaw wrote:
> On 2007-10-15, Didier Verna <······@lrde.epita.fr> wrote:
> These are all "design" considerations - in the cosmetic, aesthetic
> sense of the term rather than a technical or engineering sense.
> Speaking personally, I don't want _any_ of this crap polluting my
> code. I'd rather separate out the aesthetic elements from the code
> entirely, and be able to say in my code "this setting is alterable
> by the user" and have a UI that was created seperately, preferably
> by someone who both knows and cares about the subjects of visual
> design and human-computer interaction.
> [...]
Many real life programs are not much more than a user interface. The
usual CRUD application. Or even big heavy applications like word or
excel or ... a web browser. In these programs, the "object model" is
mainly there to support the UI. Printing a document is a matter of UI,
wysiwyg is a matter of UI, then you have the UI to configure all this.
Also, more often than not, the deciding factor for the customer will be
the UI.
So yes, of course, it's good to have a separation between your code and
the UI. But the UI deserves all your attention. It is my opinion that
every programmer should research those matters. And instead of
relegating these to an UI "artist", he should work tightly with him to
achieve the best possible result.
Sacha
From: Jon Harrop
Subject: Re: on the strange weakness of Graphical User Interface Languages
Date:
Message-ID: <13hbe0hr74mhcf6@corp.supernews.com>
Sacha wrote:
> So yes, of course, it's good to have a separation between your code and
> the UI. But the UI deserves all your attention. It is my opinion that
> every programmer should research those matters. And instead of
> relegating these to an UI "artist", he should work tightly with him to
> achieve the best possible result.
I agree that programmers should be made far more aware of the artistic side
of GUIs.
However, if you consider the dress-sense of your average programmer would
you really want them having a hand in any customer-facing aspect of your
work, e.g. the GUI?
Look at John McCarthy, for example:
http://www.bartnagel.com/images/John_McCarthy.jpg
--
Dr Jon D Harrop, Flying Frog Consultancy
http://www.ffconsultancy.com/products/?u
Here is one possible way to clarify the whole problem. An attempt at a
simplified theory, which can be clearly understood by everyone and then
later refined into a more complete theory.
When the user clicks a button, things happen at different levels of
abstraction. The user presses the mouse button, then releases it, at a
low hardware level of abstraction. The user clicks a point on the
screen, at a somewhat higher level of abstraction. That point on the
screen is in a button widget, and the user is clicking that button
widget, at a still higher level of abstraction. At an even higher level
of abstraction than that, the user is making a selection from a group of
buttons. The program, abstracted above the level of the GUI, wants
information from the user, and the user is providing that information.
Each of those layers of abstraction is naturally very complicated,
because a lot of things can happen at any point in time in each layer,
and all of those things have to be taken into account by the software.
The programmer needs widgets because the lower layers of abstraction
below widgets are naturally too messy and tedious. But the programmer
actually needs something at a higher level of abstraction than widgets,
because widgets themselves are too messy and tedious.
None of the toolkits are complete. They're all compromised by the need
for simplicity. Like having a hammer, because it's simple, and makes
every problem a nail.
The bigger your toolkit, the heavier it is, but the more problems you can
solve better. Tools are expensive. People use compromised toolkits,
because they can't afford better ones and they can't afford to deal with
the weight and size of a big toolkit.
But software is different than metal tools. The only things that stop us
from using a twenty ton toolkit are the problem of obtaining the tools
and the problem of keeping each tool handy and not letting it get lost
among the other tools. The problem of the twenty ton weight is easily
solved by modern multi-gigabyte disk storage, which was not easily
available to the original designers of GUI libraries that have been
evolving for decades.
So, what we really need is a way to get a complete set of tools, and a
way to keep each tool handy. Getting a complete set of tools is hard,
especially if we have to design each tool manually. But the OP wants to
use combination to create an orthogonal set of tools from a smaller set
of more primitive tools. If we can do that, it will also help us keep
the tools handy.
Therefore, this discussion should not be construed as an argument about
whether GUILs are inadequate, but, rather, a discussion about the OP's
proposal for solving that inadequacy. A discussion about how to use
combination of primitives to fill in the whole orthogonal set of all
potentially desirable GUI tools. Because we're using combination, we
don't have to name each tool, nor even be aware of each tool. We can
think in terms of the combinations. A push button that toggles and stays
pushed till you push it again to release it, is just another style of
push button. Just a different combination. You don't have to remember
the name of that style vs the original push button. You just have to
remember the combination of features you want it to have. A Mickey Mouse
push button, where he sits down when you push the button, is still
another style. There can be an unlimited number of combinations. Make
the button triangular and make it take half the screen. Just another
combination.
So the issue really is how to build this stuff and make it handy. How to
make it easy for the programmer to tell Mickey to sit down when the
button is pressed, without the need to make such actions part of the
program logic, but just the GUI style combinations.
The programmer needs to be able to add more stuff to be combined in the
combinations. Maybe nobody ever thought to include Mickey Mouse
capability. But that's just another combination of other capabilities.
A different combination could have someone else sitting down, or doing
something else. The programmer needs to be able to easily add whatever
is missing, to be used in whatever combinations are desired.
Keeping a group of buttons lined up is just a matter of making them a
group, which is another kind of widget, and giving that group the right
combination, such as being able to adapt to different layout spaces
without getting distorted.
To restate the theory, GUI's are naturally complicated, not just because
we're doing them wrong. They're complicated because so many different
things can happen in so many different ways. But software is good at
conquering complexity.
Most existing GUILs are compromised for expediency. What we need is
simply one that isn't. One that provides for unlimited combinations,
with unlimited access at all levels for the programmer to easily add
anything missing, without spending any time fighting needless obstacles
such as built in quirks and restrictions on what can be easily added or
combined.
On 2007-10-12 08:49:29 -0400, Mark Tarver <··········@ukonline.co.uk> said:
> But the primitives are nowhere in sight
> and what you are given is a grab-bag of tools for making buttons and
> various widgets.
This is the central problem imho. The fact that the toolkits are not
functional is of lesser significance.
The designers of GUI toolkits have, in general, striven to make them
"easy to use." This seems to mean "relatively high level." As a result,
the primitives are hidden or unavailable.
The problem for me comes from the broken, hard wired assumptions the
toolkit designers often make about how the primitives should be tied
together. Without access to the primitives it becomes extremely
difficult or impossible to get the behavior one wants without going
outside the toolkit.
Raffael Cavallaro wrote:
> The problem for me comes from the broken, hard wired assumptions the
> toolkit designers often make about how the primitives should be tied
> together. Without access to the primitives it becomes extremely
> difficult or impossible to get the behavior one wants without going
> outside the toolkit.
Out of curiosity, what are those "broken, hard wired assumptions"? I
suppose it's nice enough to make such an assertion, but if the
specifics are not brought out into the open air and examined, it's
just going to frustrate those of us who might possibly do something
about it. :-)
(BTW, please also Cc: me your reply; I don't usually read this group
and I'm on the road for the next week anyway so might forget to check
for followups. Thanks in advance!)
Donal Fellows.
On 2007-10-13 16:53:19 -0400, dkf <···············@man.ac.uk> said:
> Out of curiosity, what are those "broken, hard wired assumptions"? I
> suppose it's nice enough to make such an assertion, but if the
> specifics are not brought out into the open air and examined, it's
> just going to frustrate those of us who might possibly do something
> about it. :-)
Well, since this is comp.lang.lisp, let's look at LispWorks CAPI as an
example. It's broken on the Mac OS in part because it has a unifying
concept of an "interface" which unnecessarily joins windows and menus
at the hip. On some platforms these things are necessarily connected
(or normally connected - windows having menus in their title bars). On
Mac OS they are independent GUI elements and shouldn't be tied together
by the toolkit.
That's a concrete example. The take-away lesson is that a cross
platform GUI toolkit designer shouldn't try to anticipate possible uses
to which various elements might be put in what combinations. Everything
that can possibly be kept independent and orthogonal should be. It's
straightforward enough given the primitives to build simple connections
of the usual suspects in the ususal platform standard way and to
provide these as libraries - "windows xp standard window," e.g. But
going the other way - undoing a hard wired connection between or among
UI elements pretty much necessitates going behind the GUI tookit's back
or subverting it altogether.
regards,
Ralph
regards,
Ralph
In article
<····································@pasdespamsilvousplaitmaccom>,
Raffael Cavallaro
<················@pas-d'espam-s'il-vous-plait-mac.com> wrote:
> On 2007-10-13 16:53:19 -0400, dkf <···············@man.ac.uk> said:
>
> > Out of curiosity, what are those "broken, hard wired assumptions"? I
> > suppose it's nice enough to make such an assertion, but if the
> > specifics are not brought out into the open air and examined, it's
> > just going to frustrate those of us who might possibly do something
> > about it. :-)
>
> Well, since this is comp.lang.lisp, let's look at LispWorks CAPI as an
> example. It's broken on the Mac OS in part because it has a unifying
> concept of an "interface" which unnecessarily joins windows and menus
> at the hip. On some platforms these things are necessarily connected
> (or normally connected - windows having menus in their title bars). On
> Mac OS they are independent GUI elements and shouldn't be tied together
> by the toolkit.
>
> That's a concrete example. The take-away lesson is that a cross
> platform GUI toolkit designer
To be fair, the LispWorks toolkit was not designed for general
cross-platform usage, I'd say.
The LispWorks toolkit used Motif (IIRC) since it appeared
on workstations many years ago. Motif uses mostly an old Windows model.
LispWorks for Windows appeared later and there
were probably not that many conceptual differences.
The Mac port was late. What they did mostly was to
adapt their toolkit CAPI to a Cocoa-based UI.
They have not redesigned the Toolkit so you can really
adapt to the different styles of User Interfaces.
To give an example:
On Windows the dialog asks something like 'Save file blabla?'
and the buttons are "Yes" and "No". (trying to remember,
hope I got that right, somehow)
On the Mac the dialog says 'Save as: blabla' and the buttons
are "Save" and "Cancel".
There is no way to anticipate what some future platform
might do. BeOS? No idea. Apple's touch UI? No idea.
But there is also no automatic way to derive the
dialog texts from a single set of strings.
Probably you have to give the texts for each and
every different platform. That means the toolkit
is only really cross-platform for those platforms
it was designed for.
Consequently LispWorks uses sometimes wrong button texts on
the Mac, because it was not designed for that and
the design later has not been extended to do so.
Common Lisp has the problem with yes-or-no-p.
On Windows you would call (yes-or-no-p "make darjeeling tea?")
and get the right question with yes and no buttons.
But on the Mac the buttons should be called "make" and
"cancel".
So. I'd say CAPI was not really designed as a cross-platform toolkit
with non-windows (or non-Motif) user interfaces in mind.
> shouldn't try to anticipate possible uses
> to which various elements might be put in what combinations. Everything
> that can possibly be kept independent and orthogonal should be. It's
> straightforward enough given the primitives to build simple connections
> of the usual suspects in the ususal platform standard way and to
> provide these as libraries - "windows xp standard window," e.g. But
> going the other way - undoing a hard wired connection between or among
> UI elements pretty much necessitates going behind the GUI tookit's back
> or subverting it altogether.
>
> regards,
>
> Ralph
>
>
> regards,
>
> Ralph
From: Joachim Durchholz
Subject: Re: on the strange weakness of Graphical User Interface Languages
Date:
Message-ID: <47115175.9060707@durchholz.org>
dkf schrieb:
> Out of curiosity, what are those "broken, hard wired assumptions"?
Stuff like:
* Grid cells, treeview labels, and menu entries can have only text.
Oh, wait, you can have an icon, too. (That's what you have to deal
with on Windows. There are workarounds, but they are... ewwww.)
* You don't get back all the parameters of a control.
* You don't get all the relevant dimensions of a control.
(E.g. for a text input control, you need outer borders, inner borders,
the position of the actual text area, and the text baseline.)
(The "broken assumption" in the "you don't get" items is that the
programmer will never need these values. Try to line up a label's
base line with the base line of a text input field and you know what
I mean.)
Sometimes, however, doing things orthogonally is hard, really hard, or
even really d***ed hard:
* Fill a grid column with a tree view.
* Make a dialog automatically adapt to size changes.
(Doing this well means you need a constraint solver.
OTOH having a constraint solver in the standard library seems a good
idea for other purposes, so...)
* Tab order. (It doesn't compose: defining a tab order for a group of
controls will often not work well when moving it to a different
context.)
* Hotkey management. No way to do that in a modular fashion, sticking
together groups of controls with pre-assigned hotkeys will often
produce a conflict.
Things usually get far worse when the software gets localized to a
different language, because in most cases, the translator doesn't get
to see the dialog in its entirety, just individual texts.
Oh, and the hotkeys must not conflict with menu hot keys either.
So, change the hotkey on a menu item and watch the hotkeys of all
your dialogs collide (but only those where that menu item is enabled,
and since determining the enabled state of a menu item is usually
equivalent to the Halting Problem, it's even difficult to do proper
tool support for such a situation).
These are just the things off the top of my head. I'm quite sure that
this list is very, very non-exhaustive.
Regards,
Jo
From: Jon Harrop
Subject: Re: on the strange weakness of Graphical User Interface Languages
Date:
Message-ID: <13h3c1koljn138@corp.supernews.com>
Joachim Durchholz wrote:
> dkf schrieb:
>> Out of curiosity, what are those "broken, hard wired assumptions"?
>
> Stuff like:
> * Grid cells, treeview labels, and menu entries can have only text.
> Oh, wait, you can have an icon, too. (That's what you have to deal
> with on Windows. There are workarounds, but they are... ewwww.)
Is that true of Windows Presentation Foundation?
> * You don't get back all the parameters of a control.
> * You don't get all the relevant dimensions of a control.
> (E.g. for a text input control, you need outer borders, inner borders,
> the position of the actual text area, and the text baseline.)
And that's just for Latin derivatives....
> (The "broken assumption" in the "you don't get" items is that the
> programmer will never need these values. Try to line up a label's
> base line with the base line of a text input field and you know what
> I mean.)
That problem plagues HTML even more, IMHO.
> Sometimes, however, doing things orthogonally is hard, really hard, or
> even really d***ed hard:
> * Fill a grid column with a tree view.
> * Make a dialog automatically adapt to size changes.
> (Doing this well means you need a constraint solver.
> OTOH having a constraint solver in the standard library seems a good
> idea for other purposes, so...)
Interesting...
> * Tab order. (It doesn't compose: defining a tab order for a group of
> controls will often not work well when moving it to a different
> context.)
> * Hotkey management. No way to do that in a modular fashion, sticking
> together groups of controls with pre-assigned hotkeys will often
> produce a conflict.
> Things usually get far worse when the software gets localized to a
> different language, because in most cases, the translator doesn't get
> to see the dialog in its entirety, just individual texts.
> Oh, and the hotkeys must not conflict with menu hot keys either.
> So, change the hotkey on a menu item and watch the hotkeys of all
> your dialogs collide (but only those where that menu item is enabled,
> and since determining the enabled state of a menu item is usually
> equivalent to the Halting Problem, it's even difficult to do proper
> tool support for such a situation).
>
> These are just the things off the top of my head. I'm quite sure that
> this list is very, very non-exhaustive.
A fascinating enumeration. :-)
--
Dr Jon D Harrop, Flying Frog Consultancy
http://www.ffconsultancy.com/products/?u
From: Ken Tilton
Subject: Re: on the strange weakness of Graphical User Interface Languages
Date:
Message-ID: <1FrQi.79$Gh6.49@newsfe12.lga>
Jon Harrop wrote:
> Joachim Durchholz wrote:
>
>>dkf schrieb:
>>
>>>Out of curiosity, what are those "broken, hard wired assumptions"?
>>
>>Stuff like:
>>* Grid cells, treeview labels, and menu entries can have only text.
>> Oh, wait, you can have an icon, too. (That's what you have to deal
>> with on Windows. There are workarounds, but they are... ewwww.)
>
>
> Is that true of Windows Presentation Foundation?
>
>
>>* You don't get back all the parameters of a control.
>>* You don't get all the relevant dimensions of a control.
>> (E.g. for a text input control, you need outer borders, inner borders,
>> the position of the actual text area, and the text baseline.)
>
>
> And that's just for Latin derivatives....
>
>
>> (The "broken assumption" in the "you don't get" items is that the
>> programmer will never need these values. Try to line up a label's
>> base line with the base line of a text input field and you know what
>> I mean.)
>
>
> That problem plagues HTML even more, IMHO.
>
>
>>Sometimes, however, doing things orthogonally is hard, really hard, or
>>even really d***ed hard:
>>* Fill a grid column with a tree view.
>>* Make a dialog automatically adapt to size changes.
>> (Doing this well means you need a constraint solver.
>> OTOH having a constraint solver in the standard library seems a good
>> idea for other purposes, so...)
>
>
> Interesting...
Yeah, maybe in another ten years you clowns will realize why I like Cells.
>
>
>>* Tab order. (It doesn't compose: defining a tab order for a group of
>> controls will often not work well when moving it to a different
>> context.)
>>* Hotkey management. No way to do that in a modular fashion, sticking
>> together groups of controls with pre-assigned hotkeys will often
>> produce a conflict.
>> Things usually get far worse when the software gets localized to a
>> different language, because in most cases, the translator doesn't get
>> to see the dialog in its entirety, just individual texts.
>> Oh, and the hotkeys must not conflict with menu hot keys either.
>> So, change the hotkey on a menu item and watch the hotkeys of all
>> your dialogs collide (but only those where that menu item is enabled,
>> and since determining the enabled state of a menu item is usually
>> equivalent to the Halting Problem, it's even difficult to do proper
>> tool support for such a situation).
>>
>>These are just the things off the top of my head. I'm quite sure that
>>this list is very, very non-exhaustive.
>
>
> A fascinating enumeration. :-)
>
Not to anyone using Eve, Flapjax, or Cello, except as a reminder of how
much pain we are no longer enduring.
kt
--
http://www.theoryyalgebra.com/
"Mother always told me, if you tell a lie,
always rehearse it. If it don't sound good
to you, it won't sound good to no one else."
- Satchel Paige
On 14 Oct, 17:41, Ken Tilton <···········@optonline.net> wrote:
> Jon Harrop wrote:
> > Joachim Durchholz wrote:
>
> >>dkf schrieb:
>
> >>>Out of curiosity, what are those "broken, hard wired assumptions"?
>
> >>Stuff like:
> >>* Grid cells, treeview labels, and menu entries can have only text.
> >> Oh, wait, you can have an icon, too. (That's what you have to deal
> >> with on Windows. There are workarounds, but they are... ewwww.)
>
> > Is that true of Windows Presentation Foundation?
>
> >>* You don't get back all the parameters of a control.
> >>* You don't get all the relevant dimensions of a control.
> >> (E.g. for a text input control, you need outer borders, inner borders,
> >> the position of the actual text area, and the text baseline.)
>
> > And that's just for Latin derivatives....
>
> >> (The "broken assumption" in the "you don't get" items is that the
> >> programmer will never need these values. Try to line up a label's
> >> base line with the base line of a text input field and you know what
> >> I mean.)
>
> > That problem plagues HTML even more, IMHO.
>
> >>Sometimes, however, doing things orthogonally is hard, really hard, or
> >>even really d***ed hard:
> >>* Fill a grid column with a tree view.
> >>* Make a dialog automatically adapt to size changes.
> >> (Doing this well means you need a constraint solver.
> >> OTOH having a constraint solver in the standard library seems a good
> >> idea for other purposes, so...)
>
> > Interesting...
>
> Yeah, maybe in another ten years you clowns will realize why I like Cells.
>
>
>
>
>
>
>
> >>* Tab order. (It doesn't compose: defining a tab order for a group of
> >> controls will often not work well when moving it to a different
> >> context.)
> >>* Hotkey management. No way to do that in a modular fashion, sticking
> >> together groups of controls with pre-assigned hotkeys will often
> >> produce a conflict.
> >> Things usually get far worse when the software gets localized to a
> >> different language, because in most cases, the translator doesn't get
> >> to see the dialog in its entirety, just individual texts.
> >> Oh, and the hotkeys must not conflict with menu hot keys either.
> >> So, change the hotkey on a menu item and watch the hotkeys of all
> >> your dialogs collide (but only those where that menu item is enabled,
> >> and since determining the enabled state of a menu item is usually
> >> equivalent to the Halting Problem, it's even difficult to do proper
> >> tool support for such a situation).
>
> >>These are just the things off the top of my head. I'm quite sure that
> >>this list is very, very non-exhaustive.
>
> > A fascinating enumeration. :-)
>
> Not to anyone using Eve, Flapjax, or Cello, except as a reminder of how
> much pain we are no longer enduring.
>
> kt
>
> --http://www.theoryyalgebra.com/
>
> "Mother always told me, if you tell a lie,
> always rehearse it. If it don't sound good
> to you, it won't sound good to no one else."
> - Satchel Paige- Hide quoted text -
>
> - Show quoted text -- Hide quoted text -
>
> - Show quoted text -
Cells or Cello might be the solution. But getting mad at people won't
help. When I brought out Qi, I got quite a rough reception on
comp.lang.functional because some of my statements, though quite
accurate, were not believed. I set about correcting that
misunderstanding by writing a study series and people eventually found
their way to my book.
Getting people to understand your position requires time, especially
if you have something substantially new to offer. What you need to do
is to do a proper presentation - a science paper that you can refer to
- that succinctly and clearly states the basis of Cello and why it is
free from the faults of other GUILs. It should be reasonably brief
and clear. Then you can cite this in posts.
If you really have the elements of what is needed - a computationally
adequate and not unmanageably large set of GUI primitives and a
powerful means of combination then you're in a strong position. If
you can give some flesh to this idea of computational adequacy and in
doing, give support to the thesis that Cello is computationally
adequate in a way that other GUILs are not then it would be great.
*I'm not attached to Qi/tk myself* - its not really the focus of my
research and I will most probably be out of CS in a year anyway. Its
just a type secure way of talking to TCL/tk and almost certainly not
the best GUIL in the world being pretty hard-wired but it works fairly
well at providing in a type secure way the basic functionality needed
to do the obvious stuff.
Mark
From: Ken Tilton
Subject: Re: on the strange weakness of Graphical User Interface Languages
Date:
Message-ID: <uZzQi.2739$tf7.1529@newsfe12.lga>
Mark Tarver wrote:
> On 14 Oct, 17:41, Ken Tilton <···········@optonline.net> wrote:
>
>>Jon Harrop wrote:
>>
>>>Joachim Durchholz wrote:
>>
>>>>dkf schrieb:
>>
>>>>>Out of curiosity, what are those "broken, hard wired assumptions"?
>>
>>>>Stuff like:
>>>>* Grid cells, treeview labels, and menu entries can have only text.
>>>> Oh, wait, you can have an icon, too. (That's what you have to deal
>>>> with on Windows. There are workarounds, but they are... ewwww.)
>>
>>>Is that true of Windows Presentation Foundation?
>>
>>>>* You don't get back all the parameters of a control.
>>>>* You don't get all the relevant dimensions of a control.
>>>> (E.g. for a text input control, you need outer borders, inner borders,
>>>> the position of the actual text area, and the text baseline.)
>>
>>>And that's just for Latin derivatives....
>>
>>>> (The "broken assumption" in the "you don't get" items is that the
>>>> programmer will never need these values. Try to line up a label's
>>>> base line with the base line of a text input field and you know what
>>>> I mean.)
>>
>>>That problem plagues HTML even more, IMHO.
>>
>>>>Sometimes, however, doing things orthogonally is hard, really hard, or
>>>>even really d***ed hard:
>>>>* Fill a grid column with a tree view.
>>>>* Make a dialog automatically adapt to size changes.
>>>> (Doing this well means you need a constraint solver.
>>>> OTOH having a constraint solver in the standard library seems a good
>>>> idea for other purposes, so...)
>>
>>>Interesting...
>>
>>Yeah, maybe in another ten years you clowns will realize why I like Cells.
>>
>>
>>
>>
>>
>>
>>
>>
>>>>* Tab order. (It doesn't compose: defining a tab order for a group of
>>>> controls will often not work well when moving it to a different
>>>> context.)
>>>>* Hotkey management. No way to do that in a modular fashion, sticking
>>>> together groups of controls with pre-assigned hotkeys will often
>>>> produce a conflict.
>>>> Things usually get far worse when the software gets localized to a
>>>> different language, because in most cases, the translator doesn't get
>>>> to see the dialog in its entirety, just individual texts.
>>>> Oh, and the hotkeys must not conflict with menu hot keys either.
>>>> So, change the hotkey on a menu item and watch the hotkeys of all
>>>> your dialogs collide (but only those where that menu item is enabled,
>>>> and since determining the enabled state of a menu item is usually
>>>> equivalent to the Halting Problem, it's even difficult to do proper
>>>> tool support for such a situation).
>>
>>>>These are just the things off the top of my head. I'm quite sure that
>>>>this list is very, very non-exhaustive.
>>
>>>A fascinating enumeration. :-)
>>
>>Not to anyone using Eve, Flapjax, or Cello, except as a reminder of how
>>much pain we are no longer enduring.
>>
>>kt
>>
>>--http://www.theoryyalgebra.com/
>>
>>"Mother always told me, if you tell a lie,
>>always rehearse it. If it don't sound good
>>to you, it won't sound good to no one else."
>> - Satchel Paige- Hide quoted text -
>>
>>- Show quoted text -- Hide quoted text -
>>
>>- Show quoted text -
>
>
> Cells or Cello might be the solution. But getting mad at people won't
> help.
Thanks for your concern!
Not to worry, I abuse these yobbos for fun, not out of anger. And I am
not sure c.l.l would know what to do with KGK (Kindler Gentler Kenny),
but...
In all seriousness, I understand completely how folks can be blind to
something staring them in the face, because I did it in spades. My RtL
details a mad search for Something Better during which I quickly flipped
past the /full page/ ad for MCL in every APDA catalog every time I read
them, even tho the project I wanted SB for was prototyped in Logo!! A
whack of the Zen stick from Jeffrey Kane on macdev had me ordering a
$500 copy 5 minutes later, almost exactly twelve years ago -- Columbus
Day, 1995.
And I cannot even complain about my market penetration. Cells-Gtk is
alive and well under the capable shepherdry of Peter Denno:
http://common-lisp.net/project/cells-gtk/
... and I get a nice mention here:
http://peak.telecommunity.com/DevCenter/Trellis#the-implementation
Other things like Adobe's Adam (C++) and Flapjax (Scheme?) reassure me
that the idea is getting through, and like Lisp it has been a long road,
going back to SketchPad (Sutherland, '63).
The good news for me is that I have absolutely no need to sell Cells or
Cello, I am doing what everyone should be doing with Lisp if not Cells
-- stop worrying about getting other people to use it, use it to make
money. See sig for a link to my Cello-based upcoming release (in beta --
nah, alpha, I know it does not work -- now if anyone is interested in
helping out).
kenny
--
http://www.theoryyalgebra.com/
"Career highlights? I had two. I got an intentional walk
from Sandy Koufax and I got out of a rundown against the Mets."."
- Bob Uecker
Ken Tilton wrote:
>
> Not to worry, I abuse these yobbos for fun, not out of anger.
Well, nice to hear that you're enjoying yourself.
Personally, I'm thoroughly unimpressed by the act of
abusing others for one's own entertainment.
(Perhaps I'm overly sensitive because I don't frequent
comp.lang.lisp, but only get a whiff of this kind of
attitude when it crosses over to comp.lang.functional.)
I contributed one post to this thread, referring to
Joe Armstrong's GUI toolkit in Erlang. I mentioned that
it has failed to gain support. It was not because the
programming model wasn't excellent - it was. It was because
most prospective users would not be interested until it
could compete aesthetically with mainstream GUIs. No-one
doubted that it could be done elegantly, but no-one
volunteered to put in the enormous amount of work required.
Amazingly, the whole discussion played out without insults.
BR,
Ulf W
From: Ken Tilton
Subject: Re: on the strange weakness of Graphical User Interface Languages
Date:
Message-ID: <AlLQi.1235$CR4.560@newsfe12.lga>
Ulf Wiger wrote:
> Ken Tilton wrote:
>
>>
>> Not to worry, I abuse these yobbos for fun, not out of anger.
>
>
> Well, nice to hear that you're enjoying yourself.
> Personally, I'm thoroughly unimpressed by the act of
> abusing others for one's own entertainment.
Well the yobbos like it. It's a kinky little S&M/bondage/domination
thing they're into.
>
> (Perhaps I'm overly sensitive because I don't frequent
> comp.lang.lisp, but only get a whiff of this kind of
> attitude when it crosses over to comp.lang.functional.)
>
> I contributed one post to this thread, referring to
> Joe Armstrong's GUI toolkit in Erlang. I mentioned that
> it has failed to gain support. It was not because the
> programming model wasn't excellent - it was. It was because
> most prospective users would not be interested until it
> could compete aesthetically with mainstream GUIs. No-one
> doubted that it could be done elegantly, but no-one
> volunteered to put in the enormous amount of work required.
We call that the "waiting for the open source fairy" phenomenon. I just
abuse the hell out of people who expect me to not only produce
astonishing open source toolkits but then /document/ them, too. Me and
Joe are out here breaking our nuts for you ungratefful, whining... oh,
what's the use?
>
> Amazingly, the whole discussion played out without insults.
Oh, c.l.l is much more fun than that. We have a kennel full of hounds to
run down unsatisfactory posters, a glue factory for melting down the
ones that don't get away from the hounds, black helicopters for those
that do -- hey, make yourself useful, tell us the secret: how did you
get rid of Harrop?
Thx, kenny
--
http://www.theoryyalgebra.com/
"Career highlights? I had two. I got an intentional walk
from Sandy Koufax and I got out of a rundown against the Mets."."
- Bob Uecker
Ken Tilton wrote:
>
> We call that the "waiting for the open source fairy" phenomenon. I
> just abuse the hell out of people who expect me to not only produce
> astonishing open source toolkits but then /document/ them, too.
I know all about it. I've spent lots of time contributing
to Open Source, with varying degrees of success. Some of
my contributions perhaps didn't get the following I thought
they deserved - others got more than they deserved IMO. In
neither case am I prepared to say anything derogatory about
those who did or did not decide to go along with my ideas.
In fact, I've been both astonished and grateful on the
occasions where people have taken my half-baked contributions
and made them into something much more than they originally
were. This is something that you can never demand that people
do for free.
> Me and Joe are out here breaking our nuts for you ungratefful,
> whining... oh, what's the use?
Indeed, and assuming that by "you", you are including me, I'd
suggest that you are jumping to conclusions. You most likely
haven't spent any time finding out about my track record in
industry and Open Source, and you probably know nothing of
my relationship to Joe. But by all means - bash away. I wrote
that I was unimpressed, but I'm not quite that easily
insulted.
>> Amazingly, the whole discussion played out without insults.
>
> Oh, c.l.l is much more fun than that. We have a kennel full of hounds
> to run down unsatisfactory posters, a glue factory for melting down
> the ones that don't get away from the hounds, black helicopters for
> those that do -- hey, make yourself useful, tell us the secret: how
> did you get rid of Harrop?
Why would we want to get rid of him? He's a productive and
knowledgeable member of the FPL community.
Now, if you don't mind, I'll spend some time trying ot answer
Jon's question, as it was both polite and well formulated.
BR,
Ulf W
On 2007-10-16 04:52:22 -0400, Ulf Wiger <·········@e-r-i-c-s-s-o-n.com> said:
> Ken Tilton wrote:
[snip]
>> tell us the secret: how
>> did you get rid of Harrop?
>
> Why would we want to get rid of him? He's a productive and
> knowledgeable member of the FPL community.
Because he is an obvious spammer - banned from Wikipedia for spamming
for example, and constantly spamming an irrelevant newsgroup, c.l.l
with adds for his services relating to languages which are *not lisp*.
Raffael Cavallaro wrote:
> On 2007-10-16 04:52:22 -0400, Ulf Wiger <·········@e-r-i-c-s-s-o-n.com>
> said:
>
>> Ken Tilton wrote:
> [snip]
>>> tell us the secret: how
>>> did you get rid of Harrop?
>>
>> Why would we want to get rid of him? He's a productive and
>> knowledgeable member of the FPL community.
>
> Because he is an obvious spammer - banned from Wikipedia for spamming
> for example, and constantly spamming an irrelevant newsgroup, c.l.l
> with adds for his services relating to languages which are *not
> lisp*.
The fact that some people on c.l.l. have issues with Jon
has hardly escaped anyone reading c.l.f., but that's your
fight. I've been following c.l.f. for several years now,
and have recently started tracking the caml-list. Jon is
a visible member of both forums, but doesn't seem to have
any problem living up to the standards of either.
I have no quarrel with Jon, and people for whom I have the
highest regard have praised some of his work. That goes
a fair way in my book, and I cannot claim to understand
the cultures of c.l.l. and Wikipedia.
Besides, I have personally experienced being branded, both
unfairly (IMHO) and sometimes outright maliciously. At times
like that, I've been grateful for those who have trusted their
own experience of my work and character. Also for this reason,
I'm very much against maligning others in public.
BR,
Ulf W
From: Duane Rettig
Subject: Re: on the strange weakness of Graphical User Interface Languages
Date:
Message-ID: <o03awbhw9f.fsf@gemini.franz.com>
Ulf Wiger <·········@e-r-i-c-s-s-o-n.com> writes:
> Raffael Cavallaro wrote:
>> On 2007-10-16 04:52:22 -0400, Ulf Wiger
>> <·········@e-r-i-c-s-s-o-n.com> said:
>>
>>> Ken Tilton wrote:
>> [snip]
>>>> tell us the secret: how
>>>> did you get rid of Harrop?
>>>
>>> Why would we want to get rid of him? He's a productive and
>>> knowledgeable member of the FPL community.
>> Because he is an obvious spammer - banned from Wikipedia for spamming
>> for example, and constantly spamming an irrelevant newsgroup, c.l.l
>> with adds for his services relating to languages which are *not
>> lisp*.
>
> The fact that some people on c.l.l. have issues with Jon
> has hardly escaped anyone reading c.l.f., but that's your
> fight.
It becomes your fight, too, when he cross-posts to c.l.l and c.l.f and
you have to see the fallout from the inappropriate (from our point of
view) posting.
I've been following c.l.f. for several years now,
> and have recently started tracking the caml-list. Jon is
> a visible member of both forums, but doesn't seem to have
> any problem living up to the standards of either.
That's fine, and he can post there to his heart's content with no
repercussions. When he posts to c.l.l, it is almost always
inappropriate.
> I have no quarrel with Jon, and people for whom I have the
> highest regard have praised some of his work. That goes
> a fair way in my book, and I cannot claim to understand
> the cultures of c.l.l. and Wikipedia.
I also have no knowledge of Wikipedia's censure, and it makes no
difference to us in c.l.l (except perhaps to demonstrate that the
abuse is not limited to some particular group of overly-sensitive
geeks). But is it so hard to understand that in comp.lang.lisp, we
prefer to talk about Lisp?
> Besides, I have personally experienced being branded, both
> unfairly (IMHO) and sometimes outright maliciously. At times
> like that, I've been grateful for those who have trusted their
> own experience of my work and character. Also for this reason,
> I'm very much against maligning others in public.
I don't much see him being maligned, from our point of view. We do
joke about his company's name in an attempt to cope with the fact that
we can't do anything about his unwelcome presence. And we do question
his honesty (or perhaps even downright deny it) for his presence in
our group, so that might be considered maligning, in the sense of
being negative. But if the negative talk is true, is it really
maligning?
--
Duane Rettig ·····@franz.com Franz Inc. http://www.franz.com/
555 12th St., Suite 1450 http://www.555citycenter.com/
Oakland, Ca. 94607 Phone: (510) 452-2000; Fax: (510) 452-0182
From: Thomas Lindgren
Subject: Re: on the strange weakness of Graphical User Interface Languages
Date:
Message-ID: <87k5pnghsx.fsf@dev.null>
Ulf Wiger <·········@e-r-i-c-s-s-o-n.com> writes:
> The fact that some people on c.l.l. have issues with Jon
> has hardly escaped anyone reading c.l.f., but that's your
> fight. I've been following c.l.f. for several years now,
> and have recently started tracking the caml-list. Jon is
> a visible member of both forums, but doesn't seem to have
> any problem living up to the standards of either.
>
> I have no quarrel with Jon, and people for whom I have the
> highest regard have praised some of his work. That goes
> a fair way in my book, and I cannot claim to understand
> the cultures of c.l.l. and Wikipedia.
Well, Ulf, you _are_ crossposting into c.l.l at the moment. I'm afraid
my experience with that guy is far less positive. For example:
"If you want your code to work, choose static typing. If you're getting paid
in cash for lashing together porn sites, choose dynamic typing."
-- Jon Harrop, <···············@corp.supernews.com>
(http://groups.google.com/group/comp.lang.lisp/msg/4280255847a66414?dmode=source)
Plenty more of the same careful, even-handed, well-informed reasoning
where that came from, in thread after thread. So, a zealot and a
preacher, not a useful contributor. But, it should be said, one that
does at least love his ray tracer.
Best,
Thomas
--
Thomas Lindgren "It was all very mechanical -- but
that's the way planetside life is." -- RAW
Thomas Lindgren wrote:
> Ulf Wiger <·········@e-r-i-c-s-s-o-n.com> writes:
>
>> The fact that some people on c.l.l. have issues with Jon
>> has hardly escaped anyone reading c.l.f., but that's your
>> fight. I've been following c.l.f. for several years now,
>> and have recently started tracking the caml-list. Jon is
>> a visible member of both forums, but doesn't seem to have
>> any problem living up to the standards of either.
>>
>> I have no quarrel with Jon, and people for whom I have the
>> highest regard have praised some of his work. That goes
>> a fair way in my book, and I cannot claim to understand
>> the cultures of c.l.l. and Wikipedia.
>
> Well, Ulf, you _are_ crossposting into c.l.l at the moment.
> I'm afraid my experience with that guy is far less
> positive. For example:
>
> ...
Fine, but I'm not interested in joining a crusade against
anyone. I've seen a number of quotes intended to prove
that Jon is a troll in c.l.l. I mentioned previously that
I don't read c.l.l. It could well be that it's perfectly
OK in that forum to bash and insult people at will, as
long as your post somehow pertains to Lisp - I don't
know. I'm not prepared to pass judgment on people based
on snippets from a forum that I'm not familiar with.
Anyway, apologies for letting myself get dragged into
the quarrel. I have no interest in it, nor the time.
I will bow out now.
BR,
Ulf W
From: Ken Tilton
Subject: Re: on the strange weakness of Graphical User Interface Languages
Date:
Message-ID: <NgbRi.98$FE7.36@newsfe12.lga>
Ulf Wiger wrote:
> Thomas Lindgren wrote:
>
>> Ulf Wiger <·········@e-r-i-c-s-s-o-n.com> writes:
>>
>>> The fact that some people on c.l.l. have issues with Jon
>>> has hardly escaped anyone reading c.l.f., but that's your
>>> fight. I've been following c.l.f. for several years now,
>>> and have recently started tracking the caml-list. Jon is
>>> a visible member of both forums, but doesn't seem to have
>>> any problem living up to the standards of either.
>>>
>>> I have no quarrel with Jon, and people for whom I have the
>>> highest regard have praised some of his work. That goes
>>> a fair way in my book, and I cannot claim to understand
>>> the cultures of c.l.l. and Wikipedia.
>>
>>
>> Well, Ulf, you _are_ crossposting into c.l.l at the moment.
>
> > I'm afraid my experience with that guy is far less
> > positive. For example:
>
>>
>> ...
>
>
> Fine, but I'm not interested in joining a crusade against
> anyone.
It's not a crusade against anyone when several members of a movie
theater audience tell someone using a cell phone to STFU.
> I've seen a number of quotes intended to prove
> that Jon is a troll in c.l.l. I mentioned previously that
> I don't read c.l.l.
OK, then maybe you should STFU if you are too lazy to research the
phenomenon for which you have elected yourself ethical monitor.
> It could well be that it's perfectly
> OK in that forum to bash and insult people at will, as
> long as your post somehow pertains to Lisp - I don't
> know.
Nonsense. It does not have to pertain to Lisp.
> I'm not prepared to pass judgment on people based
> on snippets from a forum that I'm not familiar with.
STFAbove.
>
> Anyway, apologies for letting myself get dragged into
> the quarrel. I have no interest in it, nor the time.
> I will bow out now.
Could you /pleeeassseeee/ take Jon with you since you think he is so
wonderful? The problem is that he has no chance of getting hits by
tediously spamming c.l.f, and besides, YDSWYE. c.l.f is a boring empty
niche for the few people who do not understand that functional is a
great paradigm and should be used 95% of the time for all the benefits
we all understand but made the incredibly common mistake of thinking,
Hey! Let's use it for everything! and made entire languages work only
that way except where they realized oh that's silly that won't work and
created monads.
If you don't know what I am talking about, click on that algebra URL in
my sig, my hits are down. <sigh>
kenny
--
http://www.theoryyalgebra.com/
"Career highlights? I had two. I got an intentional walk
from Sandy Koufax and I got out of a rundown against the Mets."."
- Bob Uecker
From: Thomas Lindgren
Subject: Re: on the strange weakness of Graphical User Interface Languages
Date:
Message-ID: <87myui9p37.fsf@dev.null>
Ulf Wiger <·········@e-r-i-c-s-s-o-n.com> writes:
> It could well be that it's perfectly OK in that forum to bash and
> insult people at will, as long as your post somehow pertains to Lisp
> - I don't know.
C.l.l. has a long history of people coming over to say nasty things
about Lisp and related topics (sometimes over and over), and has
admittedly developed a culture of answering back in kind. But I
wouldn't say it's thereby welcomed.
Best,
Thomas
--
Thomas Lindgren "It was all very mechanical -- but
that's the way planetside life is." -- RAW
From: Damien Kick
Subject: Re: on the strange weakness of Graphical User Interface Languages
Date:
Message-ID: <13iq5oblfu64p2c@corp.supernews.com>
Ulf Wiger wrote:
> Raffael Cavallaro wrote:
>> On 2007-10-16 04:52:22 -0400, Ulf Wiger
>> <·········@e-r-i-c-s-s-o-n.com> said:
>>
>>> Ken Tilton wrote:
>> [snip]
>>>> tell us the secret: how did you get rid of Harrop?
>>>
>>> Why would we want to get rid of him? He's a productive and
>>> knowledgeable member of the FPL community.
>>
>> Because he is an obvious spammer - banned from Wikipedia for spamming
>> for example, and constantly spamming an irrelevant newsgroup, c.l.l
>> with adds for his services relating to languages which are *not
>> lisp*.
>
> The fact that some people on c.l.l. have issues with Jon
> has hardly escaped anyone reading c.l.f., but that's your
> fight.
You know, that's another reason for me not to like you. That rumhead
spent twenty years in jail for poisoning a kid. If you know him, you
must be a jailbird yourself. Would you show these gentlemen to the door?
> I've been following c.l.f. for several years now,
> and have recently started tracking the caml-list. Jon is
> a visible member of both forums, but doesn't seem to have
> any problem living up to the standards of either.
Of course, it isn't too surprising that DDT would have no problems
living up to the standards of a forum like caml-list as writing about
OCaml on caml-list would seem to be <pause> rather /on/ topic.
> [...] and I cannot claim to understand the cultures of c.l.l. and
> Wikipedia.
Fair enough. But then why the apologetic on c.l.l? You seem happy with
FPL and FPL seems quite happy with DDT. You can keep him. Please.
Hey! Get me! I'm giving out wings!
From: Jon Harrop
Subject: Re: on the strange weakness of Graphical User Interface Languages
Date:
Message-ID: <13hbdldi83r76f3@corp.supernews.com>
Raffael Cavallaro wrote:
> ...banned from Wikipedia for spamming...
Misinformation.
I think what you mean is that a crusade of Lispers tried and failed to get
me banned from Wikipedia. Apparently, they also tried and failed to get me
banned from c.l.lisp by approaching my ISP. They have now retreated into
posting fake reviews of my work. They are easily spotted though, being the
only negative reviews...
> ...adds for his services relating to languages which are *not lisp*.
If someone like "are" posts on c.l.lisp with a subject "Lisp and OCaml" only
to be overrun with misinformation about OCaml from the Lisp community, what
is wrong with me pointing out the faults in their arguing and flaws in
their favourite language that were fixed in ML/Haskell?
From your line of arguing here, for example, it sounds like you would rather
hear an opinion from someone who hadn't written the book on the subject...
--
Dr Jon D Harrop, Flying Frog Consultancy
http://www.ffconsultancy.com/products/?u
From: Jon Harrop
Subject: Re: on the strange weakness of Graphical User Interface Languages
Date:
Message-ID: <13h7a2h1ra81088@corp.supernews.com>
Ulf Wiger wrote:
> I contributed one post to this thread, referring to
> Joe Armstrong's GUI toolkit in Erlang. I mentioned that
> it has failed to gain support. It was not because the
> programming model wasn't excellent - it was. It was because
> most prospective users would not be interested until it
> could compete aesthetically with mainstream GUIs. No-one
> doubted that it could be done elegantly, but no-one
> volunteered to put in the enormous amount of work required.
That's very interesting. Could you explain exactly what it is about Joe's
toolkit that makes it attractive from a programmer's point of view? Does it
separate design from logic so that non-coders can work on the GUI alongside
coders?
Also, would it take much work to write a back end in OCaml that targets
something like Smoke's declarative vector graphics:
http://www.ffconsultancy.com/products/smoke_vector_graphics/
I think it would be great to bridge the current gap between GUI libraries
for Linux and freeform rendering using OpenGL etc...
--
Dr Jon D Harrop, Flying Frog Consultancy
http://www.ffconsultancy.com/products/?u
Jon Harrop wrote:
>
> That's very interesting. Could you explain exactly what it is about
> Joe's toolkit that makes it attractive from a programmer's point of
> view?
That's a good question, although you didn't mention if you
had looked at his paper. I will assume that you have. (:
The thing that is so nice is how it fits into the Erlang
programming model. Erlang is first and foremost a message-
passing language, and X is fundamentally all about message
passing. Joe described a nice way to use lightweight
processes in Erlang to map onto the basic X protocol.
As with many nice ideas in the Erlang community, Torbj�rn
T�rnqvist wrote the first ex11 prototype. Others helped
map all the X11 messages to nice-looking Erlang messages,
and Joe came up with a nice framework around, illustrating
how to write complex widgets on top of it.
All widgets must support a set of generic messages, but are
free to add their own. Each top-level widget has its own
context (its own process), which means that there is no
strange interleaving of events. If your own custom widget
needs to access the lowest-level X protocol, doing so is
unproblematic.
> Does it separate design from logic so that non-coders can work on
> the GUI alongside coders?
I think it follows, but Joe stopped short of clearly
demonstrating this.
Using "middle-man processes" is a common technique in
Erlang. Middle-man processes act as protocol translators,
and can filter out lots of unwanted noise, presenting
the user with just the messages needed for the task.
There were competing initiatives on the GUI front at
the time when ex11 was presented. Mats Cronqvist made
gtkNode (http://www.erlang.se/euc/05/1620cronqvist.pdf),
which uses code generation to generate an Erlang API
to GTK widgets. His approach achieved many of the
niceties of Joe's ex11, but at the same time made pretty
much all of GTK (and e.g. Glade) available to the user,
and as far as I can tell, the support needed since then
has been minimal for Mats.
Not surprisingly, this approach attracted more users. (:
> Also, would it take much work to write a back end in OCaml that targets
> something like Smoke's declarative vector graphics:
>
> http://www.ffconsultancy.com/products/smoke_vector_graphics/
>
> I think it would be great to bridge the current gap between GUI libraries
> for Linux and freeform rendering using OpenGL etc...
I have no answer to this, but perhaps the designers of
Wings3d (http://www.wings3d.com) would.
BR,
Ulf W
On 2007-10-15, Ken Tilton <···········@optonline.net> wrote:
> The good news for me is that I have absolutely no need to sell Cells or
Oh, is that why documentation for Cells is so sparse?
d.
From: Ken Tilton
Subject: Re: on the strange weakness of Graphical User Interface Languages
Date:
Message-ID: <YfOQi.12$l%4.5@newsfe12.lga>
David Lichteblau wrote:
> On 2007-10-15, Ken Tilton <···········@optonline.net> wrote:
>
>
>>The good news for me is that I have absolutely no need to sell Cells or
>
>
> Oh, is that why documentation for Cells is so sparse?
Yes and no. No because it is not sparse, it is thoroughly documented,
partly in... hang on... cells-maifesto.txt, partly over at Cells-Gtk,
partly here, partly there, and how do you, Mr. Lichteblau.
As for a nice neat PDF with roman numerals and everything, well, I think
what you are missing is that that would do nothing to sell Cells, it is
just the lame excuse people give when they need one for not trying
something, like oh golly if you just dropped the price to... no, if you
gave it away and sent me $100.... What happens is you spend a month (by
the time yer done) on glorious documentation and surprise surprise the
same people now have a different reason for not doing X they just wanted
to waste a month of my time by begging and pleading for something they
had no intention of using anyway. Fortunately I knew all this long ago
and ignored their sorry whining butts and am working hard on adding
library 42 to Cello at 3am when I get this silly email from some guy in
Greece who seems to have downloaded Cells and created Cells-Gtk without
even telling me never mind without asking ONE LOUSY QUESTION. Sorry. And
you think Cells needs documentation? What I think is that His Kennyness
did such a beautiful job on the library that a child of three could Just
Use It, having of course the advantage of being a child of three and not
knowing they cannot possibly use it without roman numerals and tables of
contents and BNF grammars and crap.
hth, kenny
Meanwhile, AllegroCLs regex package is thoroughly and brilliantly
documented and includes exactly forty characters of example by mistake
because they were trying to make some other point, while Cells has Celtk
(from which Vasily was able to clone Cells-Gtk), Cells-Gtk, Cello, the
regression test, and why oh why do I bother with you people!!???
kt
--
http://www.theoryyalgebra.com/
"Career highlights? I had two. I got an intentional walk
from Sandy Koufax and I got out of a rundown against the Mets."."
- Bob Uecker
From: Joachim Durchholz
Subject: Re: on the strange weakness of Graphical User Interface Languages
Date:
Message-ID: <fet6t5$n7p$1@online.de>
Jon Harrop schrieb:
> Joachim Durchholz wrote:
>> dkf schrieb:
>>> Out of curiosity, what are those "broken, hard wired assumptions"?
>> Stuff like:
>> * Grid cells, treeview labels, and menu entries can have only text.
>> Oh, wait, you can have an icon, too. (That's what you have to deal
>> with on Windows. There are workarounds, but they are... ewwww.)
>
> Is that true of Windows Presentation Foundation?
Dunno.
My practical experience is limited to the classic GDI functions.
As far as I can tell from a few cursory looks through the docs, GDI+
(the .net equivalent of GDI) is a lot better but is still limited.
I know even less about WPF, so I'll leave that to others to comment upon.
>> * You don't get back all the parameters of a control.
>> * You don't get all the relevant dimensions of a control.
>> (E.g. for a text input control, you need outer borders, inner borders,
>> the position of the actual text area, and the text baseline.)
>
> And that's just for Latin derivatives....
Oh, right. It would be interesting to see what the requirements for a
vertical script are. And whether it would be culturally acceptable to
use horizontal lines anyway. (How would a Japanese quote an Englisch
name when writing vertically? I don't have the faintest idea...)
>> (The "broken assumption" in the "you don't get" items is that the
>> programmer will never need these values. Try to line up a label's
>> base line with the base line of a text input field and you know what
>> I mean.)
>
> That problem plagues HTML even more, IMHO.
I'd say that's a deficit of the rendering engines.
Which in turn seem to have given up on the issue because the native
toolkits don't support baseline positioning. (Well, GDI doesn't. I don't
know how it would be on X or whatever.)
>> Sometimes, however, doing things orthogonally is hard, really hard, or
>> even really d***ed hard:
>> * Fill a grid column with a tree view.
>> * Make a dialog automatically adapt to size changes.
>> (Doing this well means you need a constraint solver.
>> OTOH having a constraint solver in the standard library seems a good
>> idea for other purposes, so...)
>
> Interesting...
The GUI framework I have worked on had some size adaptation techniques,
and it turned out that the thing became immensely complicated after
acquiring too many ways to let the constraint information flow. We had
all kinds of problems propagating the constraints across the container
hierarchy: endless cycles, surprising effects, overcomplicated and
moderately difficult-to-maintain code that worsened little by little,
and the rare case where a desired behaviour couldn't be easily
expressed. A constraint solver would have been just as complicated as
what we had, but it wouldn't have had that complication creep.
(I even explored possibilities to retrofit a constraint solver, but the
project was dropped. Part of this was that it would have pushed our time
budget, but more important was that it would have been difficult to
display and handle the constraints in the designer application. I.e.
you'd want to attach the constraints to the containers and controls that
the user sees on the screen, but trying to draw numerous constraints in
the same screen space gets you into placement conflicts. Getting this
all polished would have been definitely too much work for the workforce
at hand.)
That constraint solvers are interesting beyond that areas is a van
Roy/Haridi influence:
Peter van Roy, Seif Haridi: Concepts, Techniques, and Models of Computer
Programming. The MIT Press, April 2004.
Regards,
Jo
Joachim Durchholz wrote:
> * Make a dialog automatically adapt to size changes.
> (Doing this well means you need a constraint solver.
> OTOH having a constraint solver in the standard library seems a good
> idea for other purposes, so...)
As soon as this thread started I just thought about whatever I have seen
with the CSS mechanism (or standard) for web page layouts. I did not
write anything since all the talk seemed to be mostly about control.
I guess for UI there are at least two aspects - control and layout and
you brought up layout.
I have done a little bit of work (a long time ago) in Tk and Java swing.
Both have layout managers as far I can remember.
In CSS that seems to be missing. In other words there is an implicit
layout manager.
And then there is the all holy thing about not using tables even when
you want tabular layout
Composing disparate pieces together in a layout using CSS seems to be
difficult.
It has has funny interaction with html standard. They say contents and
layout are different and then they go on to say div is a block element
and you can't have block html element in a inline html element.
Anyways this is random mumbling, but the point I am trying to make is
I find CSS hard to learn and use. It may be because I am not capable or
because people who create those things may be don't give sufficient
thought to coming up with what constitutes primitives (point of this
thread ?)
Anyway I have no idea if all this makes sense, all I know is CSS is hard
to reason with.
Why is this all relevant to lisp. I don't know, except writing such
things in a css newsgroup will probably get me about 1000 replies on how
to do table layout using float style.
-Antony
From: Jon Harrop
Subject: Re: on the strange weakness of Graphical User Interface Languages
Date:
Message-ID: <13gv2kfrde383d8@corp.supernews.com>
Mark Tarver wrote:
> I've been working with TCL/tk and I'm struck at how messy graphical
> languages are. Before anybody jumps on TCL/tk, or starts advertising
> their solution I don't think that it is *that* language that is
> specifically to blame. I'm seeing the same thing in Visual Basic and
> in CLIM and indeed in every GUIL I've looked at...
I've not done much work on GUIs but I found OCaml's LablGTK interface to be
good and F#'s interface (with Intellisense) to Windows Forms to be
excellent.
I'm sure there is plenty of scope for improvement though. As you say, GUI
APIs tend to be very complex and this is where functionality like
Intellisense really pays off.
YMMV.
--
Dr Jon D Harrop, Flying Frog Consultancy
http://www.ffconsultancy.com/products/?u
From: Ulf Wiger
Subject: Re: on the strange weakness of Graphical User Interface Languages
Date:
Message-ID: <470F7B2B.90205@e-r-i-c-s-s-o-n.com>
Mark Tarver wrote:
>
> FPLs
>
> 1. A well defined theory of Turing equivalence
> 2. A small number of primitives and
> 3. A powerful means of combination
>
> When you come to GUILs the position is reversed. You have this vaguer
> idea of computational adequacy which means that the GUIL can do the
> things you want. But the primitives are nowhere in sight
> and what you are given is a grab-bag of tools for making buttons and
> various widgets. Since the user's wish list is indefinitely large,
> GUILs become bloated and you end with 1000 page manuals of commands,
> hacks and hooks of every descripton. Reminiscent of PL/1 actually.
> So what you have is 'the wrong thing'.
>
> GUILs
> 1. A vague idea of computational adequacy.
> 2. A huge number of primitives.
> 3. A weak means of combining together.
>
> Now I sat down and wondered why that was. Was the field inherently
> just a big intellectual hack, or have human beings made a mess of it.
> I decided that was probably more that human beings made a mess of it
> and that there was a much more elegant approach. We had to begin with
> a formal theory of widgets and by asking dumb-sounding but actually
> deeply serious questions like 'What is a window'?
Joe Armstrong wrote a paper a few years ago, describing a
mapping to the X protocol. The approach is perhaps fairly
specialized towards Erlang, but he made an interesting
observation:
- the X protocol is simple (154 mostly simple messages)
- XLib is more complex (800+ routines)
- Motif et al are hideously complex
The Erlang/Joe take on this is that the underlying semantics
is a naturally concurrent message passing system, but the
widget sets go to great lengths to hide the inherent
concurrency.
http://www.erlang.se/workshop/2004/ex11.pdf
Perhaps the current mess is a result of this sort of
evolution. While Joe's approach felt pretty natural in
Erlang, the approach you suggest might be equally successful.(*)
BR,
Ulf W
(*) Joe's approach was only conceptually successful. His
GUI toolkit didn't get any followers - too much work to make
it into a competitive framework.
From: Joachim Durchholz
Subject: Re: on the strange weakness of Graphical User Interface Languages
Date:
Message-ID: <feo1lb$o6f$1@online.de>
Mark Tarver schrieb:
> GUILs
> 1. A vague idea of computational adequacy.
> 2. A huge number of primitives.
> 3. A weak means of combining together.
>
> Now I sat down and wondered why that was. Was the field inherently
> just a big intellectual hack, or have human beings made a mess of it.
The end users have contributed a large part of this.
I.e. it's ergonomics. Worse, it's ergonomics not for a small set of
people who share a lot of ideas and ideals (as would be the case for
programming language ergonomics), it's for the far larger set of
"anybody who is ever going to use the computer". And doing ergonomics
for a large, varied group of individuals is a messy process.
The other party who has been contributing to the mess is programmers.
Far too many programmers know about ergonomics. They *think* they know
ergonomics because they themselves are users, but eating your own dog
food only tells you something about how well it is for you and people
like you - if you're programming for end users, you need to do
laboratory studies with dummies from the street. And that's beyond what
most programmers do, or have been taught to do.
(I just recently came across reports from such a testing lab. One test
was when programmers watched users through a one-way mirror. The more
emotional scenes were those *behind* the mirror, when the programmer
shouted "press that button, you i***t!" ...)
Of course, GUILs are often far more complicated than necessary.
On the other hand, you can't simply just set up a widget hierarchy; this
interferes badly with stuff like tab order. Things get worse if the
programmer's hierarchy deviates from the perceived hierarchy (i.e. if
you have invisible containers).
> And I think that this is not only a shame but
> indicative of a problem with FP in general. Its not so much that the
> FP paradigm is weak and incapable of doing the task, it is that as
> functional programmers we're very much boxed in by the decisions of
> the people who designed the environment within which our work is
> embedded. It's very very difficult to do the right thing when
> everything around you is doing the wrong thing.
GUI libraries are just as messy as GUI languages.
I think the problem lies more with GUI interfaces in general rather than
with any specific technology trying to wrap it.
I have spent three years working on and co-developing a GUI library. I
know how the Windows API looks like, and what comes of it if you try to
wrap the stuff in an object-oriented framework. I have looked at
alternatives to what we were doing, and they were either not flexible
enough or too complicated.
Regards,
Jo
In article <························@t8g2000prg.googlegroups.com>,
Mark Tarver <··········@ukonline.co.uk> wrote:
...
> GUILs become bloated and you end with 1000 page manuals of commands,
> hacks and hooks of every descripton. Reminiscent of PL/1 actually.
Right, how much better is ANSI Common Lisp with its tiny spec
and elegant language!
> So what you have is 'the wrong thing'.
see above.
On 13 Oct, 15:01, Rainer Joswig <······@lisp.de> wrote:
> In article <························@t8g2000prg.googlegroups.com>,
> Mark Tarver <··········@ukonline.co.uk> wrote:
>
> ...
>
> > GUILs become bloated and you end with 1000 page manuals of commands,
> > hacks and hooks of every descripton. Reminiscent of PL/1 actually.
>
> Right, how much better is ANSI Common Lisp with its tiny spec
> and elegant language!
>
> > So what you have is 'the wrong thing'.
>
> see above.
You know that Richard Gabrial, shortly after the CL spec appeared,
criticised CL as overblown and I think he was right? I think that it
would have been better for CL if the committee had been more ruthless
in paring down CL and hiving a lot of those functions into libraries.
But nevertheless there is power under the fat,
and some solid theory. The right thing is there deep inside - a thin
man trying to get out. I don't know if the same is true elsewhere.
Mark
Mark
In article <·······················@e34g2000pro.googlegroups.com>,
Mark Tarver <··········@ukonline.co.uk> wrote:
> On 13 Oct, 15:01, Rainer Joswig <······@lisp.de> wrote:
> > In article <························@t8g2000prg.googlegroups.com>,
> > Mark Tarver <··········@ukonline.co.uk> wrote:
> >
> > ...
> >
> > > GUILs become bloated and you end with 1000 page manuals of commands,
> > > hacks and hooks of every descripton. Reminiscent of PL/1 actually.
> >
> > Right, how much better is ANSI Common Lisp with its tiny spec
> > and elegant language!
> >
> > > So what you have is 'the wrong thing'.
> >
> > see above.
>
> You know that Richard Gabrial, shortly after the CL spec appeared,
> criticised CL as overblown and I think he was right? I think that it
> would have been better for CL if the committee had been more ruthless
> in paring down CL and hiving a lot of those functions into libraries.
> But nevertheless there is power under the fat,
> and some solid theory. The right thing is there deep inside - a thin
> man trying to get out. I don't know if the same is true elsewhere.
I fail to see how that is different from GUI toolkits.
Take 'widgets'. There is a description of how they work and
a 'protocol' to use and extend them. Then there is a library
of widget implementations (buttons, pop-up menus, tables,
text display, text edit, lists, tables, scrollers, icons,
images, tree displays, and so on. To use them you only need
to understand the basic principles and then you take the
items you need for your application. Take windows.
There are basic principles how windows work, how you create
them, how you put objects into windows and so on. Then there
is a library of window types (modal dialogs, floating windows,
windows with scrollbars, windows with subpanes, different
borders, ...). Again you don't have understand all that
to create a basic window and draw some stuff inside.
Same for graphics. There is a drawing protocol (say something
based on postscript) and then there is a library of
drawing primitives and modifiers to those (lines, curves,
rectangles, patterns, dashes, color, ...). Again you
don't need to know all colors and shapes to pick one, a rectangle,
and draw it with a border and a fill color.
It's all basic principles and a library implemented
according to those: windows, widgets, events, colors,
shapes, transformations, ...
It is the same in Lisp: there are principles how Lisp works
( ;-) ) and then you have all kinds of datastructures:
strings, characters, hashtables, arrays, lists, sequences, ...
Maybe the 'strange weakness' is only because you didn't had
the time to read a bit more about GUI toolkits and try to find
some structure?
>
> Mark
>
> Mark
On 13 Oct, 18:02, Rainer Joswig <······@lisp.de> wrote:
> In article <·······················@e34g2000pro.googlegroups.com>,
> Mark Tarver <··········@ukonline.co.uk> wrote:
>
>
>
>
>
> > On 13 Oct, 15:01, Rainer Joswig <······@lisp.de> wrote:
> > > In article <························@t8g2000prg.googlegroups.com>,
> > > Mark Tarver <··········@ukonline.co.uk> wrote:
>
> > > ...
>
> > > > GUILs become bloated and you end with 1000 page manuals of commands,
> > > > hacks and hooks of every descripton. Reminiscent of PL/1 actually.
>
> > > Right, how much better is ANSI Common Lisp with its tiny spec
> > > and elegant language!
>
> > > > So what you have is 'the wrong thing'.
>
> > > see above.
>
> > You know that Richard Gabrial, shortly after the CL spec appeared,
> > criticised CL as overblown and I think he was right? I think that it
> > would have been better for CL if the committee had been more ruthless
> > in paring down CL and hiving a lot of those functions into libraries.
> > But nevertheless there is power under the fat,
> > and some solid theory. The right thing is there deep inside - a thin
> > man trying to get out. I don't know if the same is true elsewhere.
>
> I fail to see how that is different from GUI toolkits.
I'm getting a kind of fatigue here - look at what Raffael Cavallero is
saying in post 27. on this thread - which is what I think said in a
different way. And Rob St Armant lowdown on GUILs in post 3. Look at
what I say in post 1. and especially what I said in response to
clarification of my position to Kenny Tilton in post 11. What I am
saying does not revolve around the size of Lisp and nor do their
comments either.
> Take 'widgets'. There is a description of how they work and
> a 'protocol' to use and extend them. Then there is a library
> of widget implementations (buttons, pop-up menus, tables,
.> ..............Maybe the 'strange weakness' is only because you
didn't had
> the time to read a bit more about GUI toolkits and try to find
> some structure?
I read TCL/tk pretty well and lo I can make buttons in a thousand
febrile shapes and colours in Qi/tk - all type secure of course. Look
here are some
http://www.lambdassociates.org/qi%2Dtk%2Dpreview/widget4.htm
I don't know if thats enough for you; but I can do the same for menus,
labels, lines etc etc. All of which of course is *totally* irrelevant
to my original post - any more than the pictures Kenny posts are
relevant to this thread. My beef is not coming from 'I can't do this
GUI stuff in Qi so I'm going to sulk'. I can do it and I see the
holes. A picture is not worth a thousand words in this case.
Mark
In article <························@e9g2000prf.googlegroups.com>,
Mark Tarver <··········@ukonline.co.uk> wrote:
...
> > Take 'widgets'. There is a description of how they work and
> > a 'protocol' to use and extend them. Then there is a library
> > of widget implementations (buttons, pop-up menus, tables,
> .> ..............Maybe the 'strange weakness' is only because you
> didn't had
> > the time to read a bit more about GUI toolkits and try to find
> > some structure?
>
> I read TCL/tk pretty well and lo I can make buttons in a thousand
> febrile shapes and colours in Qi/tk - all type secure of course. Look
> here are some
>
> http://www.lambdassociates.org/qi%2Dtk%2Dpreview/widget4.htm
>
> I don't know if thats enough for you; but I can do the same for menus,
> labels, lines etc etc. All of which of course is *totally* irrelevant
> to my original post - any more than the pictures Kenny posts are
> relevant to this thread. My beef is not coming from 'I can't do this
> GUI stuff in Qi so I'm going to sulk'. I can do it and I see the
> holes. A picture is not worth a thousand words in this case.
Which holes? I have the feeling that your rant is pointless.
Saying that everybody is doing it wrong makes no sense to me.
Your own words: 'It's very very difficult to do the right thing when
everything around you is doing the wrong thing.' That's not meant
serious, right? I'd hope.
What is a GUIL? Is CLIM one? You mentioned it. I fail to
see how it relates to what you say.
Basically many GUI Toolkits and the languages are using
some kind of object-oriented approach. There is some
mismatch with functional languages. But that does not make
the approach of the GUIL (whatever that is) 'wrong'.
Take CLIM. It goes a long way to provide the primitives
in many part of the domain 'constructing guis'. It
does more than most users will ever need by developing
a theory for example how windows and their subcomponents
are related (see Silica), how this can be extended and combined.
CLIM actually gives an answer for 'what is a window'. One
might not like the answer, but there is one.
There are quite a few other very elegant GUI toolkits.
That FP may not fit well with those is a problem of FP,
not of the toolkits. If you don't like the situation,
provide an idea what do you want to fix how. Otherwise your
rant is just going nowhere.
>
> Mark
On 2007-10-13 20:13:04 +0100, Rainer Joswig <······@lisp.de> said:
> There are quite a few other very elegant GUI toolkits.
>
> That FP may not fit well with those is a problem of FP,
> not of the toolkits. If you don't like the situation,
> provide an idea what do you want to fix how. Otherwise your
> rant is just going nowhere.
With all due respect, it seems that you are missing the point,
which is NOT about the lack of versatile, powerful and diverse
UI toolkits out there, but about the lack of an underlying
*generative* theory.
Given that this lack (or "hole") is already difficult for some
(eg: yourself) to perceive, it would be extremely difficult to
give an example, but as Alan Kay reportedly said: "It is not a
fish that invented water", it is probably the case that the CS/IT
community is too blinded by current practice to even see the
problem.
But look at it that way:
Why should I, the programmer, choose a combo box to
display some choices for the user to enter, when the
real goal is to allow the user to do what he pleases
with the data. Why is it that I can't ask such questions
to the computer: "Please provide the user with ways to
manage this kind of data", and let it decide to come up
with either pre-canned answers (combo box, set of radio
buttons) or "invent" new ones that are more adapted to
the problem+user domain than any preconceived set of
available widgets could ever be?
The question is definitely not about Look and feel, possibly
partially about feel, but certainly about user goals and how
to get help _from the computer_ to get those elements for the
user to play with.
The question is about reasoning in more abstract terms than
what the WIMP describes. For example the late Taligent once
came up with PPT paradigm. This failed in the market place
for various reasons, but certainly not from trying to get
another look at human-computer-interaction.
What's common between MVC, "User OI" (whatever that is) and
PPT? Are they orthogonal? Or subsets? Is there some kind of idea
that could *generate* all three of them and then a few more?
I beleive THAT is the question
--
JFB
verec <·····@mac.com> writes:
> On 2007-10-13 20:13:04 +0100, Rainer Joswig <······@lisp.de> said:
>
>> There are quite a few other very elegant GUI toolkits.
>>
>> That FP may not fit well with those is a problem of FP,
>> not of the toolkits. If you don't like the situation,
>> provide an idea what do you want to fix how. Otherwise your
>> rant is just going nowhere.
>
> With all due respect, it seems that you are missing the point,
> which is NOT about the lack of versatile, powerful and diverse
> UI toolkits out there, but about the lack of an underlying
> *generative* theory.
>
> Given that this lack (or "hole") is already difficult for some
> (eg: yourself) to perceive, it would be extremely difficult to
> give an example, but as Alan Kay reportedly said: "It is not a
> fish that invented water", it is probably the case that the CS/IT
> community is too blinded by current practice to even see the
> problem.
Rainer's comments are well-taken; personally, I think that the search
for a theory of user interaction can proceed independently of the
development of better environments for designing and implementing user
interfaces.
On the former point, there's actually a fair amount of interest in
such a theory, both in the abstract and toward practical ends. One
project (which as far as I know is no longer active) focused on XIML,
an extensible interface markup language. I've seen a few nice demos:
for example, you might have a window that shows a bar chart with axes,
each bar annotated by a numerical value corresponding to its height.
You shrink the window, and the chart shrinks, with the annotations
disappearing when the window grows too small; at some point the
graphics are replaced by a single number representing the mean of all
the data. Obviously a huge amount of semantics needs to be included
in the representation, above the presentation level, to make this kind
of flexibility possible, but that was what XIML was aiming at.
I pretty much agree with the rest of verec's post, below. Again in my
personal view, I think that the two most promising current avenues are
in cognitive modeling (on the psychology side of HCI) and in formal
modeling (as done by the more mathematical people in HCI). Will this
lead to better languages for interaction design? Probably; it's a
separate question whether interface developers will adopt them in
practice.
> But look at it that way:
>
> Why should I, the programmer, choose a combo box to
> display some choices for the user to enter, when the
> real goal is to allow the user to do what he pleases
> with the data. Why is it that I can't ask such questions
> to the computer: "Please provide the user with ways to
> manage this kind of data", and let it decide to come up
> with either pre-canned answers (combo box, set of radio
> buttons) or "invent" new ones that are more adapted to
> the problem+user domain than any preconceived set of
> available widgets could ever be?
>
> The question is definitely not about Look and feel, possibly
> partially about feel, but certainly about user goals and how
> to get help _from the computer_ to get those elements for the
> user to play with.
>
> The question is about reasoning in more abstract terms than
> what the WIMP describes. For example the late Taligent once
> came up with PPT paradigm. This failed in the market place
> for various reasons, but certainly not from trying to get
> another look at human-computer-interaction.
>
> What's common between MVC, "User OI" (whatever that is) and
> PPT? Are they orthogonal? Or subsets? Is there some kind of idea
> that could *generate* all three of them and then a few more?
>
> I beleive THAT is the question
> --
> JFB
In article <·······················@news.aaisp.net.uk>,
verec <·····@mac.com> wrote:
> On 2007-10-13 20:13:04 +0100, Rainer Joswig <······@lisp.de> said:
>
> > There are quite a few other very elegant GUI toolkits.
> >
> > That FP may not fit well with those is a problem of FP,
> > not of the toolkits. If you don't like the situation,
> > provide an idea what do you want to fix how. Otherwise your
> > rant is just going nowhere.
>
> With all due respect, it seems that you are missing the point,
> which is NOT about the lack of versatile, powerful and diverse
> UI toolkits out there, but about the lack of an underlying
> *generative* theory.
Forget generative theories. Nobody programs using Church Numerals.
Any non-trivial software will not be based on the
kernel Lisp functions. Instead it uses objects, functions,
classes, macros, etc. All those are NOT reduced to CAR and CDR.
It just makes no sense.
I don't develop software using the 'generative theory'.
I'm using a programming language and its implementations.
There is a pragmatic blend of all kinds of facilities.
The theory of UI toolkits is mostly based on object orientation.
Containment, Part-Of, ISA, instance creation,
, messages (events), delegation and all that stuff.
You get two buttons in a window by creating three instances
and adding the buttons to the window (containment, part-of).
Buttons will react to events (messages).
Think objects, classes, generic functions, instance generation,
relations, constraints ... there you have your underlying
theory.
> Given that this lack (or "hole") is already difficult for some
> (eg: yourself) to perceive, it would be extremely difficult to
> give an example, but as Alan Kay reportedly said: "It is not a
> fish that invented water", it is probably the case that the CS/IT
> community is too blinded by current practice to even see the
> problem.
No, you want to see everything through one set of glasses.
But the domain is more complex and there are different
mechanism than FP - which does not mean that there
are none - they are just different.
>
> But look at it that way:
>
> Why should I, the programmer, choose a combo box to
> display some choices for the user to enter, when the
> real goal is to allow the user to do what he pleases
> with the data.
That's a fantasy world.
Though CLIM has some elements in that direction.
Called 'Semanticue' in Genera.
> Why is it that I can't ask such questions
> to the computer: "Please provide the user with ways to
> manage this kind of data", and let it decide to come up
> with either pre-canned answers (combo box, set of radio
> buttons) or "invent" new ones that are more adapted to
> the problem+user domain than any preconceived set of
> available widgets could ever be?
First you have to solve akk kunds of AI problem for that.
What you want is far away from practical problems
of creating users interfaces.
> The question is definitely not about Look and feel, possibly
> partially about feel, but certainly about user goals and how
> to get help _from the computer_ to get those elements for the
> user to play with.
This is all research. There hasn't been any useful
answers to these problems. I'd rather solve more
practical problems.
> The question is about reasoning in more abstract terms than
> what the WIMP describes.
CLIM for example talks about abstract 'gestures'.
Then there is some adaption to the underlying UI
(it chooses special implementations or a more general
one, depending on what is available).
But if you have a WIMP, design for a WIMP. If you have
a touch-screen, design for it. Imagining the grand
unified theory of UI will only keep you away from
writing any practical software.
> For example the late Taligent once
> came up with PPT paradigm. This failed in the market place
> for various reasons, but certainly not from trying to get
> another look at human-computer-interaction.
I don't want to solve THE question of human-computer-interaction.
I want to write a news reader for a device with a touch screen.
I want to write a user interface such that somebody
can enter diagnosis rules for a set of devices.
And so on.
That there is some dominant UI paradigm (WIMP, Hypertext Browser, ...),
does not mean that this is completely stupid. Sure we see the constraints
and there are alternatives - but that does not make
programming languages and their UI toolkit 'strangely weak'.
>
> What's common between MVC, "User OI" (whatever that is) and
> PPT? Are they orthogonal? Or subsets? Is there some kind of idea
> that could *generate* all three of them and then a few more?
Who cares?
> I beleive THAT is the question
I believe that is fantasy land.
> --
> JFB
From: Peter Herth
Subject: Re: on the strange weakness of Graphical User Interface Languages
Date:
Message-ID: <fesubf$r9p$02$1@news.t-online.com>
Mark Tarver wrote:
>
> I read TCL/tk pretty well and lo I can make buttons in a thousand
> febrile shapes and colours in Qi/tk - all type secure of course. Look
> here are some
>
> http://www.lambdassociates.org/qi%2Dtk%2Dpreview/widget4.htm
>
Just looking at the source code example, a good start would be a
GUI framework which doesn't require you to put verbatim Tk code
in your Lisp code... :)
Peter
--
Ltk, the easy lisp gui http://www.peter-herth.de/ltk/
On 14 Oct, 12:25, Peter Herth <·······@t-online.de> wrote:
> Mark Tarver wrote:
>
> > I read TCL/tk pretty well and lo I can make buttons in a thousand
> > febrile shapes and colours in Qi/tk - all type secure of course. Look
> > here are some
>
> >http://www.lambdassociates.org/qi%2Dtk%2Dpreview/widget4.htm
>
> Just looking at the source code example, a good start would be a
> GUI framework which doesn't require you to put verbatim Tk code
> in your Lisp code... :)
>
> Peter
>
> --
> Ltk, the easy lisp guihttp://www.peter-herth.de/ltk/
There is an argument for sticking to the TCL/tk attribute-value
vocabulary which is that more people know it than anything I can make
up. And I don't require TCL/tk command string passing by the
programmer. I think
(button .b [-command (delay (output "Hello world"))
-text "Friendly"])
for a button .b that prints "Hello World" and has "Friendly" written
on it
is reasonably clear and concise - don't you think?
Mark
Mark Tarver <··········@ukonline.co.uk> wrote:
> There is an argument for sticking to the TCL/tk attribute-value
> vocabulary which is that more people know it than anything I can make
> up. And I don't require TCL/tk command string passing by the
> programmer. I think
>
> (button .b [-command (delay (output "Hello world"))
> -text "Friendly"])
>
> for a button .b that prints "Hello World" and has "Friendly" written
> on it
> is reasonably clear and concise - don't you think?
In PS/Tk you would write
(define b (tk 'create-widget 'button
'text: "Friendly"
'command: (lambda () (output "Hello World"))))
The advantage of this approach is that the button widget is a
first-class object that is bound to a LISP (or, in this case,
Scheme) variable. This allows you to pass the widget around
and address it directly at a later time, without having to
remember its Tcl name:
(b 'configure 'state: 'active)
--
Nils M Holm <n m h @ t 3 x . o r g> -- http://t3x.org/nmh/
Mark Tarver wrote:
> There is an argument for sticking to the TCL/tk attribute-value
> vocabulary which is that more people know it than anything I can make
> up. And I don't require TCL/tk command string passing by the
> programmer. I think
>
> (button .b [-command (delay (output "Hello world"))
> -text "Friendly"])
>
> for a button .b that prints "Hello World" and has "Friendly" written
> on it
> is reasonably clear and concise - don't you think?
>
Oh, I am all for sticking to the Tcl/Tk vocabulary
(and hence did it) but I strongly prefer to write it in
Lisp:
(make-instance 'button :text "Friendly"
:command (lambda ()
(princ "Hello world")))
the event function being a real lisp closure with all its
powers and of course having full CLOS features like widget
subclassing and so on...
Peter
--
Ltk, the easy lisp gui http://www.peter-herth.de/ltk/
On 14 Oct, 13:21, Peter Herth <·······@t-online.de> wrote:
> Mark Tarver wrote:
> > There is an argument for sticking to the TCL/tk attribute-value
> > vocabulary which is that more people know it than anything I can make
> > up. And I don't require TCL/tk command string passing by the
> > programmer. I think
>
> > (button .b [-command (delay (output "Hello world"))
> > -text "Friendly"])
>
> > for a button .b that prints "Hello World" and has "Friendly" written
> > on it
> > is reasonably clear and concise - don't you think?
>
> Oh, I am all for sticking to the Tcl/Tk vocabulary
> (and hence did it) but I strongly prefer to write it in
> Lisp:
>
> (make-instance 'button :text "Friendly"
> :command (lambda ()
> (princ "Hello world")))
>
> the event function being a real lisp closure with all its
> powers and of course having full CLOS features like widget
> subclassing and so on...
>
> Peter
>
> --
> Ltk, the easy lisp guihttp://www.peter-herth.de/ltk/
Hi,
Some good ideas here but Qi at the moment does not have classes which
I'm fixing.
I can see the argument for representing commands as closures and thats
easily done.
I can also see the argument for being able to create new classes of
widgets.
But if you make the native widgets set of TCL/tk in classes what is to
stop somebody
creating a nonsense widget that inherits the attributes of, say,
circles and buttons or any
two widgets that really do not belong together. In that case the
resultant widget would
have a skewed command set and you could end up asking for the menu
option of a button
or some strangeness.
Mark
On 2007-10-16 07:48:07 -0400, Mark Tarver <··········@ukonline.co.uk> said:
> what is to
> stop somebody
> creating a nonsense widget that inherits the attributes of, say,
> circles and buttons or any
> two widgets that really do not belong together. In that case the
> resultant widget would
> have a skewed command set and you could end up asking for the menu
> option of a button
> or some strangeness.
1. What is to prevent someone from doing the same with CLOS? (nothing I
think) Lispers generally accept that more or less complete freedom at
runtime entails allowing greater possibility of programmer error as
well.
2. Why is it inherently erroneous to want a button that has a menu
(presumably pop-up) co-located with it? I remember some research a few
years back with pie-menus where pretty much any GUI element could have
a menu associated with it. In other words, the fact that two GUI
elements are orthogonal (buttons & menus here) but not generally
spatially co-located sometimes means merely that this particular
combination hasn't found (general) use yet, not that this is some
inherent error.
Mark Tarver wrote:
> Some good ideas here but Qi at the moment does not have classes which
> I'm fixing.
>
> I can see the argument for representing commands as closures and thats
> easily done.
> I can also see the argument for being able to create new classes of
> widgets.
>
> But if you make the native widgets set of TCL/tk in classes what is to
> stop somebody
> creating a nonsense widget that inherits the attributes of, say,
> circles and buttons or any
> two widgets that really do not belong together. In that case the
> resultant widget would
> have a skewed command set and you could end up asking for the menu
> option of a button
> or some strangeness.
Yes, that might look silly. So be careful when crossbreeding things :)
(And that is the only actual restriction in LTk, that you can only
inherit from one widget class, however from any number of non-widget
CLOS classes, which works very nicely)
Peter
--
Ltk, the easy lisp gui http://www.peter-herth.de/ltk/
Mark Tarver wrote:
> I'm getting a kind of fatigue here - look at what Raffael Cavallero is
> saying in post 27. on this thread - which is what I think said in a
> different way. And Rob St Armant lowdown on GUILs in post 3. Look at
> what I say in post 1. and especially what I said in response to
> clarification of my position to Kenny Tilton in post 11. What I am
> saying does not revolve around the size of Lisp and nor do their
> comments either.
Who is numbering the posts for you? Do the numbers stay the
same as more posts arrive? Why do you expect that other
people will associate particular posts with these numbers?
Bear
On Thu, 18 Oct 2007 19:03:58 -0700, Ray Dillinger <····@sonic.net>
wrote:
>Mark Tarver wrote:
>
>> I'm getting a kind of fatigue here - look at what Raffael Cavallero is
>> saying in post 27. on this thread - which is what I think said in a
>> different way. And Rob St Armant lowdown on GUILs in post 3. Look at
>> what I say in post 1. and especially what I said in response to
>> clarification of my position to Kenny Tilton in post 11. What I am
>> saying does not revolve around the size of Lisp and nor do their
>> comments either.
>
>Who is numbering the posts for you? Do the numbers stay the
>same as more posts arrive? Why do you expect that other
>people will associate particular posts with these numbers?
Mark may be reading online though Google, etc. There are some desktop
news clients that provide numbering, but I am not aware of any that
are stable unless the entire thread is saved.
Re: Google - it's numbering is stable wrt it's own message archive.
However, I have seen in busy groups that when several replies have
close timestamps, my provider sometimes sees them in a different order
than Google does.
Kent Pitman complained a while back about messages that don't stand
alone (about one of my posts, in fact). Quoting enough context for a
message to stand alone leads quickly to very long messages, but I
basically agree with him that excessive abbreviation and vague
references to other messages don't cut it.
George
--
for email reply remove "/" from address
In article <<························@t8g2000prg.googlegroups.com>>,
Mark Tarver <··········@ukonline.co.uk> wrote:
>
> Now I sat down and wondered why that was. Was the field inherently
> just a big intellectual hack, or have human beings made a mess of
> it. I decided that was probably more that human beings made a mess
> of it and that there was a much more elegant approach. We had to
> begin with a formal theory of widgets and by asking dumb-sounding
> but actually deeply serious questions like 'What is a window'?
Take a look at Antony Courtney's PhD thesis, "Modelling User
Interfaces in a Functional Language". You can find it online at
<http://http://www.apocalypse.org/~antony/work/pubs/ac-thesis.pdf>
In this thesis, he does ask questions like "What is a window?", and
answers them with a denotational semantics of graphical user
interfaces in terms of synchronous dataflow. He then uses this to
guide the design and implementation of a small GUI toolkit for
Haskell.
There are certainly places where you can question his design choices,
but the cool thing is you can *really* question them, because
everything is careful and precise enough that a rigorous argument
is possible.
--
Neel R. Krishnaswami
·····@cs.cmu.edu
From: Pascal Costanza
Subject: Re: on the strange weakness of Graphical User Interface Languages
Date:
Message-ID: <5nk54qFileleU1@mid.individual.net>
Mark Tarver wrote:
> You have this vaguer
> idea of computational adequacy which means that the GUIL can do the
> things you want. But the primitives are nowhere in sight
> and what you are given is a grab-bag of tools for making buttons and
> various widgets. Since the user's wish list is indefinitely large,
> GUILs become bloated and you end with 1000 page manuals of commands,
> hacks and hooks of every descripton. Reminiscent of PL/1 actually.
> So what you have is 'the wrong thing'.
>
> GUILs
> 1. A vague idea of computational adequacy.
> 2. A huge number of primitives.
> 3. A weak means of combining together.
>
> Now I sat down and wondered why that was.
I don't think the problem is that GUILs are inadequate, but rather that
GUIs are inadequate.
The situation we currently have is that computers and their UIs simulate
paper (cf. Alan Kay's "The Computer Revolution hasn't happened yet"). Or
even worse: They simulate things we know from everyday life (buttons,
sliders, etc.) without even remotely giving the same amount of
tangibility as the real stuff.
This is done by appealing to the ways of using things that we already
know from everyday life, but the resulting effect is that using a
computer is far too complicated, while there is no obvious way to get
real efficiency out of computers, from a user's perspective. We are
simply not taking advantage of what computers could do, and instead
focus too much on what computers are essentially bad at.
Before improving the languages to express GUIs, it's probably better to
first investigate how to improve UIs. Not that I have particularly good
ideas myself, of course... ;-)
And yes, I agree with Kenny that data-driven approaches based on, for
example, his Cells stuff, is likely the simplest way to go for
current-days GUIs. The advantage of Cells is that you remove not only
manual forwarding of data, but that you also remove effects to a large
degree and essentially get a functional programming style for expressing
GUIs.
Pascal
--
My website: http://p-cos.net
Common Lisp Document Repository: http://cdr.eurolisp.org
Closer to MOP & ContextL: http://common-lisp.net/project/closer/
From: John Thingstad
Subject: Re: on the strange weakness of Graphical User Interface Languages
Date:
Message-ID: <op.t0a4bhgupqzri1@pandora.upc.no>
P� Tue, 16 Oct 2007 17:54:01 +0200, skrev Pascal Costanza <··@p-cos.net>:
>
> Before improving the languages to express GUIs, it's probably better to
> first investigate how to improve UIs. Not that I have particularly good
> ideas myself, of course... ;-)
>
Have you looked at the work done for Windows Vista. Here the win32 library
gets replaced by WinFX. The interface can then be specified by a
specification language called XAML. This is usually designed by a designer
and requires little programming skills just knowledge of the design tools.
Interface elements can be made to look like anything you want. It can be
video's or it can be 3D design elements. One example I saw, a sportswear
store, had a 3D carousel on which a set of running video's were on the
surface. You then selected the video on the carousel for the type of item
you wanted. Say Slalom. From the programmers perspective it is just a
radio button. You could then select a item from the video say the ski's
and get a picture with the product specs and price..
These links might give you some idea.
http://msdn2.microsoft.com/en-us/library/ms752059.aspx
http://msdn.microsoft.com/msdntv/episode.aspx?xml=episodes/en/20031107winfxba/manifest.xml
From: Wade Humeniuk
Subject: Re: on the strange weakness of Graphical User Interface Languages
Date:
Message-ID: <m2d4vemp8r.fsf@telus.net.no.spam>
Pascal Costanza <··@p-cos.net> writes:
>
> The situation we currently have is that computers and their UIs
> simulate paper (cf. Alan Kay's "The Computer Revolution hasn't
> happened yet"). Or even worse: They simulate things we know from
> everyday life (buttons, sliders, etc.) without even remotely giving
> the same amount of tangibility as the real stuff.
>
> This is done by appealing to the ways of using things that we already
> know from everyday life, but the resulting effect is that using a
> computer is far too complicated, while there is no obvious way to get
> real efficiency out of computers, from a user's perspective. We are
> simply not taking advantage of what computers could do, and instead
> focus too much on what computers are essentially bad at.
>
> Before improving the languages to express GUIs, it's probably better
> to first investigate how to improve UIs. Not that I have particularly
> good ideas myself, of course... ;-)
>
I think this is really valid point. It appears the common way of
using a computer is to simulate what was done before computers. We
mimic spreadsheets as they were done on paper (while adding some
automated arithmetic between cells). 3D computer games mimic how we
move and interact in the real world. An inventory system becomes a
glorified catalog (again with some automation of the really tedious
tasks, of course the really boring work of actually doing inventory is
kept as is). Instead the spreadsheet and the inventory systems could
be automated away with enough ingenuity and application of computer
tech. As for 3D games, well, who knows?
Wade
Wade Humeniuk <········@telus.net.no.spam> writes:
> Pascal Costanza <··@p-cos.net> writes:
>
>>
>> The situation we currently have is that computers and their UIs
>> simulate paper (cf. Alan Kay's "The Computer Revolution hasn't
>> happened yet"). Or even worse: They simulate things we know from
>> everyday life (buttons, sliders, etc.) without even remotely giving
>> the same amount of tangibility as the real stuff.
>>
>> This is done by appealing to the ways of using things that we already
>> know from everyday life, but the resulting effect is that using a
>> computer is far too complicated, while there is no obvious way to get
>> real efficiency out of computers, from a user's perspective. We are
>> simply not taking advantage of what computers could do, and instead
>> focus too much on what computers are essentially bad at.
>>
>> Before improving the languages to express GUIs, it's probably better
>> to first investigate how to improve UIs. Not that I have particularly
>> good ideas myself, of course... ;-)
There are actually lots of good ideas out there about how to improve
user interfaces, as I expect no one would find surprising. There are
probably a half-dozen reasonably good computer science conferences on
various aspects of human-computer interaction (and over a dozen more
not-so-good conferences). Unfortunately, few relatively ideas, even
good ones, make it out of the research laboratories into commercial
interfaces. (I think Eric Horvitz's experience at Microsoft with his
work on LookOut is a good and probably typical example.)
> I think this is really valid point. It appears the common way of
> using a computer is to simulate what was done before computers. We
> mimic spreadsheets as they were done on paper (while adding some
> automated arithmetic between cells). 3D computer games mimic how we
> move and interact in the real world. An inventory system becomes a
> glorified catalog (again with some automation of the really tedious
> tasks, of course the really boring work of actually doing inventory is
> kept as is). Instead the spreadsheet and the inventory systems could
> be automated away with enough ingenuity and application of computer
> tech. As for 3D games, well, who knows?
This is a tough problem. Consider that what we had before graphical
user interfaces was mainly command line interfaces. Applications with
GUIs, such as spreadsheets and word processors, were viewed as an
enormous leap forward exactly because they looked and behaved a bit
more like their real-world counterparts. That is, instead of having
to be a scientist or engineer to use a computer, you could be an
accountant familiar with ledgers or a business person familiar with
paper documents, and you could get work done without having to spend a
lot of time learning about computers. For better or worse, just as
most drivers don't care how their car works, as long as it runs, most
computer users don't care how their computer works, as long as they
can get something done with it.
One of the ways that HCI people have traditionally thought about GUIs
is that they're so-called model worlds: in contrast to having an
approximation of a conversation with the computer (via a command
line), you take actions through the interface to manipulate model
objects in the domain of the application. The idea is that a model
world combines some automation with other more familiar elements. The
tricky thing is that you want an interface that does the right thing,
but "the right thing" is often hard for a non-technical person to
specify unambiguously. And if the system's inferences turn out to be
wrong, even only occasionally, people tend to be frustrated-- objects
and tools in the real world are usually very predictable in their
behavior.
Of course, everything that I've written above applies to the mythical
average user. Programmers and other types of expert users are another
breed entirely.
From: Pascal Costanza
Subject: Re: on the strange weakness of Graphical User Interface Languages
Date:
Message-ID: <5nmuj2Fif9o9U1@mid.individual.net>
Rob St. Amant wrote:
> For better or worse, just as
> most drivers don't care how their car works, as long as it runs, most
> computer users don't care how their computer works, as long as they
> can get something done with it.
I am happy that I don't have to use reins and spurs to drive a car. If
cars had been designed in the same way user interfaces for software are
designed nowadays, this would have been the logical consequence.
("...because this is what people were already used to.")
> Of course, everything that I've written above applies to the mythical
> average user. Programmers and other types of expert users are another
> breed entirely.
I think this will be regarded as the single biggest mistake of our times
in future history books about computer science - that everything had to
appeal to the mythical average user.
The frustrating thing is that people say "average", but actually seem to
mean "stupid." This makes our software much worse than it actually could be.
Pascal
--
My website: http://p-cos.net
Common Lisp Document Repository: http://cdr.eurolisp.org
Closer to MOP & ContextL: http://common-lisp.net/project/closer/
From: Paul Wallich
Subject: Re: on the strange weakness of Graphical User Interface Languages
Date:
Message-ID: <ff5m5d$ftt$1@reader1.panix.com>
Pascal Costanza wrote:
> Rob St. Amant wrote:
>
>> For better or worse, just as
>> most drivers don't care how their car works, as long as it runs, most
>> computer users don't care how their computer works, as long as they
>> can get something done with it.
>
> I am happy that I don't have to use reins and spurs to drive a car. If
> cars had been designed in the same way user interfaces for software are
> designed nowadays, this would have been the logical consequence.
> ("...because this is what people were already used to.")
>
>> Of course, everything that I've written above applies to the mythical
>> average user. Programmers and other types of expert users are another
>> breed entirely.
>
> I think this will be regarded as the single biggest mistake of our times
> in future history books about computer science - that everything had to
> appeal to the mythical average user.
>
> The frustrating thing is that people say "average", but actually seem to
> mean "stupid." This makes our software much worse than it actually could
> be.
Not so much "stupid" as "unschooled in the domain at issue" -- which may
be worse. Except for some of the really high-value applications, it
seems that the interfaces don't get pegged toward what a constant user
of the software might know, but rather what the programmers and a few
managers know about how things get done in a particular domain.
As long as UI programming is hard, that's going to be the case simply
because getting some programmer and a bunch of constant users together
for long enough to get things "right" is going to be very expensive.
paul
Pascal Costanza <··@p-cos.net> writes:
> Rob St. Amant wrote:
>
>> For better or worse, just as
>> most drivers don't care how their car works, as long as it runs, most
>> computer users don't care how their computer works, as long as they
>> can get something done with it.
>
> I am happy that I don't have to use reins and spurs to drive a car. If
> cars had been designed in the same way user interfaces for software
> are designed nowadays, this would have been the logical
> consequence. ("...because this is what people were already used to.")
Yes, and that's a good example; I've read that some of the earliest
cars to be built actually did have reins instead of a steering bar or
a steering wheel. Fortunately, better sense prevailed.
For some reason the computer industry seems to have enormous inertia
when it comes to changing the way that people interact with software.
I agree that it would be great to have new (and competing) interfaces
out there, and I don't entirely understand why this isn't the case.
There's a paper I have my students read, by Gentner and Nielsen,
called "The anti-Mac interface", which begins,
At recent user interface conferences, several speakers have
lamented that the human interface is stuck. We seem to have
settled on the WIMP (windows, icons, menus, pointer) model, and
there is very little real innovation in interface design anymore.
And this was written in 1996!
>> Of course, everything that I've written above applies to the mythical
>> average user. Programmers and other types of expert users are another
>> breed entirely.
>
> I think this will be regarded as the single biggest mistake of our
> times in future history books about computer science - that everything
> had to appeal to the mythical average user.
>
> The frustrating thing is that people say "average", but actually seem
> to mean "stupid." This makes our software much worse than it actually
> could be.
One thing that's sorely lacking in most application interfaces, I
think, is good ways for novice users to become expert users (ideally
simply by using the system). There's always RTFM, but hardly anyone
does it.
On Wed, 17 Oct 2007 15:48:12 -0400, ·······@ncsu.edu (Rob St. Amant)
wrote:
>
>For some reason the computer industry seems to have enormous inertia
>when it comes to changing the way that people interact with software.
>I agree that it would be great to have new (and competing) interfaces
>out there, and I don't entirely understand why this isn't the case.
>There's a paper I have my students read, by Gentner and Nielsen,
>called "The anti-Mac interface", which begins,
>
> At recent user interface conferences, several speakers have
> lamented that the human interface is stuck. We seem to have
> settled on the WIMP (windows, icons, menus, pointer) model, and
> there is very little real innovation in interface design anymore.
>
>And this was written in 1996!
>
Users don't want to have to learn anything to interact with computers,
they want to communicate with machines as they would with another
human and have it provide meaningful results - without having to know
or care how the machine operates.
I don't know about you, but I don't see any evidence that the
pseudo-sentience of the computers on Star Trek, which can interpret
natural language and automatically generate queries and script
operations based on their understanding of the intent, is anywhere on
the horizon.
George
--
for email reply remove "/" from address
George Neuner <·········@/comcast.net> writes:
> I don't know about you, but I don't see any evidence that the
> pseudo-sentience of the computers on Star Trek, which can interpret
> natural language and automatically generate queries and script
> operations based on their understanding of the intent, is anywhere on
> the horizon.
It's certainly not here yet, but there are promising efforts, I think.
James Allen at Rochester has been working on mixed-initiative
planning, with a natural language component, for over a decade; his
TRAINS and TRIPS demos from the mid-90s are still pretty impressive.
Eric Horvitz's Bayesian approach to mixed-initiative interaction in
more conventional interfaces is good, too. There some nice work on
programming by demonstration by Dan Oblinger and Larry Bergman at
IBM. . . Inferring user intent is a hard nut to crack.
George Neuner <·········@/comcast.net> writes:
> I don't know about you, but I don't see any evidence that the
> pseudo-sentience of the computers on Star Trek, which can interpret
> natural language and automatically generate queries and script
> operations based on their understanding of the intent, is anywhere on
> the horizon.
I forgot to mention: One of the things that bugs me about Star Trek
interfaces, on the Next Generation shows, at least, is not how smart
they are but how poorly designed some of them are. For example, the
captain will say something like, "Zoom in on sector 23 mark 75," with
no visual cues about what this corresponds to on the main screen.
WTF? Are ship's captains required to mentally impose a Cartesian grid
on an enormous display and be able to just call out appropriate
coordinates?
> WTF? Are ship's captains required to mentally impose a Cartesian grid
> on an enormous display and be able to just call out appropriate
> coordinates?
Yes; and save the galaxy on a weekly basis while running a Starship
and conducting rapid fire serial monogamy with a succession of nubile
women. All us men can do this - right? ;)
Mark
From: Larry Elmore
Subject: Re: on the strange weakness of Graphical User Interface Languages
Date:
Message-ID: <1XCRi.7445$GR1.1386@trnddc08>
Mark Tarver wrote:
>> WTF? Are ship's captains required to mentally impose a Cartesian grid
>> on an enormous display and be able to just call out appropriate
>> coordinates?
>
> Yes; and save the galaxy on a weekly basis while running a Starship
> and conducting rapid fire serial monogamy with a succession of nubile
> women. All us men can do this - right? ;)
Well, all us Real Men (tm), anyway. :)
Mark Tarver <··········@ukonline.co.uk> writes:
>> WTF? Are ship's captains required to mentally impose a Cartesian grid
>> on an enormous display and be able to just call out appropriate
>> coordinates?
>
> Yes; and save the galaxy on a weekly basis while running a Starship
> and conducting rapid fire serial monogamy with a succession of nubile
> women. All us men can do this - right? ;)
If only I'd been accepted into Starfleet Acadamy, I'd *know* how to do
all that!
Continuing in the off-topic-ness, I'll just mention a couple of other
user interface problems in the Next Generation universe:
Flat touch panels. They're nice because they're reconfigurable, but
you'll never see anyone aside from Data the android using them
efficiently, at least for typing and comparable activities. Because
touch screens don't have the same tactile feedback as keyboards (e.g.,
for placement of one's fingers or confirmation that a key has been
pressed), they're not nearly as fast for data entry (e.g., expert
speeds for "soft" keyboards versus mini-QWERTY keyboards versus
standard keyboards are in the range of 35 wpm, 70 wpm, and, um,
higher, respectively).
Natural language commands. How often do you hear Captain Picard say,
"Earl Gray, hot"? He never seems to ask for any other beverage. A
reasonable system, even by today's standards, would allow him to say,
"Computer--tea," and have it give him his usual.
On 2007-10-18 13:46:25 -0400, ·······@ncsu.edu (Rob St. Amant) said:
> Because
> touch screens don't have the same tactile feedback as keyboards (e.g.,
> for placement of one's fingers or confirmation that a key has been
> pressed),
Uh, this is Star Trek - for feedback the computer directly stimulates
your brain to provide the tactile sensation of pressing a key. This is
not your grandpa's touch screen... ;^)
Raffael Cavallaro
<················@pas-d'espam-s'il-vous-plait-mac.com> writes:
> On 2007-10-18 13:46:25 -0400, ·······@ncsu.edu (Rob St. Amant) said:
>
>> Because
>> touch screens don't have the same tactile feedback as keyboards (e.g.,
>> for placement of one's fingers or confirmation that a key has been
>> pressed),
>
> Uh, this is Star Trek - for feedback the computer directly stimulates
> your brain to provide the tactile sensation of pressing a key. This is
> not your grandpa's touch screen... ;^)
Busted. I should have realized there's an invisible hologram hovering
an inch above the surface.
From: Paul Wallich
Subject: Re: on the strange weakness of Graphical User Interface Languages
Date:
Message-ID: <ff8rrt$gu2$1@reader1.panix.com>
Rob St. Amant wrote:
> Mark Tarver <··········@ukonline.co.uk> writes:
>
>>> WTF? Are ship's captains required to mentally impose a Cartesian grid
>>> on an enormous display and be able to just call out appropriate
>>> coordinates?
>> Yes; and save the galaxy on a weekly basis while running a Starship
>> and conducting rapid fire serial monogamy with a succession of nubile
>> women. All us men can do this - right? ;)
>
> If only I'd been accepted into Starfleet Acadamy, I'd *know* how to do
> all that!
>
> Continuing in the off-topic-ness, I'll just mention a couple of other
> user interface problems in the Next Generation universe:
>
> Flat touch panels. They're nice because they're reconfigurable, but
> you'll never see anyone aside from Data the android using them
> efficiently, at least for typing and comparable activities. Because
> touch screens don't have the same tactile feedback as keyboards (e.g.,
> for placement of one's fingers or confirmation that a key has been
> pressed), they're not nearly as fast for data entry (e.g., expert
> speeds for "soft" keyboards versus mini-QWERTY keyboards versus
> standard keyboards are in the range of 35 wpm, 70 wpm, and, um,
> higher, respectively).
Briefly getting serious, that points to one of the biggest problems for
anyone who wants to roll their own non-WIMP user interfaces: not only do
they have to write all the software, they also have to build all the
hardware and the firmware to talk to it. Doing that well is expensive,
time-consuming and in need of skills not typically found in one person.
And that's just to test stuff out, much less figure out what works and
develop some useful theories.
It's possible that the growing digitization of everything will help with
this, since you'll be able to buy sliders, knobs, buttons, 3-D gesture
recognizers and so forth that all talk TCP-IP or something close enough.
(You can already get knobs.)
paul
From: Cesar Rabak
Subject: Re: on the strange weakness of Graphical User Interface Languages
Date:
Message-ID: <ff8jts$om9$1@aioe.org>
Mark Tarver escreveu:
>> WTF? Are ship's captains required to mentally impose a Cartesian grid
>> on an enormous display and be able to just call out appropriate
>> coordinates?
>
> Yes; and save the galaxy on a weekly basis while running a Starship
> and conducting rapid fire serial monogamy with a succession of nubile
> women. All us men can do this - right? ;)
>
Well, no half of it is easy but the other half... ;-)
From: Didier Verna
Subject: Re: on the strange weakness of Graphical User Interface Languages
Date:
Message-ID: <muxy7e1ndk9.fsf@uzeb.lrde.epita.fr>
·······@ncsu.edu (Rob St. Amant) wrote:
> I forgot to mention: One of the things that bugs me about Star Trek
> interfaces, on the Next Generation shows, at least, is not how smart
> they are but how poorly designed some of them are. For example, the
> captain will say something like, "Zoom in on sector 23 mark 75," with
> no visual cues about what this corresponds to on the main screen.
> WTF? Are ship's captains required to mentally impose a Cartesian grid
> on an enormous display and be able to just call out appropriate
> coordinates?
Sci-Fi series have never been that smart about the interfaces of the
future. Often, they reflect the current state-of-the-art as much as they
invent something new. For instance, in Star Trek TOS, the crew is
already able to talk to the computer, but the computer answers with a
big typewriter sound and blinking lights on the console (even bigger
than those on the PDP ;-)
--
Resistance is futile. You will be jazzimilated.
Didier Verna, ······@lrde.epita.fr, http://www.lrde.epita.fr/~didier
EPITA / LRDE, 14-16 rue Voltaire Tel.+33 (1) 44 08 01 85
94276 Le Kremlin-Bic�tre, France Fax.+33 (1) 53 14 59 22 ······@xemacs.org
On Oct 18, 8:26 am, Didier Verna <······@lrde.epita.fr> wrote:
> Sci-Fi series have never been that smart about the interfaces of the
> future. Often, they reflect the current state-of-the-art as much as they
> invent something new. For instance, in Star Trek TOS, the crew is
> already able to talk to the computer, ....
> --
Ah, this thread is getting serious at long last, I think. :)
But remember HAL - when talked to, he did not respond with
hierarchical roll-down menus, nor did he clutter up his display with a
milllion mouse-click buttons. Computer systems are not being
automated, we human window-pushers are.
From: Didier Verna
Subject: Re: on the strange weakness of Graphical User Interface Languages
Date:
Message-ID: <muxsl48ogu2.fsf@uzeb.lrde.epita.fr>
Lars Lundback <·············@gmail.com> wrote:
> Ah, this thread is getting serious at long last, I think. :)
>
> But remember HAL - when talked to, he did not respond with
> hierarchical roll-down menus, nor did he clutter up his display with a
> milllion mouse-click buttons.
He should have followed the lead of XEmacs's Options => Advanced menu.
That's a must-have in any GUI front-end ;-)
--
Resistance is futile. You will be jazzimilated.
Didier Verna, ······@lrde.epita.fr, http://www.lrde.epita.fr/~didier
EPITA / LRDE, 14-16 rue Voltaire Tel.+33 (1) 44 08 01 85
94276 Le Kremlin-Bic�tre, France Fax.+33 (1) 53 14 59 22 ······@xemacs.org
From: Cesar Rabak
Subject: Re: on the strange weakness of Graphical User Interface Languages
Date:
Message-ID: <ff9vie$5fv$1@aioe.org>
Didier Verna escreveu:
> ·······@ncsu.edu (Rob St. Amant) wrote:
>
>> I forgot to mention: One of the things that bugs me about Star Trek
>> interfaces, on the Next Generation shows, at least, is not how smart
>> they are but how poorly designed some of them are. For example, the
>> captain will say something like, "Zoom in on sector 23 mark 75," with
>> no visual cues about what this corresponds to on the main screen.
>> WTF? Are ship's captains required to mentally impose a Cartesian grid
>> on an enormous display and be able to just call out appropriate
>> coordinates?
>
> Sci-Fi series have never been that smart about the interfaces of the
> future. Often, they reflect the current state-of-the-art as much as they
> invent something new. For instance, in Star Trek TOS, the crew is
> already able to talk to the computer, but the computer answers with a
> big typewriter sound and blinking lights on the console (even bigger
> than those on the PDP ;-)
>
This happens due a slightly different reason: the letters have to be big
enough so the they appear in the movie screen.
From: Cesar Rabak
Subject: Re: on the strange weakness of Graphical User Interface Languages
Date:
Message-ID: <ff8jr1$nl8$2@aioe.org>
Rob St. Amant escreveu:
> George Neuner <·········@/comcast.net> writes:
>
>> I don't know about you, but I don't see any evidence that the
>> pseudo-sentience of the computers on Star Trek, which can interpret
>> natural language and automatically generate queries and script
>> operations based on their understanding of the intent, is anywhere on
>> the horizon.
>
> I forgot to mention: One of the things that bugs me about Star Trek
> interfaces, on the Next Generation shows, at least, is not how smart
> they are but how poorly designed some of them are. For example, the
> captain will say something like, "Zoom in on sector 23 mark 75," with
> no visual cues about what this corresponds to on the main screen.
> WTF? Are ship's captains required to mentally impose a Cartesian grid
> on an enormous display and be able to just call out appropriate
> coordinates?
I don't see as intellectually burden after a second thought. If we had
that computer and would like to zoom in a certain corner across two
streets would you need any visual cues?
On Wed, 17 Oct 2007 22:43:36 -0400, ·······@ncsu.edu (Rob St. Amant)
wrote:
>George Neuner <·········@/comcast.net> writes:
>
>> I don't know about you, but I don't see any evidence that the
>> pseudo-sentience of the computers on Star Trek, which can interpret
>> natural language and automatically generate queries and script
>> operations based on their understanding of the intent, is anywhere on
>> the horizon.
>
>I forgot to mention: One of the things that bugs me about Star Trek
>interfaces, on the Next Generation shows, at least, is not how smart
>they are but how poorly designed some of them are. For example, the
>captain will say something like, "Zoom in on sector 23 mark 75," with
>no visual cues about what this corresponds to on the main screen.
>WTF? Are ship's captains required to mentally impose a Cartesian grid
>on an enormous display and be able to just call out appropriate
>coordinates?
Yup. And that would really be wrong because "mark" designates polar
coordinates.
George
--
for email reply remove "/" from address
From: Pascal Costanza
Subject: Re: on the strange weakness of Graphical User Interface Languages
Date:
Message-ID: <5nnelnFja3k5U1@mid.individual.net>
George Neuner wrote:
> On Wed, 17 Oct 2007 15:48:12 -0400, ·······@ncsu.edu (Rob St. Amant)
> wrote:
>
>> For some reason the computer industry seems to have enormous inertia
>> when it comes to changing the way that people interact with software.
>> I agree that it would be great to have new (and competing) interfaces
>> out there, and I don't entirely understand why this isn't the case.
>> There's a paper I have my students read, by Gentner and Nielsen,
>> called "The anti-Mac interface", which begins,
>>
>> At recent user interface conferences, several speakers have
>> lamented that the human interface is stuck. We seem to have
>> settled on the WIMP (windows, icons, menus, pointer) model, and
>> there is very little real innovation in interface design anymore.
>>
>> And this was written in 1996!
>>
>
> Users don't want to have to learn anything to interact with computers,
> they want to communicate with machines as they would with another
> human and have it provide meaningful results - without having to know
> or care how the machine operates.
This assumes that we don't have to learn anything to communicate with
other humans. That's wrong as well.
Pascal
--
My website: http://p-cos.net
Common Lisp Document Repository: http://cdr.eurolisp.org
Closer to MOP & ContextL: http://common-lisp.net/project/closer/
On Wed, 17 Oct 2007 23:55:03 +0200, Pascal Costanza <··@p-cos.net>
wrote:
>George Neuner wrote:
>>
>> Users don't want to have to learn anything to interact with computers,
>> they want to communicate with machines as they would with another
>> human and have it provide meaningful results - without having to know
>> or care how the machine operates.
>
>This assumes that we don't have to learn anything to communicate with
>other humans. That's wrong as well.
I didn't say people don't *have* to learn ... I said they don't *want*
to have to learn.
George
--
for email reply remove "/" from address
From: Pascal Costanza
Subject: Re: on the strange weakness of Graphical User Interface Languages
Date:
Message-ID: <5nqu1nFje6amU1@mid.individual.net>
George Neuner wrote:
> On Wed, 17 Oct 2007 23:55:03 +0200, Pascal Costanza <··@p-cos.net>
> wrote:
>
>> George Neuner wrote:
>>> Users don't want to have to learn anything to interact with computers,
>>> they want to communicate with machines as they would with another
>>> human and have it provide meaningful results - without having to know
>>> or care how the machine operates.
>> This assumes that we don't have to learn anything to communicate with
>> other humans. That's wrong as well.
>
> I didn't say people don't *have* to learn ... I said they don't *want*
> to have to learn.
Oh, ok. Sorry.
Pascal
--
My website: http://p-cos.net
Common Lisp Document Repository: http://cdr.eurolisp.org
Closer to MOP & ContextL: http://common-lisp.net/project/closer/
In article <··································@4ax.com>,
George Neuner <·········@/comcast.net> wrote:
> On Wed, 17 Oct 2007 23:55:03 +0200, Pascal Costanza <··@p-cos.net>
> wrote:
>
> >George Neuner wrote:
> >>
> >> Users don't want to have to learn anything to interact with computers,
> >> they want to communicate with machines as they would with another
> >> human and have it provide meaningful results - without having to know
> >> or care how the machine operates.
> >
> >This assumes that we don't have to learn anything to communicate with
> >other humans. That's wrong as well.
>
> I didn't say people don't *have* to learn ... I said they don't *want*
> to have to learn.
>
> George
> --
> for email reply remove "/" from address
Well, I'll take a contrarian view on this is that people, in
general, love to learn. They can't help it because each and every
interaction they have with their environment is a learning
experience. People will gladly tackle hobbies with a learning curve
from weekend baseball, to knitting, to woodworking, to painting, to
watching their favorite sports program. (And I've yet to watch a
sports program that is not utter gibberish to those without a
treasury of learned information about both the rules, and the league
in question.) People spend billions of dollars on complex computer
interfaces that they will spend hours trying to master. Most people
call these interfaces "games."
So the problem isn't with willingness to learn. Anybody with the
ability to interact with computers is learning whether they like it
or not. The question is, what do computer interfaces actually teach
with their superficially inconsistent rules, mixed metaphors, and
glitchy bugs?
From: Cor Gest
Subject: Re: on the strange weakness of Graphical User Interface Languages
Date:
Message-ID: <87lk9xbyoj.fsf@cleopatra.clsnet.nl>
Some entity, AKA Kirk Sluder <····@nospam.jobsluder.net>,
wrote this mindboggling stuff:
(selectively-snipped-or-not-p)
> So the problem isn't with willingness to learn. Anybody with the
> ability to interact with computers is learning whether they like it
> or not. The question is, what do computer interfaces actually teach
> with their superficially inconsistent rules, mixed metaphors, and
> glitchy bugs?
With this discription one could allmost say that the darned thing was
becoming more human since inception ... ;-)
Cor
--
Alle schraifvauden zijn opzettelijk, teneinde ieder lafaard de kans te
geven over spelling te zeuren in plaats van in te gaan op de inhoud.
(defvar My-Computer '((OS . "GNU/Emacs") (IPL . "GNU/Linux")))
http://www.clsnet.nl/mail.php
On Sat, 20 Oct 2007 14:27:05 GMT, Kirk Sluder
<····@nospam.jobsluder.net> wrote:
>In article <··································@4ax.com>,
> George Neuner <·········@/comcast.net> wrote:
>
>> On Wed, 17 Oct 2007 23:55:03 +0200, Pascal Costanza <··@p-cos.net>
>> wrote:
>>
>> >George Neuner wrote:
>> >>
>> >> Users don't want to have to learn anything to interact with computers,
>> >> they want to communicate with machines as they would with another
>> >> human and have it provide meaningful results - without having to know
>> >> or care how the machine operates.
>> >
>> >This assumes that we don't have to learn anything to communicate with
>> >other humans. That's wrong as well.
>>
>> I didn't say people don't *have* to learn ... I said they don't *want*
>> to have to learn.
>>
>> George
>> --
>> for email reply remove "/" from address
>
>
>Well, I'll take a contrarian view on this is that people, in
>general, love to learn. They can't help it because each and every
>interaction they have with their environment is a learning
>experience. People will gladly tackle hobbies with a learning curve
>from weekend baseball, to knitting, to woodworking, to painting, to
>watching their favorite sports program. (And I've yet to watch a
>sports program that is not utter gibberish to those without a
>treasury of learned information about both the rules, and the league
>in question.) People spend billions of dollars on complex computer
>interfaces that they will spend hours trying to master. Most people
>call these interfaces "games."
>
>So the problem isn't with willingness to learn. Anybody with the
>ability to interact with computers is learning whether they like it
>or not. The question is, what do computer interfaces actually teach
>with their superficially inconsistent rules, mixed metaphors, and
>glitchy bugs?
People actively resist learning about things that frighten them. The
problem is that people seem to have a unique fear of computers that is
fundamentally different from their fears of other technology
(automobiles, flying, etc.). Many people act as if they believe the
computer is sentient and judges them if they make a mistake. Even the
most irrational, terrified flyer doesn't think the plane is angry at
him.
George
--
for email reply remove "/" from address
In article <··································@4ax.com>,
George Neuner <·········@/comcast.net> wrote:
> People actively resist learning about things that frighten them. The
> problem is that people seem to have a unique fear of computers that is
> fundamentally different from their fears of other technology
> (automobiles, flying, etc.). Many people act as if they believe the
> computer is sentient and judges them if they make a mistake. Even the
> most irrational, terrified flyer doesn't think the plane is angry at
> him.
This is one of those big differences between learning theory and
instructional theory. People can no more resist learning than they
can resist breathing. If you are interacting with the world around
you, you are learning, at least according to just about every theory
of how humans process information about their world published since
the 1900s.
Now instructional theory, that's another matter. Computer
interfaces certainly have an instructional design. Click on the
File menu, something happens. Click on it again, the same thing
happens. People can certainly resist instruction, and there are
whole case studies out there about the implicit "hidden curriculum"
of school systems that teach the exact opposite of what was intended
by school administrators. People who resist computer interfaces are
certainly learning something, perhaps it's "get the tech support guy
to do it for me," or "avoid doing this as long as possible" or
"perhaps I can use the previous version."
It seems to me coming from the question of "how people learn" rather
than "how do we draw pixels" that starting with the assumption that
every keypress and mouse click is a learning experience might be a
useful start for talking about GUIs.
> George
> --
> for email reply remove "/" from address
Kirk Sluder wrote:
> It seems to me coming from the question of "how people learn" rather
> than "how do we draw pixels" that starting with the assumption that
> every keypress and mouse click is a learning experience might be a
> useful start for talking about GUIs.
Ahh, never thought about that before. Will fix in my next program...
GUI, meet shock collar. :)
George Neuner <·········@/comcast.net> writes:
> On Sat, 20 Oct 2007 14:27:05 GMT, Kirk Sluder
> <····@nospam.jobsluder.net> wrote:
>
>>So the problem isn't with willingness to learn. Anybody with the
>>ability to interact with computers is learning whether they like it
>>or not. The question is, what do computer interfaces actually teach
>>with their superficially inconsistent rules, mixed metaphors, and
>>glitchy bugs?
>
> People actively resist learning about things that frighten them. The
> problem is that people seem to have a unique fear of computers that is
> fundamentally different from their fears of other technology
> (automobiles, flying, etc.). Many people act as if they believe the
> computer is sentient and judges them if they make a mistake. Even the
> most irrational, terrified flyer doesn't think the plane is angry at
> him.
Yes, people anthropomorphize computers quite a bit. For a somewhat
controversial take on this, there's Reeves and Nass's book, The Media
Equation, which argues that the most minimal social cues will cause
people to treat computers like other people. Fortunately, cars and
planes don't provide those cues.
On Oct 20, 9:25 pm, George Neuner <·········@/comcast.net> wrote:
> On Sat, 20 Oct 2007 14:27:05 GMT, Kirk Sluder
>
>
>
>
>
> <····@nospam.jobsluder.net> wrote:
> >In article <··································@4ax.com>,
> > George Neuner <·········@/comcast.net> wrote:
>
> >> On Wed, 17 Oct 2007 23:55:03 +0200, Pascal Costanza <····@p-cos.net>
> >> wrote:
>
> >> >George Neuner wrote:
>
> >> >> Users don't want to have to learn anything to interact with computers,
> >> >> they want to communicate with machines as they would with another
> >> >> human and have it provide meaningful results - without having to know
> >> >> or care how the machine operates.
>
> >> >This assumes that we don't have to learn anything to communicate with
> >> >other humans. That's wrong as well.
>
> >> I didn't say people don't *have* to learn ... I said they don't *want*
> >> to have to learn.
>
> >> George
> >> --
> >> for email reply remove "/" from address
>
> >Well, I'll take a contrarian view on this is that people, in
> >general, love to learn. They can't help it because each and every
> >interaction they have with their environment is a learning
> >experience. People will gladly tackle hobbies with a learning curve
> >from weekend baseball, to knitting, to woodworking, to painting, to
> >watching their favorite sports program. (And I've yet to watch a
> >sports program that is not utter gibberish to those without a
> >treasury of learned information about both the rules, and the league
> >in question.) People spend billions of dollars on complex computer
> >interfaces that they will spend hours trying to master. Most people
> >call these interfaces "games."
>
> >So the problem isn't with willingness to learn. Anybody with the
> >ability to interact with computers is learning whether they like it
> >or not. The question is, what do computer interfaces actually teach
> >with their superficially inconsistent rules, mixed metaphors, and
> >glitchy bugs?
>
> People actively resist learning about things that frighten them. The
> problem is that people seem to have a unique fear of computers that is
> fundamentally different from their fears of other technology
> (automobiles, flying, etc.). Many people act as if they believe the
> computer is sentient and judges them if they make a mistake. Even the
> most irrational, terrified flyer doesn't think the plane is angry at
> him.
>
> George
Joel Spolsky - User Interface Design for Programmers:
A very significant portion of your users are scared of the darn
computer. It ate their term paper. It may eat them if they press the
wrong button. And although I've always known this intellectually, I've
never really felt this fear of the computer.
Until last week. You see, last week I set up the payroll for my new
company. I have four people to pay, and the payroll company has set me
up with a Web-based interface in which I enter payroll information.
This interface has a suctionlike device directly hooked up to vacuum
money straight out of my bank account.
On Oct 21, 1:29 pm, Slobodan Blazeski <·················@gmail.com>
wrote:
> On Oct 20, 9:25 pm, George Neuner <·········@/comcast.net> wrote:
>
>
>
> > On Sat, 20 Oct 2007 14:27:05 GMT, Kirk Sluder
>
> > <····@nospam.jobsluder.net> wrote:
> > >In article <··································@4ax.com>,
> > > George Neuner <·········@/comcast.net> wrote:
>
> > >> On Wed, 17 Oct 2007 23:55:03 +0200, Pascal Costanza <····@p-cos.net>
> > >> wrote:
>
> > >> >George Neuner wrote:
>
> > >> >> Users don't want to have to learn anything to interact with computers,
> > >> >> they want to communicate with machines as they would with another
> > >> >> human and have it provide meaningful results - without having to know
> > >> >> or care how the machine operates.
>
> > >> >This assumes that we don't have to learn anything to communicate with
> > >> >other humans. That's wrong as well.
>
> > >> I didn't say people don't *have* to learn ... I said they don't *want*
> > >> to have to learn.
>
> > >> George
> > >> --
> > >> for email reply remove "/" from address
>
> > >Well, I'll take a contrarian view on this is that people, in
> > >general, love to learn. They can't help it because each and every
> > >interaction they have with their environment is a learning
> > >experience. People will gladly tackle hobbies with a learning curve
> > >from weekend baseball, to knitting, to woodworking, to painting, to
> > >watching their favorite sports program. (And I've yet to watch a
> > >sports program that is not utter gibberish to those without a
> > >treasury of learned information about both the rules, and the league
> > >in question.) People spend billions of dollars on complex computer
> > >interfaces that they will spend hours trying to master. Most people
> > >call these interfaces "games."
>
> > >So the problem isn't with willingness to learn. Anybody with the
> > >ability to interact with computers is learning whether they like it
> > >or not. The question is, what do computer interfaces actually teach
> > >with their superficially inconsistent rules, mixed metaphors, and
> > >glitchy bugs?
>
> > People actively resist learning about things that frighten them. The
> > problem is that people seem to have a unique fear of computers that is
> > fundamentally different from their fears of other technology
> > (automobiles, flying, etc.). Many people act as if they believe the
> > computer is sentient and judges them if they make a mistake. Even the
> > most irrational, terrified flyer doesn't think the plane is angry at
> > him.
>
> > George
>
Sorry seems that computer hates me:
Joel Spolsky in User Interface Design for Programmers has a touchy
story why people are afraid of computers.
(quote
A very significant portion of your users are scared of the darn
computer. It ate their term paper. It may eat them if they press the
wrong button. And although I've always known this intellectually, I've
never really felt this fear of the computer.
Until last week. You see, last week I set up the payroll for my new
company. I have four people to pay, and the payroll company has set me
up with a Web-based interface in which I enter payroll information.
This interface has a suctionlike device directly hooked up to vacuum
money straight out of my bank account.
Yow. Now this Web site is scary. There are all kinds of weird buttons
that say things like "MISC (99) DEDUCTION." The funny thing is, I even
know what a MISC (99) DEDUCTION is-because I called up to ask them-but
I have no idea whether the deduction should be in dollars, hours,
negative dollars, or what, and the UI doesn't tell me, and it's not in
the help file anywhere. (Well, the help file does say "Enter any MISC
(99) deductions in the MISC (99) DEDUCTION box," in the grand
tradition of help files written by people who don't know any more
about the product than what they can figure out by looking at it.)
If this were just a word processor or a bitmap editor, I'd just try it
and see what happens. The trouble is, this is a vacuum-cleaner-like
device programmed to suck money directly out of my bank account. And
due to the extreme incompetence of the engineers who built the site,
there is no way to find out what's going on until it's too late: the
money has been sucked out of my bank account and direct-deposited into
my employees' accounts and I don't even find out what happened until
the next day. If I type 1000, thinking it means dollars, and it really
meant hours, then I'll get $65,000 sucked out of my account instead of
$1000.
So, now I know what it feels like to be one of those ordinary mortals
who will not do something until they understand it fully.
Programmers, on the whole, are born without a lot of sympathy for how
much trouble ordinary people have using computers. That's just the way
of the world. Programmers can keep nineteen things in their short-term
memory at once; normal people can keep about five. Programmers are
exceedingly rational and logical, to the point of exasperation; normal
people are emotional and say things like "my computer hates me."
)
Slobodan Blazeski
Kirk Sluder <····@nospam.jobsluder.net> writes:
> Well, I'll take a contrarian view on this is that people, in
> general, love to learn. They can't help it because each and every
> interaction they have with their environment is a learning
> experience. People will gladly tackle hobbies with a learning curve
> from weekend baseball, to knitting, to woodworking, to painting, to
> watching their favorite sports program. (And I've yet to watch a
> sports program that is not utter gibberish to those without a
> treasury of learned information about both the rules, and the league
> in question.) People spend billions of dollars on complex computer
> interfaces that they will spend hours trying to master. Most people
> call these interfaces "games."
I agree. I'm told that big games companies can usually rely on an
army of alpha and beta testers (paid? I don't know) who will spend
days playing a new game to figure it out. This approach doesn't
translate to productivity software like spreadsheets and word
processors, for some reason :-). Although I did read a paper a few
years ago that described a mapping from control room monitoring tasks
for a factory, or something similar, to a video game interface. That
idea has a lot of promise.
> So the problem isn't with willingness to learn. Anybody with the
> ability to interact with computers is learning whether they like it
> or not. The question is, what do computer interfaces actually teach
> with their superficially inconsistent rules, mixed metaphors, and
> glitchy bugs?
Yup. This can be studied at different levels of detail, too, from
whether individual commands are being learned to whether the overall
goals of the user (e.g., am I having fun?) are being met.
Rob St. Amant <·······@ncsu.edu> wrote:
+---------------
| I agree. I'm told that big games companies can usually rely on an
| army of alpha and beta testers (paid? I don't know) who will spend
| days playing a new game to figure it out. This approach doesn't
| translate to productivity software like spreadsheets and word
| processors, for some reason :-). Although I did read a paper a few
| years ago that described a mapping from control room monitoring tasks
| for a factory, or something similar, to a video game interface. That
| idea has a lot of promise.
+---------------
Yeah, right. Make your games and your real apps *too* similar, and...
http://imdb.com/title/tt0086567/
WarGames (1983)
...
Tagline: Is it a game, or is it real?
Plot Outline: A young man finds a back door into a military
central computer in which reality is confused
with game-playing, possibly starting World War III.
-Rob
-----
Rob Warnock <····@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
Pascal Costanza wrote:
> Rob St. Amant wrote:
>
>> For better or worse, just as
>> most drivers don't care how their car works, as long as it runs, most
>> computer users don't care how their computer works, as long as they
>> can get something done with it.
>
> I am happy that I don't have to use reins and spurs to drive a car. If
> cars had been designed in the same way user interfaces for software
> are designed nowadays, this would have been the logical consequence.
> ("...because this is what people were already used to.")
>
But you do have to use a steering wheel, pedals, probably gear stick,
indicators and other strange doohickeys: We now have wide lock-in to
a "conventional" but really extremely weird and old mechanical-era car
interface.
And don't try to tell me it "makes sense" (with my mechanical engineer
hat on, I say, no, for modern vehicles, it really doesn't) - it's just
what you've learned.
David Golden wrote:
> But you do have to use a steering wheel, pedals, probably gear stick,
> indicators and other strange doohickeys: We now have wide lock-in to
> a "conventional" but really extremely weird and old mechanical-era car
> interface.
>
> And don't try to tell me it "makes sense" (with my mechanical engineer
> hat on, I say, no, for modern vehicles, it really doesn't) - it's just
> what you've learned.
I am trying to imagine the application of standard widget sets, menus,
hotkeys, mouse and etc, to the operation of an automobile.
Even though a new user could use the interface and find all the menu
options, it would without a doubt be a horrifically bad way to do it.
An automobile (and much other heavy machinery) requires real-time
fine-grained control of multiple inputs. That's not something our
current widget sets and computer GUI kits are good for. In fact,
with the mouse we're generally limited to manipulating one single
control at a time.
The important aspects of vehicle control could be put on a 2-axis
joystick: shove it forward for throttle, pull it back for brake,
push from side to side for steering, and provide an automatic
transmission for shifting etc. I've even seen some prototype cars
that do exactly this. But unless that joystick has something like
a full meter of side-to-side travel, I don't know if the steering
input is sufficiently fine-grained to compare with a steering wheel
that goes five revolutions from lock-to-lock. Remember, you spend
most of your time on the highway making adjustments that involve
moving the steering wheel less than one degree.
A steering wheel provides very fine-grained control of a primary
input. It's not the only way to do that, but it sure does work.
Also, it provides mechanical redundancy and sufficient leverage
to use it: If power steering fails (and it sometimes does: for example
I had a power-steering fluid line break a few weeks ago) the wheel
is large enough to provide enough mechanical advantage so you can use
your puny human arms to control the vehicle through old-fashioned
mechanical linkages. I've seen joystick-operated cars, but I have
trouble imagining how you'd control them through that kind of routine
minor mechanical failure.
I will grant that the throttle/brake/shifter/clutch combo could use
some more serious sorting out. I'd prefer it as a one-axis joystick
actually. But I'm pretty sold on steering wheels with mechanical
linkages in addition to any power-assist as being a Right Thing.
If not for mechanical linkages my misadventure with the broken
fluid line would have been much, much worse.
Bear
Ray Dillinger wrote:
> I am trying to imagine the application of standard widget sets, menus,
> hotkeys, mouse and etc, to the operation of an automobile.
>
Well, I didn't really intend to suggest _that_ was a viable replacement.
Cars _will_ be drive-by-wire eventually, though. I share
some distrust of such automation, but it has advantages too. Just has
fly-by-wire systems now respond more rapidly and flexibly to changing
conditions than humans manage, so too can drive-by-wire systems.
Actually, the biggest problem with steering wheels is the steering
column. While it's not as gruesomely lethal as it once was (back
before collapsible steering columns were introduced), the steering
column still significantly increases the danger to the driver in
collisions. Various alternatives, including drive-by-wire, even if
still by "joy"wheel (i.e. steering wheel shaped computer input device)
or yoke can eliminate the worst of the steering column.
> The important aspects of vehicle control could be put on a 2-axis
> joystick: shove it forward for throttle, pull it back for brake,
> push from side to side for steering, and provide an automatic
> transmission for shifting etc. I've even seen some prototype cars
> that do exactly this. But unless that joystick has something like
> a full meter of side-to-side travel,
(Aside: Various somewhat tank-lever like back/forward designs allow
quite a lot of travel, and even your desired mechanical coupling, while
avoiding needing such a nastily positioned steering column. Though you
have to be careful they're not impalement-hazards themselves of
course.)
While joysticks are indeed a feature of quite a few prototype cars (and
current industrial vehicles), I'm always a little wary of 2-axis (or
more) ones for control as you described, myself - very easy to
accelerate a bit when you meant to turn...
> I don't know if the steering
> input is sufficiently fine-grained to compare with a steering wheel
> that goes five revolutions from lock-to-lock.
(Steering wheels here tend to be < 3 revs lock-to-lock, and fairly
stiff. IIRC americans favour really loose steering. But they have
fewer bendy roads and complicated city streets)
David Golden wrote:
> Ray Dillinger wrote:
>>I don't know if the steering
>>input is sufficiently fine-grained to compare with a steering wheel
>>that goes five revolutions from lock-to-lock.
>
>
> (Steering wheels here tend to be < 3 revs lock-to-lock, and fairly
> stiff. IIRC americans favour really loose steering. But they have
> fewer bendy roads and complicated city streets)
Here in the US, sports cars tend to be as you describe. My
vehicle is not at all sporty and its main use is hauling
cargo. 5 revs is fairly standard for such applications.
Anyway, the point stands: it's all about granularity of control
and what you call the length of the control axis.
Still, vehicles are good examples of a system requiring I/O
with needs that current computer I/O methodologies simply don't
address. It's good support for the thesis that current
methodology is inadequate.
Bear
On Fri, 19 Oct 2007 08:55:03 +0100, David Golden
<············@oceanfree.net> wrote:
>(Steering wheels here tend to be < 3 revs lock-to-lock, and fairly
>stiff. IIRC americans favour really loose steering. But they have
>fewer bendy roads and complicated city streets)
Actually, most Americans prefer tight handling when given the option
at comparable cost. The preference for soft vs hard ride is a
different matter - a lot of Americans do seem to prefer a soft ride
(not me, I like to feel the road). But Cadillac at least seems to
have come up with a soft riding suspension that still offers pretty
tight handling.
I think, though, that cost is the primary factor. In Europe you can
get a bare bones car with decent handling - not so in the US (unless
you buy foreign). American auto manufacturers consider handling a
premium feature. They also like to bundle features so if you want
"sport" handling you also have to take a larger engine, 6-speed
transmission, 17 inch wheels, mag wheel covers, sport tires, etc. The
difference in price between the base model and the "sport" model may
be 30% or more. A lot of people just won't pay the difference.
George
--
for email reply remove "/" from address
Ray Dillinger <····@sonic.net> writes:
> The important aspects of vehicle control could be put on a 2-axis
> joystick: shove it forward for throttle, pull it back for brake,
> push from side to side for steering, and provide an automatic
> transmission for shifting etc. I've even seen some prototype cars
> that do exactly this. But unless that joystick has something like
> a full meter of side-to-side travel, I don't know if the steering
> input is sufficiently fine-grained to compare with a steering wheel
> that goes five revolutions from lock-to-lock. Remember, you spend
> most of your time on the highway making adjustments that involve
> moving the steering wheel less than one degree.
>
> A steering wheel provides very fine-grained control of a primary
> input. It's not the only way to do that, but it sure does work.
> Also, it provides mechanical redundancy and sufficient leverage
> to use it: If power steering fails (and it sometimes does: for example
> I had a power-steering fluid line break a few weeks ago) the wheel
> is large enough to provide enough mechanical advantage so you can use
> your puny human arms to control the vehicle through old-fashioned
> mechanical linkages. I've seen joystick-operated cars, but I have
> trouble imagining how you'd control them through that kind of routine
> minor mechanical failure.
Right. There's also the issue of fundamental differences in the way
that different input devices, such as steering wheels and joysticks,
map to tasks, which need to be carefully considered. Resolution and
what's been called the length of the control axis (lock to lock wheel
range versus the width the joystick travels) are mentioned above.
There's also the isometric quality of the movement (there are
stationary steering wheels and joysticks that respond to pressure
rather than movement), the motion type (rotary versus linear--I don't
think this would be important in practice, though), whether the device
has a neutral position (using a non-isometric joystick that maps its
absolute position to the direction of travel might not be robust
enough--an accidental joggle of the knee could cause a crash), the
size of the dead zone (play in a steering wheel), and so forth.
As was mentioned up-thread, it can be problematic when the performance
properties of a software interface (from the user's point of view) can
change drastically depending on the input device hardware. I'm glad
I'm not in automotive human factors; these issues are hard enough to
model for devices that control stationary computers. :-)
In article <··············@telus.net.no.spam>,
Wade Humeniuk <········@telus.net.no.spam> wrote:
> I think this is really valid point. It appears the common way of
> using a computer is to simulate what was done before computers. We
> mimic spreadsheets as they were done on paper (while adding some
> automated arithmetic between cells). 3D computer games mimic how we
> move and interact in the real world. An inventory system becomes a
> glorified catalog (again with some automation of the really tedious
> tasks, of course the really boring work of actually doing inventory is
> kept as is). Instead the spreadsheet and the inventory systems could
> be automated away with enough ingenuity and application of computer
> tech. As for 3D games, well, who knows?
>
> Wade
Well, this is due to a problem that is very well understood by
people invested in human performance technology, rather than
computer display technology. Successful technology isn't just lines
of code or pixels drawn on the screen, it's a change in human labor
processes. Where computer systems have had their most success is
when they've been used to change or eliminate human labor processes.