Hi Jens, Shame you didn't get much feedback, lets see if I can send you some.
*Be the web - but better.* My own plan for moving things into the mainstream would be to start by being able to have lively pages look and behave like a normal web page, the principle of least surprise for the user. This means links open operate on the same page, and "do you want to leave this page" is at least optional. To open in edit mode, I would do something like add a url parameter &mode=edit. (I call this concept "deadly") Being the web but better, SVG, no css, no html, no browser compatibility issues. (IE finally) just direct manipulation. I always thought that the same effect as css can be achieved by having a DOM crawling script, like a clever find and replace. So if you tag objects in your model the script can say: for all the squares tagged "blah" make them red. The same mechanism can be used for translation, and accessibility, but basically you have a scripting language that can do anything on the fly, what do you need all the overhead of defining syntax, code and parsers etc. Even though I was using squeak and seaside, css and browser compatibility killed me as far as web dev was concerned. So instead I used WIX, in one weekend I had a reasonably cool wix site, but... it is flash. *Do flash Websites (www.wix.com) - But Better* Alternatives to flash? Are there any? OpenLaslo looked promising, it deploys on DHTML and Flash, but Lively is looking like it can match them. Laslo is coded in XML, Lively uses direct manipulation. I know which I would choose. My own goal would be to offer www.wix.com users what they can't have at the moment, a "flashy" website that can run on the iPad. I Chasing wix.com would be easy, my site uses backgrounds, text, picture buttons with rollover and tabs, and that is about it. I have a couple of embedded movies, that would be nice. *Do Hypercards least copied feature - But Better* The winning feature for me would be to be able to pull in the same components in multiple projects. i.e. to provide a background page. No one has succeeded in providing a Hypercard replacement for the masses, and I think that however many GUI builders have chased after Hypercard's crown, none have recreated the simplicity of the Hypercard Background. Easy to build databases were made by simply having a field on the background which had different content on each page. I suspect that it would be a good principle for components to be able to serialise their layout and positioning separately from their content data. So if a "card" can pull in components layout from a "background" but supply the data locally. *Coding for coders* This idea of going viral, shouldn't be hard. Keeping things as simple as possible. The most common development model is a local file system and a text editor. If some of the the content data/resources can be pulled in separately from local files some may prefer to be able to edit them directly. Translation comes to mind. So a source checkout or zip from launchpad, ( launchpad automatically provides tar.gz ) . Is the simplest I can come up with that would allow a coder to contribute back easily. If a lively page itself can know about and save all its parts that would be quite clever, skipping the need for a checkout step. What I am saying here is, running from local files is probably the way to go if you want coders to get involved. The step of thinking about and configuring local web server with dav, is a little too much effort, and for many corporate non-power users (authors and builders) they wouldn't have the time, nor would they be allowed to. The general public will be happy to work in a wiki no doubt. *The Best Idea from "Quicktime Interactive"* The ability to copy and paste i.e. drag and drop live (I assume serialised in to JSON) components from one project to another. In this case form one web page to another. Can it be done? If so, then you don't need a parts bin any more, you just take components from the pages describing or using them. regards Keith -- View this message in context: http://forum.world.st/Status-tp3933841p3939233.html Sent from the Lively Kernel mailing list archive at Nabble.com. _______________________________________________ lively-kernel mailing list [email protected] http://lists.hpi.uni-potsdam.de/listinfo/lively-kernel
