[Edu-sig] Alan Kay - another one of his ideas

[Paul D. Fernhout]

Andreas-

Welcome onboard Edusig. I guess your appearance here signals a real 
interest in the core Squeak team in Python? (For those of you who do not 
know Andreas, he did the original Squeak port to Windows, plus many other 
neat Squeakish things, especially 3D ones.)

Thanks for your clarifications; I was responding mainly to the intent 
outlined here,
   http://www.redhat.com/archives/olpc-software/2006-April/msg00035.html
which seemed a little more ambitious.

Also, having dealt with this issue of stuff in a browser in other 
settings, I think it is wandering into an area that is a little more 
complex than is alluded to (as nice as the ideas you suggest are, 
including dynamic translation to multiple backends, like Jython already 
can do for Python on Java).

For the biggest example problem, people expect the "Back" button in a 
browser to do certain things. So, in LogoWiki, does the back button reset 
the simulation? Not saying whether it should or not -- just that this is 
the kind of area where expectations tend to get violated. For another 
example, people expect URLs to be a good description of state. So when I 
press the run button, and then cut and paste the URL, does that produce 
the identical output bitmap for another user? Again, I'm not saying 
whether it should or not -- just that this is another potential area of 
violated applications -- because you are trying to use a browser in a way 
people have little experience with. I'm not saying what the LogoWiki team 
has done is not interesting, or a great demo (if I could see it :-), but I 
am saying that trying to put complex content in a web browser is fraught 
with lots of perils, because you end up trying to map a complex set of 
possibilities made possible by simulation and interactive editing into a 
very specific set of expectations derived from dealing with hypertext.

Let me give a more concrete example of a "thin client" for a complex task 
failing in practice, from here:
http://www.theserverside.com/tt/articles/article.tss?l=NakedObjectSeries_5
"What is really beginning to force the issue, however, is the growing 
awareness of the limitations of the browser interface from a user 
perspective. Our opening example is one of many. A couple of months ago we 
met with a large company in the engineering supplies business. They had 
launched an online application that allowed their frequent customers to 
order supplies, and provided other functionality to help those customers 
manage certain aspects of their own businesses. The new application has 
already been very successful in business terms. With a familiar 
browser-based interface it was easy for their customers to learn. Within 
weeks of the launch, however, the most active customers were beginning to 
express frustration with the user interface: not just because of the slow 
response time but with the strong modality. Keeping multiple jobs open at 
once, moving or copying objects between those jobs, dealing with a phone 
enquiry in the middle of a task - all the realities of their customers' 
businesses - are difficult if not impossible on the browser-based system."

That article goes on to make a very important distinction: "The web 
browser was designed for navigating hypertext documents; it has adapted 
well to very simple business transactions, but not to more complex tasks. 
Alan Cooper made a useful distinction (see 
http://www.cooper.com/articles/art_your_programs_posture.htm ) between 
'sovereign' applications (used intensively) and 'transient' applications: 
his point being that they have very different user interface needs. The 
thin client architecture can often meet the needs of a transient 
application: Amazon.com and its one-click ordering is possibly the epitome 
of this approach. But a browser-based interface, with its strong 
sequentiality and modality, is totally unsuited to sovereign applications."

So, a deep question for an educationally-oriented developer is, do you 
want to focus on supporting "transient" educational experiences or 
"sovereign" educational experiences? Since I personally think the 
educational value in an interactive programming environment is more in how 
it lets kids learn by doing, I personally am far more interested in 
providing learners and designers with open ended tools (which was also 
Kay's original emphasis) than canned "educational" content. Although I'll 
admit that if a learner can find such "canned" content when they want it, 
that is a very good thing, so I'm not entirely against such content -- 
just a matter of emphasis. And, at the very least, even if you want to 
deliver such content with the web (e.g. Ajax or Flash or Java 
applications derived from Python or Smalltalk), that does not mean that 
your development environment also has to run on Ajax (or Flash, or Java, 
or whatever).

I also think the analogy to Wikipedia is somewhat problematical and may 
miss the forest for the trees. Sure, Wikipedia has a lot of specific 
interesting pages which users wander onto. But "Wikipedia" is a complex 
platform both in a social sense and in a technological sense, even if the 
content is served through a web browser. It's kind of like looking at 
Squeak and its community and saying, well, that's just about clever use of 
BitBlit, so let's make BitBlit better. I feel that just trying to make 
more dynamic pages misses the broader issue here of Wikipedians (the 
authors) interacting with a very large system with a long persistent 
history and surrounded by a community. It's ironic that when I started 
thinking about contributing to Wikipedia some time back, my reaction is 
that it needs local tools to it can be a distributed network to share 
server load and allow people to visualized relationships between articles 
and authors in 3D (i.e. perhaps something built on Squeak :-).  So, I had 
a very different set of thinking about that forest heading in a very 
different direction.

I'm not saying, say Wikipedia, could not benefit from LogoWiki technology, 
just that I don't see that as a really big win, compared to say, just 
using Flash or Java Applets for dynamic content. What's really happening 
here is just a battle over standards for end user content delivered over 
the internet. A nice win, maybe, to use more open solutions like 
JavaScript over Flash, and so a battle worth fighting, but not a big win 
in-and-of-itself for education. And many solutions can coexist. And it 
seems to me that Alan Kay's work was always about the big ideas. And if 
one is going to fight the battle directly, then perhaps it might be easier 
at this point to argue more for Java solutions (as problematical as they 
are) like Java Applets or Java web start. For the Python Community, Jython 
already runs on those, so it is a "good enough" solution. So, maybe 
targeting Jython/Java (or using a similar compatible approach) is another 
way to go, even for Smalltalk related systems.

[I have a bit more to say on Squeak/Python/Jython issues I'll put in 
another post.]

--Paul Fernhout

Andreas Raab wrote:
> Paul D. Fernhout wrote:
> 
>>I don't mean to complain specifically about these pages, just to point out 
>>that while the supposed intent here is to make programming available to 
>>the masses by using a dumbed down environment like a web browser, in 
>>practice, this fails for me. Whereas, when I install Squeak or Python, it 
>>works. So, I think Alan Kay may be going in the wrong direction here in 
>>some ways, compared to Squeak. Not to say it might not be useful for 
>>certain audiences, just that it fails the "everyone" test, at least for me.
> 
> 
> Not surprising, really, because you're missing the point of Logowiki. 
> Logowiki's main purpose is as an example for what "dynamic content" on a 
> web page can mean, in particular in an educational setting. Remember 
> that we lost the ability to author with the introduction of the world 
> wide web and we're only about to get it back. The choice of Logo is 
> simply because it's easily recognizable for the intended target audience.
> 
> [A secondary motivation for Logowiki is as an experiment in "zero 
> install" deployment and to be able to see what can be done with Ajax and 
> friends and a bit of compiler translation technology which is not so 
> different from PyPy btw - parts of it would make perfect sense to 
> translate Python to Javascript code on the fly]
> 
> 
>>And of course, the site was also inaccessible when I first learned about 
>>it (from Kirby's post to this list I think) from too much demand most 
>>likely, so it also failed the cost test. Presumably, they just could not 
>>afford to put enough resources into the project for "everyone".
> 
> 
> Paul, you are confusing a demo with a product. Logowiki was done to 
> explain to OLPC what we mean when we use terms like dynamic content and 
> what may change if, for example, Wikipedia had the ability to included 
> such dynamic, end-user authored content.