There are different ways to handle compression for the web but here we’ll be looking at unzipping using Flash.

Flash doesn’t handle zip files natively but there are a few libraries available that will add support. The one we’ll be using here can be found at nochump.com

First off we need to actually load our zip file:

private function loadZip():void{
    var loader:URLLoader = new URLLoader();
    //since flash doesn't know what to do with a .zip
    //we need to make sure it just loads it as a
    //binary file so it doesn't try to cast it as text.
    loader.dataFormat = URLLoaderDataFormat.BINARY
    loader.addEventListener(Event.COMPLETE, onLoadComplete);
    loader.load(new URLRequest("main.zip"));
}
private function onLoadComplete(e:Event):void{
     //do stuff here
}

Once we have our zip file loaded we can begin to manipulate it to get at the delicious compressed data it contains.

private function onLoadComplete(e:Event):void{
        // get our data from our loader
        var loader:URLLoader = URLLoader(e.target);
        //create a new Zipfile and pass it our data to decode
	var myzip:ZipFile = new ZipFile(loader.data);
}

Each ZipFile has a property called entries which is an array of ZipEntrys. Each file in the zip has a corresponding ZipEntry. A ZipEntry is basically a data object that contains the file name, size, last modified date and a couple of other properties about the file. To trace the first file name we could just do this trace(myzip.entries[0]);
To actually get at the data we need to use the method ZipFile.getInput(entry) which returns a bytearray of our file.

var entry:ZipEntry = myzip.entries[0];
var data:ByteArray = myzip.getInput(entry);

Once we have a byte array there a few different ways to decode our data. For this example, my zip contains an xml file. We need to convert our data to an XML object. This is surprisingly easy.

var myXml:XML = XML(myByteArray.toString());
trace(myXml);

If our zip contains images it slightly more complicated. The easiest way is to use a Loader’s loadBytes method. This loads a bytearray and decodes it into the correct type (ASDocs). In this case, jpg.

var myLoader:Loader = new Loader();
myLoader.contentLoaderInfo.addEventListener(Event.COMPLETE, onBytesComplete);
myLoader.loadBytes(myByteArray);				

private function onBytesComplete(e:Event):void{
	var loader:Loader = Loader(e.target.loader);
	addChild(loader.content);
}

One major caveat to loading a zip of images is that its quite CPU intensive. While you do save time on load you can end up waiting for Flash to decode your images for you. Also, zipping a bunch of images doesn’t save much space. It does however cut down on the amount of requests you are making to the server.

And that’s all there is too it. Loading compressed files is a great way to compress your load times and make sure your user can zip on through!

See these quick examples:
cubes
lines
starfield

First off, if you don’t know about Paper.js, definitely check it out, its a vector graphics framework built on top of Javascript and the HTML 5 Canvas element. It gives you the ability to easily draw some pretty neat things, and performance seems pretty great as well (usually runs about 60fps). It takes a bit getting used to, but its an interesting approach to the normal javascript development process. Here is the basic setup.

<script src="js/paper.js" type="text/javascript"></script>
<script src="js/main.js" type="text/paperscript"></script>
<canvas id="draw" width="100%" height="100%" resize="true"></canvas>

As you can see, first you include the Paper.js source file, then you include your code file with the type as text/paperscript. This will setup your basic events and also provide your script with the extra functionality and classes that Paper.js uses. You also pass the id of the canvas element you want to draw to with the canvas parameter. That’s pretty much all you need to get you started. Paper.js adds a lot of new classes to use for drawing and also hooks up your events for you so you can get right to the creative part. A complete api reference is available here. My template file usually starts off with some of the more common events, as seen below.

function onFrame(e) {
	e.time // Time in seconds since the app started
}
function onResize(e) {
	view.size // The current canvas size, in a Size object.
}
function onMouseMove(e) {
	e.point; // The current mouse position, in a Point object.
}

I won’t go into too much detail about the basic javascript code, but i will go over some of the basic drawing techniques I’ve used. Path is your basic drawing class, allowing you to draw lines and shapes similar to the flash graphics engine. To control the look of your Path you set fillColor and and strokeColor (they accept CSS values or the colour classes provided by Paper.js like RGBColor). Once a path has been created, it is in the display list unless you specifically call remove(). You can also add your paths to a Group which allows you to control them all with a single function call. I’ll go over how i drew the shapes in each example.

