The Solution
Fix the Web With Squeak
So how do we fix the Web? Bolt-on half-measures designed to enable features from HTML 1.0 have proved to be terrible failures. Wouldn't it be nice if there was one language for web creation. What if this language applied regardless of whether you wanted to post some text or write a complex application? What if there was a means for non-programmers to use this language? The whole idea sounds a little unlikely, right?
Absolutely wrong. This is no pie-in-the-sky dream. The language, called Smalltalk, already exists. The smalltalk browser plugin is already in use, and you can download it right here. *Link to smalltalk plugin* Smalltalk is a well-known language originally designed at Parc Xerox, and further refined at Apple Computing. It's in use today, and it's very easy to learn.
A little review is in order here. A workable web environment requires a common language, such as HTML, plus three applications; a composer, for creating the content, a server, for sending the content to another computer, and a client for reading the content. In the case of a Squeak-enabled web, Smalltalk is the common language. Any web server can send out methods, classes, and programs all written in Squeak. That part is very easy. But what about the composer and the client?
It's currently possible to compose content in Squeak's Morphic environment, which is a combination interpreter and IDE. It's possible to write programs for the client very quickly - the Morphic is a really efficient programming environment. However, if you want to publish something to a high level of professional design, using the Morphic is somewhat difficult. It's possible, but at the moment it's pretty painful.
The client is similarly immature. The plugin works perfectly for getting a Smalltalk program off the web and running it, but it needs some improvements to be able to handle published content at a high level. So we need to make major improvements to both the client and the composer.
Required Client Improvements:
The plugin needs more complex mouse behaviors. The default left-click needs to be a request for a link. The default right-click will open a menu similar to the right-click menu in Firefox, complete with "Back, Forward, Reload, Bookmark Page, Save Page, Send Link, View Image, View Page Source, etc." options.
The squeak plugin needs better browser integration.
The plugin needs to make decisions about page layout, text size, picture size, etc., based on knowing about the current size and shape of the window it's working in. This will require the creation of special classes and methods written in smalltalk that will properly read/write graphic design elements such as columns, navigation bars, graphics, icons, etc., and render them as a properly designed page. These classes will be shared between the plugin and the composer.
The plugin needs to make native use of SVG graphics. It can't merely display them, it needs to be able to resize them on the fly.
The graphical elements and tabs already built into the plugin need improvement. They are ugly and badly designed. Ideally we will make the client themeable and request themes from the community.
HTML currently prefers an enviroment with only three fonts. This made sense when everyone did their surfing with a 14,400 modem. Now that we have DSL it makes no sense at all. The plugin needs to natively use as many fonts as the designer wishes, and it needs to download them from the web at will. It should not violate intellectual property rights.
The plugin will need good HTML handling so it can use advertising content designed for the old web. (Maybe it can simply call gecko?)
The plugin needs to be able to make http requests of ordinary servers. Eventually there will be special Smalltalk enabled servers that provide enhanced content, but the plugin will always work with Apache or IIS, or any other web server.
The plugin will need to work with Windows, Linux and MacIntosh.
Required Composer Improvements:
The composer needs more complex mouse behaviors. The default left-click needs to do the appropriate thing inside the current environment. This might choose a text box, open a new graphics box, move a box, etc. The default right-click will open a menu similar to the right-click menu in Open Office Writer, giving the user proper publishing choices, such as "cut, paste, Insert background photo, make bold, etc."
The composer will require special classes and methods written in smalltalk that will properly read/write graphic design elements such as columns, navigation bars, graphics, icons, etc., and render them as a properly designed page. These classes will be shared between the plugin and the composer.
The composer needs to make native use of SVG graphics. It can't merely display them, it needs to be able to design them into text and give them a default size.
The graphical elements and tabs already built into the composer need improvement. They are ugly and badly designed. We might make the client themeable and request themes from the community.
The composer will need to work with Windows, Linux and MacIntosh.
The composer will need to export classes to a client or server.
The composer should hide the morphic unless the user wants to go down to that level.
The composer should have templates, a help system, samples, and (hopefully) a wizard.
The composer should be able to make pages into clickable links that work in Apache. It should also be able to deal with directories for appropriate server-side integration.
Go back to "The Problem"
Continue to "The Grand Plan"
