I haven’t looked at performance yet, and there is possibly a lot of ways to optimize this code – this article can be a start for further fine tuning. The helper function looks like this:

function map(val:Number, inMin:Number, inMax:Number, outMin:Number, outMax:Number, decimals:uint=0):Number
{
var returnVal:Number;
 
// Sets the total range for both in and out
var inRange:Number = inMax - inMin;
var outRange:Number = outMax - outMin;
 
//calculates the ratio for the value in relation to the in range
var ratio:Number = (val - inMin)/inRange;
//makes sure that the value is within range
val = Math.max(inMin, val);
val = Math.min(inMax, val);
//Finds the same ratio in the out range and shift it into place
returnVal = (outRange * ratio) + outMin;
 
//rounding of the decimals
var factor:int = Math.pow(10,decimals);
returnVal = Math.round(returnVal*factor)/factor;
 
return returnVal;
}

The function takes the the following arguments:

• val: the number to be remapped
• inMin and inMax: The original range, in which the value is measures in relation to.
• outMin and outMax: The destination range, that the value will be re-mapped to
• decimals: sets the precision in decimals (optional)

var inRange:Number = inMax - inMin;
var outRange:Number = outMax - outMin;

val = Math.max(inMin, val);
val = Math.min(inMax, val);

var ratio:Number = (val - inMin)/inRange;

returnVal = (outRange * ratio) + outMin;

var factor:int = Math.pow(10,decimals);
returnVal = Math.round(returnVal*factor)/factor;

Optimization

An example

import flash.display.Sprite;
import flash.events.MouseEvent;
 
//make the small square and color it dark grey
var inArea:Sprite = new Sprite();
inArea.graphics.beginFill(0x333333);
inArea.graphics.drawRect(0,0,100, 100);
inArea.graphics.endFill();
addChild(inArea);
 
//make the large square and color it black
var outArea:Sprite = new Sprite();
outArea.graphics.beginFill(0x000000);
outArea.graphics.drawRect(0,0,400,400);
outArea.graphics.endFill();
outArea.graphics.lineStyle(1, 0xFFFFFF, 0.3);
addChild(outArea);
outArea.x = inArea.width;
 
//adds a listener for the small square, that listens for mouse movement
inArea.addEventListener(MouseEvent.MOUSE_MOVE, updateDrawing, false, 0, true);
function updateDrawing(event:MouseEvent):void
{
	//Map the local coordinates from the mouse movement to the size of the large square
	var targetX:int = map(event.localX, 0, event.target.width, 0, outArea.width);
	var targetY:int = map(event.localY, 0, event.target.height, 0, outArea.height);
 
	//Draws the line in the large square.
	outArea.graphics.lineTo(targetX, targetY);
}
 
//Helper function
function map(val:Number, inMin:Number, inMax:Number, outMin:Number, outMax:Number, decimals:uint=0):Number
{
	var returnVal:Number;
	// Sets the total range for both in and out
	var inRange:Number = inMax - inMin;
	var outRange:Number = outMax - outMin;
 
	//makes sure that the value is within range
	val = Math.max(inMin,val);
	val = Math.min(inMax,val);
 
	//calculates the ratio for the value in relation to the in range
	var ratio:Number = (val - inMin) / inRange;
 
	//Finds the same ratio in the out range and shift it into place
	returnVal = (outRange * ratio) + outMin;
 
	//rounding of the decimals
	var factor:int = Math.pow(10,decimals);
	returnVal = Math.round(returnVal*factor)/factor;
 
	return returnVal;
}

Some will say, that Flash is thereby obsolete. They may even use the “Flash-killer” word, but in my opinion that tells me more about there insight and knowledge about the platforms responsibilities, than HTML5 is superior when it comes to the sites of the future. HTML has always had the responsibility of bringing webpages to the user via the browser. The Flash Player has always been a plug-in, that made it possible to satisfy users demands in terms of interactivity, video etc. and complemented HTML, where it wasn’t sufficient. Now with HTML5, nothing has changed there.

The Flash Platform is dead

I will bring some love to new new HTML5 features in another post, but let me dvelve a bit on the head line. When I say, Flash is dead, I actually mean, the previous well known (and hated) use of the Flash Player is dead. Using Flash to make complete sites with the need of seekable information, and “efferent reading” has to stop. The small banners that pops up, with no reason at all, has to stop. If that is what you have used Flash  to produce, you should seriously consider broaden your mind – we have HTML for that, now. When it comes to aesthetic reading, engaging and entertaining the user. When it comes to breaking the boundaries, and search for new possibilities in what the web and devices can deliver, please continue. Flash has never intended to kill HTML, it depends on it. But the misuse  of technology from developers (myself included, from time to time) has given the technology a bad name.

Long live the Flash Platform

Fortunately, the platform is strong and very much alive, and the latest version of Adobe AIR and Flash Player brings signs of a bright future. When I discuss the topic with developers, they actually do not have a clear answer, when it comes to compatibility across multiple devices. Native Android developers, can’t enter en iOS sphere, and Xcode developers are forever doomed to live in the walled garden. Both of them, can only argue, that the other should join them … why not give the user a choice. I think that the Flash Platform is one of the best attempt to actually be agnostic in terms of platforms. I think it’s time to look at some of the features I find interesting

64-bit support

I don’t know what took them so long, actually. I am not aware of the complications that are involved in making 64-bit versions of software. I guess there must have been internal complications regarding codecs or other 32-bit stuff not yet upgraded or just the fact that making a 64-bit version of the AVM or the like isn’t a walk in the park. Anyway, now it’s available and works like a charm in my 64-bit version of Internet Explorer as well as my other browsers on both Windows and Mac OS. I haven’t tried the Linux version, but I haven’t heard anyone with complaints. Please post your experiences with performance, if you are a Linux user.

Captive runtime

Captive Runtime is captivating Now developers have the choice to embed the AIR 3 runtime in the App, so people no longer need them as an external download. That, of course, brings a larger file to the devices, and it is therefore not just something you would do in all cases. In larger projects, and definitely on desktops, that seems like an obvious choice.

You can read about Captive runtime at http://www.adobe.com/devnet/air/articles/air3-install-and-deployment-options.html

Accelerated 2D

