Lab ExperimentunA

Moousture in future

It has been months since the release of Moousture; and its time I should speakup about the library itself and the future it may have. Honestly speaking, after the release there has been a good as well as some bad feedback; but the good feedback and the “WOW Factor” was always dominating yet the bad feedback included fear and people not ready to accept a new way to interact with browsers. After the announcement of Chrome OS and the looking at time line of Mozilla Ubiquity I am very much excited about the enormus potential this pure JS library can have in future.

Currently the Moousture is using string edit distance for gesture matching. I am currently experimenting is Euclidean distance or Manhattan distance measures. Till yet they are no good than the string edit distance(except few cases); so the quest continues in this area. Also I am looking for an Android and Palm Pre so that I can implement a probe for them as well; having the iPhone version in action I am very hopeful that they would be easy to implement too and will be available in no time.

Having said all that, I think the most important thing missing for Moousture currently is awareness and publicity. People have no idea how to and where to put this baby in action. I can see its potential usage from normal website accordions and login forms to javascript based games (since the announcement of WGL from firefox, opera, webkit I know flash is going to be replaced). Off-course I won’t should out publicity, publicity all over but yet I am look for potential places and people who can really utalize it.

3 months ago

August 7, 2009

Comments (View)

About Dynamic JS Loading

While loading Javascript from an external sources and hand embedding the script tags I came across the browser’s behaviour when they are asked to load a .js file. Studying the famous Steve Souder’s book “Even faster websites” I came across some of the main concepts on how browsers load stuff up and the optimizations. Although modern browsers are improving at a great deal but we should never forget the X-factor of quick loading websites.

I still remember I used to hate the GMAIL pre-loading. With my experience of designing I have learned that users usually call a system fast which loads and responds quickly, not the ones with a loading bars! Loading bars are the old “Flash” fashion now. Take an example if I only want to check out a list of my mails (In case I am expecting somebodies mail), guess what? You have to see that loading bar every time you cleaned browser’s cache! Should I make that html layout default with no scripts? Well don’t you ever do that! Because your message Compose will loose its cool WYSIWYG editor and that auto-completion email address feature with a long list of what elses. The whole point of story is that there is no place for me to stand between the coolness and quickness.

The same factor of doing deffered loading was exploited by Microsoft in claiming there operating system to be fast in XP version. However doing a deffered loads on javascripts has its own disadvantages, one of them is network traffic. The more you boil the fundamental parts and components of your javascripts, the more requests you have to make in order to load them and the network traffic goes up accordingly. So while making a design choice it is extremely important for a programmer to make a good choice between the amount of loadable code chunks and the number of loadable code chunks. Please remember that loadable code chunks here are referred as a .js files. So the number of loadable files and the size of loadable files are the most important factor and are totally up to a programmer.

So are there any outlines for a programmer to do that? Well there are lots of efforts out there, most of frameworks like dojo and YUI are providing there loaders. Steve souders is one of the guys going around and making programmers aware that only backend optimization is not the whole story. As closing I would recomend every so called “Web 2.0 developer” to have a look at lazy loads and convince himself that when and why they are important?

4 months ago

July 10, 2009

Comments (View)

Mootools Cross Domain Ajax Requests

Recently I came across the issue of Cross-Domain ajax requests. Since I am a mootools lover I started looking over for some adapter that can help me do that. I came across many solutions which apperantly seemed to work. The flXHR, Fjax they all seemed to be there but I was already using mootools in my project right? Why should I write the boiler plate onreadystatus change when its already done! Ok then I there must be adapter for these. And guess what flXHR provided adapters of Prototype, jQuery, Dojo, but not mootools. So I took up the headache reading up the checked out Git of mootools Request.js and fortunately it provided me with a well crafted interface exactly same as XMLHTTPRequest ( except few things which were obviously to be cross-domain specific). So I have implemented a XDomain (Cross domain adapter for flXHR). You can enjoy the treat demo here.

Download mooflXHR file here. Dependecies:

Mootools
flXHR

The adapter provides with a mooflXHR object and a mooflXHR.JSON object. Both of them are excatly following the same API as that of Request and Request.JSON respectively. In options you can specify an additional option of XDomain. This XDomain object will be passed to the constructor of flXHR providing you the ability to customize the power of flXHR without breaking the Request style abstraction. A simple example can be:

var mooflProxy = 
	new mooflXHR.JSON({
		XDomain: {
		noCacheHeader:false,
		loadPolicyURL:"http://search.yahooapis.com/crossdomain.xml"
	},
	url: "http://search.yahooapis.com/ImageSearchService/V1/imageSearch",
	method: "GET",
	onSuccess: doFoo,
	onFailure: dontFoo
	});

Hope you enjoy the XDomain.

5 months ago

July 1, 2009

Comments (View)