O.C.A.S

Extending the Modernizr.prefixed method

2012-01-08T18:59:00.000+01:00

Starting with version 2.0 the awesome feature detection js library Modernizr includes a method called "prefixed". In short, this method will give you the correct prefixed version of a CSS 3 property which still requires this. E.g: -webkit, -moz and so on. Used in conjunction with the jQuery library you can use Modernizr.prefixed for typical tasks like adding a transition to an element in script without having to clutter up your CSS with a gazillion lines of vendor prefixes.

However, the Modernizr.prefixed method will always return the JavaScript version of the style property. Modernizr.prefixed('transform') will return "WebkitTransform" in a Webkit browser. If you are using jQuery.css() this might not be a problem as jQuery.css() understands this format as well, if it's passed as the property (first parameter). However the prefixes might also be needed as the actual value of an style property. Consider the following:

 $('#myDiv').css(Modernizr.prefixed('transition'),Modernizr.prefixed('transform') + ' 1s linear');

This snippet will attempt to set a transition on the "myDiv" HTML element using jQuerys´ "css" method and the Modernizr.prefixed method, but it will fail to do so. Why? Well, since jQuery is awesome it will allow us to pass "WebkitTransition" or "-webkit-transition" (if in a webkit browser) as the first parameter to the "css" method. For the second parameter jQuery.css() expects a CSS formatted string «-webkit-transform 1s linear», however the code above will generate «WebkitTransform 1s linear», which is not valid CSS and hence the entire method fails. What is needed is a Modernizr method which spits out a CSS formatted and prefixed string, let's call it "Modernizr.cssprefixed". Sadly this is not a part of Modernizr as of today, but the solution is given in the Modernizr.prefixed documentation, we only need a more convenient version of the RegExp given in the docs.

 Modernizr.cssprefixed = function(str)  
 {  
      return this.prefixed(str).replace(/([A-Z])/g,function(str,m1){   
         return '-' + m1.toLowerCase();   
      }).replace(/^ms-/,'-ms-');   
 }

Now that we have this spanking new method we can update our line of code to:

 $('#myDiv').css(Modernizr.prefixed('transition'),Modernizr.cssprefixed('transform') + ' 1s linear');

Voila, it works!

Getting you bearings with JavaScript on iOS

2011-10-23T20:46:00.000+02:00

This post is an extension of my previous post on accessing the gyroscope in your iOS device from JavaScript for a web application. So be sure to read that one first or you'll probably get squat.

New in iOS 5 is the ability to access the compass using JavaScript. This is done precisely in the same way as with all other «orientation data». The «deviceorientation» event on the window object will (on iPhone 4 or newer running iOS 5 and newer) contain two properties related to the compass, these are:

«webkitCompassHeading» [0-360°] - Where 0 is magnetic north
«webkitCompassAccuracy» - How many degrees the heading is off (-1 if error)

So for the demo I'm using the same arrow as in the gyroscope post, except now with gorgeous «north» and «south» indicators added. The goal of the demo is to make the arrow point towards north. When you're done playing with it, take a look at the source and amaze at its simplicity.

Further reading:

The HTML 5 History API

2011-10-09T18:04:00.000+02:00

The HTML 5 History API will allow us to update the browser history and keep the all so important functionality of the back and forward browser buttons when the site is loading content dynamically using XMLHttpRequest.

You want to use XMLHttpRequests (AJAX) to avoid unnecessary page loads, hence reducing network traffic and therefore speeding up you web-app, you probably already do this in your web-apps. However, before the advent of the HTML 5 History API there was a problem with this otherwise smart approach to building web-apps. When a page updated it's content this would not be reflected in the browser history and you had to do a lot of work to make the back and forward buttons work as expected. Thanks to the HTML 5 History API this is now much simpler. In this article I'll explain an approach to "mimicking" a common server-side approach to "dynamic" page loading using parameters in the url, while retaining the functionality of the browser history. Take a look at the demo.

What this typical AJAX demo does is pretty basic:

At startup it loads a page depending upon the presence of a parameter.
When you click a link (at the top), it fetches and swaps the content of the "content" holder of the main page.

Pushed history items

However, after having clicked the links you'll also notice that the back and forward buttons are working, without actually navigating you away from the main page, like the're integrated with the app. Also, items are "pushed" onto the browser history, making it possible to navigate directly to a previously loaded page. It's just updating the content of the content box when you click a link, not the entire page. This is what happens:

When a link is clicked the new content is fetched using a XMLHttpRequest.
The current content is replaced and the browser history is updated.

All of these operations are accomplished using only three (3) API calls:

The «onpopstate» event allows us to listen to events fired when the history is being navigated, like when using the back button. (see line 57'ish in the demo code for how this is handled).
The «replaceState» method allows us to replace the current state in the browser history. This is used to create a state when for example on initial page load.
The «pushState» method allows us to add things to the history stack (it's a stack, hence push and pop).

Now, this does not work in all browsers (IE..duh!) and as of writing this post still has «Working Draft» status. However, support is pretty good and when Microsoft finally adds support in IE 10, all major browsers will support the History API.

Take a look at the demo and the source code (which is heavily commented) and feel free to use the source freely.

Bye!

Creating a simple WYSIWYG editor with HTML and JavaScript

2011-07-03T18:29:00.000+02:00

Wouldn't it be nice to provide the users of your website with a WYSIWYG rich text editor instead of boring forms and a bunch of textfields? Enter «contenteditable». This is a simple property which can be set on any DOM element, like divs, sections and so on. What it does it making the element writable for the user, directly inline with all your predefines styles and content.
contenteditable="true"
To get set up, set the «contenteditable» property of your selected element to "true". In my demo I'm using a «section» element, but as noted above, you can use any DOM element. And that is it actually. You now have a working rich text editor running on you web-page. You can use the keyboard shortcuts like «cmd+b» to make selected text bold and so on. But wait, there's more.

document.execCommand('bold',false,null);

This simple JavaScript command will allow you to programmatically make text bold and thats not all, there are a dozen of built in commands which can be executed on the selected text, for an overview take a look at the WHATWG specification.

When combining «contenteditable» with the HTML 5 storage APIs you can pretty easily make a powerful rich text editor for your users. Take a look at my simple demo to see how you can accomplish this. As a side note, iOS 5 brings support for «contenteditable» on mobile platforms as well.

Accessing the gyroscope and accelerometer using JavaScript

2011-06-26T17:06:00.001+02:00

With the advent of "mobile" devices such as the iPad, iPhone and all the gazillion Android devices, an increasing demand for browser-applications to sport the features and functionality native applications arises. In this article I'll have a quick look at one of these features, namely «device orientation». First of all, take a look at the demo. In this demo I'm using the "deviceorientation" event listener of the «window» object to listen for orientation events. Orientation events are in short events triggered when your device is twisting and turning, sort of. In my iPhone, these events originate in the accelerometer and the gyroscope. For your phone this might be different, but it doesn't matter as the API's for accessing the data are pretty much the same and part of the «DeviceOrientation Event Specification». Note that this demo is only tested on the iPhone 4, so if you have something else it might not work. Let's get to it then.

window.addEventListener('deviceorientation', orientationHandler, false);

First of all we need to add an event listener for the «device orientation» event. This event is fired by the «window» object as mentioned above. We then simply set up our event handler.

function orientationHandler(e)
{
 image.style.webkitTransform = "perspective(500) 
rotateZ("+e.alpha+"deg) 
rotateX("+e.beta+"deg) 
rotateY("+e.gamma+"deg)";
}

There are three properties of the «orientation event» we want to get at.

«alpha» - This is rotation about the Z axis. In other words left and right rotation.
«beta» - This is rotation about the X axis. This means how much you are tilting the device towards you.
«gamma» - This is the rotation about the Y axis, or the angle of the device screen if you may.

There are also two other properties present in iOS 5 which gives you access to the compass and it's accuracy, but those are not used in this example.

The «perspective(500)» transform simply defines how "far away" from the object you are when it's rotated, or the depth if you like. Since the properties of the «device orientation» event correlates to the values handled by the CSS transform properties, no calculation is needed. Try it out! (Should work on iPhone 4 and iPad 2)

References:

W3C - DeviceOrientation Event Specification

HTML 5 Web Workers and image processing

2011-06-05T19:08:00.003+02:00

One of the more exiting things we are getting via the new HTML specification is Web Workers. If you have no idea what Web Workers (lets call them Worker from now on) are you can basically think of them as "sandboxed" threads. By threads I do refer to threads as in «multithreading», an architectural feature of modern CPUs and operating systems. Workers allow us to run tasks separately from the main thread where all the drawing, animation and DOM manipulation is going on. This allows us to do calculations without leaving the impression on the user that the browser is "hanging". If you have worked with other "thread wrapping" technologies like Grand Central Dispatch (GCD) you will get Workers without fuzz, however Workers do have some limitations that other similar technologies don't have.

Workers limitations and usage
First of all, Workers are separate code blocks of JavaScript not found in the spawning script, kinda.. In most cases a Worker is a separate JavaScript file which you DO NOT refer to in you HTML script tags in the HTML document. However, Workers can also be defined inline through the BlobBuilder interface. In this post I will use only external Workers. Also, there are two kinds of Workers, «Shared» and «Dedicated». I will only use «Dedicated Workers» in this post.

Workers cannot access the following:

The DOM or the DOM APIs
The window object
The document and the parent object.

A worker can access:

The «navigator» object
«XMLHttpRequest»
A read-only version of the «location» object
The Application cache
setTimeout(), clearTimeout() and setInterval(), clearInterval()

A Worker can also spawn other Workers and import external scripts via «importScripts()».

The demo (aka. the fun part)
For the demo this time I have created a simple web-app which loads and displays 3 pictures n times. You can randomize the position of the images by clicking the randomize button. You can pick the number of images displayed as well as their size. The two image manipulation buttons will grayscale and invert the images, if you check the checkbox the images will perform the randomize animation concurrently with the image processing. It's this latter part which calls for the usage of Workers.

The demo will show you how to spawn a separate Worker for each of the images, thereby allowing for concurrent processing and animation without much degradation in performance. I won't explicitly go through all the layout and animation code here, rather focusing on the usage of the Workers.

var worker = new Worker('DWGrayscale.js');
worker.addEventListener('message', function(e){
   ctxAr[e.data.index].context.putImageData(e.data.imagedata,0,0);
});
worker.postMessage(...imagedata...);

On line 126 - 133 within the grayscale function we create a Worker for each of the images, then we add a listener for the «onmessage» event allowing the Worker to communicate with the main thread. We finish off by posting a message to the worker using «postMessage» and passing the image data. These messages are the only way to communicate with a Worker. This means that we also need to implement this interface in the Worker itself.

addEventListener('message', function(e){
 var imageData = e.data.imagedata;
 //....process image data....
 postMessage(...imagedata...);
});

In the Worker «DWGrayscale.js» we grab the passed image data from the «data» property of the event. We then go on processing the image data, when done we post a message back to the main thread passing the image data which then in turn can be used to update the canvas element on screen.

Why not pass the Canvas element or at least the Canvas context?
Workers do not have access to the DOM, because it would not be thread safe. Workers are limited to passing object which can be serialized into JSON, which does not support cyclic objects. The Canvas element is a DOM element and the context is a cyclic object, hence we need to get the actual pixel array which we can pass back and forth to the Worker.

Take a look at the demo and the source code to learn in more detail how the demo was created.
Note also that you should probably run the demo in Safari as it has no limitation on the number of Workers concurrently running like Chrome has, also the animations uses the WebKit prefix and will not work in non WebKit browsers. So, please don't use this code in an production environment!

References:

Quicktip: Skewing an image with JavaScript and CSS3

2011-05-01T20:14:00.000+02:00

Have you ever found yourself in a situation where you needed to skew a rabbit? If you haven't, you'll probably enter this place soon, so here I am to prepare you. The task is to skew an image on a HTML page using CSS and JavaScript. This could be attached to for instance a button click event. This is a one liner..
document.getElementById('myImage').style.transform = "skew(-15deg)"
The «skew» property of the «transform» CSS method takes degrees of skew as an input. Negative numbers will skew the image top right, bottom left and positive numbers..the other way around.
Note that in order for this to actually work, you will need to use vendor prefixes as the time of writing this post. For Safari (desktop and iOS) and Chrome (and Android) you would use «webkitTransform» for FireFox «mozTransform» and so on.

The Peacekeeper

2011-04-11T20:21:00.000+02:00

Peacekeeper on an iMac 3.0 Ghz

I decided to try out Futuremaks spanking "new" Peacekeeper browser tester today. In contrast to other more "nerdy" tests like Acid3 and SunSpider which are useful for people like me, Peacekeepers tests are more targeted at actual normal usage of a browser, making it slightly more interesting for users without a degree in computer science.

On the other hand, if you want to understand the six test, well.. it gets a bit technical. The first test «rendering» is a test of how fast the browser can draw stuff to the screen, while doing other calculations and operations at the same time. The second test which Futuremark calls «social networking» is actually a test in how fast the browser can create a SHA1 hash, parse some XML and filtering and sorting the elements of an array. Thirdly we arrive at the «complex graphics» test, which is a test on canvas drawing operations, canvas being part of the new HTML 5 standard. The «data» test which I have renamed to "arrays" does work on exactly that, array manipulation. The «DOM manipulation» test, is one of the most important tests as this tests the browsers ability to look up elements in the DOM fast. This should be of particular interest to jQuery fans. The last test «text parsing», is what its name suggests, parsing and searching in strings. To get a full detailed explanation of what the individual test entails, see Futuremarks FAQ site.

My testcomputer was an iMac 3.06 GHz, with 8GB of RAM and an ATI Radeon HD 4670 graphics card running OS X 10.6.7. It matters, because these tests will very, much, depending on your computer and OS.

As for the results one can clearly see that the WebKit browsers beat the snot out of Firefox. Chrome is clearly the fastest browser overall, however for DOM manipulation Safari is slightly faster than Chrome. Again, beware of this one jQuery fans because this is where all those selectors come into play. Chrome is ruling the array manipulation speed, this might be due to the V8 JavaScript engine. All the browsers basically suck when it comes to rendering HTML 5 Canvas graphics. As a side-note, I observed a test that was run on a Windows based computer as well. To our surprise, both Chrome and Opera beat Internet Explorer 9 into the slippers when it came to canvas performance. Beauty of the web my ass, in your own tests internally made tests perhaps.

Conclusion
So, judging from this Google Chrome is the browser your should go for. And in my opinion, it is. For me, I'm sticking with Safari for my day to day use, but I'm using Chrome when writing this blog post.

Scaling and rotating an elephant using JavaScript

2011-04-03T19:40:00.006+02:00

This second post about «touch» is somewhat an extension to my previous post «Drawing by touching using JavaScript». However in this post the focus will be on «gesture events». A gesture event is an event which will fire when more than one finger is present on the screen. Due to the somewhat complex nature of the accompanying demo, I will not walk through it line by line, but rather focus on some key ares which are important when dealing with touches and gestures.
Step 1 is to take a look at the demo and read through my comments. To understand this you will need a basic understanding of object oriented JavaScript and I will not walk through that part of the demo in this post. What I will explain in some detail is how the gesture events work (to see how touch events work, refer to my previous post) and some nifty tricks you can do with event handlers and transforms. Oh..and you will be needing a touch device to test this thing. Let's get cracking then.

The basic functionality of this demo is to place images on the page which have some touch and gesture events applied to them. This will allow us to move, scale and rotate the images using gestures. An array «elephants» is used to keep track of all the images on the page. On line 70 (in the demo JavaScript file) an Object called «TouchImage» is defined. This object will keep track of all events and transforms associated with one image. We create a new «TouchImage» on line 52. This happens for every time you hit the «Create elephant» button. Then on line 99 - 104:

tImage.image.addEventListener('gesturestart', tImage, false);
tImage.image.addEventListener('gesturechange', tImage, false);
tImage.image.addEventListener('gestureend', tImage, false);
tImage.image.addEventListener('touchcancel', tImage, false);
tImage.image.addEventListener('touchstart', tImage, false);
tImage.image.addEventListener('touchend', tImage, false);

Now, this might look a bit strange, we're passing «this» («tImage» is a closure for «this») as the event handler for the listeners. This is because at line 117 we define a method called «handleEvent» on the «TouchImage». This is a magical method in JavaScript which will basically handle any event passed to it's object. Within this method we check to see if the caller is a function and if it is, we simply call it.

TouchImage.prototype.handleEvent = function(event)
{
 if(typeof(this[event.type]) === "function"){
  return this[event.type](event);
 }
}

This way we can extend the «TouchImage» object with methods called «gesturesstart» and so on, the same names as the events. An additional plus is that we stay within scope of the object, avoiding to pass closures around like rag dolls. Now to the gesture handlers. In contrast to «touch» handlers, there are only three «gesture» handlers: «getsurestart», «gesturechange» and «gestureend». Each of these will trigger only if there are more than one finger on the screen.

TouchImage.prototype.gesturestart = function(event)
{
 event.preventDefault();
 this.startRotation = this.rotation;
 this.startScale    = this.scale;
}

In «gesturestart» which triggers when a second finger is placed on screen, we capture the current scale and rotation values of the «TouchImage» in question.

TouchImage.prototype.gesturechange = function(event)
{
 event.preventDefault();
 
 this.scale    = this.startScale * event.scale;
 this.rotation = this.startRotation + event.rotation;
 
 this.applyTransforms(); 
}

In «gesturechange» we calculate the scale and rotation by using the start values and the changed values. The scale is multiplied with the new scale and the rotation is calculated by adding the start rotation to the current rotation. This works because both values in the change handler will give us the amount changed since the start event. Then we call the «applyTransforms()» method where the actual transform is done.

TouchImage.prototype.applyTransforms = function()
{
 var transform = 'translate3d(' + this.posX + 'px,' + this.posY + 'px, '+this.posZ+'px)';
 transform += ' rotate(' + this.rotation + 'deg)';
 transform += ' scale(' + this.scale + ')';
 this.image.style.webkitTransform = transform;  
}

The transform is done on all properties at the same time. You cannot separate them from each other, because we are in effect overwriting the entire transform style element each time something is changing. Do also note that we are in fact using «transform3d», which is quite different from the regular «transform». The reason for this is twofold. First, the «transform3d» will render the image on it's own 3D layer, at times triggering hardware rendering. This will yield a significant performance increase. Secondly, the «transform3d» allow us to stack elements in the «z-axis», hence we can move the active element to the front. We do this sorting by calling the «sortDepth» method, which only sorts the «elephants» array.

That's the gesture events. Now, there are regular touch events in this application as well. These are used to move the «TouchImage» objects around the screen. I won't cover how this is done in detail here because it's much the same as in the previous post. However one thing to notice is that an offset is calculated in the «touchstart» handler. This is done so that when moving the image it tracks from the point where the user places her finger on the image. If we didn't do this the image would snap to 0,0 under the users finger when moved, making for an unexpected user experience. That's it and that's that!

Drawing by touching using JavaScript

2011-03-19T18:46:00.001+01:00

The web is no longer exclusive for desktop and laptop computers. With the introduction of the iPhone and the iPad Apple changed how we interact with the web. In the wake of Apples success with iOS devices we see the emergence of a slew of "handheld" devices. They are all different, some are small, others bigger and more powerful, however most of them utilize touch as a means of input. In this article I take a look at how we can create a simple touch enabled drawing application using only JavaScript and a tinsy-winsy bit of HTML 5.

First, you can try the finished app (with comments) and download the source code from here.

The first thing we need to do is to make sure that the user visiting our web-app is on a device which can understand touch events. This is pretty straight forward. We accomplish this by asking the «window» DOM element if is knows about one of the touch events.

if('ontouchstart' in window == false){
   alert('Sorry, you need a touch enabled device to use this app');
   return;
}

If this does not stop our script, we know that the current device supports the touch events we need. The next step is to prevent the screen itself from scrolling when you drag your finger across it. We need to do this because touch events «bubbles» in JavaScript. This means that all the parent elements will get a chance to handle the touch event after we have handled it in our function. So after we have handled the «touchmove» event in our canvas element it will bubble right up to the window element where the browser will try to scroll the window. PS: Sometimes you might want this behavior, for example when you're scrolling a page. For our demo, we don't need it. To disable page scrolling we listen for the «touchmove» event on the document element, then we flag the event as handled using «event.preventDefault()».

Now to the construction part. We need to create a canvas element.

var canvas = document.createElement('canvas');
canvas.width  = window.innerWidth;
canvas.height = window.innerHeight;
document.body.appendChild(canvas);

We now have a «canvas» element which is the same size as our entire page. Next up we need to create a context in which to draw for the canvas. A context is kinda like a page within a drawing pad. The context can receive JavaScript drawing commands as we will see later on.

ctx  = canvas.getContext('2d');
ctx.strokeStyle = "rgba(255,0,0,1)";
ctx.lineWidth   = 5;
ctx.lineCap     = 'round';

The context is now set up using the color red with a 5 pixel wide stroke and rounded ends. You can change these values as you like of course.

In order for our fingers to be able to produce wonderful line drawings, we need to tell our application to listen for touch events. We'll need three of them. The «touchstart» event is where we set our starting position for the drawing operation. This event fires when a finger is added to the screen. The «touchmove» is where we draw the lines, this event fires when we move a finger on the screen. The «touchcancel» is where we handle exceptions, like what happens if you receive a call in the middle of your art creation extravaganza. This event fires whenever it needs to.

canvas.addEventListener("touchstart",touchstartHandler,false);
canvas.addEventListener("touchmove", touchmoveHandler,false);
canvas.addEventListener("touchcancel", touchcancelHandler,false);

Now we'll need to handle those events as well, here is where the real fun begins! Let's have a look a the «touchstart» handler first.

function touchstartHandler(event)
{
   ctx.moveTo(event.touches[0].pageX, event.touches[0].pageY);
}

It's just one line, but do take notice in the «touches» object contained within the event. This is an array (well, kind of) of touches. The reason for this is that most humans have more than one finger, so the «touches» object could actually contain several values. We only need one, so we refer to the first (0) element in the «touches» object. Now that we have found the first finger we get it's location on the screen by asking for the «pageX/Y» values. We then continue to move the canvas context pointer to the coordinates for this finger using the «moveTo» method. This happens every time we place a finger on the screen. But, only for the first finger.

function touchmoveHandler(event)
{
    ctx.lineTo(event.touches[0].pageX, event.touches[0].pageY);
    ctx.stroke();
}

In the «thouchmove» handler we do the actual work of telling the canvas context to draw a line from where it's last location was to where the finger is now. The first time this is called the line is drawn from where we placed the finger on to the screen, set in the «touchstart» handler. After that, the canvas context will update it's starting position to the location of the last drawing operation. Like the «moveTo» command in «touchstart» the «lineTo» will update the coordinate position, but it will also issue a drawing command which is rendered to the screen when we call the «stroke» method.

That's it. Try it out on your iPad, iPhone or any other touch device which understands the new HTML 5 APIs by clicking this magical link.

Recommended further reading:

Safari web-content guide - Handling events

Quicktip: Flipping an image with JavaScript

2011-03-16T18:46:00.003+01:00

Let's say you wanted to flip an image in you web-app horizontally or vertically. By using a tiny bit of JavaScript and CSS 3 this is really easy.

//Get the image
var img = document.getElementById('myimage');
//Flip it horizontally
img.style.webkitTransform = 'scaleX(-1)';

And you're done! Note that this will only work in webkit browsers. The equivalent for Mozilla browsers would be «img.style.MozTransform». To flip the image vertically you could use: «scaleY(-1)». And to flip both horizontally and vertically at the same time: «scale(-1,-1)».

[edit 17.03.2011]
You can of course do this in other browsers besides Gecko or WebKit based browsers, as pointed out in the comments. Safari will actually support both the «webkit» and the «Moz» prefix, but this will most likely go away soon. So what you'll need to use is feature detection. This will still not work in ALL browsers, but the usable ones will most likely support it.

if(img.style.webkitTransform){
  img.style.webkitTransform = 'scaleX(-1)';
}else if(img.style.MozTransform){
  img.style.MozTransform = 'scaleX(-1)';
}else if(img.style.OTransform){
   img.style.OTransform = 'scaleX(-1)';
}else if(img.style.msTransform){
   img.style.msTransform = 'scaleX(-1)';
}else{
   img.style.transform = 'scaleX(-1)';
}

HTML 5 Offline data storage

2011-02-28T22:21:00.000+01:00

One of the most anticipated features of HTML 5 and all it's consequential technologies and APIs are the «offline storage» APIs. In this post I'll take a "real world" approach to using the HTML 5 Web-Database and the «HTML 5 Offline application cache». I will take you through an example where a complete elephant gets stored on your computer. That's right! A pink one as well! The point of this demo is to investigate how to store both static data as well as dynamic data which might not be known at design time. For this occasion I have created a demo which you are free to download and inspect. It is fully commented and somewhat verbose for easier reading. What this application does in essence is to store a HTML and a JavaScript file on your computer, then it will go on to store a picture (which could be dynamic data) in a local database, hence making the application usable when not online. Let's have a look!

So, our goal is to store both static data and some dynamic data. To achieve this we'll need to use two approaches as mentioned above. The first one, called «HTML 5 Offline Application Storage» is almost automatic once you have it configured. We will utilize this method to store our main JavaScript file so that it will work when you're not online. Cool!
This approach uses a simple text file, called a «manifest file» which tells the browser which data to store locally. In order for this file to be interpreted by the browser correctly you'll need to (1) configure your web-server to serve this file with the «text/cache-manifest» mime-type. It doesn't matter what kind of extension you use, but I prefer either «.manifest» or «.cache». Now that thats out of the way we need to create the «manifest file». Mine looks something like this.


CACHE MANIFEST
# Cache manifest version 1.0.5
# If you change the version number in this comment,
# the cache manifest is no longer byte-for-byte
# identical.

main.js

NETWORK:
# All URLs that start with the following lines
# are whitelisted.

http://web.kinderas.com/

The first line MUST be the text «CACHE MANIFEST». After that you'll go on to specify the files you'll like to be cached. Here you'll put stuff like JavaScript files, HTML pages, CSS files and so on. Mine only has the one «main.js». Note that you do NOT need to specify the HTML file which declares the manifest file. This will typically be your «index.html» file or something like that. More on that later. The next section is the «NETWORK:» section. In this section you specify a "white list" containing URL's from where your application is allowed to get it's data. If you don't specify this your app will not download any data, not from the server it's hosted on or from anywhere else. I have specified my own domain since this is where the elephant is hosted.
You declare the manifest file in your HTML file like so:
<html manifest="cache.manifest">
That is it for the manifest file actually. If you are simply going to host a static site, a game or something like that, this will work just file as is. Note that to update your files, you do need to make a change in the manifest file itself, like incrementing the version number.

Next we need to add some sexy JavaScript in order to make the pink elephant available for your viewing pleasure in locations the WiFi gods have forsaken. There are three main steps to this: (1) Opening and creating the database and the table if it's not already present. (2) Reading the image from the database or saving it to the database if it's not already in there. (3) Displaying the image. I will not be explaining every line of the code in this post, you'd rather take a look at the JavaScript file and read the comments. However I will discuss some of the more important points briefly.
Not all browsers will support the HTML 5 database APIs, so we need to check for this before we can do anything. To do this we check for the existence of the «openDatabase» method on the «window» object, like so:


if(!window.openDatabase){
// No support for HTML 5 db
return;
}

This will detect if the browser has support for the methods we need. If not, give the user a message or some alternative content.
Then, to open / create the database we would we simply write:
db = openDatabase('testdb','1.0','Offline Elephant DB',1024*1024);
We have just created a 1MB database or opened one if it already existed. Now it's ready to execute SQL queries using transactions.

var sql = 'CREATE TABLE IF NOT EXISTS offline_image (id INTEGER ....);';
db.transaction(
 function(transaction){
  transaction.executeSql(sql,[],
  function(transaction, result){
   //The table was created
  },
  errorHandler);
 }
);

The database table has now been created if it wasn't already there. We now need to check if there is an image already saved in the database, this happens on line 56 in the «readImage()» function. If there is an image with the matching filename saved, we use that, if not we go on to loading and serializing the image, as follows.

var canvas = document.createElement('canvas');
var ctx    = canvas.getContext('2d');
var img    = document.createElement('img'); 
img.onload = function(){
 canvas.width  = img.width;
 canvas.height = img.height;
 ctx.drawImage(img,0,0,img.width,img.height);
 var base64Image = canvas.toDataURL();
 showImage(base64Image);  
}
img.src = sImgURL;

To be able to save the image we need to create a text version of it's data. We can accomplish this by loading the image and then rendering it in a canvas element. The Canvas element has a method called «toDataURL» which will create a base64 representation of the Canvas content. Base64 images, also referred to as data urls can easily be saved to the database. Base64 data can also be read directly by the «img» element, so there is no need to decode the base64 string again once it's encoded. But, do note that the canvas element will give you the png base64 version of the image, and it's quite a bit larger than the original binary file.

That's the gist of it, but you do need to take a look at the demo and the JavaScript in order to really understand what it going on here. Once you get the hang of it, this is a really powerful approach to making web-applications much more accessible and more interesting.

Further reading:

9 things I've learned about web-development

2011-02-09T22:37:00.004+01:00

I've been a developer for quite some time now, meddling with both the web-centric and the native side of things. As of lately, that is for the last 3 months or so I have focused more in depth on "standards" based web development. Meaning HTML, CSS and JavaScript. Even if I've been writing HTML since 1996 (yeah, I'm getting old), I have never really bothered to really focus in depth on the basic building blocks of HTML, CSS and JavaScript, until now. 4 books and many many hours of training videos later I feel that I've learned something, which is that an iPad make for a lousy pillow if you keep trying to sleep on it! But more than that, I found 9 things that I have learned, which may be blatantly obvious to you if you are a fancy pantsy web-developer, but then again, maybe you'll learn something new?

1. Web-designers and web-developers think differently.
What do I mean by that? Consider of how you're tagging your HTML with classes and id's. The designer approach to this would be classes all the way, then using the clever selector syntax of CSS to reach the nested areas of the document. This makes sense when working with formatting. Developers tend to view the HTML as a framework with components. Classes are used for formatting while id's are used to identify areas of the markup one would need to reach via JavaScript. Designers will prioritize the "flow" of the «document» whilst developers don't consider it a document at all. I don't think either approach is «correct» or «wrong», it's just two ways of approaching the same challenge.

2. CSS is not a layout language.
Almost all layout in modern HTML based webpages are done using CSS, so how can anybody claim that it's not a layout language? I too was somewhat surprised when time and time again the "people who knew what they are talking about" kept repeating this. From the WHATWG to W3C and several books on the topic kept driving this home..«not a layout language». Turns out, CSS is a formatting language with some layout features. Semantics? Well, not really. If you compare CSS 2.1 to a "real" layout language like MXML you'll soon notice a big difference. Layout languages, or UI markup languages have special layout components to group element, flow elements, sort elements both horizontally and vertically. CSS 2.1 does not have this, it's totally reliant on either floats or absolute positioning. This will better with the introduction of the flexible box model in CSS3, but still it will remain a formatting language at heart.

3. CSS selectors are incredible powerful...stuff
This is one of the areas on which I have discovered most new stuff. CSS 2.1 embodies most of them, but with the introduction of the CSS 3 standard, selectors can now do some amazing stuff. Conditional child selection, substrings within attributes while traversing child elements are just some examples. And the best part is that they are largely supported in all modern browsers, including Internet Explorer 8. If I where to recommend one area on with to focus you attention, if you don't already know this, it would be CSS selectors. It's not complicated or hard to understand, there are just so much under the hood which can make your CSS writing a lot more enjoyable.

4. Things will look different in different places.
If you try to create pixel perfect designs across all browsers and platforms you will go bonkers, that is unless you are a technophile machochist whom derives enjoyment from banging your head up against the gigantic wall of Internet Explorer inconsistency. You're much better off using either the progressive enhancement or the graceful degradation approach where you serve different users the same content, only wrapped in a slightly different presentation. This way Internet Explorer users can sit and stare at that black and white page of rich text all day long, while us WebKit fanboys can swim in the loveliness that is a modern browser with animations and shit.

5. A position is not the same position elsewhere, or everywhere.
Since this is more or less an extension of point 4, I can't be bothered to find a pretty picture for this one. (As a side note, if you use Google image search for the term "position", turn safe search on!) What this point is concerning, what I've found is: Firefox and Chrome (or any other browsers) does not have the same interpretation when it comes to rendering a point at, say x: 100, y: 100. Since it's up to the user agent (browser) to parse your CSS and HTML and then draw it on the screen, you will at certain points end up in a situation where an absolute point in the top left coordinate system will differ from user agent to user agent and even on the same user agent on different operating systems. This can be avoided by using floats and containers instead of using absolute positioning. But, it's better to accept that things might not look exactly the same everywhere.

6. Modernizer Rocks!
If you ever need to use conditional CSS 3 or HTML 5, Modernizer is by far the best solution I've found. The way Modernizer works is actually twofold. You can first use it with CSS directly. Lets say you want to take advantage of the RGBA color model found in CSS 3, but you also need to support those pesky Internet Explorer users. All you need to do in your stylesheet is to prefix your class or id selector with ".rgba". Let's say I wanted to apply a style via the selector «h2[class*="onkey"]», but only for browsers supporting RGBA. It would look like this: «.rgba h2[class*="onkey"]». The RGBA class simply adds itself as a ascendant class. This style would then only apply if RGBA was supported. The other way of using Modernizer is with JavaScript. To check for support for H.264 video playback abilities, simply use «Modernizer.video.h264» and it'll return false, "maybe" or "probably". Yep, that is the HTML 5 spec for video format detection..

7. jQuery selectors are convenient, JavaScript is fast!
If you don't know what jQuery is, you should go find out! Someone once wrote that jQuery is Gods gift to JavaScript. Where God is of course John Resig and I was the one that wrote that, just now in fact. jQuery is seriously awesome, it allows for fast and easy cross browser development. Underscoring cross browser, which is what it does really really well. It is just a JavaScript framework, a tiny one at that, but crammed with neat functionality, from animations, ajax loading and the usage of CSS selectors to get a hold of DOM elements. You can say things like: «jQuery('div.donkey')» which would give you all the donkey divs in the page. This is really convenient, because you can find stuff in the DOM with the same syntax used in the CSS. There is a downside however. When using CSS selectors in a CSS file or in the HTML file, the user agent takes care of all the heavy lifting required to traverse the DOM and find those elements. This is fast because the user agent does this natively using a compiled language such as C. However, jQuery is not written into the native part of the browser and will therefore need to use JavaScript to traverse the DOM to find the elements based on the CSS selector. Hence using the build in JavaScript functions «getElementById», «getElementsByTagName» or the spanking new «getElementsByClassName» is much faster than using the jQuery selectors. What you can do is combine them like so «jQuery(getElementById('id-name'))». Then you would get the speed of the native JavaScript functions while keeping all the jQuery goodness as well.

8. There are datatypes in JavaScript!
!!Nerd alert!! Even if you don't explicitly declare datatypes in JS, there is a difference between for example «"2"» and «2». If you where to add these two values together «"2" + 2», you'd get «"22"», while «2 + 2» returns «4». Now, what if «a = [2,3,"a"]» and «b = 2». What would «a + b» give you? That's right «a + b => "2,3,a2"». JS has a lot of functions for dealing with this. You have «toString()» to convert a number to a string, «parseInt(strNum)» to convert a string into a whole number and so on. The important thing is to be astutely aware of it, even if you can't declare a strict datatype.

9. The WebKit Web Inspector is your most important tool
If you're in any WebKit browser, Safari, Chrome so on you have access to the build in "Web Inspector". This tool is your best friend when working with HTML, CSS and JavaScript. It will do anything the more famous Firebug does and more. Don't get me wrong, I'm not railing on Firebug which is an awesome tool, I am however highly recommending the WebKit Web Inspector because of it's speed, advanced profiling tools and unsurpassed JavaScript debugger. Try it and you'll see why I'm praising it!

So that's it, or more likely, that's some of it. If you have actually read all the text down to this I truly hope that this post have contributed in some small way to your blah blah blah blah..you know the drill. Now get back to work, those recursive functions won't be creating themselves ;-)

The truth about Google and H.264

2011-01-18T23:15:00.000+01:00

If you leave this post remembering only one thing, let it be this: Making something Open Source does not automatically make it better, it just makes it Open Source. How's that for flamebait?

Unless you have been living in a box buried underground lately, you have probably noticed the shitstorm surrounding Googles decision to drop support for the H.264 codec in it's Chrome web-browser. Of course, as a web-developer I do indeed have some thoughts on why this happened and whether it's a smart move. However, before sharing from my goldmine of biased opinion we'll need to get the REAL facts straight, so you can judge for yourself.

Open vs. Free

H.264 is a codec constructed from a bunch of patented technologies and it's developed by the «Video Coding Experts Group» and the «MPEG Group». H.264 is a video standard (ISO/IEC 14496-10) handled by the «International Organization for Standardization». H.264 is an open standard, however it is not a free standard. All the patents included in H.264 are handled by MPEG-LA, not to be confused with the MPEG Group. Microsoft and Apple are some of the minor patent holders of H.264. H.264 is free to use for non-commercial usage, for end users for it's lifetime. For commercial usage (e.g. iTunes Store) and for usage in decoders (e.g. in browsers) one will have to pay a license fee capped at $6.5M. H.264 sports a bunch of hardware decoders, from iOS devices to Televisions and DVD/BlueRay players. To create H.264 files you can use everything from Apple QuickTime to FFMPEG. H.264 is supported by Apple Safari, Internet Explorer 9 and Google Chrome via the Mpeg4 container.

VP8, the codec within the WebM container, was developed as a proprietary product by a company called On2 Technologies. In 2010 On2 Technologies was acquired by Google, whom continued to release the patents within VP8 under a Creative Commons License. VP8 is free to use and free to implement. As of today there are slim to none hardware support for VP8 decoding. To decode/encode VP8 today you'll most likely use Google own software based «libvpx» library or the FFMPEG(ffvp8) implementation. VP8 is today supported by Opera and Firefox 4 via the WebM container.

The thing to notice here is that H.264 is indeed an open standard, developed by an independent companies and approved as a standard by ISO, but it's not free to implement. VP8 was developed as a proprietary product by one company, later released into the public domain as Open Source. VP8 is free to implement.

What does it all mean?
In my opinion Googles move has nothing to do with being open, it might have something to do with being free however. For companies like Mozilla, which develops a truly Open Source product it totally makes sense to not implement a video codec for which you have to pay patent royalties. Note that Mozilla does not support MP3 either, which also contains commercial patents. It's not that Mozilla can't pay the license fees, it is more the fact that you cannot freely distribute as Open Source a product which implements a patent encumbered video decoder. Mozilla (Firefox) has never had support for H.264, which is a decision I completely support on the basis of their completely open approach in other areas of the implementation as well.
Google on the other hand made the rather strange decision to remove it's already existing support for a widely used codec in a browser littered with other patented technologies. Under the flag of being "open". It's this "being open" part which rubs me the wrong way. Google Chrome is NOT an open browser in the same sense as Firefox is, it implements mp3 and it's own embedded FlashPlayer to mention a few things. As far as I can see, the only logical explanation for Googles move is that this is a business decision. They don't want to pay for a license partly under the control of Apple and Microsoft and would rather control their own codec, namely VP8, which is under Googles control, even if it's Open Source. VP8 has never been through any independent standards organization like H.264 has, it was developed as a proprietary product, in sharp contrast to the independent development of H.264 which was a joint operation shared by many companies. Codec developers also claim the superiority in quality of H.264 over VP8. It's estimated that about 60-70% of all web video is encoded in H.264 already, a large part of that is YouTube owned by Google. The reason you can watch video for hours on your Android. Microsoft or iOS device is the H.264 hardware encoder which sits inside of it. Despite all of this Google chooses to exclude H.264 from it's web-browser.. to be open.. yea right!

Graceful degradation vs. Progressive enhancement

2011-01-09T18:38:00.000+01:00

There are three possible things you might be feeling after seeing that header. (1) No interest at all (confused?), (2) somewhat intrigued and curious (and confused?) or (3) already in the trenches ready to defend your position.

First of all, I know that this is somewhat of a "controversial" area, but in the end you do not need to agree with what I have to say, it's just my point of view. But, before we get to the subjective part, let's take an objective look at what is involved when considering these two approaches to (in this case) making web-applications.

Graceful degradation (or fault-tolerant system).
In web design, this is the basic idea that we design and write code for the most capable browsers first, then we add support for less capable browsers. An example of this is the "alt" attribute of the «img» tag. Most users will get the image, while those that browsers that do not support (or choose not to display) images gets the "degraded" text representation. The «noscript» tag is another example.

Progressive enhancement.
When subscribing to «progressive enhancement», you will first design and write code for the least capable browsers (like Internet Explorer). Then you'll add in functionality to enhance the experience for users with more capable browsers (like Opera, Firefox, Chrome and Safari). The linked stylesheet is a much used example of this. First you create the web-app in pure HTML (works almost everywhere), then you link a stylesheet to the page (which is ignored by old browsers), making the experience better for more up to date users. The FlashPlugin based «SIFR» method is also an example of «progressive enhancement».

Aren't those two identical (or the subjective part)?
Both of these practices will lead to the same result in most cases. That is, the goal of both approaches is to give the best user experience no matter what browser might be trying to display the web-application. The difference is the starting point. Where as «progressive enhancement» assumes the lowest common denominator as a starting point, «graceful degradation» assumes the opposite, starting at the newest and adding in support for less capable browsers later.

It is my opinion that the starting point of the lowest common denominator is a not such a good idea, because this line of thought will slow down the progress of new technology adaptation, especially within large enterprise environments. I don't think people in general will catch up on anything unless there is an incentive to do so. A "degraded" experience is a great incentive. Also, web-developers should in my opinion be allowed to adapt new technology as early as possible. A bunch of pig headed Internet Explorer users should not stand in the way of that. There is also the issue of security, speed and support for assistive devices. I would highly recommend the online book "20 things I have learned about browsers and the Internet" from the Google Chrome team, where you can read about why up to date browsers are important for the Internet itself.

I know what you are thinking. "Wouldn't both approaches allow for rapid technology adaptation?". The answer is of course yes...and no. You can use «progressive enhancement» and still push the limits of technology, forcing the world forward. However, to put it bluntly, that is not the intention of this approach, it's intention is to first support the slackers, then new technology. «Graceful degradation» aims at first supporting new technology, then give the slackers the content, but with a lesser experience. There's a subtle, but important difference here.

Note that «graceful degradation» has it's drawbacks as well. It is somewhat more complicated to add in "old technology" to a "new technology" project, rather than building "new technology" on top of "old technology" like «progressive enhancement» does it. But, as time goes by, a «progressive enhancement» approach will have more and more of it's foundation deprecated, while the root building blocks of a «graceful degradation» based project will become more and more relevant.

Web-apps vs Native-apps

2010-12-28T22:47:00.001+01:00

There is a world, a nerdy world occupied by people living in a private bubble called "IT". In this world "new" things are created, things that "ordinary" people couldn't care less about until they are publicized and popularized. Things like Facebook, Twitter, the iPad, gMail, the AppStore and the Internet are things created by the people in this nerdy world. Right now an imagined war is raging in this world, a war between the "by god we will cram everything into a browser" people and the "browsers are cool but slow" people. I'm of course talking about web-apps vs native-apps, or Google vs Apple as some have come to believe. So, is there a war? And who's winning?

When contemplating the differences inherently present in the not so wide crevasse between web-apps and native apps there are four main areas I want to examine:

Performance
Accessibility
Data persistence and security
The browser

Performance

The first thing that springs to mind when taking the classical approach to this age long tiresome debate is the issue of performance. Native apps perform better than web-apps, hence the end user gets a smoother and better experience when using the app. This is true, in most cases. However, performance is more than just the smoothness of animations and the speed of which data is read. Consider the process of installing Adobe Photoshop on your trusty Windows laptop, then activating it, then figuring out how to navigate the god awful interface just to adjust the contrast of an image. Compare that workflow to opening the image with Picnik and the choice is pretty clear. Web-apps rule! But, wait. What if you want to edit the movie you shot during the holiday with your FlipMino HD, can you do that in a web-app? Well, sort of, with services like JayCut and the likes. However, you will get a much better result using iMovie, which is already on you Mac. What about Skype, code compiling, 3D games and so on..? To make a long story short, native apps will outperform web-apps when it comes to pure performance and as long as web-apps are based on a document oriented language (HTML). It will always be a catchup game for web-apps. But, web-apps have another kind of performance advantage, accessibility.

Accessibility

A web-app is always up to date, most of them are easy to use, requires no installation and can be used from almost any computer. That is, except when you're not connected to a network. A statement with modifications indeed, some web-apps do work when in offline mode as well, however a pure offline web-app would be pretty pointless. Consider Google Docs versus Microsoft Office. If you're an author (a brave one) you might want to use MS Word, or if you need some crazy ass pivot tables or other super advanced stuff you would perhaps also need MS Excel. However if you just want to calculate stuff, create and produce formatted text, spreadsheets and presentations, Google Docs is far superior to MS Office. Oh, have you tried to collaborate in real time on a MS Word document, doesn't work does it?! Also, Google Docs keeps your documents on the server so you can access them from anywhere and they are always backed up. Does it work offline, well, not yet.

Data persistence and security

With a native-app your data is always available to you, online or offline, provided that your computer is with you of course, or that you have synced the data to the cloud. What happens if (God forbid) your house (containing your laptop) is leveled by aliens? Where did all your native-app data go? It's history! Your e-mail and Google Docs data is safe at Google. That is, if you are okay with Google searching through your e-mails and documents in order to give you targeted advertisements? And what happens if, say you have saved all your links and bookmarks at a cloud service (lets call it Delicious) and then out of the blue Yahoo! suddenly decides to fire all the people working at that service and let it die a slow death. What about all those years worth of bookmarks then? This is somewhat complicated isn't it?

The browser

How awesome do you think it would be to play Halo: Reach in Google Chrome? Not so much? What about programming a movie-editor that has to work within the browser sandbox and is only allowed to cache 10MB of data, how would that go down you think? It wouldn't you say? Last one: Let's say we want to persuade ReSpawn Studios or Epic Games to work with WebGL on an unknown amount of browsers and computers instead of writing their engines based directly on a familiar platform. No dice? This is because the browser isn't a gaming platform, it isn't a good platform for handling a lots of files or large files. But, it does add another layer of security and it make everything accessible everywhere, plus if you're using Facebook and gMail what more do you need.. The average time a user spends in a web-page is about 10 seconds, this makes the "browser experience" kinda ..volatile..and short lived. Native app sessions are more persistent and have a longer lifespan, hence more suitable for playing games, editing movies and so on. The browser can do many things, not everything and yes, native apps will continue to be perform better for some time.

There is no war. The browser with it's web-apps is an awesome platform for some things, just as native apps do better on other things. I for one enjoy both web-apps and native-apps and will continue to do so for a long time I suspect.

Scrolling a div on multitouch devices using JavaScript

2010-10-11T21:46:00.004+02:00

With the emergence of touch devices and the slow but steady tendency of replacing the mouse as an input device, this leaves us with fingers. Both the iOS platform and the Android platform sports APIs for dealing with touches from fingers, for native apps that is. But what about web-apps? Enter the JavaScript touch DOM events. In this post I'll discuss how to use the touch events to scroll a container (a div) using a finger, e.g. on an iPhone.

What you'll need
First of all you need a touch device or a simulator like the iPhone simulator to test your code. The code itself can be written in any text editor, however it is recommended to use an editor with a build in debugger or a test environment that supports debugging JavaScript touch events. You might be thinking that Firebug or Drosera is great for debugging, but how exactly would you trigger the touch events in your desktop browser? Well, you can't. This is why I'm using Dashcode from the iOS SDK for my JavaScript coding. More on using Dashcode in a later post.
Note that this code is written for WebKit based browsers, but should work in principle on other touch browsers as well.

The HTML

 <div id="holder">
   <div class="content">
       your content here
   </div>
</div>

Notice that the content is inside of a div within the holder div, this is because you can't scroll the div in which the touch event is attached to.

The CSS


#holder{
   width: 300px;
   height: 200px;
   background-color: blue;
   -webkit-box-shadow: 3px 3px 5px #000;
   padding: 10px;
}

#holder div{
    width:100%;
    height:100%;
    color: white;
    overflow: auto;
    -webkit-user-select: none;
}

Not much revolutionary here, but do note that we set the "overflow" property to auto on the content div, not the holder itself. Also, we set the "-webkit-user-select" to "none" on the content div, thereby preventing the user of selecting the content. This is optional.

The JavaScript
There are three main touch events:

touchstart - Called when a finger touches the listening container (finger down)
touchmove - Called repeatedly when a finger moves (finger down and moving)
touchend - Called when a finger leaves the listening container (finger up)

Each of these methods gives us an event with a touches array. Remember, there might be more than one finger since these APIs are made to handle multitouch devices. To get a hold of the vertical position of one finger you would query the touches array for one finger and get it's pageY property, like this: event.touches[0].pageY

From this we can calculate and set the scrollTop property of the content container. But, wait! If you try this the rest of the page will also scroll, not what we wanted. The reason why this happens is because the touch event bubbles all the way up to the window, making the browser think it needs to scroll the window because you have dragged your finger on it. We need to tell the event to stop bubbling, we will handle the event ourselves. We do this by calling: event.preventDefault()

The complete JavaScript code will then look something like this:

var startPos;
function init()
{
    var scrollArea = document.getElementById('holder');
    scrollArea.addEventListener('touchstart', function(event){
        touchstartHandler(event);
    }, false);

    scrollArea.addEventListener('touchmove', function(event){
        touchmoveHandler(event);
    }, false);

    scrollArea.addEventListener('touchend', function(event){
        touchendHandler(event);
    }, false);
}

function touchstartHandler(e)
{
    startPos = e.touches[0].pageY;
}

function touchmoveHandler(e)
{
    var touch = e.touches[0];
    var targetBox = e.currentTarget.getElementsByTagName("div")[0];
    e.preventDefault();

    var fingerMoved = startPos - touch.pageY;
    startPos = touch.pageY;

   targetBox.scrollTop = targetBox.scrollTop + fingerMoved;

}

This is just a simple example, but it's something you'll probably end up using a lot. Speaking of...

When should you override the default window scroll
On an iPhone there is not as much need for this method as you'll probably scroll the entire screen in most cases anyway. However, the iPad is a different story. Take a look at the iPad version of gMail created by Google. They are using this method with success, and they have added inertia scrolling as well. This can be accomplished using the last touch event we did not implement, touchend. Maybe more on this in a later post. Anyway, you should use you own scrolling when it's appropriate to scroll only a part of the app, like a spilt view list or something like that.

Downscaling images in Flash applications

2010-10-02T15:24:00.000+02:00

The other day I ended up in an interesting discussion regarding how to downscale a large image in a Flash based application. What we figured out was that even though the FlashPlayer can do bilinear smoothing on scaled images automatically, this will fail when the scaling factor is more than 2 times of the source image. Hence a custom method is needed.

The simple approach (scaling down less than 2 times the size)
If the loaded image is to be scaled less than 2 times (400 -> 200) simply use the build in "smoothing" property of the Bitmap Class. This can be set directly on the Bitmap itself or via different DisplayElements such as the mx:Image in Flex. If you set this property to true the Bitmap will use bilinear scaling, achieving quite good results.

Grayscale bilinear interpolation

Now, if you need to do actual resampling of an image, in other words create a new smaller image, then you need to do this manually using the "draw()" method of the BitmapData Class. Use the bitmapData.draw() method and set the "smoothing" property to true. This will give you the same result as setting the smoothing property on an Bitmap container, however it uses less memory as only the pixels for the resulting image is stored (if you remember to dispose of the original data!).

Scaling down more than 2 times
Let's say that you have an image that is quite large and you want to create a thumbnail from it. A thumbnail is often way smaller than 2 times smaller than the original image. It would be quite nice to use the above method to just scale the image, or better resample the image with the "smoothing" property set to true. However, if you try to do this the FlashPlayer will simply fail and default back to using the "nearest neighbor" algorithm. If you try it you'll soon discover that this will give you a horrible result.

What you'll need to do in this case is to do an iterative or recursive resampling of the image at hand. In layman terms this means resampling the image several times, each time no more than 2 times downscaling factor. You could call this a multi pass resampler (actually it would be a multi-multi pass resampling as the draw() method is also multi pass). You would still use the build in "BitmapData.draw()" method to accomplish this, you only divide the work into multiple jobs. This will give you a much better result. Note that in my experience, function calls in ActionsScript 3 are quite expensive, hence a iterative approach would maybe be preferable to a recursive one.

Using PixelBender
If you have decided to go for the manual approach of resampling the picture, you can use a PixelBender shader to do the job. In this case the actual resampling will be a lot faster (as the PB language is based on C), however applying the PB shader and passing the image back and forth takes time. See the speed section..

Combining the two
So, what if you have an application and you don't know in advance the downscale factor. Well, then you'll need to use both of the approaches like so:

Calculate the scale factor
If the scale factor is less than 2, set "smoothing" to true on the container or do a singe pass resampling.
If the scale factor is more than two, use the multi pass scaling approach. And set the "smoothing" property of the container to false (else it will be blurry).

What about speed?

Let's say that you have an image that is 1200 x 1200 pixels and you're resampling it to 200 x 200. This is a 6 times resample and will look like ass using only the "smoothing" property, but it is faster.

Let look at some hard results. In this test we see how much time is used extra compared to no "nearest neighbor" scaling (default in Bitmaps if smoothing is off).

Method	Time in ms
Smoothing property on	0 ms
Multi pass resample	9 ms
Multi pass PixelBender	32 ms

Using the smoothing property takes no extra time, because it fails and defaults back to nearest neighbor. The other two are both pretty fast, however even though the PB algorithm is way faster than the others, we see that the applying of the shader eats a lot of time, thereby making the multi pass resampler method the way to go on a large rescaling operation.

Shifting the attention - facing forward.

2010-07-05T20:09:00.002+02:00

“Innovation is the ability to see change as an opportunity - not a threat”. - Unknown

This is not where I'm going to announce to the world that I'm leaving the FlashPlayer platform behind all together. Nor is this where I'll tell you to forget everything you know, gather you wits about you and start over. No, this is where I'll tell you what I've learned, how I've learned this and why this is.

Like Borland Delphi back in the days, the Adobe FlashPlayer architecture is dying without itself being aware of it. It's not because Flash content is evil, nor because the FlashPlayer is particularity crappy. Still, many sites, like YouTube are heavily dependent on the FlashPlayer in order to display their content. This will be true for quite some time. However, at the same time, all these sites still depending on the FlashPlayer do not express enthusiasm for it, it's seen more as a necessary evil in order to get the job done while we are waiting for something better. Well, change has come to the interwebs..and it's called HTML 5.

HTML 5 is acctually a standard being developed by the World Wide Web Consortium. Like HTML 4 it's a specification used by browser vendors to integrate the support into their browsers. This by it self means that individual browser vendors are responsible for the performance of HTML content in their browsers, effectively launching a race to be the fastest browser. This is a win for HTML 5 over Flash, seeing as Flash Player has no real competitors, because Adobe is the sole vendor. However, HTML 5 and it's companions CSS 3 and JavaScript cannot accomplish the same as the content you create using Adobe Flash, or so many people think. Actually, it can. Both 2D animations, 3D animations, advanced text layout and so on is readily available using HTML 5. So is advanced interactions. What HTML 5 does not have, that Flash do have, is an advanced authoring tool. Using HTML 5 may require more development skills, longer production time and more work to achieve the same result as using Flash authoring, today. This will change in time as HTML 5 skills grow more common amongst web-developers and the marked for great tools enlarges.

“Innovation distinguishes between a leader and a follower.” - Steve Jobs

Let's not forget the devices. The iPad, the iPhone, Android devices and the Google Chrome OS. These are the platforms of the future, the PC is not. Yeah, PCs will still be around, we as developers will still adhere like superglue to our Macs and Chrome computers. But, the normal users, aka. "most people" will not. Flash belongs to the PC era, HTML 5 is build for the touchscreen generation. This is kinda hard to see if you don't look closely, but think about it. How many iPads and iPhones does Apple sell? A lot! How many Android devices are there? A lot! Granted, Android phones do have a FlashPlayer, but have you tried it? Yes, it really sucks. And that is the most devastating blow to the FlashPlayer, the experience on future devices sucks or it simply isn't supported like on iOS devices.

Change is one of the most difficult things for humans to endure. We don't play well with it at all, but sometimes it's for the better. Remember, there is nothing wrong with plugin based technologies like FlashPlayer or Silverlight, like there was nothing wrong with the horse and carriage. But, now we drive cars, even if they can't do everything horses can do. This does not, however, mean that we hate horses, does it?

Resulting from my contemplation is an understanding that my attention will focus on the utilization of standard based technologies in the foreseeable future. I believe HTML 5 and all its companions will be the way of future web-based solutions. Flash is not dead, will perhaps never die, but if you're starting out today as a greenhorn developer, go for the future. And if you are a seasoned web-developer like myself, embrace this opportunity to learn new things, to start from "scratch".

Some great HTML 5 demos can be found here:

Screencast #4 - Parsing XML using the iPhone SDK

2010-05-31T23:03:00.008+02:00

In this Screencast I'll show you how to parse a XML Twitter feed using the NSXMLParser that comes with the iPhone SDK (Cocoa Touch). All of this under 10 minutes, which makes for an attention demanding learning experience.

Download source code

PS: Even though I forgot to mention it during the screencast, do remember to implement dealloc!!

Do we need Flash anyway? Apple says hell no!

2010-02-21T20:54:00.000+01:00

Unless you have been living in a box for the last couple of months or so, you're probably noticed that there's somewhat of a controversy dealing in the subject of Adobe Flash and Apple Inc.'s not so new policy to not support this widely used content type in their mobile devices.
In short, Apple cry fault on several things like CPU usage and instability, using these as the foundation for it's "no Flash content on our devices" policy. But, is it really that simple? Here's my take on this soon to be "greek tragedy".

What is Flash?
First of all, Flash is a type of media content, like images, movies and so on. Flash by itself doesn't do diddly-squat, it's just a description and a file format. In order to view Flash content you'll need an interpreter, in others words a player. What Apple is calling "the great evil" is (hopefully) the Adobe FlashPlayer, not the content type which is actually Flash.

Is Flash crashing my browser?
No! As described above, Flash all by itself can't do anything. If anything related to Flash is crashing your browser, it is the Adobe FlashPlayer. So you may ask, is the FlashPlayer the reason (most of the time) my browser is suddenly crashing? In my opinion it probably is. The Adobe FlashPlayer is quite unstable and buggy and slow. Why? Read on..

Is the FlashPlayer a "CPU hog"?
Yes it is. The Adobe FlashPlayer runs a constant loop of so called frames, driving animation, UI and so on. This will create a constant load on the CPU, because the content can change without reloading the webpage holding the Flash content. In contrast, HTML will create a heavy CPU load when initially loading the content and then it becomes static, thereby not using any (almost) CPU cycles. So, what if you where able to create the same content as you can show in the FlashPlayer in say.. HTML and JavaScript. What do you think would happen to the CPU load of that HTML page then? Of course, it would use more CPU cycles.
So, Adobes FlashPlayer is slow, no doubt about it, but this does not make Flash itself a "CPU hog" or anything like that. If Apple wants a faster FlashPlayer.. write one!

Will Flash die, what might prevent it?
Flash will die, or evolve into something else, eventually. But, it won't happen tomorrow, or the next day. Event though Apple does not support Flash in the iPhone and the iPad, almost any other device does or will support it. However, if you're a smart developer you'll use this time to widen your skill set beyond the Flash platform.

Development time and cost
The time spend creating an online application or website will in many cases be the deciding factor in a project, unless you're Google or Apple that is. Using the Flash platform compared to JavaScript/HTML solutions leaves the latter far behind in the dust when it breaks down to actual production time. This factor will no doubt change with the advent of advanced frameworks like JQuery and SproutCore. But still, anything you can do in JS and HTML, Flash can do better and faster from an time and design standpoint... today.

Dropping legacy support is the way of making a more stable player
One of the biggest problems with the Adobe FlashPlayer as I see it, is it's reluctance to get rid of old and bad ways of creating content. If Adobe where to drop support for the old player model, supporting ActionScript 2 and Flash 8 and older, I'll bet money that Flash content around the web would run faster, smoother and crash way less. If they are willing to do this I do believe Flash content might have a future, if not it will be kept alive by the need for banner ads, for a while.

Why doesn't Apple support Flash content?
Well, Steve Jobs allegedly stated that Apple wasn't supporting Flash content on the iPhone and the iPad for reasons dealing in instability, performance and generally bad user experience. If that's all, why not support Microsoft Silverlight?
Flash could be a competitor for Apple, both in the apps section of their business model and in the media consumption part (buying videos from the web (e.g. Hulu) and not the iTunes Store).
This is why, in my opinion, Apple will not support Flash content on their mobile devices. And really, if you think of it, is is such a problem? If you depend on Flash driven web content, don't buy Apple hardware. For me, being both an Apple "fan" and a Flash developer, I don't see the need for Flash content on mobile devices. No matter how you word it, the iPhone and the iPad won't give you the entire web..

Screencast # 3 - iPhone web app Twitter viewer

2010-02-13T19:00:00.004+01:00

In this Screencast I create a really simple iPhone Web Application using DashCode, one of the tools provided trough the iPhone Developer Tools.
I'll show you how to create a simple Twitter viewer, getting started using lists and how to use value transformers in DashCode.

Download DashCode Project

Screencast # 2 - Scrolling HBox without scrollbars (Flex 3)

2010-01-24T20:21:00.003+01:00

In this screencast we'll be looking at how to scroll an HBox in Flex 3, without having the scrollbars present. I'll also show you how to get a nice animation effect when doing the scrolling.
Source code below the video.

Download source

Screencast # 1 - Filtering ArrayCollections

2010-01-17T23:18:00.013+01:00

In this first screencast I take look at loading XML data into an ArrayCollection, avoiding some common pitfalls and then doing live filtering on the data shown in an DataGrid.
Note that this is my first sceencast and my native language is not english, so this is just me getting my feet wet so to speak.
Source code below the video.

Download source

Quicktip: Searching an ArrayCollection fast and easy

2009-10-24T00:00:00.006+02:00

Let's say your Flex project needs to maintain a large amount of data, like all the userdata from you big ass site. You can use several datastructures in Flex to store complex userdata, from XML to linked lists. However, perhaps the most useful and easiest structure is the Flex native ArrayCollection. This structure gives you a lot for free, for instance.. searching for stuff.

Let's say you have all of your users in "usersCollection" which is an ArrayCollection. A user object may contain things like "firstNamename","lastName", "email", "address" and so on. Now, what if you need to find a specific user like "John Rambo". Then you'll need to search both the first and last name fields. You could of course traverse the entire collection using a loop, checking every iteration. Hang on, there is a faster way using a cursor (it's kinda lika a struct pointer if you're a C person).

First you need to sort the collection

var mySort:Sort = new Sort();
mySort.fields = [new SortField('lastname')];
usersCollection.sort = mySort;
usersCollection.refresh();

Then we create the cursor, pointing to the first item in the collection at init.

var cursor:iViewCursor = usersCollection.createCursor;

Now, we need to search both first and last name, so we create a searchobject.

var sObj:Object = {firstname:"John",lastname:"Rambo"};

We are now ready to do the actual search by using the findAny method of the cursor.

if(cursor.findAny(sObj)){
 //We found him
}else{
 //John Rambo is lost again
}

In order to get to the user we found we utilize the current property of the cursor.

var foundUser:Object = cursor.current;

Do keep in mind that the cursor is now pointing to the user found, so if we want the next user in the list we can simply go "cursor.moveNext()"

Why should you use this method? It's more flexible, it's faster and uses less resources than the traditional iterative loop approach.

Adobe Flash becoming an "Ad tool" full time?

2009-05-17T16:27:00.007+02:00

As reported by Ryan Stewart, Adobe is altering the name of the next version of Flex Builder(code name «Gumbo») to «Flash Builder». Seeing this in correlation with the new «Flash Catalyst», I can't help wonder where this leaves the Flash authoring tool.

Adobe Flash has for some time been struggling with a bad rep for being the tool "which is used for creating annoying banner ads". This view does hold water in many cases, adding insult to injury the fact that many Flash sites are poorly built and tend to leave users with a crashing web-browser. It seems like Adobe are segmenting out Flash as a cowboy tool, fronting Flash Catalyst and Flash Builder as the tools for creating "real" RIA applications and "robust" rich interactive web sites. On the other hand this may not be their intention at all, however I do believe it will be the result following this strategy.

I base this assumption on two things in large. One is the fact that the Flash authoring tool becomes more or less redundant with the introduction of Flash Catalyst, seeing it from a designer standpoint. As for developers, the Flash authoring tool has never been the first choice to put it in subtle terms. The second argument bases itself in the evolutionary direction in which rich internet applications are heading. Current trends shows that rich web-sites and RIA applications grow ever more complex, at the same time users are demanding a more friendly UI, conformity in the experience and short load times. Flex and Catalyst performs advanced tasks better..

Adobe Flash authoring is a tool for creating interactive animations, but has been used for everything else in the past years. I do not think the Flash authoring tool will die, but it's role will diminish, leaving Flash Catalyst as the main designer tool for rich content and Flash Builder as the developers choice.

Why and when to break out of the browser

2009-05-07T21:44:00.013+02:00

"A web app can do what a computer from 15 years ago, without a disk can do" Daniel Jalkut

While Daniel Jalkut was sort of kidding when making this statement on "Core Intuition 17", he wasn't really kidding. The fact remains that desktop applications sport a lot more features, both UI, functionality and user friendly vise compared to Web 2.0 applications. But, when does it make sense to move something onto the desktop, and to what desktop?

With the advent of the real iPhone SDK and the AppStore, Apple managed to light a spark in the idea of creating applications once again. It's nothing new, this idea of creating applications instead of webpages, however the distribution model(AppStore) is "new". Suddenly everybody, designers, web-developers, marketing people.. the list goes on.. everybody is making iPhone applications. In most cases they are good apps, however in other cases there seem to be a lack of planning/thought ahead of launching xcode.

Why and when should you consider making your project into an application instead of a web-application? I always ask myself the following questions before making such a decision:

Does the application need to access local resources on the users computer?
Does the application need to exist outside the web-browser? Why?
Does the application rely on server storage completely?
Does the functionality ask for a custom UI?
What solution handles the users frustration level in the best way?
Does the IA need a page-based layout?
What's the degree of interaction required?

While contemplating these questions you would probably form an idea as to what is needed for your application to succeed. But, bear in mind that most of the questions above result in solutions that can and will run fine in a browser. Trough RIA tools like Flex and SproutCore, the most demanding UI demands can be met. But, if your application needs to do a lot of local file access, or it needs to exist outside a browser session... Imagine a chat client running only in the browser, it would be no good because you'd go offline when you closed the window.

My advice would be this: Think about it.. are you presenting information that constantly updates, like a news site, why in gods green acres would you do that in an application, it screams web page! Remember that users pick their applications(no matter the platform) with much greater consideration and care than they pick websites to read/use. An application on the computer desktop or on any device needs to satisfy a need or solve a problem, be it something practical or a just game. An application exists forever, because you don't own it like you own your webpage. A webpage can be revoked and it will for all intense and purposes be gone from this world. An application is downloaded and cannot be removed unless the user decides to delete it.

Don't try to emulate a desktop application in a webpage if the application actually needs to exist on the users computer. Try to see if you idea fits into the following boxes, in this order:

Can I solve this using HTML/CSS?
Can I solve this using HTML/CSS and JavaScript
Should I solve this using SproutCore/Flex(or similar)?
Can I solve this without platform specific APIs?

Here is what I would do:

Create a webpage
Create an advanced webpage
Create a RIA application running in the browser
Create a RIA/RAD application running in a cross platform runtime(AIR or Java)
Create a platform application

Now, go do some real work, until next time.. cheerio!

Generating a thumbnail and saving it to disk

2009-04-25T19:11:00.006+02:00

This quicktip will show you how to load an image from wherever and how to generate a thumbnail from that image and save it to the disk. In fact, you can use this method to generate screen dumps from any visual component from within Flex.

There are some considerations, first the actual scaling of an image can be done in several ways, the most used trough a scale Matrix. However, in this example I'll be utilizing the Flex library in order to scale the image using smoothing, thereby accomplishing a better result than with simply a Matrix.

Let's say I have loaded an image into a Flex Image component(myImg) and wish to generate a widescreen(16/9) thumbnail for it.

Load the image

myImg.source = "http://graphics8.nytimes.com/images/2006/12/28/business/28dog.xlarge1.jpg";

When the image is finished loading(Event.COMPLETE) we generate the thumb at a size of 200x112

var orgBitmap:BitmapData = new BitmapData(myImg.contentWidth,myImg.contentHeight);
var thumb:BitmapData = new BitmapData(200,112);
orgBitmap.draw(myImg);//Get the orginal image

var scaleImg:Image = new Image();
scaleImg.load(new Bitmap(orgBitmap,"auto",true));//Set smoothing to true
scaleImg.content.width = 200;
scaleImg.content.height = 112;

thumb.draw(scaleImg);//Here we have the scaled image data

Now we have scaled the image using the Image component in Flex which actually does smoothing on the image when scaled. Now we need to convert the bitmapdata into valid JPEG format.

var myjpeg:JPEGEncoder = new JPEGEncoder(80);//Set quality to 80
var thumbdata:ByteArray = myjepeg.encode(thumb);

Now we need to save it to disk(to desktop)

var fl:File = File.desktopDirectory.resolvePath("myimage.jpg");
var fls:FileStream = new FileStream();
fls.open(fl,FileMode.WRITE);
fls.writeBytes(thumbdata);
fls.close();

There you have a smoothed thumbnail waiting for you on the desktop.

Coding the DocumentClass in Flex Builder

2008-12-03T21:57:00.001+01:00

Since the dawn of Flash CS3, developers have been given the grace of the DocumentClass(explained). The DocumentClass effectively replaces the «lets write all our code on frames» approach which, frankly was more of a hackers approach to coding within the Flash IDE. The main advantage of the DocumentClass is it's life outside of the Flash IDE, it's a separate .as file.
However, there are some things to consider when jumping in to a project using the DocumentClass. One of these considerations must be, that the built in code editor in the Flash IDE, well..it's not the best environment in to be writing code. Alternative ActionScript editors exists, like TextMate(OS X) or FlashDevelop(Win). But the far superior cross platform alternative in my opinion, is Flex Builder. FB is great for many reasons, mainly because it utilizes the power of the Eclipse platform, an environment well known to Java and CF developers.
In short, Flex Builder is a powerful coding environment. But there are some considerations to take when working with a DocumentClass to be exported trough Flash.. one of them is that Flex cannot see your instance names(objects on the stage) and give you code completion on them..in fact, it will complain and claim it's an error. This can be fixed in a jiffy..

In Flash, open the project settings.

Click the «Settings» button to the right of the «script» drop down

Unckeck «Automatically declare stage instances»

Now Flex will let you declare your own instances from within the DocumentClass, like they where properties of the DocumentClass itself(which they are). However, you will need to define the instances as «public» properties/variables, so the Flash compiler can see them. Okay, time for an example.

Let's say I have a blue movieclip on the stage with an instance name of "cheeseball". Here is how I access this movieclip from within my DocumentClass.


package{
	import flash.display.Sprite;
	import flash.display.MovieClip;
	
	public class MainClass extends Sprite{
		
		public var cheeseball:MovieClip;//<-----
		
		public function MainClass(){
			trace("The name of the clip is "+cheeseball.name);
		}
	}
}

As you can see, the «cheeseball» movieclip on the stage is now accessed by defining it as a public property, making it visible to both Flash and Flex, giving you code completion, error checking and all kinds of wonderful things. Do this and your day will be shinier!

QuickTip: MOUSE_OVER vs ROLL_OVER

2008-12-02T18:53:00.001+01:00

So, what is the difference between the MouseEvents, MOUSE_OVER and ROLL_OVER? The short answer is that MOUSE_OUT triggers when mousing over a child of the listener object, ROLL_OUT only triggers when leaving the listener objects bounding box. Consider the following code:


var sp:Sprite = new Sprite();
sp.graphics.beginFill(0xFF0000);
sp.graphics.drawRect(0,0,200,200);
sp.graphics.endFill();

var inner:Sprite = new Sprite();
inner.graphics.beginFill(0x00FF00);
inner.graphics.drawRect(0,0,50,50);
inner.x = 75;
inner.y = 75;
sp.addChild(inner);
addChild(sp);

sp.addEventListener(MouseEvent.MOUSE_OVER, report);
sp.addEventListener(MouseEvent.MOUSE_OUT, report);
sp.addEventListener(MouseEvent.ROLL_OVER, report);
sp.addEventListener(MouseEvent.ROLL_OUT, report);

function report(evt:MouseEvent):void{
	trace(evt.type);
}

The sprite "inner" is a child of "sp". When rolling over "sp", both the MOUSE_OVER and the ROLL_OVER will trigger. However, when rolling over "inner", MOUSE_OUT will trigger, succeeded by MOUSE_OVER again. ROLL_OUT will not trigger when rolling over "inner". Test it out and it will all become clear!

Flash and Flex, bridging the gap

2008-11-22T16:58:00.002+01:00

This post is a followup of my previous post regarding Flex and Flash. Although this is a followup, the focus has changed in parallel with the internal functionality and focus of Flex Builder and Flash. Back in august 2007, Flex and Flash existed in two different worlds, this is still the case, however now there are bridges between the two worlds.
As a developer, Flex (Builder/Eclipse) is a tool far superior to the Flash editor from my point of view. But when it comes to flexible design, Flex Builder still brings little to none to the table. And as far as my understanding of Adobe strategy goes, this is done intentionally. Flash should be an animation and design tool, whereas Flex Builder focuses on the developers. Adobe does intentionally try to separate the two..smart move!

What Adobe has done to amend for the intentional wedge driven in between Flash and Flex, is to create ways for developers to remain in Flex Builder while "importing" design created from within Flash. This is done trough bridging tools like the Flex component kit and the Flex component templates. This enables designers to stay in Flash(or any other CS product), using tools familiar to them, creating the design to be implemented via Flex. This approach to creating rich interactive content is much better than the old one involving big ass .fla files and no code help what so ever(almost). The snag is, when Adobe decides to change the approach of the designer developer workflow, change is also forced upon a bunch of Adobe/Macromedia users. To change their entire workflow may seem as a daunting task for many designers and developers. However this change is a change for the better, it's just a matter of dropping the conservative mindset.

As of now, the Flex Component kit is the best way to prepare for the real transition in my mind. You can of course go ahed and do lots of CSS styling in Flex builder, not a good idea unless there's only one person working on the project, as Flex builder is needed to see the design as a whole. The real transition is of course the introduction of FXG, the new interchange format making it possible to do full designs in CS products, add interactivity in the upcoming Flash Catalyst, then do the development in Flex Builder. In this way the different tools will keep their strengths and not worry about unrelated functionality, Flash becomes a design/animation tool and Flex a development tool exclusively. Like the current workflow of movie editing suites like FinalCut Studio, you will be able to use the FXG format to pass files back an forth between the designer and the developer, maintaining the focus, never worrying about stuff outside your field of your expertise. This is a long awaited and a big step for Adobe. Along with AIR, this move will in my opinion reinforce the FlashPlayer status as the goto(pun intended) technology for cross-platform interactive content and development.

Optimizing Flash performance

2008-11-04T13:31:00.017+01:00

Introduction
As Flash designers and developers get a hold of even more advanced tools and scripting languages, the need for performance considerations within flash projects become ever so apparent. Lately I've seen people complaining about flash apps that bug down their CPU and memory when visiting sites containing flash media. I see this problem as two parallel problems.

1. Sites relying on advertisement (often flash banners) try to cram a gazillion banners and ads into every nook and cranny available on their site. This is simply greed, a condition for which I can offer no cure.

2. The Flash editor has been an animation tool for quite some time. As a result, things common to other development platforms, like performance optimization, has not been and still isn't a priority in most Flash projects. However, this has started to change, something I will try to contribute into trough this post. So, let's get it on...

General optimization

WMODE. First of all, if you don't have an amazingly good reason for using it, do not use wmode! In short, wmode is used to make the background of the swf file become transparent. Wmode will render the swf unreadable to screen readers, force the swf to run when on a hidden tab and make the content of your swf to render much more slowly than in normal mode. Read more about this (Tinic Uro).
Vectors and bitmaps. If you are animating a complex static vector, that is a vector that does not change it's content, e.g. a rectangle, then use the «cacheAsBitmap» property or simply use a bitmap instead. Let's say you are tweening a vector shape across the stage. The Flash-Player(FP) will have to recalculate all the vectors in the shape for every frame. For complex shapes, this will take up a lot of CPU cycles. With «cacheAsBitmap» turned on, the FP will calculate the vectors once, create a bitmap and re-render the bitmap instead. But do note this!! For vector shapes that are changing, not static, like lines that are constantly moving inside of a movieclip, if so..do not use «cacheAsBitmap». The reason for this is that FP now have to re-render both the changed vector shape AND create a new bitmap for every frame. So «cacheAsBitmap» is only good for static vector shapes.
MovieClips. Not every shape needs to be a movieclip. If you need frames, you do need a movieclip, but if not, use a sprite(in ActionScript) or a Shape in the editor. Shapes does not have mouse and keyboard events and leave a much smaller memory imprint than MovieClips.
Alpha. Crop your artwork instead of using big ass areas of alpha channel. The FP do render the alpha channel areas even if you cannot see them.
Alpha video. A flv video encoded with an alpha channel using the On2Vp6 codec is about 4 times more complex to decode than one without the alpha channel. FP do not support alpha using H.264. Read more.

ActionScript optimization
This section is on ActionScript 3 only and can get somewhat technical.

Strong typing. By typing your variables and functions the performance gain is substantial, in general 10 times faster. In AS3 the byte-code produced by the compiler actually changes based on typing. Also, strong typing makes it much easier to debug your app as the compiler will give more accurate debugger results. More on this.
Numbers. Even though strong typing is quite easy to do, it's not always clear as to what type is the most efficient one. For numbers the «int» type is the speediest of the bunch, however «Number» does not lag far behind. However, it's smart to use «int» for iterations and situations where you are working on integers only as this will make debugging more effective. But do avoid «uint», unless you really need it. The «uint» type is a turtle compared to «Number» and «int». More on this here.
Local variables. If you are going to access a variable more than two times, store it in a local variable first. Local variables are faster because they do not require a lookup into objects. E.g:
var fName:String = person.firstname; if(fName == "jim" || fName == "jill")
is faster than
if(person.firstname == "jim" || person.firstname == "jill")
Data binding. Binding in Flex is a valuable and efficient way of handling data, however bindings do take up memory and they are general type. In other words bindings don't know what part of the data that will change, therefore all the data needs to be watched. If you are going the access the data only once or twice, it's better to do an manual assignment in code.

That's all folks.. be sure to check out the links as well.

Quicktip:Event handling

2008-08-18T08:25:00.003+02:00

I've been seeing a lot of this(image) following the launch of ActionScript 3. For me, having the debugger version of Flash Player installed it manifests as an error dialog box telling me that loading did never complete. If you don't have the debugger version of the Flash Player this will only result in the application stopping without any message.

What puzzles me a bit is how often I see this error and the share number of professionally build Flash sites where this occurs. Now, this is completely avoidable. It's just a question of handling your events.

Basically there are 6 event you handle when loading stuff over http(s). You don't actually need to do anything upon the occurrence of an event(however it is smart to do so), you simply need to handle it in order to avoid FP throwing an error shown above. Do this and your app will feel so much more well made to the end user.

Sound visualizer using SoundMixer

2008-06-03T22:00:00.006+02:00

This time you'll get a complete class drawing a visualizer graph for the sound playing(or, actually the bytes in the sound). You can show the graph as a raw sound wave or as grouped by frequency(where a fourier transformation has been applied). This is just a simple demo, but you can separate out different frequencies to get some really cool effects. Play around with it and see what you get. PS: You do need to provide your own sound ;-)


package  {
import flash.display.GradientType;
import flash.display.MovieClip;
import flash.events.Event;
import flash.media.Sound;
import flash.media.SoundMixer;
import flash.net.URLRequest;
import flash.utils.ByteArray;

[SWF(width='512',height='300',backgroundColor='0x000000',frameRate='30')]

public class SpectrumTest extends MovieClip{

private var _eql:Boolean = true;//Show as grouped by frequenzy
private var _completeGraph:Boolean = false;//Complete graph fill
private var _spikeAmp:uint = 100;//Amplifier for graph peaks
private var _graphFill:Array = new Array(0xFF0000, 0xFFDF21);//Colorfill for graph

private var _soundBytes:ByteArray;

public function SpectrumTest(){
var s:Sound = new Sound(new URLRequest("yoursoundfile.mp3"));
s.play(0, 3);
this._soundBytes = new ByteArray();
this.addEventListener(Event.ENTER_FRAME, drawGraphHandler);
}

private function drawGraphHandler(evt:Event):void{
graphics.clear();
graphics.clear();
graphics.beginGradientFill(GradientType.LINEAR, this._graphFill, [1,1],[0,255]);
graphics.moveTo(-1, 150);
            
                  //Get the bytes
SoundMixer.computeSpectrum(this._soundBytes,this._eql);

for(var i:uint=0; i<(stage.stageWidth * .5); i++){

var num:Number = -this._soundBytes.readFloat() * this._spikeAmp + stage.stageHeight * .5;

graphics.lineTo(i*2, num);

}

if(this._completeGraph){

graphics.lineTo(512, 300);

graphics.lineTo(0, 300);

graphics.lineTo(-1, 150);

}

Briefly: SWF and FLV formats opens up

2008-05-01T19:36:00.003+02:00

Adobe has announced the Open Screen Project which will be one big step in the openness direction of the SWF and FLV file formats. In practice this means that you can build your own Flash player, or an FLV flayer. So, iPhone Flash player anyone?

Ryan Stewart has written a more in depth explanation on what this announcement means.

Quicktip: Skewing an image using ActionScript 3

2008-04-20T21:35:00.005+02:00

So you want to skew an image, or a MovieClip or perhaps any other DisplayObject. You could do this manually in the Flash editor of course, but what if you need to do it dynamically, or in Flex.. Here is how.

//If you prefer to draw one visually, skip down
/*var target:MovieClip = new MovieClip();
target.graphics.beginFill(0x000000);
target.graphics.lineTo(100,0);
target.graphics.lineTo(100,100);
target.graphics.lineTo(0,100);
target.graphics.lineTo(0,0);
target.graphics.endFill();
//center it on the stage
target.x = stage.stageWidth *.5-50;
target.y = stage.stageHeight *.5-50;
//add the mc to the stage
addChild(target);*/
/*****/
//Set the skewing angle
var degX:Number = 15;
var degY:Number = 15;

//Get the transform matrix for the object to skew
var m:Matrix = target.transform.matrix;
m.b = Math.tan(degY *(Math.PI/180));
m.c = Math.tan(degX +(Math.PI/180));

//Apply the matrix to the transform object
var t:Transform = new Transform(target);
t.matrix = m;

//Apply the skew
target.transform = t;

Looks like a lot of code, but remember that the first 10 lines of code(not counting comments) are just to draw a MovieClip onto the center of the stage. The actual skew is achieved in just 8 lines of code.

When applying this to a movieclip it will look something like the image in the top of the post.

Quicktip: Ducking local security in FlashPlayer

2008-03-27T21:42:00.007+01:00

Ever needed to test a swf containing networking residing on your local hard drive? Sure, you can choose to export for only network from the publish menu in Adobe Flash. But what if you need to load some movies locally and then make a connection to your remote server at the same time? Well, out of the box, you can't. But wait, there is a simple solution to allow flash player to do both when playing locally. Only tree easy steps..

1. Open your favorite texteditor(BBEdit, Coda, Textmate..) and create a new textfile. At the first line, type the path of the folder where your project resides, e.g./Users/username/myproject

2. Save the file with a .cfg extension to: /Library/Application Support/Macromedia/FlashPlayerTrust/

3. There is no step 3

Note: You can do this for your entire user account, but I strongly recommend not to do so, cos this will allow not trusted files to run both networking and local command on your computer if you download them. You don't want that.

Briefly: New Layout

2008-03-20T23:36:00.003+01:00

So, I decided to change the layout. More mobile device friendly layout, not more to say on that issue

Quicktip: Avoiding popup blockers in AS3

2008-03-13T23:01:00.006+01:00

Adobe/Macromedia did change a couple of things as the release of ActionScript 3 became a reality.

For once, it's not as easy as it once was to open an external browser window. There are many solutions to this floating around, many of them involve using the "wmode" parameter in the HTML embed code for the swf. In my opinion this is not a good idea cos it will bring a bunch of new problems with it, like handling textfields and so on. I've written a possible solution for this problem which works using standard embed code in the HTML. It simply tries to use the ExternalInterface, if that fails, it falls back to navigateToURL. Hey, remember to import ExternalInterface, URLRequest and NavigateToURL in order for it to compile properly.


private function openURL(url:String, window:String = "_blank") : void {
   var WINDOW_OPEN_FUNCTION:String = "window.open";
   if(!ExternalInterface.call(WINDOW_OPEN_FUNCTION, url, window)){
       navigateToURL(new URLRequest(url),window);
   }
}

What I've done

2008-02-28T22:36:00.025+01:00

So.. time to show off some actual results of my work I suppose. The idea is to publish new projects as they emerge. But as some old Chinese dude once said: «Things Takes Time». In layman's terms that about sums to: "I haven't got anything new to show you just yet". In the meantime I'll present thee with some "old" projects in which I have held the part of developer. Note that these projects where not created solely by me, I merely did the development part of it. To read more about some of the people involved in making these projects please visit Voyagedigital.com.
Due credits also to Kjartan over at madebykjartan for his exquisite web-design in the «lenka» project. There are many more I'm sure..please don't sue me or go into a wild rampage if I forgot to mention your name ;-)

Freia 2007
This project was developed by using Flash 8 and ActionScript 2, which where the cutting edge at the time. I know, hard to imagine AS2 cutting anything whatsoever.. Anyway, some of the features included a totally physics driven ragdoll game, where the purpose was to avoid enemies and win the princess. Hey! It's not original, but darn tutting cool. Click here to watch it live.

Lenka (The Chain)
A project with a goal of actually helping people, which was a real inspiration. This was my first Actionscript 3 project and therefore one should be kind in evaluating it's effectiveness and robustness!
Thinking back, this project should have been done using Flex, but we ended up doing it in the first release of Flash 9. Smart? Well.. But hey.. it still rocks! (offline)

Menn og kreft 2006 (Men and chancer)
This was done in Flash 8 and AS2, and boy did this project get fat. Tons of cartoons loading and cellular services adjoined by a fully fledged online video editor with exporting features. Basically we worked our collective asses of making it, and by golly it's slow to load..but still, it's worth it.. mostly because of Runes (The Art Director) way cool character design. Watch it live here.

Menn og kreft 2007(Men and cancer 2007)
The project was a followup to the project above, only this time Rune had hatched a completely spanking new and exiting idea. «How to live life», as told by a cartoon midget with a sassy attitude. This time done in Flash 9 and Actionscript 3, much more smooth and lightweight that the previous year. And to top it off, the amazing "kick my ass" game. It's the black button in the middle.
Click here to watch Steinar go bananas

That's some of them. Sorry they're all in norwegian, but still, you don't have to read the text you know. Well, I'll be back with more incredibe nerdy stuff at a later moment in time.

Quicktip: Changing the font in Flex 3 editor

2008-02-28T20:43:00.003+01:00

Have you ever wanted to turn enlarge that font size in the code editor in Flex builder 2/3, but have thrown in the towel after several hours poking around to find this setting? Since Flex is build on Eclipse, this part of the editor is actually identical to the Eclipse interface. To change the font, choose Window -> Preferences -> General -> Appearance -> Colors and fonts.

In that small list of folders, choose Basic -> Text font and hit the change button. Tada! Kinda a lot of effort, but it will be worth it in assisting your eyes from squinting all day long.

And hey, while we're at it. If you are starting to type something in the code editor, but can't quite remember the whole variable name or whatever... hit ctrl+ spacebar. Flex will then make a suggestion. This is a very handy feature as well..

Quicktip: Actionscript 3 and number bases

2008-01-24T16:07:00.000+01:00

"Oh my God, he's writing about numbers, how boooring!".. I bet you're thinking something like that right now, but hang on, this isn't really about numbers, it's about colors and all the cool things you can make em do.

So what does number bases has to do with colors? Well, in this exact moment you are looking at several colors, and at least two color models. The most commonly used on webpages, hexadecimal colors, like #FFFFFF or 0xffffff (in Flash/flex). In fact, hexadecimal means 16 based, as opposed to decimal or 10 based like we're used to (0-9). This is kinda good to know, because.. let's say you want your flash app to sample some colors from a picture and present the colors to a web-designer in a hexadecimal format.. how would you go about converting the premultiplied color value Flash gives you into an usable hex color?

Let's say you sample the color white, Flash gives you 16777215, completeley useless for a designer. Let's transform that value into a hex color in one line:

var myWhiteColor:uint = 16777215;

trace(myWhiteColor.toString(16));

And there you go, Flash spits out "ffffff". This happes because the toString method takes the radix or number base as a parameter and converts the passed number. To reverse the conversion you'd use parseInt("0xffffff"), that would give you the original premultiplied color value.

Tip: Tracking you Flash/Flex site[UPDATED]

2007-12-12T21:01:00.000+01:00

There's a lot of fuzz surrounding this topic. So why should we bother with tracking what users do to our applications and games on the web? Well, there's a lot of reasons for doing this, however the main motivation should be to gain knowledge about the user friendliness of you creation. Do the user understand how to use the site/app, or does he give up after a short try? If your in the advertising business there also be alternate motives, but then you'd probably know what you're looking for..so.. I'm just going to outline how to track you app.

The first thing you need to do is to head over to Google Analytics(GA) or a similar service unless you want to develop you own tracking system, something I will not touch with a ten feet fork in this article..

GA is pretty straight forward to set up, and once you have managed to set up tracking on the html page that will host your swf file it's time to get into the clever stuff. The thing is, to track something from ActionScript 1/2 vs AS3 are two different things. In AS2 you would simply use the getURL("javascript:pageTracker._trackPageview('myTrackingPoint');"). This will then add a tracking point called «myTrackingPoint» to GA, in AS3 it will look like this: ExternalInterface.call("pageTracker._trackPageview","myTrackingPoint"). This difference can be traced back to that AS3 has a different and much more powerful interface to talk to JavaScript.

To use this in an effective manner I highly suggest using some kind of folder structure when tagging your apps. Like e.g. if you have 5 buttons in your main menu, then track them like so:

ExternalInterface.call("pageTracker._trackPageview","mainmenu/button_home");

In this case GA will create a folder structure which makes navigating within the GA report much more useful.

Okay.. now your on your own..

User friendliness - a matter of taste?

2007-11-02T23:51:00.000+01:00

Sneaking about on the WWW I tend to find all these articles dealing with something the authors call user friendliness in computer programs. Most of the articles deal in the differences between the OS X interface and the Windows interface. But they often tend to generalize, thereby and hence talking about user interface design in general. And that's nice, that people care about how things look, but that's also the problem. 90% of the articles dealing in user interface design focus on visual design. Now, visual design is only a small part of the user interface. Indulge me while I explain why it's important to know this.

User interface design is not if that button should be red or blue, or it's that too, but not only. The isolation of visual elements is called graphical design, which is something quite different from user interface design. Since my field of interest lie within the world of RIA applications, I'll use this as my point of origin for this statement.
When you sit down on your trusted behind and start thinking about how your RIA application should behave, you need to take into consideration the following elements: IA/SD, UID/HMI and GD. So, that's a lot of nice not disclosing concepts, here's what they mean.

IA - Information architecture. SD - System design(systemization):
In RIA development, these two are actually the same thing. In other areas like website development, IA will adhere to a slightly different path than SD, but in most cases, and in this case, they are the same thing.
The science of expressing a model or a concept of an entire system is the shortest possible definition of these concept I cold come up with on the fly. This means using a modeling approach to break down large amounts of data to a more readable format in which logical paths of data can be seen in the development and design of the application. In others words, trying to predict the users movement trough the system. This approach lays the foundation for usability and findability in applications, websites and databases.

UID - User interface design. HMI - Human machine interaction:
Like IA and SD, UID and HMI also go hand in hand, the only difference lies in more empirical approach of UID, while HMI is much more theoretical. UID is, as the expression denotes, a collection of rules on how to design the user interface of your application, like buttons and boxes and stuff. The rules that make up UID are derived from HMI principles, like Fitts' law, reaction time and so forth. Let me stress this point, these rules are measurable data, it is not a matter of taste. The HMI principles are built upon years of research into human physiology, psychology and human habits. So when the UID principle state that the OS X menubar on the top of the screen is a better way to go than attaching the menubar to each and every window(Windows), we know this because we can actually prove it trough a HMI principle. And therefor we simply adheres to the UID/HMI principles when designing an interface.

GD - Graphical design:
This is not a matter of taste either. Surprised? Well, GD is kinda a matter of taste, but there are lot's of rules in this area too. It's a reason why you are reading this black text on a white background you know. Graphical designers knows that this work, and they stick to it most of the time. In this area you encounter subjects like readability, fonts and so on. But do not get me wrong, graphical designers do not only deal in colors and fonts, they also need to know stuff from the UID area, how else would that know how to design a button that the user actually will understand how to click.. The transition between UID and GD is blurred, and I think it should be. The result of all these fields coming together will result in a efficient, understandable, beautiful and intuitive user interface.

So here is my point in all of this. You cannot simply look at an application and say that it's ugly and therefore it must it can't be user friendly.. it may very well be extremely user friendly. And then again, a really pretty application with fancy stuff in it may be completely useless. User friendliness is not a matter of taste, it's a matter of skill and knowledge, plus a touch of magic.

No way to dodge it - The Leopard review

2007-10-31T21:00:00.000+01:00

So here it is, the worlds most advanced OS, Apples OS X 10.5 Leopard. By now it has already been written a bunch of reviews into the crooks and crannies of Leo, so this will not be a feature tour of the entire OS, click the link at the top to experience that. Instead I'll take a brief look at what's important to me in this release, and why I plunged straight into it and upgraded both my Macs to run OS X 10.5.

My main excitement in this release was in the new Mail application.. yeah, geeky right? But the ability to take notes, create todos, and have everything beautifully organized and synced with a simple IMAP account was a very appealing idea to me. And boy do I use it, I love the new Mail application, not so much the stationaries perhaps, but everything else comes of as much more efficient and polished compared to earlier releases. So I did expect Mail to be great one might say, but I did not expect CoverFlow to be as handy as it turns out to be. This is the ability to see your documents and files as content previews ordered in a sort of shuffle stack mode. Incredibly handy when browsing media files! And it's all powered by QuickLook, the new brilliant way of presenting the content of any file, anywhere. You no longer get an icon for a document type, you get an actual preview of what's inside of the document instead, and further more.. a touch of the space bar and voila, full screen preview of any file without opening a single program.

Any bad stuff then? Of course there is, Apple makes mistakes like any other company developing a piece of software spanning millions of lines of code. However, not many mistakes in this release. Some people are arguing that the dock and the menu bar has a weird graphical appearance.. well, the thing is, people always fear change, and this is one such case in my opinion. There is nothing wrong with the new desktop, it's just different.

If you need one reason besides those already mentioned to upgrade; Spotlight! It's blazingly fast and you can search any shared computer.

A more in depth review of Leopard can be found at Ars Technica.

Review: Pixelmator

2007-09-26T21:37:00.001+02:00

The brand spanking new Pixelmator from the Dailide brothers adds a new member to Delicious generation software pool. So, this is an image editor app for OS X, utilizing Apples core image processing routines. It's not a Photoshop replacement, yet. But it has the potential of becoming one.

I'm a vigorous Photoshop user, so naturally I'm accustomed to the tools provided to me in that app. Containing in that mode, Pixelmator was a no brainer, the menus and tools where almost exactly where I expected them to be located. There is one huge difference in the UI though.. Pixelmator is far better than Photoshop, not only does it look prettier, it's also more logical, cleaner and does make for a sleeker experience. You won't get scared when being presented with the Pixelmator interface, you'll go "vow, way cool man!". Where when opening Photoshop for the first time you'll go "ehm, do I really need this".

However.. this is the first release of Pixelmator, and it is slow.. sometimes too slow, even on my iMac Core2Duo. Photoshop is much faster..and that matters. But as a whole I do believe that Pixelmator will become a Photoshop competitor..in time. Check it out at www.pixelmator.com!

Windows better on Macs? Is Apple getting greedy? And leave Steve Jobs alone!

2007-09-22T15:56:00.000+02:00

An intriguing blog post by Steven Frank co creator of Panic software, discussing if Windows runs better on a Mac. He also shares some insight into why OS X is in fact a better OS compared to Windows.

Also, veteran Will Shipley from DeliciousMonster thinks Apple is getting greedy, is he right? Lot's of good stuff in his post.

But of course, our all time favorite Apple fan Justine, just wants us to leave Steve Jobs alone.

Anti piracy

2007-09-09T12:27:00.000+02:00

Embrace, extend and extinguish

2007-09-02T22:02:00.000+02:00

The three e's, Embrace, Extend and Extinguish. Not many people besides those already up into their neck in nerdyness knows what this term describes. In short, this is a term used by Microsoft to describe their strategy to do a hostile takeover in areas of the computer industry where standards are widely in use..like the Internet. The term was actually first made public by the U.S. Department of Justice.

It works like this: You enter a product category, e.g. the www with a browser. Let's call it Internet Explorer. This is the embrace part, when you enter the area, seemingly on fair terms. But then, when your browser has become widespread, then you start to add proprietary abilities to it. Let's call it ActiveX for example. These new features does of course implement functionality not found in competing products, like other browser, and therefore companies will start to use this closed technology, for example for online movie rental. But wait, isn't this a great thing, adding features to browsers.. Sure, except the technology added is closed, so no other browser can ever support it. And then, we enter the final stage. Since the MS browser now has all these features not supported by other browsers and there is a de facto monopoly in some areas of browser technology, like DRM video.. this gives MS the power to extinguish the competition. And this is why IE is the most widespread browser in the world... E.E.E.

In 2004, to prevent a repeat of the "browser wars," and the resulting morass of conflicting standards, Apple (makers of Safari), Mozilla (makers of Firefox), and Opera (makers of the Opera browser) formed the Web Hypertext Application Technology Working Group to create open standards to complement those of the World Wide Web Consortium. Microsoft has so far refused to join, citing the group's patent policy, which requires that all proposed standards be possible to implement on a royalty-free basis.

But why do they do this? It's not like they need the money, and IE is a free browser..so no money to make there. The thing is, the business strategy utilized by Microsoft is based on markedshare. Unlike other companies like Apple and Sun, which base their business plan on profit, Microsoft move money around from areas where they make the money to areas where they loose, all to gain markedshare. The idea is to run competitors into the ditch using size and brute force, effectively creating a closed standard like in the case of Microsoft Office. This way Microsoft don't have to worry about the profitability or quality of their product, people have to buy them, cos there is no other alternative.

Medal of Homer

2007-09-02T15:12:00.000+02:00

"The Simpsons game, coming this fall. To every platform ever made!"

Priceless!

Quicktip: Getting the GET params in ActionScript

2007-08-29T21:53:00.000+02:00

So, you want to get the content of a GET variable, like «http://nytimes.com/?id=dork» the id from the URL of that web page. Using a server side script like PHP in conjunction with ActionScript you can use $_GET['id'] and print that to a FlashVars on the page in which the swf file is embedded. That sounds like a tedious solution, and what if you can't control the server side scripting? Well, good news, using the spanking new ExternalInterface api for ActionScript 3 we can get the id value passing a bit of JavaScript.


var myStr:String = ExternalInterface.call("window.location.search.substring", 1);

Note that this will accually give you the entire string "id=dork", so you will have to split it on the equal sign.


var myParams:Array = myStr.split("=");
var param:String = myParams[1];

There you have it.. no server side scripting, only ActionScript and javaScript, all from within the one swf file.

Fitts' law and RIA

2007-08-28T20:03:00.000+02:00

To my amazement, it seems like the usage of Fitts' law in Internet applications and websites is a rather controversial topic these days. There are critics out there claiming that Fitts' law is an old and outdated approach to designing user interface elements.
Well.. the law of gravity is also getting old, but guess what.. it's still relevant. I really don't insinuate that Fitts' law and the law of gravity are the same, but the point being made here is that Fitts' law is just that, a law describing physical movement. This is not an idea made up by a besserwisser trying to revolutionize the UI of computers. I believe that the biggest problem with Fitts' law, is the fact that most people working in UI design, and particularly in RIA and web design, have either little or no knowledge of the actual content of Fitts' law.

So what is it? In short, Fitts' law is model describing human movement. It was described by Paul Fitts back in 1954. Despite to popular belief, Fitts' law isn't all about making things bigger on screen. As this is a part of the law, the actual formula describes the relationship between distance between the starting point and the target, and the size of the target. And you have something called infinite width, which I will describe in more detail later.

Mathematically speaking the law states that «Time = a + b log2(D/S+1)». Where D is the distance from where your cursor is currently at to the target, and S is the width of the target. The a and the b are constants. It's not that hard now is it, but yet extremely powerful when taken in to use. So how do we use it? Let's start of with the words of Bruce Tognazzini.

While at first glance, this law might seem patently obvious, it is one of the most ignored principles in design. Fitts' law (properly, but rarely, spelled "Fitts' Law") dictates the Macintosh pull-down menu acquisition should be approximately five times faster than Windows menu acquisition, and this is proven out.

What TOG is talking about here is the infinite width. What that means is that, like in the Macintosh menubar, the menu is at the top of the screen, always. This will let the user move his cursor at full speed to the top of the screen, because no matter if the user keeps pushing the mouse upwards, the cursor will stay in the same place, hence making a target of infinite width.

But let's drop the Os X vs Windows crap. Let's instead concentrate on how to apply the principles of Fitts' law to our RIA apps and web sites. Now note that these are only my suggestions on how to apply Fitts' law, so please do your own research. My opinions are largely based on my studies of HCI from the university and later experiences in building applications, RIA apps and web sites.

1. Contextual menus. If you are going to build a contextual menu, make it a pie menu. I don't really like contextual menus, because they hide the interface from the user, but it seems they're here to stay so let's make the best of it. Well, a pie menu will be faster than a dropdown menu. The reason for this is that you minimize the distance the cursor have to travel by centering the menu under the cursor at creation time. Additionally, pie pieces make for bigger targets than lines of text in a drop down menu.

2. Buttons. Group your buttons together in that order the user is most likely to use them. Commonly used buttons should be bigger and more accessible that less important and less used functions.

3. Dialogs. Attach your dialog windows to the window it belongs to. In this way, the user will know where the dialog will appear and the movement can therefor be "trained". Fitts' law doesn't actually describe trained movements at all, but this is important in conjunction with "the easy to hit target", this explains it's relevance in this context.

4. Edges. If you are in control of the mouse pointer. E.G a full screen app. Then make use of the edges to place important UI elements. Edges are much easier to navigate to because of the infinite width. But don't use both horizontal/vertical edges of the screen so the user need to move the cursor over the entire width..that would be bad. For both right and left handed people, the upper left edge of the screen is the spot most easily navigated to.

5. Drag and drop. Since the muscle tension increase when doing drag and drop operations(holding mouse button pressed), it's a good idea to minimize the distance the user has to drag something to drop it. You could for example pupup a drop-box next to the item when the drag operation starts, hence minimizing the distance.

In my opinion, Fitts' law is an easy to implement principle that requires some thought and consideration, but it's worth it.

Something different

2007-08-26T13:59:00.000+02:00

Follow up: Flash and H.264[updated]

2007-08-21T21:49:00.000+02:00

As a follow up to my recent article concerning my guess that YouTube was moving over to the H.264 codec, leaving the Adobe flv format behind. Well, it looks like it's true, kinda.. only not. Today Adobe announced in a press release support for the H.264 codec within the Adobe Flash Player version 9.x. Adobe also adds support for HE-AAC which is a part of the MPEG-4 standard like H.264. The press release do not mention in specific words on what wrapper will be supported. Will Flash Player add support for QuickTime directly, or more likely, will the H.264 codec be wrapped by the flv format. [Update: After reviewing and testing the new Flash player it is now clear that it does indeed support all h.264 formats, m4v, mov and so on. There is no new API to be used, you can use it directly trough the netstream object like you would with any flv file]

This is really great news for Flash developers as this release laster this fall will make users adapt the updated Flash Player at a faster rate, due to the almost inevitable adoption of this codec by YouTube and other online based video providers. The added support for H.264 will also mean the utilization of HD video from within Flash based apps and presentations.

A beta will be released today at labs.adobe.com

Quicktip: Flipping an image in Actionscript

2007-08-15T21:17:00.000+02:00

Ever needed to flip a dynamically loaded image in Flash or Flex? Like for making mirror effects and so on..
There is no property in ActionScript 3 called "flipImage", but there is one easy way to do it.

In AS3, to flip an image horizontally, go like so:


var flipper:MovieClip = new MovieClip();
//Load your image into the flipper MC
flipper.scaleX = -1;

This works because you're actually resizing the image beyond zero, literately turning it inside out.
PS: This will not work with components, like the UILoader.

Flash vs Flex, what to choose when

2007-08-15T20:13:00.002+02:00

If you're a ria developer like me you've probably encountered this situation at least once. You have this somewhat large project to do, there are lots of interactive elements to it and the target format is swf. If you don't already know this, both Adobe Flash and Adobe Flex delivers in the swf format, the same player and all. The only real difference dwells in the approach in which you choose to take developing the finished product. My approach to this would be to first define what kind of project this will be. Will this end up to be a presentation (1), driven by animations and not so much depended on user interaction to work. Or will it become a (2) true ria application, containing lots of interactivity and projecting a user depended interface.

In the first case, your choice should be Flash, as this tool has a timeline and is in fact intended for online presentations with some interactivity. Flash is great for presenting video, small games and other project that can be clearly defined as more depended on the designer rather than the developer.

In the second case you could in fact go for Flash as well, which will be slow and horrible, but it will do the job and the end product will most likely end up looking almost identical. However, when doing developer driven project, the tool used should be a developer tool. Enter Adobe Flex. The UI of Flex is dramatically different from Flash, focusing on code to a much larger extend and totally abandoning the timeline. Because Flex is build like any other developer tool, like xCode and Visual Studio, most developers will feel much more familiar with the UI of Flex. Another thing to consider is development time. Since Flex features layout elements made especially for making applications, it much easier to set up an UI that will shrink to fit the needs of the user. And Flex has even more trick up it sleeves, it can handle swf's exported from Flash. So really, you can have the designer make custom elements all the way trough and set it up visually in Flex. However, most designers will probably end up using Flex powerful CSS support instead, as it's quicker and makes for a more consistent user interface.

The difficult thing here isn't really to convince a designer to work in Flex, or a developer to work in Flash.. the hard thing is to define which is the right tool for the project you're currently working on. Well, good luck with that then ;-)

YouTubes secret move

2007-08-11T14:30:00.001+02:00

YouTube is a great service that allows people to both upload and watch videos. The thing which makes YouTube stand out from all other similar services, is the substantial implementation of so called social tools, like commenting and rating functions. However, even though YouTube is an immensely popular service, it has one problem: Video quality. The videos seen on YouTube are often in bad shape even before they are transcoded into the Flash video format (flv). To encode a video into the flv format, one most commonly would use the On2Vp6 codec, so does YouTube. Even though this codec is substantially better that the Sorenson Sparc which it replaces, Vp6 do produce grainy and bad picture quality at low bitrates.

Now something is stirring within YouTube as a response to this quality issue. If you've been following along into the dealings of Apple Inc. lately you'd notice that they have released a score of products closely integrated with YouTube. Both AppleTv and the oh so fantastic iPhone both hold YouTube functionality. But.. none of them have the ability to play back the flash format. Lately, the newly risen iLife 08 (iMovie) also include the choice of publishing your movie directly to YouTube. No doubt this functionality is a result of Apple and Google being in cahoots(Google is the owner of YouTube), but the interesting part here is that all Apple products which can upload to and download from YouTube utilizes the H.264 codec from the MPEG group.

Since the H.264 codec is far superior to the On2Vp codec and the H.264 is open to everybody, there are now some speculation YouTube is slowly converting it's material to be encoded into H264 instead of Flash. This would mean a significant gain in quality for YouTube material, and could be a necessity if YouTube is to target home entertainment systems with large monitors.

I think this would be a smart move by YouTube, because let's face it, Flash video isn't exactly impressive in it's quality versus size ratio. But, as YouTube and services like are the driving force behind getting people to upgrade their Flash plugins, this may entail that Flash designers and developers will have to dig into QuickTime development, as QuickTime is the only real alternative for playing H.264 video online today. Well..let's get to it then..

Making all others look like amateurs

2007-08-09T22:48:00.000+02:00

So, once again Apple rocked the community with a full score of new apps, ranging from the most excellent iLife '08 to the gigantic and extremely well written Web 2.0 app called .Mac Web Gallery. Everything appears to been in development for several years, however they did it in one year. And in a couple of months Leopard will arise as well. Compare that to Microsoft's five year Vista "experiment". So how the heck are they able to do this time and time again, staying ahead..
The answer is so simple..

If you have read or watched Apples "Think different commercial" you already know why Apple stands out to this extent. The people that actually build their software, engineers like Scott Forstall, designers like Mike Matas, they aren't exactly what you would call an average software developer. The front most profiles, the decision-makers within Apple are front-runners for OpenSource development, they often come from small independent ideological companies like Delicious Monster and OmniGroup. Not what you would expect from a company making it's living by making software and hardware. Other similar companies keep their cards close, for good reason. If you make an invention you can't simply make it available for all, then it can be copied and suddenly you're out of customers..right? Well, Apple has realized that if you find the best people in the world, and somehow manage to combine their talents, others will find it hard to follow, no matter if their holding the source code.

"..no respect for the status quo" it says at line 8 of "Think different". And this is exactly why Apple have so devoted fans, because they really change things. They don't make something that people buy and then sit back and look at the money flooding in, they keep on working, making things better..

It's very exiting to see Apple moving into the Web development community in full force now. Well, really they where one of the first to make use of the old HTTPRequest extention, now cleverly named AJAX. (see web gallery)
.Mac Web Gallery is really a desktop app on a website. It mirrors iPhoto perfectly, and it can do everything Flickr can, and then some. The focus is in great design and great functionality, making things easy to use, removing the typical "website look" and replacing it with a familiar and logical design derived from the desktop apps. And of course, all metaphors that exist in the desktop app, browsing, mosaic and the new "skimming", they are all reflected onto the web app. This makes for a familiar and consistent user interface. Cos that is what we really want, something we just can use, not learn to use.

The future of the Internet

2007-08-07T00:38:00.000+02:00

This post is merely to underline on my previous claim that desktop applications are really the future of the internet. As you know, if your read my last posting, I tend to think that the cloud will work more or less like a giant back-end system in the future. That is, you have the experience of an desktop app and the content of the internet, all at once. And yea, here are two dudes whom think so too ;-)

RIA - Rich Internet Application

2007-08-04T23:56:00.000+02:00

According to Wikipedia: "Rich Internet Applications are Web applications that look and behave like desktop applications." I totally agree, and therein lies the conundrum. Web-designers and web-developers alike have their way of doing things, and so has application designers and developers. Even thought they all are in the same business, the application approach to things have a somewhat longer history to rely upon. The web-developer approach really didn't come into play until the middle of the 1990's. By then application developers already had clocked in about 10 years of experience creating software and UI design. But the much anticipated clash of the different groups of developers and designers was never to come, for the simple reason that they where doing different things in different places. That is, until now. These days it's not longer enough to master "tagging" and Photoshop to satisfy the needs of clients wanting to blow away competitors online. And with the introduction of such tools as Adobe Flex and Microsoft Blend the www is rapidly heading towards application design and development. I haven't forgotten about Google and their go for JavaScript AJAX development, however, that's somewhat outside of the scope of this, as it largely remains web-development.

To develop an application for the web versus the development for an OS, are two different worlds by far. There is not only the technical aspect of filesystems, hardware and low level programming versus the high level web development strategy, it's also the heavily fortified rules of user interface design existing in application development. On the other hand, app developers escape the headaches of making sure their app can run alike in all browsers.

My take on this is to take the best of both sides. UI design guidelines have come a long way on the client side of things. The Apple design manual can by it self carry the entire weight of the user experience. However, the freedom expressed by some web-designers, the ability to throw out old concepts and bring in new ones is something we should have in the mix, as long as these new ideas conform to established truths about what people actually do in front of a screen. Regarding development, I do firmly believe that pure web-developers have a lot to learn from application developers in the fields of efficiency and security.

The problem that still remain, is the speed of the evolution in RIA design. Most people do not have enough computing power to run high end RIA applications. The reason for this is the inefficient browser and the plug in architecture. In a recent interview with Bill Gates and Steve Jobs (yes, together), this question was brought up. Those two disagree on many things, but one thing stood out that they both truly believed in. They argued that in the future the Internet will function more like a giant database, a back end system while the front end part will be handled by client apps running naively on the system of the user. Thereby effectively removing the problem of bad user experience. They make a good point. The thing is, you cannot leap into the future online, cos you can't be sure that people will be able to follow you. And it looks like many developer companies have came to the same realization, just take a look at Air (Apollo), it's Adobes way of moving application development away from the web and onto the desktop, but at the same time keeping the multi platform Flash development environment.

For the future I predict that the web will keep it's role as a place to get information, to advertise and a place to play. But for bigger more complex things I believe that people, given time, will notice the better user experience and the share speed a desktop app can provide. A good example is Apples Google maps client on the iPhone. It's a client running on a phone that actually outperforms the original Google maps client by a factor of ten. As people become more tech capable, they'll demand more, and then we whom are designers and developers should hear their call.. or crash and burn.