Lines / Source

Lines are one of the easiest things to draw in Paper.js. Simply create a Path, add points to the line by sending a Point object to the add() function. If you would like your line to be curved instead of jagged, simply call smooth() on the Path. To change the thickness and colour, simply set the strokeColor and strokeWidth properties. Note: the smooth() function must be called any time the points change.

path = new Path();
path.strokeWidth = Math.round(Math.random()*4)+2;
path.strokeColor = STROKE_COLOR;
for (var n=0; n<POINTS; n++) {
	path.add(new Point(width/(POINTS-1)*n,start+i*SPACING));
}

The animation of this is a simple sin wave with a multiplier based off mouse position.

Stars / Source

Stars is also a simple application.

new Path.Circle(new Point(0,0),values.size);
initial.fillColor = 'white';

var symbol = new Symbol(initial);
for (var i=0; i<values.stars; i++) {
	var item = symbol.place(Point.random()*view.size);
}

We create an initial circle using the Path.Circle function passing in the center point and the radius. This time, we create a Symbol out of the circle which basically turns our circle into a stamp. We call the function place() on the Symbol and pass in a Point object to create a copy of the item at that location. Since we do not keep track of each item in this project, we can simply loop through the children of the activeLayer which is a property of the project variable (available by default without having to declare it).

var layer = project.activeLayer;
for (var i = 0; i < layer.children.length; i++) {
	layer.children[i].x += values.speed*item.data.scale;
}

The speed of the particles in this example is controlled by mouse position.

Cubes / Source

The cube creating part of this example was taken from the Paper.js examples, but i’ll try to explain whats going on:

Path.RegularPolygon(view.center, 6, 30);

This function creates a 6 sided polygon that has a radius of 30, simple enough, but to create the 3d colouring effect, we have to parse each segment (each segment being a triangle for each side of the shape) into its own Path. To do this, we run through the segments array and clone() each segment into a path and colour them appropriately. This only needs to happen once, as we are then able to simply clone() the Cube that we have created and stored when we want to make another.

The animation of this is just a simple spring effect with a mouse based rotation applied to the container.

I hope these examples have given you a good primer to get started with Paper.js. Now that you have the basics, you are good to go, let your creativity fly. Paper.js allows you to easily create shapes, lines, and even work with loaded images. There is still a lot of unexplored terrain left for me to explore, but here are a few of the examples i came up with after taking a look through the examples posted on the Paper.js website. I’ve also provided the links to the source so you can see how its done.

View Examples

You can check out the official examples here.

Text and typography effects are all the rage right now. This example shows you what you can do when you can manually animate each individual letter. Manually splitting text fields for animations can be pretty annoying though. In this post I’ll show you how to split your text fields for use in animations.

First off, you’ll need a text field. I prefer to have my TextField in place and added to the displaylist already so that you can replace it later with your individual fields.

To split our fields we’re going to create a class that will split our text up for us, store references to the fields it creates and replace our single TextField with many fields. This class should also provide methods for accessing our newly created fields.


package {

}
}
}

So now we have our class structure flushed out. As you can see we have a Vector for storing our fields, as well as places to store references to both our original field and its parent.

We would use this new class like this:

var splitText:SplitText = new SplitText();
splitText.splitify(myField);

//do something here to the new fields!


But wait! our split method doesn’t do anything yet! Lets fix that.

Lets build our function:

public function splitify(textField:TextField):void{

//we increment our counter like this because using myArray.length() is actually very very slow.
_numFields++;
}
}


Done! we now have our fields in place and ready to be animated!
As an example of what we can do, this next chunk will change the color of each letter to something random.


for(var i:int = 0; i< splitText.numFields;i++){
var tf:TextFormat = splitText.textFields[i].getTextFormat();
tf.color = 0xFFFFFF * Math.random();
splitText.textFields[i].setTextFormat( tf);
}


