Fed up with the web

> Dear Squeakers and Tweakers,
>
> I have been charged with building a website for a creative arts group,
> and I have to say I am fed up with the web, web2.0, AJAX, even Seaside
> (sorry avi) and all the rest.
>
> Its a long story I have been coding javascript in a little gizmo called
> TiddlyWiki for a year or so to try and do something a little clever with
> Web Browsers as a client, to be honest its hard work. This week I was
> looking at Laszlo a fairly cool tool (though on the same day I found a
> book about Laszlo son of Dracula which didn't bode well). In Laszlo you
> throw together an XML file which reflects the structure of your UI, the
> sort of thing you would do with a drag and drop GUI builder 15 years
> ago, sprinkled with some javascript for defining behaviours, and pop
> your data into a second XML file. This text file collection is requested
> by your browser which (when developing) hits a Java Tomcat serverlet
> which churns compilers for a minute or so to produce a swf file that
> will run on a flash plugin (but it doesnt bother to use any features of
> flash it just wants the renderer and vm). Within 1 day I find that
> Laszlo cant tile a graphic as a background and I hunt around and find it
> has a draw canvas that implements part of the Web Hypertext Application
> Technology Working Group spec for drawing. I looked at this spec and the
> future of the humble browser looks ominous, complicated is not the word
> for it. In this whole venture all I am thinking is What a mess!
>
> Then I found Tweak, and loaded a squeak image - as you do - and lo, we
> launch pretty quickly dont we, compare that with mozilla or acrobat and
> I am on a 500Mhz box remember the old days?
>
> All I want is to draw a picture, display some text, and share it with my
> friends. It would be nice if that text was familiar to my friends and
> you could click on things the way they are used to, but thats all I am
> asking for. A bit of user interactivity might be nice.
>
> So... what would it take to simply take squeak and present it in such a
> way as to be familiar to the average web browser user. Take a look a
> Tweak, Large fonts and we are almost there, some form of text layout
> engine, have text with inlined images and widgets. We are so close to
> having something useable but we never quite make it.
>
> thoughts anyone?

>
> So... what would it take to simply take squeak and present it in  
> such a
> way as to be familiar to the average web browser user. Take a look a
> Tweak, Large fonts and we are almost there, some form of text layout
> engine, have text with inlined images and widgets. We are so close to
> having something useable but we never quite make it.
>
> thoughts anyone?
>
> Keith

>
> On 5/26/06, *Darius Clarke* <[hidden email]
> <mailto:[hidden email]>> wrote:
>
>     Somewhere Avi had a Seaside demo where he presented the Squeak
>     desktop as a graphic to the web browser. Clicking on the graphic
>     in the browser sent the click through to Squeak so you could
>     browse through your Squeak environment. No text entry, dragging,
>     or animation. Perhaps not too hard to add those with javascript
>     libraries.
>
>
> ------------------------------------------------------------------------
>
>
>  

> John M McIntosh wrote:
>> We are trying to do this with Sophie, building books you can  
>> interact with, then publishing to a http server, then reading the  
>> book from the http server in a Sophie authoring/reader application.
> Can you explain this a bit more? Will the user have a squeak image?  
> And, then would they download a "book" via something akin to  
> Squeakmap? (where the Book Repository (the Squeakmap) is a repo of  
> books the user can browse and  "install" a selected book into the  
> image?)
> How do you see this architecture? Does the user interact with the  
> book locally?
>
> brad

> Dear Brad,
>
> I am getting psyched up to do this, Its going to be a quest, a rally
> call, I think time and effort spent seeing if I can deliver a squeak
> hosted web page  will be time well spent. Heck I dont care if my users
> have to load a plug in, if I just pause to think about it I just hate
> the web architecture that much. These new technologies dont even have
> rotation in their base rendering engine, I just took the trash can for
> a 360 degree spin just to remind me how good it feels and working in a
> code browser rotated at 33 degrees just because you can do it and no
> one else can!
>
> Step 1, I discovered Text Tool in tweak, and it works! Bliss
> Step 2, find some more fonts, X11 Fonts are there in SqueakMap, could
> use some more though.
> Step 3, lets go get that Squeakland plug in....

> Dear Squeakers and Tweakers,
>
> ........
>
> thoughts anyone?
>
> Keith
>
>
>
>
>
>
>
>
>
> ___________________________________________________________ All new  
> Yahoo! Mail "The new Interface is stunning in its simplicity and  
> ease of use." - PC Magazine http://uk.docs.yahoo.com/nowyoucan.html
>

> Dear Brad,
>
> I am getting psyched up to do this, Its going to be a quest, a rally
> call, I think time and effort spent seeing if I can deliver a squeak
> hosted web page  will be time well spent. Heck I dont care if my users
> have to load a plug in, if I just pause to think about it I just hate
> the web architecture that much. These new technologies dont even have
> rotation in their base rendering engine, I just took the trash can for a
> 360 degree spin just to remind me how good it feels and working in a
> code browser rotated at 33 degrees just because you can do it and no one
> else can!
>
> Step 1, I discovered Text Tool in tweak, and it works! Bliss
> Step 2, find some more fonts, X11 Fonts are there in SqueakMap, could
> use some more though.
> Step 3, lets go get that Squeakland plug in....
>
> Keith
>
>
>
>
>
>
> ___________________________________________________________
> All new Yahoo! Mail "The new Interface is stunning in its simplicity and
> ease of use." - PC Magazine http://uk.docs.yahoo.com/nowyoucan.html

> [hidden email] wrote:
> >> have you thought about the Squeakland plugin and starting there?
> >
> > There seems to be little that the Squeakland plugin can't do relative to
> > the various other web options. Its only flaw is its lack of ubiquity.
> >
> > ===Blake===
>
> I started but cant seem to get the plugin to work at all as yet
> following the instructions on squeakland. I am on Windows 2000 with IE6
> Firefox 1.5
>
> Johns Sophie videos look cool.
>
> anyone got any ideas about how to get the squeakland plugin working
> (even with 3.8 image perhaps or whatever VM tweak is using)
>
> Keith
>
>
>
>
>
> ___________________________________________________________
> All new Yahoo! Mail "The new Interface is stunning in its simplicity and
> ease of use." - PC Magazine http://uk.docs.yahoo.com/nowyoucan.html

> [Squeakzilla subtitle: The dinosaurs did die out you know]
>> be interested to know how your progress goes with your project. If
>> you go the "plugin" route, or if that doesn't satisfy your needs, where
>> you go next.
>>
>> thanks for keeping us informed,
>>
>> brad
> This is a muse...a dream... or a rant... take it as you will. (p.s. I
> am now a carer as my day job so I don't really know what I am talking
> about since I have been out of touch with coding and particularly
> squeak for a while so do feel free for correct me or update me if you
> want to)
>
> Since everyone is doing scary specs these days. (
> http://www.whatwg.org/  this site is what motivated me to thingk this
> way!) I think the first step is to informally spec out the desired
> solution a bit.
>
> If we do this spec and it looks worthwhile then perhaps Todd could get
> some VCs (see his blog) to pay for it to be coded by September when I
> need this website to go live ;-)
> Plug-in looks like the only way:
>
> We could do a thin client (like the Avi demo mentioned earlier) in
> which case there are plug-ins for the likes of VNC available. This
> would not handle multi-media at all well so given that I want to piggy
> back this into the browser world the plug in route looks like the only
> viable way. The aim could eventually be to be able to dump the browser
> container using some native widgets (thus saving several hundred Mb of
> memory/disk useage, and lots of CPU cycles), but I guess thats a way
> off. Instead the browser (mozilla etc) is sufficiently
> "extensible/hackable" that we can probably wangle whatever we need
> through their hooks.
>
> Ubiquity:
>
> The lazslo people have targeted the flash plugin as a runtime in order
> to get ubiquity, and now they are targeting DHTML, impressive I have
> to say, but IMHO its still hard work, and in the last three days of
> getting my head around the tutorials I seem to spend half my time
> hunting through the bug reporter and filing bug reports. I think that
> the firefox missing plugin search should help us a lot with the
> ubiquity issue, and since we all have broadband these days we don't
> mind the odd 30 Mb download. Now if we can get a few vm carrying Apps
> released into Application space (sophie?), ubiquity might not be so
> difficult after all, Acrobat managed it with a basic file viewer app
> after all, and Seaside could be distibuted as a webserver, CMS
> platform, to get the vm onto servers. Is the vm in any linux distros
> as standard? Half the stuff I load when I install linux I never even
> look at, so it shouldn't be hard to get distributed if we really try
> hard enough. (does the linux kernal need a vm?) Of course the whole
> idea of spoon is that at some point the size of the distribution could
> be quite small, and easier to sneak in to places.
>
> Goals:
> 1. Antidote to the feature bloat hotch potch technology collage that
> the web web2 is threatening us with and the plethora of learning curves.
> [The web has a several models, and several versions of models and
> standards, and versions of standards, with their formats markup,
> editors, validators, etc for storing data statically on filesystems,
> data transport to load it into a browser, a second model of the static
> data, now dynamic, in the browser, the DOM, and a vm with scripting
> environment to manipulate the DOM, and dare I say it a third model in
> the internal rendering engine. Instead of all of these different bits,
> lets have one model and one (or 2) vm(s) with one scripting engine and
> renderer all working together in a seamless homogeneous manner.]
>
> 2. Say no to static text files, say no markup languages, say no to
> XML, just use binary data wherever possible and direct manipulation
> wherever possible. If data models are hierarchical and nodes have
> attributes then its the same as xml anyway.
>
> 3. The result should look like the users familiar web world. Flash
> worlds are usually based upon a fixed sized display area. Documents
> can be long vertically and scroll down. Support both. (Laslo and flex
> are both Flash bound and so they dont feel quite right for this
> project) for this to work we need to escape the plug-in box, or at
> least look as though we do.
>
> Implementation Ideas:
>
> Serverside: Expect to have Seaside/Kom on the serverside, Seaside is
> looking to play in an AJAX world and our client will just be the
> ultimate AJAX client (the same as Laszlo is aiming to be). Seaside has
> or can do all of the authentication and session, keep alive
> connections and server push type stuff that we might need.  Of course
> if we know that our servers are going to be squeak we can optimize
> many things. Compressed data transport at a minimum. For example
> Lazslo uses their Tomcat serverlet to compile xml file that defines
> the app and serve the resulting swf flash file, they also use the
> server as a proxy for accessing many web services. I think the reason
> for this is that the plug in security model only allows contact with
> the originating server machine. We could use the server to pass
> messages to our plugin container if the direct pipe is not available
> (I haven't checked yet) We could similarly use the server to proxy
> other services (e.g MySql, SqueakMap etc). The server will be able to
> supply resources updates etc that the client might need, e.g. it could
> be a font server, or updated plugin server.
>
> Clientside:
>
> Say no to cookies. Have a file area for plugin use and an OODB for
> persistent client side data. It might seem a bit heavyweight but I am
> sure I can think of some useful uses for it.
> Would it be possible to have a "no-save" policy like hypercard, in
> which disk based data "persisting" is transparent, and so abruptly
> leaving a web page and returning to it potentially allows us to return
> to the same state easily, just like when you are filling in a web form
> and you hit the back button the fields that you filled in are still
> there. The onunload browser event could help us persist relevant state
> automatically.
>
> Clientside Display:
>
> No markup just an object model and direct manipulation. Aim to
> recreate most of the browser display functionality and scriptability
> without the overhead of parsers etc. The first problem is the browser
> scroll bars, we could hide them and provide our own, or use theirs and
> handle their events to scroll our display region. The second option
> will allow us to be compatible with themed browsers, and looks to be
> the best bet (as long as we don't have to route the scroll events via
> the server)
>
> (note: In the section below we are not trying to rewrite Mozilla here,
> just put together enough components to be able to look like Mozilla -
> remember no parsing of HTML just direct manipulation and assembly of
> components. You can do the parsing of HTML if you want to but I dont)
>
> Panels can provide the equivalent of html divs, they can be manually
> positioned via handles in the (tweak) project builder or automatically
> positioned by your choice of AlignmentMorph type container. The
> standard paragraph flow of a typical web document would be provided by
> vertical alignment container. Within this container simple components
> can provide many of the paragraph based display elements, e.g. <ul>
> <ol>, paragraph border, paragraph background/pattern/pic/shading,
> before/after spacing, and I guess a table component goes without
> saying. We would need a richtext control, one which can provide a
> rectangular paragraph style presentation, and this may double as a
> styled editable text field (bye bye wiki syntaxes of the world). A
> second variant of the richtext control would be the equivalent of an
> html span element, a run of text over one or more lines within its
> container up to the next component, and/or the ability to insert a
> component inline as part of the text run.
> Support mouse over, and onclick actions (drag n drop too?) on bits of
> text and components. Some links would need to be routed to the browser
> container in order to hit a normal "Mesozoic" web page. Some links
> would visually turn the page within our view in order to simulate
> visiting other web pages within a site which may or may not need to
> hit the server to retrieve more content. If the progress path though a
> site is predicable then the client may prefetch the next page in
> anticipation.
>
> The idea that web pages and markup should be content as opposed to
> presentation is foundational to the way the web has evolved and what
> markup languages are all about. In a web app, our display component
> collection is likely to be a view on some form of abstract data model
> anyway, so if we need a different view on our data then we just build
> an alternative presentation. If our presentation has been authored in
> the project builder then we might want to use this content on its own
> outside of its presentation. We could ask the component tree to
> serialise itself into Xml if we wanted to and manipulate it from
> there, but we dont want to. In MVC, MVP style why not just treat this
> "document" as a Model and whatever use we have for this data, we build
> Views and Presenters that pull the data they need out of our model,
> through various queries. We can annotate the original model with node
> ids etc to make this easier, we could even emulate XPath functionality
> on our model since we are expecting our display components to be
> hierarchical. Now doing it this way we get something that XML cant do
> out of the box, not only can we pull data out of our model, but we can
> put it directly back in as well.
>
> I remember one of the web frameworks out there sucked in its designers
> html template into an object model, then the coders  write code to
> manipulate that model into a form that included the hooks the coders
> needed. Then a code gen tool, generated code that would stream out the
> completed final html file (fast!). The important bit that made all of
> this work was to have the data in a live usable tweakable model. So I
> figure if we only have our data in this live tweakable useable form,
> then we win.
>
> The other thing about XML and the markup languages is that we loose
> the idea of data elements having behaviour, ie. none of the elements
> are objects. Our "squeak-dom" components may potentially be objects
> too, or might be given aspects that allow them to function as objects
> in other contexts.
>
> Stylesheets: All of the components that are used in the model should
> be skinnable, through setting attributes and thus configurable via a
> programmatic interface. A stylesheet is a script that trawls through
> the model and applies non-default styling to the elements it finds.
> E.g. If you find a list component with attribute flashy defined then
> change its bullet graphic to this one. Thus to support this stylesheet
> method each component attribute (including extents and positioning)
> will need a default value, a user supplied value, and a stylesheet
> applied value. Thus it should be possible to easily revert a
> stylesheet and apply another one.
>
> I better get some sleep, I have 11 hours washing up to do tommorow!
>
> Feedback welcomed, am I crazy or should we try it?
>
> Keith