Status

Nothing much seems to have happened for couple of months, is lively now deadly?

thanks in advance

Keith
_______________________________________________
lively-kernel mailing list
[hidden email]
http://lists.hpi.uni-potsdam.de/listinfo/lively-kernel

Hi Keith,
_______________________________________________
lively-kernel mailing list
[hidden email]
http://lists.hpi.uni-potsdam.de/listinfo/lively-kernel

Hi Keith,

I did not get any Feedback and I went on vacation. After this we decided that we needed a process for updating / merging different code bases / lively installations.... Which we do not have right now. so if you have any feedback of how the release candidates work for you this would be great.

Best,
Jens



Am 25.10.2011 um 18:39 schrieb "Keith P. Hodges" <[hidden email]>:

> Hi Jens
>
> great to hear you are still there, the fact that the release candidates were coming in quick succession and then stopped led me to wonder.
>
> I am now investigating feverishly.
>
> Keith
_______________________________________________
lively-kernel mailing list
[hidden email]
http://lists.hpi.uni-potsdam.de/listinfo/lively-kernel

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

Hi Keith,

thanks for your comments. This is valuable feedback.

On 26.10.2011, at 05:34, keith1y wrote:

>
> *Be the web - but better.*
>

 Separating between edit mode and using mode makes some things easy but at the same time not so lively any more. Your are right that people don't expect to be able to
break a internet page by reading it. But think about reading a book with a pen? Lively comes only with a very powerful pen....

> *Do flash Websites (www.wix.com) - But Better*
>
>
You are are right we should make simple thinks more simpler and provide more of such content that allows for creating page via drag and drop.

> *Do Hypercards least copied feature - But Better*
>
>
Yes, I too really like the HyperCard idea, we should work on this one as well.


> *Coding for coders*
>
Our non lively (and not yet existing) process of open source style collaboration is also a challenge we have to tackle. Maybe Fabian's git project will bring us there a step further.

> *The Best Idea from "Quicktime Interactive"*
Yes, copy and paste should not be a problem, we implemented it for svg where it really was hard and with html things should be really easy again.

Best,
Jens


_______________________________________________
lively-kernel mailing list
[hidden email]
http://lists.hpi.uni-potsdam.de/listinfo/lively-kernel

Hi Keith,
_______________________________________________
lively-kernel mailing list
[hidden email]
http://lists.hpi.uni-potsdam.de/listinfo/lively-kernel