Paul D. Fernhout wrote: > Gregor Lingl wrote: >> The logowiki can be found here: >> >> http://www.logowiki.net > > Just as a general comment, running a current Mozilla under Debian > (Unstable), with JavaScript turned on, there are no graphics on those > pages for me when I click Run. Nothing happens.
You probably don't have support for the <canvas> tag, which is relatively new and the only way to do that style of graphics in a web browser at this time. Only very new Firefox and Safari support it, and IE has some hacks to make it work which may or may not be enabled. Of course, it would be good if the site pointed out this limitation, but that's entirely feasible to do. > 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. A web browser is not a dumbed down environment at all. While Alan described the browser as barely being up to the capabilities of an Apple ][ (in the email that was linked previously: http://www.redhat.com/archives/olpc-software/2006-April/msg00035.html), a browser is also wildly more powerful than that. For dynamically creating graphics it is pitiful, with only this very new tag to make it feasible at all, and even then only to a very limited audience. For other features -- the features which demonstrably matter to the larger world! -- it is quite capable. The web browser's constraints are significant, but also the source of its power. It gives substantial power to the client to do the rendering and to make choices, and very limited control to the content creator. This is in contrast to a more "powerful" medium like PDF or PostScript, which allows for fine-grained control. The result is a high level of abstraction, and a substantial number of intermediaries (browsers, server-side software of many kinds, etc). I personally prefer the compromises HTML made, because it demands open content and has done well to create a democratic medium where the skill required to publish is fairly low, and it is not hard to achieve a result that is on par with the most professional output you might find. Using Logo Wiki as a way to encourage people to download a plugin would be a mistake IMHO. Putting all your code into a little dead box embedded on a web page is pretty lame, and it shows. There's only two kinds of plugins that matter anymore: video (Quicktime, Windows Media, etc) and Flash. And Flash is taking over video too. Everything else is entirely dead (and good riddance!). Plugins of various kinds have been done many, many times, and failed many, many times. (There's even a Logo/Java plugin: http://turtletracks.sourceforge.net/) OTOH, if you really want fancy output, you want Flash pure and simple. I'm glad Logo Wiki is in Javascript and uses the canvas, but if they really want more control and graphical power then Flash is the obvious next step. > 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". Probably just a misconfiguration or something minor; the architecture they use puts all the processing in the client, and can scale easily to a very large number of clients. It's just dead content as far as the server can tell. > I've fought this battle before in other (commercial) situations. The web > is good for many things. But if you want a rich client, forcing everything > through a web browser involves making big sacrifices which often just > often aren't worth it. If they don't embrace the medium, then maybe it won't be worth it. If they embrace the DOM -- which is a lousy bitblt, but a great text layout system -- then it might be worth it. If they embrace the DOM and HTML forms and HTTP, then they might just get HyperCard, because I'm pretty sure it's living in there somewhere waiting to get out. -- Ian Bicking | [EMAIL PROTECTED] | http://blog.ianbicking.org _______________________________________________ Edu-sig mailing list [email protected] http://mail.python.org/mailman/listinfo/edu-sig
