Friday, October 26, 2007

Feedback Frenzy

So.... let's recapitulate what happened a couple of days ago;

1) I got impatient with not getting my program "out there"
2) I decided to release early & often
3) I even did a small screencast (though I didn't realize how small until I saw the tiny windows in the blog :)

My idea was that it didn't matter that my design looked like being hit over the head with a live chicken greased in peyotl, as long as those who did the looking-around were programmers themselves and had the wits and tenaicty to dig around for features - especially if I wrote the features up beforehand.

It was, of course, a very silly idea. The end-result was that of the around 1400 people who took their time to load the composer, a whopping 74 did vote on - and the result was 1.4 (out of 5). Not exactly glamorous, but that's show-biz, I guess.

The big reasons people thought it sucked was 1) It looked like crap and 2) They didn't understand what to do.

Note that in the ajaxian blurb I had bullet point that described the main features, in this very blog I described how to go about it, I put a link to the FAQ clearly visible on the page, and there was a new "System Menu" which labeled each subcategory.

This did not daunt more than a hardy few. It seems that *any* inconvenience is too much for most people - even supposedly battle-hardened programmers (who were my main audience for the alpha release).

But what was good was that I was able to try out the system under moderate load, with moer then one person at a time, since I really didn't know if it would hold water or not (it did, thankfully). So the expereince was not compeltely wasted. Also, I got to know some really interesting people who are doing similar thigns (and a troll, but who's counting? :)

The bottom line is now that I'll rewrite the entire system from more-or-less scratch. It's a wonderful feeling, and it will take *much* less time, since I know what I didn't like with my (architectural) design the last time around.

First of all, I decided to use a database - object layer. So today I managed to coach Propel (of phpdb fame) to generate schemas and classes from my initial phpmyadmin doodles, and during the weekend I'll set up a very basic and wonderfully designed dojo-1.0b frontend.

See you all then.

Wednesday, October 17, 2007

JDA Composer reaching alpha 0.80

JDA Composer is yet another web-based mashup IDE, in the same vein as Microsoft Popfly, openKapow, TIBCO GI and stuff like that. The focus is not so much to be complete one-stop shop but to let people quickly prototype mashups and export them as stand-alone archives when done.

The url, for the impatient is here;

Note that this is alpha-level software which might work, might not and will most probably crash and burn you machine so bad you'll think it's running Vista or something. Just so you know. Right now it's only tested in Firefox :)

Here's a screencast (without sound) that shows how to create a simple google maps Gadget;

You don't need to login to try it out, which is intentional. The focus is on first designing your UI properly, style elements, drag and drop them on each other, change background images, et.c. Then, add JavaScript Blueprints to selected elements. For those of you who recognize the term in this context; Yes, I'm using JDA (Javascript Dataflow Architecture) to wire things together. The composer is itself built using JDA, and it also generates pages adhering to the same standard.

A description of JDA is outside the scope of this document, but I just want to say a few things about Blueprints. They're the basic building-blocks of JDA, actually just JavaScript functions which tie in to the JDA runtime in the page and declare input and output terminals. each input terminal a Blueprint declares has a handler function inside the Blueprint, and each declared output terminal can be tied to send JavaScript objects to the input terminal of another Blueprint. I'm lying a little bit about how it works here :) , but I want to emphasize the LEGO-block functionality of JDA.

As you can see in the screenshot, the Composer has a window which draws the relations between the input and output terminals of the components. In the auto-loaded example page, there is a GenericForm blueprint, which wraps a form with any number of components, and overrides any submit button, so that a submit of the form instead sends a name-value pair list of all input elements ion the output terminal of the component. This is connected to an input terminal of the GoogleMap component, which scans for addresses, and shows them on the map. Not very complicated as an example, but it illustrates the possibilities.

If you want to define your own Blueprints, that's OK as well, just go to the System Menu "JS IDE", and you'll get a window which after a while lists the currently registered Blueprints in the system. Pick one up, if you want, and get a list of the functions inside it. If you choose a function, you'll get a very nice code editor (Which I've thankfully expropriated from Christofe Dolivet and his EditArea team. Thanks! :)

Right now I feel that the system is stable enough to handle a casual try out from people in the know. Please flame me heavily by mail or in the Google Group provided.


PS video

Sunday, October 14, 2007

Usability and Gaming

One good way to measure the usability of the tools you make is to observe whether you're using them yourself or not, and if so, how much. I had an idea to make a small javascript-based game, possibly using facebook as userbase, either as an app or from the outside...

So, I started to make a small blueprint in the composer and tried out the new editor, and it does work. However, I found one thing annoying, and that was that I haven't the foggiest idea how to *reload* a component, when I've added it to the framework. Possibly this might be easy, I haven't a clue, but at the moment I have to reload the entire composer each time I change the code after I've tried it. This is a bit annoying.

So I definitely have to make reloading of code a priority. Another weird thing is that for some reason, loading of scripts or images never gets done on the spot, but rather when the _onInit function returns. But only inside the composer. When I export the page, it works spotlessly, as seen below;

Finally - A code editor that works

Since last christmas I've been looking for off-the-shelf code editor. The kind that captures tab and insert four spaces, the kind that groks JavaScript syntax and highlights reserved words, etc.

I tried using dojo's editor and editor2, but wasn't satisfied with the code aspect of it all. I didn't need formatting so much as syntax highlighting.

Then I saw Marijn Haverbeke's in-browser javascript editor, which kind of blew me away. It looked to good to be true, which turned out to be the case. Not because Marijn isn't a truly good programmer (I dived quite deep into the code at times), but because he used mochikit (without the optional namespacing).

The resulted in the editor borking most of dojo (which takes great pains to namespace itself and not to collide with other stuff on the page), which I relied on heavily for windowing and diverse stuff. I tried to refactor in namespacing in Marijns codebase for about a week before I gave it up. It was really a shame, and so until today I had just a plain textarea to use as editor for my spanking new online Web IDE. :-P

But I checked Marijn's site a couple of days ago, and he had added a link to realted projects, one of which was editarea by Christofer Dolivet, which turned out to be very well-behaved indeed.

OK, I had to be creative when I created things dynamically all the time, and I couldn't use just one instance of the editor, but had to create new ones and remember them and so on, but on the whole I must say I'm greatly relieved. Not everything works perfectly, but it looks good and it works well enough. And it's LGPL as well! Thanks!!

Friday, October 5, 2007

Gadgets Ohoy!

This is so sweet!!! I was lamenting the sad state of my programming proficiency over a couple of beers with a couple of friends yesterday. I was especially bothered that I hadn't managed to translate absolute to relative positioning.

One of the guys told me that I didn't need to; Absolute works as relative coordinates within parent containers. I replied that it did not, but started to think about it. Then I started to experiment a bit more than I did the first time around. Then I discovered that it was actually true; As long as the parent element is relatively positioned. Whew!

And that was the final stopper. In only a couple of hours I managed to create an exported for Google gadgets. Prrof is in the pudding .. er .. pictures. Compare the gadget view with the editor view.