Flash is all about experiences. There is no need to use Flash, if you don’t wan’t to engage the users. If you just have some plain information to present, there is no need to roll out the big canons. The Flash Player is a plug-in that takes over, when the other give up, and can’t deliver – at least not with an economically reasonable solution. It is the easiest way to make impressive visual results, that works on all major platforms. Because of that, it is also a very demanding job, that takes a lot of processing power. With Flash Player 11 and AIR 3, Adobe has made it possible to port most of the calculations to the graphic card, so the processor is free to other tasks. That increases the performance immensely, all the previous examples (like those on http://www.bytearray.org/?p=3371) would have made the fan fly out of my MacBook Pro after 4 seconds … now there is silence.

One of the most prominent examples are the Starling Framework. Starling is very intuitive, and use well known word like Sprite and addChild() and genrally build upon the concept of the Display List.

To get this performance boost, Flash takes advantage of Stage 3D, and that is only available for desktops at the moment. Adobe is working hard to implement it in the mobile version, but Android have to wait until a later update. That also means, that we are in a time, where some content actually can’t be played on mobile, even though they are at the same player level … that’s not good, but hopefully sorted out in a near future.

JSON

Everybody is talking about JSON these days, and for a reason. The format makes it possible to exchange data in a readable way using a JavaScript like syntax. Both JavaScript and ActionScript 3.0 derives from the same standard, making it easier to work with and understand for some, in contrast to the XML language. You have always been able to read JSON into a Flash document, but the internal support makes is consistant and faster to get the data ready for use. Actually, we are are talking one line here to get it all parsed.

Adobe MAX gave a sneak at the next version of Flash (codename Reuben) that exported a sprite sheet of a characters walking cycle. That shows something about JSON as a serious and integrated way of making 2D games and motion in the years to come.

Stage 3D

When Flash introduced the ability to work with z-coordinates and move 2D objects in a 3D space (in CS4 i guess) the crowd went wild – everybody was happy. Then they realized, that i actually wasn’t as good as real 3D, and the need for manipulating real 3D objects was on the rise again. When Adobe released the first previews of Flash Player 11, it was jaw dropping. Thibault showed a red car driving around in a virtual street, and no one in the room could believe their eyes. But it was real, and with the release, they showed Unreal Tournament 3 from Epic Games, running in a browser.

That tells me, that the Flash Player has taken it’s responsability as a plug-in serious, and goes for the balls, that HTML5 has a hard time to catch. I am sure we are going to see web experiences in the years to come, that we had a hard time to imagine only a year ago. On top of Stage 3D’s low level API a range of external companies has build frameworks for us to use. Some of the well known are Alternativa, Flare3D and Away 3D. Of course you could dive into the low API, but the other way around is much easier for normal developers and designers.

Aside from that, there is a project called Proscenium on Adobe Labs, that is a code library used to acces the low-level API, to easely create 3D content in Flash Player 11.

Read more about the wonderful world of Stage 3D at http://www.adobe.com/devnet/flashplayer/stage3d.html

Native Extensions

On the mobile platform, there is a constant demand for speed and integration with the system. Native tools like Xcode and Android SDK has an advantage over runtimes like AIR, in that they have full control over the system. AIR isn’t able to access the inner workings of the mobile platform, so you could not access the local API. AIR it self is making progress, like native keyboard on devices and frontface camera access, but the big leap forward here is Native Extensions. Now you can program an extension to AIR in the native language of the device, and AIR is then able to attach to it and communicate with it. There has already been examples of Map View on iOS and connection to Kinect controller without a proxy. I haven’t tried native extensions in myself, but it seems like it’s going to be a big deal if it runs smoothly.

Content Protection

I love the way that HTML5 has taken websites seriously again. I like the easy way, that video is treated. If all browsers could agree on the codec, it could end up as a good solution. The problem is that there is no protection embedded with the video. You could just copy the link and download the movie. Many content providers aren’t that happy about that. There are solutions to solve that, but I sense that they are moving away from the clean HTML5 solution. Flash and AIR has build in Flash Access that secures the content. Initially it only works with desktop and Android, and I guess that the way into Apples heart is a bit longer

Heal the Web, make it a better place

This is just some of the news. You can read more at the Flash Player 11 feature page and the AIR 3 feature page. This is an epic release, that will mark the start of a new era – the 3D era. We will se browsers taking HTML5 to the max, and transitions like fade and slide, will be everyday for the common designer. But when the smoke disappears, the need to do the extraordinary will emerge – this is where Flash kicks in. Flash Player will fulfill it’s role as the plug-in, that helps HTML getting things done. AIR is taking a different path down the mobile path. It is an interesting path, but it is not quite there yet. It is there in terms of being able to deliver a more than decent result on various devices, but the “works on Android, soon on iPhone” makes it not quite stable yet. It will be, hopefully soon.

I think that this release, shows that there is a world, where both technologies can live in harmony – and truly believe they will. We haven’t talked about topics like all the Smart TVs that supports the platform. We have only briefly talked about Epic Games, but Unity has also shown support to deliver on Stage3D. Aside from that, there is the Open Screen Project, that count a broad range of manufacturers , interested in making a common platform for Rich Internet Applications end experiences.

I know that the Flash Player aren’t allowed on iOS – well no plug-ins are, no harm there … but AIR are. AIR, may end up being a long term solution, if they fix the minor incompatibility. Flash Player is now a solid 64-bit plug-in, and yes – everybody is trying to find exploits and security breaches on it, but then again. It is on a lot of machines, end therefore a perfect target, across platforms. Adobe should be on it’s toes to close these security issues and gain trust in the platform, and then – when iOS settles at a reasonable level, the market will decide if users with the plug-in is more interesting than those without.

… only time will tell.

I have made a short article with an example on how that is done in Flash and ActionScript 3.0. You can read the article at http://www.hjaelpmignu.dk/content/dynamic-call-functions

Det kræver i sig selv ikke meget at regne ud, da en mobil processor ikke har en reel chance mod en flerkernet CPU og dedikeret grafikkort. Hvis du vil dykke ned i nogle af de pæne eksempler kan du f.eks. kigge på:

• http://www.frameratefest.com/
• http://endlessmural.com/
• http://www.chromeexperiments.com/

Fantastiske muligheder for at udfolde sig, tårner sig op i horisonten, men det er netop disse mange muligheder som jeg frygter kan ende i det jeg har valgt at kalde “Det store dyk”.

Fremtidens medier bliver de oversete

I tidligere versioner af HTML. Det er egentlig forkert at skrive tidligere versioner om HTML 4.01 og XHTML, da de ret beset stadig er de aktuelle versioner, men snakken om HTML5 for alt andet til at føles som en fjern fortid. Med HTML4 var alle mobile enheder nye og spændende. Desktop platformen var domineret af Flash indhold, så snart tingene skulle røre sig ud af flækken – der var aldrig nogen reel mulighed for at overføre disse sites til dem der havde fået sig en mobil, der kunne besøge internetsider. Hvad var løsningen? Det var selvfølgelig at teste for om det var en telefon der viste siden og derefter at levere mobiloptimeret indhold. Prøv at besøg sider som cnn.com og du bliver omdirigeret til cnnmobile.com. Besøg tv2.dk og du bliver omdirigeret til deres mobile site. Denne tilgang blev brugt af et par årsager:

1. Der var en begrænset skærmstørrelse
2. Opløsningen var markant lavere
3. Der var ingen fintfølende mus
4. Der var ikke den samme hastighed i forbindelsen

Der var selvfølgelig også en række andre faktorer, med hensyn til muligheder for at bruge tastatur, det personlige forhold til browseren som telefonen giver, men ovenstående er vigtige i denne sammenhæng. Designere lavede deres sites som de plejede og vurderede derefter, hvilket indhold der var relevant på mobiler. Det resulterede i “mobiloptimerede” sites, der kun viste det absolut mest nødvendige. Sites, hvor tekst blev skåret til og billeder beskæret. Alle tiltag blev gjort for at dem med mobiler fik en god og effektiv oplevelse. På det tidspunkt var der mange penge i datatrafik, og mønterne rullede ud af pungen, hvis sitet var for tungt.

Computeren haltede efter for en stund

Med iPhone blev alt ændret. Udvalgte teleoperatorer fik lov til at servicere den – der skulle leveres en dataplan, der gav brugeren mulighed for at bruge 3G netværket med telefonen. Man kan sige at det var en iPod med telefon, men sammenlægningen af disse to ting gjorde at telefonen sparkede alle andre telefoner af banen. Sparkede MP3 afspillere af banen og sparkede smartphones som iPaq o. lign. af banen. Ikke at de andre bare forsvandt, men de kunne ikke konkurrere på specifikationer, og der var ingen af de andre, der havde formået at tvinge teleudbydere i knæ som Apple havde formået. Tilsæt en smule hype (eller spandevis af hype) og iPhones success var en realitet.

Spådomme om computerens endeligt flød, og senere udmeldingen om at Flash ikke kom til iOS, gjorde alt andet end iOS udvikling til perifære interesseområder. Snakken om hvordan det videre forløb (og stadig forløber) er et andet indlæg værdigt, men jeg vil med ovenstående nævne at en smartphone (iPhone) nu skulle have følgende faciliteter:

1. En relativ stor skærmstørrelse
2. En opløsning, der nærmede sig lave opløsninger på computere
3. Muligheden for at trykke på skærmen, med en eller flere fingre
4. Mulighed for både 3G og Wifi, samt effektiv synkronisering

Dette fik computeren til at sakke yderligere bagud i interesse, da muligheden for at tilgå viden overalt, gjorde selv den tyndeste laptop mindre relevant til en lang række opgaver. Derudover er telefonens “altid-tændt” natur, noget som batteritunge laptops ikke kunne forholde sig til. Forbrugsmønsteret ændrede sig lidt før den tid, så der kommer fokus på sociale og personlige relationer, samt deling af billeder og videoklip. Muligheden for at tage et billede, der hvor du var og uploade det så venner kunne se det, med det samme gjorde alt med ledning til et dårligt sats.

De nye browsere

Browserne havde barslet længe med at implementere HTML5, men en iPhone havde muligheden for at starte forfra og definere de muligheder som en smartphone havde når den besøgte et website. Den ville have “The best/full internet experience”. Mange tilhængere af Flash Playeren mente ikke at det var tilfældet, men de havde kun defragmenterede versioner af Flash Lite, der (mildt sagt) ikke performede særligt godt. Der var ikke rigtig nogle modargumenter, så iPhone blev det man kiggede til når man skulle arbejde på mobile platforme. iPhone havde webkit installeret, og der var ingen mulighed for andre udbydere af browsere at byde ind, så den har trukket meget af udviklingen og sørget for at de andre browsere på stationære og bærbare fik travlt.

Vi begynder at dykke

Flere devices kom til. Tablets og Android telefoner blev spyttet ud, og et kapløb om at levere den bedste ydelse, oplevelse og batteritid gik igang. De fleste bryster sig af mulighederne for at overtage computerens rolle … og lidt til. Opløsningen er nu kommet så højt op, og hukommelse og hastighed gør at normale besøg på nettet er en fornøjelse på en iPad (den eneste jeg har at referere til) og smartphones. Derudover matcher de nyeste udgaver af alle de store browsere mange af de HTML5 og CSS3 tiltag, der er under udarbejdele. Udviklingen er faktisk gået så hurtigt, at en ratificering af standarden er rykket fra 2022 til 2014 – det er en ordentlig mundfuld. Der er nu ikke mere den store forskel på de browsere der afvikler på computer og de browsere, der afvikler på Android og iPhone.

Skrid Flash. HTML5 er her

Ønsket med Flash har altid været at kunne udvikle i et miljø og levere interaktive oplevelser på alle platforme tilgængelige. Med Apples afvisning af plug-in’en ligner det en umulig opgave. Apple derimod slår på tromme, for HTML5 og dens muligheder for at overtage den proprietære plug-in. Canvas, Javascript samt CSS3, skal løfte arven og opfylde drømmen om en kode, der kører i alle browsere. Mulighederne og eksemplerne med HTML5 begynder at sprudle og minder delvist om dagene med Macromedia Flash 3, hvor grænser skulle søges og muligheder udforskes. Som browsere bliver udskiftet og begynder at opdatere vil alt dette pionerarbejde begynde at bære frugt. Vi er allerede begyndt at teste for muligheder i den besøgendes browser. Nu tester vi om det er den nyeste, og leverer lidt ekstra – før testede vi om den var for gammel og udelod noget.

“Det store dyk”

Med denne kamp om ligestilling, først fra smartphonen og siden computerens browser, gør at særstatus og hype på mobilen nedtonet og kun nævnt når der kommer nye og hurtigere modeller. Det er der ikke noget galt i, men det der kan ende galt er at designere og udviklere ser mindre fornuft i at lave synderlig specielle tiltag for at optimere andet en layoutet – HTML5 og JavaScript vil fungere på alle større platforme. Det er allerede tydelig at der bliver taget højde for at ændre CSS når browserstørrelsen er over eller under bestemte dimensioner – men hvad med koden og canvas elementet?

Mange af eksemplerne rundt om på nettet der beskæftiger sig med HTML5, canvas og JavaScript, sætter en ære i at det også kører på mobile enheder. De simple målinger jeg har foretaget viser imidlertidig at det er alt andet end tilfredsstillende hastigheder, der præsteres. Der findes dygtige udviklere og interaktive designere, der kan presse de vildeste ting ud af JavaScript og leverer imponerende eksempler på deres kunnen, men der er altså også de andre – dem der er mindre rutineret og leverer meget tung kode. Deres uvidenhed og manglende muligheder for at teste på alle de forskellige mobile enheder der findes, gør at de nok tager deres udvikling for givet eller i værste tilfælde helt glemmer at der findes smartphones. Og hvis de husker at de findes, så husker de måske ikke at folk har givet flere tusinde kroner for dem, og måske stadig ikke kan forsvare at der skal købes ny, lige med det første.

De store sites kommer ganske givet ikke i problemer, men mindre og mellemstore virksomheder, har måske ikke ressourcer til at optimere eller lave deciderede mobiloptimerede sites. Mange vil sidde med en holdning at folk jo kan opdatere deres telefon med en nyere model, eller leve med at det jo trods alt går lidt langsommere på små enheder.

Tilbage til overfladen

Det er selvfølgelig en pessimistisk tankegang, og den prøver også at ridse noget op, der skal gøres en indsats for at undgå. Jeg er af den overbevisning at vi er nød til at skrue vores tanker tilbage til tiden før iPhone – selv om vi udvikler til iPhone. Vi skal have fornemmelsen af at skære billeder til op optimere kode, når vi designere websites. Mine fornemmelser er at der ikke er noget negativt at sige om selve HTML5, CSS3 og jQuery mobile. De kører fantastisk på de fleste modeller jeg har testet. Anderledes anstrengt forhold har jeg til canvas elementet og JavaScripts arbejde på den. Det kan så nemt gå galt med koden, der gør de kreative idéer uløselige på grund af dårlig performance på mobile enheder.

I fremtiden bør vi overveje om indhold er relevant at vise på en tablet eller smartphone. Vi skal søge lidt væk  fra at alt fra desktop skal med, eller at folk har mulighed for at prøve kræfter med de interaktive og programmeringstunge dele af sitet. Styrkeforholdet er skiftet igen, efterhånden som browserforskelle udviskes, og udviklerplatformen (Mac og Windows) er overbefolket af Quad Core processorer og vilde grafikkort.

De nye muligheder med Canvas er mange gange de hurtige maskiner forundt. For kort tid siden var alle øjne på mobilerne. Det er de på mange punkter stadig, men grænsesøgning og de ekstreme eksempler er lukket land for mange mobiler – det bør man huske når eksemplerne rykker fra laboratoriet og ind i produktionshallerne.

Study 1

• Desktop PC: 99.9 FPS (Firefox)
• MacBook Pro: 97 - 98 FPS (Safari)
• iPad (iOS 4.3): 19 - 20 FPS (updated 17/3 – 2011)
• HTC Desire HD (2.2): 15.5 - 16.5 FPS
• Inspire 4G (2.3): ~ 14 FPS (updated 17/3 – 2011)
• HTC Desire (2.2): 14.4 - 14.7 FPS
• iPad 1 (iOS 4.3): 13 – 13.5 FPS (updated 17/3 – 2011)
• iPad 1 (iOS 4.2): 12.4 - 13.3 FPS
• iPhone 4 (iOS 4.3): 9.9 - 10.5 FPS (updated 17/3 – 2011)
• iPhone 4 (iOS 4.2): 9.9 - 10.3 FPS
• iPhone 3GS (iOS 4.2): 9.9 - 10.3 FPS
• HTC Legend: 7.5 - 8.9 FPS

Conclusion 1

Study 2

• Snow flakes was made as a separate class (Flake.as)
• Updated variables, etc so they are strictly typed
• Minor changes in variable names
• Used Flash Player’s flash.sensors.Accelerometer to handle motion

Flake.as

package 
{ 
import flash.display.Sprite; 
import flash.display.BitmapData; 

public class Flake extends Sprite 
{ 
private var canvasWidth; 
private var canvasHeight; 
private var speed: Number; 
private var alpha: Number; 
private var size: Number; 
private var amp: Number; 
private var shift: Number; 
private var range: Number; 

public function Flake (w, h, a, s) 
{ 
this.canvasWidth = w; 
this.canvasHeight = h; 
this.x = 200; 
this.y = Math.random () * -1 * h; 
this.alfa = Math.random () * 0.5 + a; 
this.speed = Math.random (); 
this.size = s - this.speed - this.alfa; 
this.amp = Math.random () * 2; 
this.shift = Math.random () * 25 + 25; 
if (Math.random ()> 0.5) 
{ 
this.shift *= -1; 
} 
this.drift = Math.random () - 0.5; 
draw (); 
} 
public function draw (canvas: BitmapData = null): void 
{ 
this.graphics.beginFill (0xFFFFFF, this.alfa); 
this.graphics.drawCircle (0.0, this.size); 
this.graphics.endFill (); 
} 
public function move (f, wind): void 
{ 
this.y + = this.speed; 
this.x + = Math.cos (f / this.shift) * this.amp + + this.drift wind; 
if (this.y> this.canvasHeight) 
{ 
this.restart (); 
} 
} 
public function restart (): void 
{ 
this.y = -20; 
this.shift = Math.random () * 25 + 25; 
this.x = 200; 
} 
} 
}

MainApp.as

package
{ 
import flash.display.Sprite; 
import flash.display.Bitmap; 
import flash.display.BitmapData; 
import flash.utils.Timer; 
import flash.events.TimerEvent; 
import flash.geom.Rectangle; 
import flash.geom.Matrix; 
import flashx.textLayout.elements.InlineGraphicElement; 
import flash.sensors.Accelerometer; 
import flash.events.AccelerometerEvent; 
import flash.text.TextField; 

public class MainApp extends Sprite 
{ 
private var bgflakes: Array = new Array (); 
private var fgflakes: Array = new Array (); 
private var bgFlakeCount: int = 200; 
private var fgFlakeCount: int = 50; 
private var frame count: int = 0; 
private var wind: int = 0; 
private var dWidth: int; 
private var dHeight: int; 
private var orientX: int = 1; 

private var bgBitmapData: BitmapData; 
private var bgCanvas: Bitmap; 
private var fgBitmapData: BitmapData; 
private var fgCanvas: Bitmap; 
private var timer: Timer; 
private var orientation: Boolean = false; 
private var myAcc: Accelerometer; 

private var filter Strength: int = 20; 
private var frame hours: int = 0; 
private var loading loop: Date = new Date (); 
private var this loop: Date = new Date (); 

private var fps: TextField; 

public function MainApp () 
{ 
init (); 
} 

private function init () 
{ 
dWidth = this.stage.stageWidth; 
dHeight = this.stage.stageHeight; 
bgBitmapData = new BitmapData (dWidth, dHeight, false, 0x000000); 
bgCanvas = new Bitmap (bgBitmapData); 
fgBitmapData = new BitmapData (dWidth, dHeight, true, 0xFF0000); 
fgCanvas = new Bitmap (fgBitmapData); 
addChild (bgCanvas); 
addChild (fgCanvas); 

fps = new TextField (); 
addChild (fps); 
fps.textColor = 0xFFFFFF; 

was i = 0; 
for (i = 0; i { 
bgflakes.push (New Flake (bgCanvas.width, bgCanvas.height, 0,3)); 
} 
for (i = 0; i { 
fgflakes.push (New Flake (fgCanvas.width, fgCanvas.height, 0.2,4)); 
} 
hours = new Timer (10); 
timer.addEventListener (TimerEvent.TIMER, draw); 
timer.start (); 

if (Accelerometer.isSupported) 
{ 
orientation = true; 
myAcc = new Accelerometer (); 
myAcc.addEventListener (AccelerometerEvent.UPDATE, onAccUpdate); 
} 
} 

private function onAccUpdate (e: AccelerometerEvent): void 
{ 
orientX = e.accelerationX; 
} 

private function setWind () 
{ 
if (! orientation) 
{ 
was mx: Number = mouseX - dWidth / 2; 
wind = (mx / dWidth) * 3; 
} 
lodging 
{ 
Wind = Number (orientX) * 3; 
} 
if (! wind) 
{ 
wind = 0; 
} 
} 

private function draw (e: Event hours) 
{ 
frame count + = 1; 

bgBitmapData.fillRect (new Rectangle (0.0, dWidth, dHeight), 0x000000); 
fgBitmapData = new BitmapData (dWidth, dHeight, true, 0xFF0000); 
setWind (); 
was: int = 0; 
for (i = 0; i { 
bgflakes [i]. move (frame count, wind); 

bgBitmapData.draw (bgflakes [i], new Matrix (1,0,0,1, bgflakes [i]. x, bgflakes [i]. y)); 
} 
for (i = 0; i { 
fgflakes [i]. move (frame count, wind); 

fgBitmapData.draw (bgflakes [i]); 
} 

was this frame hours: int = (Number (this loop = new Date ())) - Number (last loop); 
Frame hour + = (this frame - time frame hours) / filter strength; 
load loop = this loop; 
fps.text = (1000/frameTime). toFixed (1) + "fps"; 
} 
} 
}

Results 2

• Dersire HD (2.2): Canvas ~ 16.5 FPS and Flash 10.1 ~ 24.2 FPS
• Inspire 4G (2.3): Canvas ~ 14 FPS and Flash 10.1 ~ 22 FPS (updated 17/3 – 2011)
• HTC Desire (2.2): Canvas ~ 14.5 FPS and Flash 10.1 21.7 to 23.5 FPS

Conclusion

• How long the phone has been switched on.
• Is it connected to the charger.
• Programs running in the background.
• Video documentation of test

• http://eksempler.hjaelpmignu.dk/flash/actionscript/snowflake/snowcanvas.html (canvas)
• http://eksempler.hjaelpmignu.dk/flash/actionscript/snowflake/snowFLA.html (Flash)

• https://gist.github.com/716215 (canvas)
• http://eksempler.hjaelpmignu.dk/flash/actionscript/snowflake/snowFLA.zip (Flash)
• http://stackoverflow.com/questions/4787431/check-fps-in-js (Frame Counter)

Forsøg 1

• Desktop PC: 99.9 FPS (Firefox)
• MacBook Pro: 97 - 98 FPS (Safari)
• iPad (iOS 4.3): 19 - 20 FPS (opdateret 17/3 – 2011)
• HTC Desire HD (2.2): 15.5 - 16.5 FPS
• Inspire 4G (2.3): ~ 14 FPS (opdateret 17/3 – 2011)
• HTC Desire (2.2): 14.4 - 14.7 FPS
• iPad 1 (iOS 4.3): 13 – 13.5 FPS (opdateret 17/3 – 2011)
• iPad 1 (iOS 4.2): 12.4 - 13.3 FPS
• iPhone 4 (iOS 4.3): 9.9 - 10.5 FPS (opdateret 17/3 – 2011)
• iPhone 4 (iOS 4.2): 9.9 - 10.3 FPS
• iPhone 3GS (iOS 4.2): 9.9 - 10.3 FPS
• HTC Legend: 7.5 - 8.9 FPS

Konklusion

• Det er klart at fornemme at begge computere rammer toppen. Den bærbare Mac har smidt en frame eller to i testen, men vil sikkert ramme 100 FPS i en anden. Selvfølgelig kan den ikke løbe fra et Quadro grafikkort, men klart er det at der er rigelig overskud til at løse opgaven.
• iOS maskinerne (iPad 1 og iPhone 4) har en hård tid, med at producere frames til canvas elementet. I gennemsnit ligger de på lidt over 10 FPS.
• Desire HD ligger en smule højere. Ikke meget, men alligevel nok til at det må betegnes som en bedre afvikling.

Forsøg 2

• Snefnug lavet som en selvstændig klasse (Flake.as)
• Har opdateret variabler osv så de er strict typed
• Mindre ændringer i variabel navne
• Brugt Flash Playerens flash.sensors.Accelerometer til at håndtere bevægelse

package
{
import flash.display.Sprite;
import flash.display.BitmapData;

public class Flake extends Sprite
{
private var canvasWidth;
private var canvasHeight;
private var speed:Number;
private var alfa:Number;
private var size:Number;
private var amp:Number;
private var shift:Number;
private var drift:Number;

public function Flake(w,h,a,s)
{
this.canvasWidth = w;
this.canvasHeight = h;
this.x = 200;
this.y = Math.random() * -1 * h;
this.alfa = Math.random() * 0.5 + a;
this.speed = Math.random();
this.size = s - this.speed - this.alfa;
this.amp = Math.random() * 2;
this.shift = Math.random() * 25 + 25;
if (Math.random() > 0.5)
{
this.shift *=  -1;
}
this.drift = Math.random() - 0.5;
draw();
}
public function draw(canvas:BitmapData = null):void
{
this.graphics.beginFill(0xFFFFFF,this.alfa);
this.graphics.drawCircle(0,0,this.size);
this.graphics.endFill();
}
public function move(f,wind):void
{
this.y +=  this.speed;
this.x +=  Math.cos(f / this.shift) * this.amp + this.drift + wind;
if (this.y > this.canvasHeight)
{
this.restart();
}
}
public function restart():void
{
this.y = -20;
this.shift = Math.random() * 25 + 25;
this.x = 200;
}
}
}

package
{
import flash.display.Sprite;
import flash.display.Bitmap;
import flash.display.BitmapData;
import flash.utils.Timer;
import flash.events.TimerEvent;
import flash.geom.Rectangle;
import flash.geom.Matrix;
import flashx.textLayout.elements.InlineGraphicElement;
import flash.sensors.Accelerometer;
import flash.events.AccelerometerEvent;
import flash.text.TextField;

public class MainApp extends Sprite
{
private var bgflakes:Array = new Array();
private var fgflakes:Array = new Array();
private var bgFlakeCount:int = 200;
private var fgFlakeCount:int = 50;
private var frameCount:int = 0;
private var wind:int = 0;
private var dWidth:int;
private var dHeight:int;
private var orientX:int = 1;

private var bgBitmapData:BitmapData;
private var bgCanvas:Bitmap;
private var fgBitmapData:BitmapData;
private var fgCanvas:Bitmap;
private var timer:Timer;
private var orientation:Boolean = false;
private var myAcc:Accelerometer;

private var filterStrength:int = 20;
private var frameTime:int = 0;
private var lastLoop:Date = new Date();
private var thisLoop:Date = new Date();

private var fps:TextField;

public function MainApp()
{
init();
}

private function init()
{
dWidth = this.stage.stageWidth;
dHeight = this.stage.stageHeight;
bgBitmapData = new BitmapData(dWidth,dHeight,false,0x000000);
bgCanvas = new Bitmap(bgBitmapData);
fgBitmapData = new BitmapData(dWidth,dHeight,true,0xFF0000);
fgCanvas = new Bitmap(fgBitmapData);
addChild(bgCanvas);
addChild(fgCanvas);

fps = new TextField();
addChild(fps);
fps.textColor = 0xFFFFFF;

var i = 0;
for (i=0; i 			{
bgflakes.push(new Flake(bgCanvas.width, bgCanvas.height,0,3));
}
for (i=0; i 			{
fgflakes.push(new Flake(fgCanvas.width, fgCanvas.height,0.2,4));
}
timer = new Timer(10);
timer.addEventListener(TimerEvent.TIMER, draw);
timer.start();

if (Accelerometer.isSupported)
{
orientation = true;
myAcc = new Accelerometer();
myAcc.addEventListener(AccelerometerEvent.UPDATE, onAccUpdate);
}
}

private function onAccUpdate(e:AccelerometerEvent):void
{
orientX = e.accelerationX;
}

private function setWind()
{
if (! orientation)
{
var mx:Number = mouseX - dWidth / 2;
wind = (mx/dWidth)*3;
}
else
{
wind = Number(orientX) * 3;
}
if (! wind)
{
wind = 0;
}
}

private function draw(e:TimerEvent)
{
frameCount +=  1;

bgBitmapData.fillRect(new Rectangle(0,0,dWidth, dHeight),0x000000);
fgBitmapData = new BitmapData(dWidth,dHeight,true,0xFF0000);
setWind();
var i:int = 0;
for (i=0; i 			{
bgflakes[i].move(frameCount, wind);

bgBitmapData.draw(bgflakes[i], new Matrix(1,0,0,1,bgflakes[i].x, bgflakes[i].y));
}
for (i=0; i 			{
fgflakes[i].move(frameCount, wind);

fgBitmapData.draw(bgflakes[i]);
}

var thisFrameTime:int = (Number(thisLoop=new Date())) - Number(lastLoop);
frameTime+= (thisFrameTime - frameTime) / filterStrength;
lastLoop = thisLoop;
fps.text = (1000/frameTime).toFixed(1) + " fps";
}
}
}

En udvikler (Jesper Storm Bache) blandede sig i en diskussion på Adobe Forums (http://forums.adobe.com/thread/752602) og er kommet med et hack, der løser problematikken indtil der kommer en permanent løsning fra Apple.

Vær lige opmærksom på at denne hack går ind og retter i selve systemet, og der er ingen garanti for at det ikke har indvirkning på andre applikationers måde at fungere på … er dog ikke bekendt med nogle bivirkninger.

Du kan hente hack’en på http://www.bache.name/download/osx/10_6_5%20keyboard%20hack.dmg

Hvad er en Community Champion?

Der er lidt meget glasur på titlen, og det lyder nok voldsommere end det er. Adobes egen beskrivelse, nagler de vigtigste pointer meget godt og betyder i al sin enkelthed at jeg skal blive ved med at gøre som jeg altid har gjort … snakke løs Hvad enten der er tale om møder i AUGOD (Den danske Adobe Brugergruppe), diverse events og produktlanceringer til folks sporadiske spørgsmål og lyst til at få opklaret (eller høre min version af) interaktive platformes mysterier og kringelkroge.

Så er du vel en rigtig Adobe lover?

det kan man da godt kalde mig. Men det er jeg kun fordi jeg elsker de værktøjer der er med til at skabe de flotteste og mest innovative løsninger online, såvel som offline. Kærligheden strækker sig over alle produkterne og de muligheder de giver designere, men min kærlighed ligger også hos andre produkter fra andre udbydere, samt åbne standarder som HTML5. En stor del af mit virke i 2011 (under denne titel) vil nok være at overbevise folk om at Flash/HTML5 problematikken ikke er en enten-eller løsning, men en både-og, med forskellige teknologier til at løse forskellige typer af opgaver.

Endelig vil noget at tiden blive brugt på http://www.hjaelpmignu.dk/ hvor du kan få svar på de spørgsmål du end måtte have til programmer og teknologier forbundet med Creative Suite. Fyr løs, og svar eventuelt på andres problemer, hvis du har en løsning.

På gensyn derude

Dette indlæg er egentlig bare et heads up, på at jeg stadig er på, og I er mere end velkommen til at kontakte mig her, på www.hjaelpmignu.dk, eller følge mig på twitter (@ockley), så skal jeg se hvad jeg kan gøre for dig

Med venlig hilsen

Karsten “ockley” Vestergaard

Jeg er selvfølgelig meget optaget af mulighederne på Flash Platformen, fordi det er en platform der byder på et utal af muligheder for at udtrykke sig og det gør det til et spændende udgangspunkt til projekter. Jeg er lige så optaget af HTML platformen og dermed også hele HTML5 “brandet” (inkl. CSS og JavaScript) da det bringer nye muligheder for at layoute oplevelser og kommunikere effektivt direkte i en browser.

Hvad skal Flash til for?

Flash har altid haft til opgave at løse interaktive og dynamiske opgaver, som HTML ikke kunne løfte selv – sådan er livet som plugin. Det gælder ikke bare Flash, men alt fra Quicktime player til video og over til Unitys web player til 3D indhold. HTML har altid været (og vil forhåbentlig altid være) et opmærkningssprog, som kan bruges til at definere indholdet på et website. Det bliver efterfølgende knyttet til et stylesheet, der definerer hvordan det skal se ud i en browser. JavaScript har endelig kunne forholde sig intelligent til brugerens måde at agere og derved variere over eller reagere på dele af indholdet. Der er mange flere facetter, men som grov skitse, går det nok an.

Problemerne er opstået, da Flash har kunnet løfte mange af de layoutmæssige og interaktive muligheder og samtidig været overlegen, uden sammenligning, når det gjaldt at integrere dynamik, animation, lyd, interaktion osv. Det har gjort det nemt for mange at bruge flash som fundament for hele sitet og ikke bare en plugin, der skal løse en opgave på et website. Ulempen ved dette er de navigationsmæssige udfordringer, søgemaskineoptimering og det faktum, at der skal meget til for at erstatte den grundrendering som er givet fra browseren

Der skal være en god bund

Den vigtigste opgave for HTML er at markere indholdet på et site. Du bruger et h-tag til overskriver, img-tag til billede osv. De nye tags i html5 giver øget mulighed for at definere om der er tale om navigation, artiker, video, lyd osv. Dette er et stort fremskridt, da det derved er muligt at forholde sig til den rene information og trække informationer på tværs af sites. Skal jeg bruge indholdet fra en artikel, kan jeg nemt fangle et <article> tag og vide at al relevant infromation bliver flyttet med. Dette vil lette presset på <div> tags (dividers) og gøre at de får arbejdsro til at opdele i forhold til layout og ikke indhold.

Gøgeungen skal væk

En af de største irritationsmomenter ved Flash er, at designere og udviklere har været fristet af de frie layoutmuligheder med Adobe Flash Professional. Følelsen af at kunne styre layoutet 100% uden at tænke på bokse og CSS har gjort at mange sites udelukkende er lavet med Flash. Lige så snart at <body> tag’et er kommet på banen, har dets eneste opgave været at vise én kæmpe swf-fil og absolut intet søgebart html … hvis jeg var html, ville jeg også blive stik tosset.

 Designere skal, endnu mere i fremtiden, lære at bruge det bedste værktøj tilat løse opgaven. Der skal ikke laves Flash-sites fordi det er nemt – der skal laves Flash-sites fordi det er det rigtige at gøre. Hvis en designløsning umiddelbart kan lade sig gøre med html5 og css3 bør og skal den laves med disse teknologier – alt andet vil være et skridt ned at stigen.

Du vil i fremtiden se flere veldesignede html5 løsninger, der løser opgaver og udtrykker sig på samme måde som du er vant til at se produceret med Flash idag.

Hvad med Javascript og canvas

Når snakken er faldet på html5 som en Flash-killer, har de fleste egentlig ment at Javascript, med muligheden for at tilgå <canvas> tag’et har givet browseren et værktøj, der stort set kan løse alle opgaver som Flash har stået for. Jeg vil ikke gå i detaljer med teknikken, men der er en del der skal løses før den metode kommer i nærheden af Flash Playeren. Eksempler som jeg lige kan komme på er:

• Performance. Der er stor forskel på hvor godt JS afvikles på de forskellige platforme
• Stabilitet. Der er forskel på hvordan JS afvikles på de enkelte platforme
• Tilgang til Virtuel Motor. En oversigt på http://en.wikipedia.org/wiki/JavaScript_engine viser, hvor mange forskellige motorer, der findes til browserne
• Opdateringsgrad. Flash Player’en har mulighed for at opdatere sig jævnligt og implementere nye tiltag. Standarder er ofte årevis om at blive enige
• Er ikke en plug-in. Fordi Javascript ikke er en plug-in kan du ikke skræddersy din oplevelse på tværs af browsere, men må tilpasse den til målgruppen.

Det er ikke fordi oventstående kun er af det onde, men det er nogle af de faktorer, der gør at der stadig er behov for properitære plug-ins der løfter de umiddelbare behov der stilles, indtil en standard kan defineres – en standard, der ofte er fremkommet efter at enkelte udviklere har præsenteret deres løsning på et problem. F.eks. er WebGL ved at samle sig efter år, men udbrydergrupper og konsollideringer. Det er nu, efter omkring 5 år, ved at nå til et punkt, hvor den kan bruges i nyere browsere (mangler dog stadig Internet Explorer). Der er ikke noget der tyder på at det vil gå hurtigere, når det “næste nye” bliver opfundet, hvilket giver nogle ret lange svartider på spørgsmål om innovation.

Jeg ser dog en stor fremtid i at JavaScript kommer til at servicere HTML5 og sørge for at logikken, der skal præsentere HTML elementerne bliver varetaget. Formvalidering, jQuery bliver fast inventar i fremtiden. Jeg har sværere ved at se Javascript skulle løse opgaver der ikke er bundet til html – ikke fordi det ikke er teknisk muligt, men simpelhen fordi jeg tror det bliver for bøvlet at udvikle og bliver afviklet for dårligt i browseren.

Endelig ser jeg stort set alle reklamer i fremtiden udviklet i HTML/CSS og JavaScript, da det vil give et bredere marked og en bedre integration i forhold til kontekst. Det bliver sværere for ad-blockers i fremtiden at adskille indholdet, og man kunne i sit stille sind have håbet på et <advertisement> tag i specifikationerne (selv om den nok ikke ville blive brugt)

Hvornår kan man bruge det

Selvom de mere skeptiske siger i 2022, er det min klare opfattelse at du skal bruge det, når en overvejende del at brugerne understøtter det. Du skal selvfølgelig være opmærksom på mulighederne for at præsentere indholdet i browsere der ikke understøtter det, men der er ikke nogen grund til at udelade alt det nye, fordi 15% af de besøgende ikke er opdateret (der er typer at sites, der ikke kan være så frimodige)

Hvis du vil have en god oversigt kan du kigge på http://findmebyip.com/litmus der under emner viser en fin gennemgang af alle de nye tags og script-muligheder. Det er også interessant læsning, når du kigger på video og lyd understøttelse i de forskellige browser og mulighederne på Mac og Win … der er stadig lidt, der skal masseres på plads.

Der findes også en oversigt på https://netaverages.adobe.com/en-us/index.html (login med dit Adobe ID) der viser en procentvis dækning af udbredelsen (både desktop og mobile) og give en pegepind for, hvordan mulighederne for implementation er. Det vigtigste at huske på (de næste mange år) er at tilbyde sekundære løsninger til browsere der ikke understøtter de nye selectors.

Kan jeg lære det

Det er ikke et spørgsmål om du kan … du skal. Fremtidens interaktive designer skal være god til både Flash og HTML – en af delene er ikke nok. Der vil i de næste år komme værktøjer der hjælper. Opdateringer af eksisterende programmer som Adobe Dreamweaver 11.0.3 og Adobe Illustrator HTML5 pack er allerede igang med at løfte noget af byrden, og programmer som Edge vil tilbyde helt nye muligheder for at arbejde med HTML5 og de omkringliggende teknologier. Der er allerede en masse sites der giver sig i kast med mulighederne, men et par at starte med kunne være:

• http://www.html5rocks.com/
• http://html5tutorial.net/
• http://www.w3schools.com/html5/default.asp
• http://webdesignledger.com/tutorials/15-useful-html5-tutorials-and-cheat-sheets
• http://www.webmonkey.com/2010/02/building_web_pages_with_html_5/
• http://www.adobe.com/devnet/dreamweaver/articles/dw_html5_pt1.html
• http://www.adobe.com/devnet/dreamweaver/articles/introducing_new_css_layouts.html

Kan jeg få hjælp

Selvfølgelig kan du det. Der er mange sites, hvor artiklerne tillader kommentarer under. De virker flinke til at svare på spørgsmål. Ellers er der altid vores eget Dreamweaver forum. God fornøjelse med HTML5

Farvel, betyder  at fare vel

Når I nu har pustet ud og holdt en velfortjent sommerferie, går det langsomt men sikkert op for jer at der ikke er mere skolegang, og I rent faktisk er “udlært” og flyvefærdige. Mit farvel til jer er for at minde jer om at alle tre år har været begivenhedsrige og lærerige, for jer såvel som mig. Jeg smider lige et par sidste ord efter jer her på min blog, hvor I ikke umiddelbart kan svare igen

De farvel I får herfra er ikke et ønske om ikke at se jer igen, men et håb om at det må gå jer godt på den fremtidige rejse. Vi lever dog i en verden, hvor det ikke sker automatisk. Nuvel, du kan blive hjulpet af en rig tante, eller en far der allerede er i branchen, men den kreative kraft, der blusser i jer, kan ikke vedligeholdes af held og klap på skulderen – så ender i med at stå og snakke om det store projekt I lavede for to år siden. Derfor, lige et par nedslagspunkter.

Det tog tre år

Selvom det sidste I har lært ofte har været det mest komplekse, er den viden og de muligheder bygget på et fundament af grundlæggende færdigheder. Hvor interessante de senere års projekter end har været, vil de første moduler kunne bruges som byggesten til andre fremtidige udforskninger – den viden må aldrig forstås som implicit. Viden om typografi, gestaltlove, formgivning, kommunikation osv. skal videreudvikles og udforskes som selvstændige projekter. Designgrudlaget ændrer sig konstant, som tektoniske plader, og hvis du ikke forholder dig opdateret til dem, vil dine løsninger ramme skævt få år ude i fremtiden, og i vil stå som en Kolos på lerfødder.

Du kan lukke af for fremtiden, men du kan ikke lukke fremtiden ned

Det er så fristende at sætte sig ind i en kasse, med det man nu engang kan. Du vil kunne bruge timer på at diskutere og retfærdiggøre, hvorfor du har ret, som nyudlært. Men hvis du lukker af for fremtiden, vil du ende som en dinosauer der ikke ved den er uddød. Du vil stå med en kuffert fuld af kuglepenne og skælde ud på folk, fordi de sender e-mail i stedet for breve. Om du vil det eller ej, så er der fuld fart på lokomotivet, og som interaktiv designer har du plads i den forreste vogn. Det er en sjov rejse, men det kan god være frustrerende at man ikke kan slappe af i længere tid af gangen. På linjen for interaktivt design på Mediehøjskolen, skal vi hele tiden korrigere og kan ikke med sikkerhed fortælle de nye studerende, hvordan deres tredje år forløber. Den korrektion har vi foretaget ind til nu … nu, hvor du er flyttet hjemmefra,  skal du selv købe toiletpapir

Den nye viden kan ikke fås intravenøs

Jeg vil ikke garantere at det ikke kommer til at ske, men som tingene er i den umiddelbare fremtid, er der ingen kloge ord på sprøjte. Du kan ikke sætte et “Joshua Davis plaster” på og få en fornemmelse af hvilke strømninger han rører frem i sin gryde. Kun med et øje der ser og et øre der hører, vil du tilegne dig færdighederne til at skabe. Kravene til interaktive designere er derudover noget skrappere, da jeres værktøjer er lidt mere komplekse end et penalhus. Mange af de ting I må sætte jer ind i, er eksperimenterende, nogle er ikke synlige, og en del af de tungeste er endda kun delelementer til en simpel løsning. Hvor den grundlæggende værktøjskasses præmis kun flyttes langsom, vil det der adskiller jer fra andre designere, være viden og forståelse for interaktion, som kun flygtigt er relevant, for derefter at blive generel og ende som forældet fordi ny opdagelser har gjort det irrelevant eller direkte forkert.

Det digitale spejl, forvrænger – derfor behøver du ikke at vrænge ansigt

Når man er interaktiv designer, er man nød til at simulere stoflighed. Der er ikke noget på Internettet der er ægte … ikke engang Internettet. Du lever af at designe oplevelser i et kunstigt rum, kun afbrudt af ormehuller med videokonference og IP-telefoni, som nærmeste kæde til den virkelige verden omkring. Intet er uforgængeligt – her er ingen pyramider eller Versailles slot. Billederne fra den virkelige verden er blevet lavet til nuller og et-taller og viser sig kun som vi forventer, fordi vores egne opsatte regler bliver overholdt. Vi ser kampagner der behandler virkeligheden til egen vinding og personer der sletter sig selv, eller manipulerer med data for at gengive en anden sandhed. Det store problem er at vi i større grad søger ind i en kunstig verden for at finde viden om, hvordan den virkelige verden er bygget op. Når I laver interaktive løsninger er i med til at vedligeholde den kunstige verden, og I skal, mere end mange andre, pleje forholdet mellem Internettet og mennesket. Med styrke kommer ansvar, og I skal altid være klar over den magt i har overfor uvidende bruger, der naivt tager det de ser for gode varer.

I former en fremtid til en samtid

I forhold til nettet, er verden kun i “fire dimensioner”. Superstrengsteoretikere bedes se bort fra denne uforskammede simplificering. Hver eneste nedslag på nettet, indeholder en dybde samtidig med den visuelle flade. Ud over dette, har den også en designet tidsfornemmelse og kronologi. På den ene side har den søgemaskinernes evige jagt på at cache indhold på større og større lagermedier, så vi kan finde ting fra en svunden, digital fortid, men også den indlejrede pulsfornemmelse i animationer, lyd og filmklip som selvstændige processer på en statisk flade. Når I designer noget, er det første gang det er på nettet. I smider endnu en “bold i spil” som ikke har været der før – ny adresse, ny grafik, måske nye principper. Det der er fremtid for nettet, er inde i jeres hoveder,og bliver først til samtid, når det har materialiseret sig. Da alle er afhængige af at søge indhold, inspiration og ny viden på nettet, er det vigtigt at dem der leverer nye oplevelser og viden, har en forståelse af at de er de første i kæden.

Lad vær med at tage kvælertag på noget du er ved at give kunstigt åndedræt

Når i designer og udvikler koncepter, så lad dem leve - hvis ikke i virkelige projekter, så i det mindste i en sandkasse hjemme hos jer selv. Du kan få en vane at tænke “Nej, ikke alligevel,” midt i processen. Det er gift for jeres pionerånd – hvis du laver brunkager, smider du ikke dejen væk, hvis formen standser noget ud der ikke helt ligner – i ovnen med den! Hvis ikke, så ender du med at acceptere halvfærdige og kuldsejlede projekter, og så er det velkommen til umulighedernes land!

Det er først når du holder hovedet i vater, at du laver noget der virkelig batter!

Tro på dig selv. Lad være med at tale ned til andre, eller dukke dig for selvfede i miljøet. Problemet med ikke at kigge lige ud er at du misser horisonten, og det er den du skal bruge til at orientere dig. Du lever af at være til, i forhold til omverden – en omverden der er gennemsyret af dit netværk. Hvis du, i din egen succes, glemmer at være i øjenhøjde med andre, knækker kæden. En kæde der i den professionelle del af netværket i forvejen kan være lidt tynd. Dem du møder på vej op, ser du igen på vej ned … det vil være så rart at lande blødt, når man tænker på hvor mange op og nedture man skal tage i et helt liv. Omvendt, må du aldrig lade dig kue af andres holdning til dine værker. Du må modtage kritik … du skal modtage kritik! Men der er rigeligt med folk, der har nemmere ved at kritisere udaf end indad. Jeg kan ikke direkte fortælle hvordan I kan kende forskel, men det har tit noget at gøre med lydniveauet – de rigtig rige, fortæller sjældent om deres penge.

Mod det uendelige … univers!

Når det så er sagt (det var nok), så har I den mest interessante fremtid foran jer. I kan levere og udbygge på eksisterende komponenter, eller I kan udforske og udvikle uopdyrket land. Med de muligheder og færdigheder I besidder, kan intet stoppe jer. Tænk både kommercielt og ikke kommercielt. Hvis man ikke forholder sig til pengene, er en del af de kommercielle projekter de kedeligste. Nye uafprøvede ideer finder sjældent indpas der. Det må dog ikke afholde jer fra at eksperimentere og lave “proof of concept” så I kan være med til at designe fremtidens interaktive design, i stedet for at vedligeholde andres opfundne regler.

Og med dette, må i fare vel. Kom tilbage og fortæl de næste studerende om jeres landvindinger, når I står og glimter.

/ockley