Now i know javascript frameworks are nothing new, and these two have been around for awhile now, but the JQuery vs Mootools debate still comes up quite often so I’d figure I’d share my reasoning for picking one over the other. It also seems like lately there has been a bit of a shift away from flash so javascript has become a more popular topic as of late. Another factor is the misconceptions of HTML5, a lot of what clients think HTML5 brings too the table, has already been possible with javascript frameworks. So lets get right into it shall we.

Right off the bat, I’ll mention that i prefer to use Mootools, so you may think there is bias but i have used both and i know some of the strengths and weaknesses of both, so bare with me. I am also the only developer at the office that likes Mootools, the other 2 experienced javascript developers both use JQuery, so you know there are different opinions floating around.

First thing we should get out of the way is where the libraries are comparable.

• Size: both libraries are roughly 80kb without being gzipped, so no real winner there.
• Speed: There are multiple tests out there comparing the speed, seems generally even, with each library excelling in different areas. (http://mootools.net/slickspeed/, i know its old, but it looks the most comprehensive)
• Selectors: Both use $ to select dom elements, JQuery uses it as a css selector, MooTools as an id selector, with $$ for your css selections, so not a whole lot of difference there.

Now for the differences, I’ll just focus on the main ones that I’ve encountered and happen to be opinionated about.

• Syntax: Here is one of the places i think MooTools has the upper hand. JQuery’s main method of programming involves chaining (function’s returning the original object so that another function can be called. i.e. MyObject.dothis().thenthis().thenthat(); ). I know many people like this way of coding, but coming from more object oriented languages, it seems like a process to make code messy and confusing. I know it is possible to write cleaner code in JQuery but chaining is the generally approved syntax so it’s what i see most often. Also the shorthand methods such as hover() which attaches function’s to rollover events. This seems like just another way to make it harder for others to work with your code, generally i’ll look for an addEventListener function call to check for rollover events, but now i also have to worry about all the extra shorthands and when combined with chaining, this can get really messy really quick.
• O.O.P: Here is where i think a lot of people will agree with me. Coming from Object Oriented Languages, i realize how important this style of coding is to me, which is also why i generally choose MooTools for my projects. It is one of the more comprehensive implementations of the O.O.P syntax that i have seen, it even includes inheritance. While the JQuery plugin syntax leaves something to be desired, at least in the realm of O.O.P.
• Community: This is where JQuery stands out. The community that stands behind JQuery is quite large, with many plugins being created and shared daily. MooTools can’t really say the same, there are definitely coders out there making scripts to share with the world, but it simply isn’t as big or as in depth as the JQuery community. One day MooTools may catch up, but i doubt it, i feel that JQuery simply targets a larger market than MooTools.

So there you have it, the reasons i choose MooTools over JQuery. You may not agree, heck, even people at my office don’t agree, but if you agree with any of the points i have made, i say give MooTools a try, i doubt you will be disappointed.

A great site that takes this debate much further is http://jqueryvsmootools.com/. It even includes comprehensive examples of each point. So if you want to know more information about these two libraries, definitely check it out.

P.S. I didn’t mention the other libraries out there because frankly, i haven’t used them (other than prototype/scriptaculous, but that was a while ago), so i can’t speak about them. I’m not trying to take anything away from them, i just don’t know enough about them.

P.P.S. MooTools can extend flash objects to call functions on them, which we do a lot around here. And last i checked, JQuery wasn’t able to.

Working with Google Sketch-up
For whatever reason, the creative team had chosen Google Sketch-up to design the galaxy. This proved to be a bit of a curveball. With thousands of lines and 3D spheres in the model, we scratched our heads wondering how we would get the data out of Sketchup and into some kind of format we could use in the browser. We spent hours googling, searching for a proven method to get the data out. We tried three.js but there wasn’t a way to make it work – managing optimization was a big concern. Our focus turned to the file types that Sketchup exported.

We eliminated all but one sphere and one line in the galaxy and exported the file in every format possible. After a bit of poking around, the .xsi file format showed the most promise. Once opened in a text editor, we were pleased to discover we could clearly see what line data looked like and what made up a sphere. Lines had a start x,y,z and end point x,y,z. Sphere data was a bit more complicated, with a single the 3d object comprised of hundreds of mesh positions defining faces of the spherical body. A flash application was written to parse the lines and php was used to parse the sphere data, average the position in space and calculate the radius. We finally had our data.

Drawing the galaxy
We had seen some promising work done by Giuseppe Sicari which bolstered our expectation that what we were going to attempt would work.. he was just missing a Camera you could control. It was now time to write our very own javascript 3D engine and in only a few days Mikko had made this. There still was no camera object and we still needed to create ‘the compass’ indicator but it was a start. High-fives were had.

Illustrator to HTML5
One of the key design elements in the site is the compass indicator that orients the user experience in the site. The compass is again re-used for the mobile version of the site. These design assets were provided as Illustrator files and we needed a way to express them as line data we could plot on the canvas. After hours of poking around we stumbled upon Pierre Lindenbaum’s library that could convert svg to html canvas drawing commands… but of course this was not ready for us to use out of the box because our data was different. Another php script was needed to convert this drawing commands into the paths we use in our native JAM3d.js. And since the compass is comprised of two planes that intersect, the second set of paths needed to be offset onto another axis and the values painstakingly shifted to make the model symmetrically join. The fun was just starting..

In Part 2, Mikko will explain the challenges we faced writing Jam3D.js, Camera3D and more!

Flash, as you are probably aware, has a limit of how big an object can be before it won’t be rendered. In flash 10, this limit is 4096*4096. Normally this isn’t an issue but when you try to apply a 3d transform to a large bitmap, especially if you are changing the Z, it can make it appear to flash to be much much larger than it is. For example, in one instance flash was reporting to me a height of 329435294 which is obviously not correct. My solution was the break up the image into 2 and put them in a container and transform the container. That doesn’t seem to make sense since the container is now the same size as the previous object but I don’t ask questions.

Lastly, I had another issue where doing these transformations in a loaded SWF caused my SWF to behave as though mouseEnabled was set to false and no amount of =true seemed to fix it. Again the solution here was to transform the container. I’m Lucky I had that option here.

You would think that after all this time and new player updates that these issues would have been ironed out and we’d have fast, easy 3D for the masses but it’s still not ready. I would suggest biting the bullet and going with something like Papervision3D or away3d even though it may seem like overkill.

1. How to get people to see your app
2. How to make money off that app

App stores really solve both of these issues. One of the coolest things as a web developer is the fact that there are ways to create “native” apps for these app stores using the standard languages we use: html, js, css, and AS3.

Here are some platforms web developers can deploy to using the languages noted above:

Conclusions:
If you are a developer and want to start developing with minimal overhead and with huge reach the Nokia Ovi store is the way to go. The Apple iDevices are extremely popular in North America but worldwide Nokia is still a HUGE player with bigger reach.

The Chrome web store is the most straightforward option for web developers. The sign up fee is very minimal and there are no other tools you need to learn (or buy) to deploy apps. Out of all the stores the Chrome web store takes the smallest cut however it’s a very new platform and doesn’t have the same user counts the other platforms can boast. The $1.99 minimum app price point is interesting in that as a developer you will not be competing against $0.99 apps however it being a new platform it could deter users.

Even though neither of the Apple stores won in any of the columns they are obviously still a great option to develop for. They were the first platform to have an app store and so the other app stores are definitely trying to compete against Apple’s stores and with good reason. The iOs store still sells the most apps out of any store.

The Android market shouldn’t be forgotten as it is currently the biggest competitor in app sales vs the Apple store. Enrollment fees are quite a bit lower than the Apple store’s and it’s nice that they payout developers quite often.

Blackberry App World is an interesting underdog. Currently it’s receiving A LOT of developer support especially from the Flash Platform community because of the Blackberry Playbook and this promotion. It’s very cool that they’ve been working on app monetization strategies more than anyone else. This gives the most avenues for developers to make money. Cost for being a App World developer is much too high though. (although currently the initial $200 fee is waved) Unlike the other stores where you pay a one time fee or anually in the App World developers pay $200 to receive 10 credits. One credit is used per app you submit. You will not receive your credit back if your application fails the QA process. You will also have to use one credit to update your app. This to me is ridiculous! In order to maintain quality of applications developers should not be penalized.

Overall the great news is that using the languages you know with some new tools you can target most, if not all of these platforms. (more on these tools in a future post)

...snapshot of the "constellation" of lines and 'spheres'

The model, aka the “constellation” pictured above, had over 8000 lines and over 300 spheres. The designer, thankfully, had used a monochromatic palette. This was a good thing because it meant that we would not have to worry about z-sorting the lines and circles. Our mission was to render this puppy, fly around and cull what we couldn’t see.

Once we had parsed the data (that’s a future post and a half), we were ecstatic, it was nearly imperceptibly different from what we were seeing in SketchUp… but.. then we glanced at our frame rate stats and we were only getting 9fps. As we moved our camera in and out we saw the fps hover between 4-9fps. We thought, ok, maybe Safari on mac is not as fast as Chrome. Alas! Chrome was performing slighly worse, with a lower bottom end at 3-6fps.

Where was our sweet spot? How many lines and spheres can one draw on the canvas and achieve acceptable frame rates? What is more taxing, lines or spheres? We would be happy with 20fps. We broke out the lab coats and went to work creating versions of the constellation with decreasing amounts of lines and spheres. We also separated the lines from the spheres and ran some tests independently. Keep in mind, that this is not uniform test since, as you can see in the screenshot above, the lines are not spread evenly in x,y or z space nor are the total number of lines and circles drawn on screen at any given time. So this is also a test of pure javascript performance, looping through the arrays and deciding if a line should be drawn.

The Tests

We ran 3 tests. For our 1st test, we took every third, then fourth line etc. from the original 8847 lines in the array. The second and third test gave us insight into how much overhead the circles were adding to the drawing methods.

We wanted to share our findings with respect to the performance (measured in fps) we recorded in FireFox, Chrome and Safari on the Mac and their counterparts on the PC. All tests were conducted at 1200×800. We were also very interested in seeing how the HTML5 canvas performed on the iPad because part of the end project is to produce similar results in the browser on the iPhone and iPad. All of these browsers support the canvas and some browsers have even fashioned marketing campaigns around their performance. But what we found surprising was the chasm separating the slowest from the fastest frame rates.

As you will see in the tables below, Firefox was pathetically slow at rendering the model on both mac and pc. Safari was better than Chrome for some reason, as it is widely believed Chrome owns the distinction of being the fastest browser.

In Test 2 and 3, you can see that drawing the circles was not an insignificant overhead, representing  a 2-5 frame jump at the lower end of the range.

While we acknowledge this isn’t completely a fair test, it shows you that Chrome is not necessarily king, and that there is serious room for improvement from Firefox. We look forward to updating this post with some numbers run against FF4 and Chrome 9. Perhaps the best news was that Safari performed well for us, and is considered the target browser for the project. We will update this post in the coming weeks with greater detail about this project as this data has more to tell us about the performance of canvas drawing methods across the browsers.

Hecham Ghazal was up first with Parallel Human Processing. I wondered what Ghazal meant by this title, but it soon became clear that he sees the internet as a socio-cognitive network – one that can solve complex tasks/problems better and faster than any artificial intelligence (AI). As Ghazal pointed out, the best AI still can’t tell you if a joke is funny but people on the internet can.

Since the start up of social networks Ghazal realized that they resembled a neural network where each neuron was represented by a human being and the axons were represented by internet connections. The problem is how do we harness the power of social networks to solve complex problems that require cognitive intelligence? One solution is Ghazal’s company LeanIn which allows users to create social networks to filter through the massive amounts of online video so that you can easily find videos you want to watch and even which section of a video everyone thinks you should watch.

Ghazal’s solution deals with organization and filtering of video content, but what else can we do with social networks? I think that this is an area that we can definitely focus on and perhaps show clients that social networks can do more than generate buzz around a product.

Next up was Dr. Hossein Rahnama with Business Models for Mobile Applications. Rahnama’s research focusses on context-aware computing and he’s best known for his involvement in the Paris Metro Application.

What I found extremely interesting about the application was how well it automatically adapts to the context it’s in – whether that be ambient noise levels or recognizing broad swipe gestures for users with impaired vision. This type of adaptation brought to mind that we usually talk about applications degrading nicely, in which case we’re typically thinking about system capabilities. In Rahnama’s talk I learned that it’s not just about the system your application is running on but also about the external environment. For example, his application would automatically switch to a minimal interface if the surrounding bandwidth couldn’t support the regular graphically rich interface. As someone who has waited countless times for Google maps to render I can definitely appreciate this feature.

Much of Rahnama’s talk focussed on context-aware applications that were developed by both graduate and undergraduate computer science students. One of these is an on campus application that will populate lecture notes based on which building the user is currently in. As part of the application’s services, some lectures are recorded and can be accessed from a user’s phone allowing students to sit back and pay attention instead of the typical mad scribbling of notes.

Another application, RAIMA (RAIMA publication abstract), dealt with multi-context visualization to allow users to network easily at conferences. Rahnama joked that he was known as the guy who researched dating applications, and I can see why after hearing about the eight dimension matching involved in this application. Essentially users build a profile specific for their work interests which then plots distances to other users based on similarities. The application displays a graph with icons of other users along with their similarity distance so that you know who to talk to. You could then message users directly without ever having to hunt them down in person.

Applications aside*, Rahnama focussed his talk on methods for how to approach application development. Though being context-aware is highly important in current mobile development he also pointed out the importance of being platform agnostic now that browsers on most mobiles support technology that can handle highly interactive applications. Other points he touched on in terms of a design model were harnessing collective intelligence, using data as the driving force, and lightweight programming models. For developers these concepts can be viewed in terms of building a core which you build tools and APIs for. Users can then use your tools to create novel content. A great example of users creating content is the Audiotool application where users can generate their own music and share with others – all within the browser, and with tools developed by people in our industry.

What I took from Rahnama’s talk was that as mobile computing grows, we as developers need to step back from trying to keep the visual appearance of an application or a site the exact same. Instead we should be focusing on how to create experiences that can adapt to both the system and the real time environment they’re in.

I believe that as interactive developers we are in the right place to create some really amazing things with the concepts from these talks. We already use social networks in many of the sites or applications we build. How about we go one step further? For example, why not let users help a game evolve into something better? Maybe the game could aggregate various ways users win levels and create a smarter AI. What about creating applications that are so context-aware they almost seem intelligent? Granted we have many applications that use geo location but we can go even further. Let’s think about concepts like ambient sound, current bandwidth, or how the user is interacting with the screen.

Yes, trying to create highly adaptable sites and applications is a lot more work but interactive developers have a history of pulling off the impossible. We’re already seeing the evolution of products that allow us to be somewhat platform agnostic with our development (e.g. Adobe AIR for almost everything), making the process of multi platform development just a little easier. Perhaps one day we can look forward to mobile browsers that have direct hooks to system hardware. To quote Rahnama “Innovation should be fun and social” and I think that we tend to follow that motto. It’s just a matter of seeing how much further we can go with it.

*There were so many applications that Rahnama went through. Here are the highlights on some more:

• A TTC version of the Paris Metro application that can automatically synch with your calendar and notify people you have a meeting with on how late you’re going to be. If you’re wondering about reception, this does require installing hardware throughout the subway.
• Automated interactive blogging that generates a comic strip at the end of the day based on phone usage that day. You can also invite friends to modify the comic strip if you’d like.
• A social table using the Microsoft Surface to suggest conversation topics based on your barcoded profile stuck to the bottom of your glass.
• Augmented reality at the ROM which allows you to use your phone or special eyewear to look at artifacts around you and receive information about them. The application also opens up a stereoscopic map of the museum to help you find your way around.

The timer had been set and the team broke into pairs. The paired teammates discussed their approach and generally speaking one team member per pair was at the keyboard while the other observed what was on screen.

Aaron and Sunil were charged with the sea mines. Nick and Mikko were working on the dock and general game framework. While Salpy and Michael worked on the sea itself.

What resulted after just a little over 2 hrs of development was a functional prototype that was tracing key game events. Really the game was less polished then everyone wanted to see it but in truth the objective had been met in a little over the allotted time. As much as i wanted to blow a whistle and pull the plug on the workstations a la Top Chef, a terrific vibe was present that felt too good to arrest.

The team is working on a tight deadline this week and probably into the next but there is a collective will to post the game once we’ve had a chance to give it that little TLC it needs.

Stay tuned!