Have you ever wondered, how you could use a String to decide, which function to be called. You could go so far to let the user enter the function name in an input field and call a function by that name, if it exists.
If you are using Adobe software to create design for print production or receive documents as a print provider, this guide is a must read for you. All relevant info on color handling, trapping, handling transparency and effects are there. Info on Job Definition Format (JDF) and how to print and edit PDF files is there. Best practise – what and how to expand objects in Illustrator are there. The Forensic Tools in the various software is explained.
All in all. 138 pages of action packed printing info available. Questions to the guide are welcomed in the forums
PANTONE colors, where art thou? I was asked a question in the forums about the lack of a specific color (PANTONE color 7692 U) in the forums. I started to look in InDesign, where the question was posted, but no avail. Same result in the other programs in Adobe Creative Suite. A quick look at PANTONE color finder proved that the color was there alright. But then, why do newer versions of Adobe InDesign and other not have the current colors in their color book.
After trawling for info in forums, I found that there where a update called PANTONE® PLUS Digital Libraries for Adobe which should update the Creative Suite software to contain the newest swatches. I tried to update via the installers, but it didn’t make any of the files show up in the programs – It looks like it stopped somewhere around CS3. As a result, I ended up extracting all the files manually, organizing them into folders, and them copied the to the respective preset-folders. Can anyone enlighten me: Why isn’t these files part of the standard updates? PANTONE colors is relative important as a reference color library for many offline designers and print providers.
I collected all the files in a all the files so you can do the update manually. Instructions on where to put them as well as the original tech-note is also included.
I hope that this will close the gap until an official release is given from PANTONE or Adobe. Please, comment any feedback on errors so the files can be updated if needed.
Link to zip-archive(Updated to v1.1.1 date: 11/10/11)
UPDATE v1.1: I have updated the files, so they also contains colors for QuarkXpress – taken from http://www.pantone.com/pages/Pantone/Pantone.aspx?pg=20727. I do not have Quark myself, but believe that they should be placed in a folder called Color inside the app-folder
UPDATE v1.1.1: I have placed all nine aco-files in the Adobe Photoshop folder, and removed the acb-files.
By now, it should be clear that there is no resistance towards HTML5 and JavaScript from Adobes point of view. We have seen the HTML5 pack for Dreamweaver and Illustrator. I believe they did it as a proof of their true interest in the technologies surrounding the Internet. In addition to that, they didn’t wan’t designers to look elsewhere for tools to design and develop HTML content. Actually, Adobe has always paid interest in these technologies – it would be odd to have the most famous HTML-layout program and not being happy, when it evolves and taken advantage of it.
The update to CS5.5 gave further proof of a dedication toward mobile devices and open standards. We where shown massive update when it comes to mobile development. iOS had to catch up on the possibilities and performance that previously was introduced for the Android platform. Flash Builder and Flash CS5.5 took care of that. HTML5 and jQuery was fully incorporated in Dreamweaver CS5.5 in addition with a lot of other stuff, to bring even more effective workflows to designers trying to approach these new devices and technologies.
But then what … was that it. No, Adobe has an underlying piece of software under the hood. They had already shown that it is possible to take a Flash timeline animation and make it HTML5 compliant. It turned into a tool named Wallaby (working title) – it’s experimental but with a lot of potential for Flash users to leverage on their existing skills.
Aside of that, a brand new program with the working title Adobe Edge is in the making. We have seen technology previews of a prototyping tool, but it has grown to be a fully featured animation tool for HTML5 pages. You can se a short walkthrough where an image and svg file is animated for a start. Afterwards a fully designed HTML page is opened and given transitions to gently introduce the page elements. Everything is layered on top of the existing design, so you wont break the layout when collaborating with other designers.
I really like the way they managed to make the timeline integrate with the DOM elemements. We may end up having an animation tool for pure HTML designers that can match features used by the Flash timeline animators. The only thing we need to see is how well it will be integrated with programming logics and JS-development … maybe Dramweaver is up for another spin.
You can be notified about the public beta at http://www.adobe.com/go/edgepreview_notify and read more about the program at http://labs.adobe.com/technologies/edge/
Jeg har i den senere tid med interesse fulgt mange af de udviklinger som HTML5 og canvas elementet har bragt. Små ting som www.radiohead.com bringer stimulerende effekter og kører fint på mobile enheder. Problemet er at det er mere reglen end undtagelsen at performance på mobile enheder afviger markant fra laptop/desktop oplevelsen.
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å:
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:
Der var en begrænset skærmstørrelse
Opløsningen var markant lavere
Der var ingen fintfølende mus
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:
En relativ stor skærmstørrelse
En opløsning, der nærmede sig lave opløsninger på computere
Muligheden for at trykke på skærmen, med en eller flere fingre
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.
This post is an examination of the performance provided by JavaScript and the canvas HTML element, and its role on mobile platforms in the future. The inspiration for this post came when I stumpled on Water Ripple Canvas by Almer Thies. It was running without problems (with Canvas: 20fps and Water: 30 fps) on my computer but was frighteningly slow with a max of 0.5 fps on my iPhone 4 (yep. A half frame per second!). I therefore found it relevant to produce a comparable piece of code that could run on the canvas element and easily port to Flash, so I could get an idea of how well each technology performed.
It is not a secret that I’m fond of the Adobe Flash Player, and have always believed that Apples excommunication of the player due performance issues had no standing ground, in light of the present alternatives. But HTML5 is a promising technology, that takes the job as website maker seriously again, and that may result in Flash being able to focus on it plug-in nature again, and help lift sites up above the tomorrows standard sites. The most important topic to discuss is: what should happen when our mobile visits a website in the month/years to come. Not distinguishing between mobile and desktop would lead to sluggish performance on mobiles when canvas gets integrated in eager designers creative solutions – a future that I predict as the “big dip”, in the worst cases.
When I dropped the restriction the PC actually easily spun on over 200 FPS, but the intention here is not to benchmark in the high end, but find a relationship in the “low end” and a relative measurement to a standard machine. PC as well as Mac differ so much on hardware as well as range of browsers, it will not contribute anything positive to uncover all facets.
Conclusion 1
It is evident that both computers frame rates hits the ceiling. The portable Mac has thrown a frame or two in the test, but will probably do 100 FPS in a another run, or with another browser. Of course it cannot run from a Quadro graphics card, but it’s clearly capable of running the test. iOS machines (iPad 1, iPhone 3GS and iPhone 4) has a hard time, to produce frames for the canvas element. On average, they just over 10 FPS.
Desire HD is a bit higher. Not much, but still enough that it should be designated as a better settlement. Lowest is the HTC Legend, with around 8 fps.
Study 2
The second test was made to compare performance between javascripts work on the canvas, and Flash Player’s work with the BitmapData class. The technique used for both are very similar and it will give the best basis for comparison, and minimal editing of the code. You can see an example at http://eksempler.hjaelpmignu.dk/flash/actionscript/snowflake/snowFLA.html
The following changes have been made from the original code:
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";
}
}
}
Comments on Code
I have kept the draw () inside the Flake class and draw the flakes with graphics.drawCircle () to keep the code across the examples as similar as possible. The transfer of values on canvas size, etc. are also retained in the Flash version is also preserved. Finally, I used Bitmap () and BitmapData () to simulate the properties used on the canvas element.
Results 2
With mobile units, that is capable of running Flash Player 10.1 and canvas, I try to measure them against each other. Not as a battle, favoring one technology, for the future (I think) belongs to them both. It’s more an attempt to find out how bad Flash performs and supporters of the canvas as a “Flash Killer” has some back support. I’ll update as I stumple on different phones/tablets on my way:
Dersire HD (2.2): Canvas ~ 16.5 FPS and Flash 10.1 ~ 24.2 FPS
HTC Desire (2.2): Canvas ~ 14.5 FPS and Flash 10.1 21.7 to 23.5 FPS
You are welcome to submit own measurements
Conclusion
I get a relatively higher frame rate when running the test in Flash Player on Android than if I the canvas version. I wasn’t able to turn the relationship between the numbers on my phone, not even leveling the difference in frame rate. I therefore think that the user will have a better experience of this experiment in a flash player, than with a canvas version. It is important to remember that the canvas element’s ability to deliver, do not need to inflict on the general view on HTML5 and CSS3. My feeling is that CSS3 has a fairly good performance on the mobile devices, perhaps because of their predictable nature, but I haven’t investigated that topic yet.
Finally, I have not taken installed software on the devices into account. It may be relevant in a recount to look at parameters such as:
How long the phone has been switched on.
Is it connected to the charger.
Programs running in the background.
Video documentation of test
My point here is to get some numbers up in the air, and a comparison of material playd on mobile devices. Please reply with the results of your own measurements for computer, tablet and mobile.
Dette indlæg er en undersøgelse af den performance som præsteres af henholdsvis JavaScript og Canvas elementet og dets rolle på mobile platforme i fremtiden. Inspirationen fik jeg da jeg kom forbi Almer Thies Water Ripple Canvas der kørte uden problemer (med Canvas: 20fps og Water:30 fps) på min computer men skræmte mig fra vid og sans med et maks på 0.5 fps på min iPhone (yep. En halv frame i sekundet!!). Jeg fik derfor en idé om at finde et sammenligneligt stykke kode, der kunne afvikles fra canvas og nemt porteres til Flash, så jeg kunne danne mig et overblik over hvor godt de hver i sær præsterede.
Selv er jeg tilhænger af Adobe Flash Player og har altid ment at iOS bandlysning af den på grund af performance ikke havde nogen gang på jord, set i lyset af alternativerne. At vi så grundlæggende skal tage os en grundig snak om, hvad der skal ske, når vores mobile enheder besøger en hjemmeside i årene der kommer, er en helt anden snak – en fremtid, som jeg spår som “det store dyk”, i værste tilfælde.
Jeg droppede begrænsningen og så at PC’eren faktisk nemt snurrede den over 200 FPS, men meningen her er ikke at benchmarke i den høje ende, men finde et forhold i “den lave ende” og en relativ måling til en standard maskine. PC såvel som Mac varierer så meget på hardware samt udvalg af browsere, at det ikke vil bidrage til noget positivt at afdække alle facetter.
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
Forsøg nummer to var lavet for at sammenligne performance mellem JavaScripts arbejde på canvas, samt Flash Playerens arbejde med BitmapData klassen. Teknikken der bruges til begge er meget ens, og det vil give det bedste sammenligningsgrundlag, og mindst mulig redigering i koden. Du kan se et eksempel på http://eksempler.hjaelpmignu.dk/flash/actionscript/snowflake/snowFLA.html
Følgende ændringer er blevet foretaget fra originalkoden:
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
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 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;
}
}
}
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 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";
}
}
}
Kommentarer til koden
Jeg har beholdt draw() inde i Flake klassen og tegner den fysisk op med graphics.drawCircle() for at beholde koden på tværs af eksemplerne. Overførsel af værdier om canvas-størrelse osv. er også bevaret i Flash eksemplet er også bevaret. Endelig er der brugt Bitmap() og BitmapData() til at simulere de egenskaber som bruges på canvas elementet.
Resultat 2
På modeller, hvor der både kan køres Flash Player 10.1 og canvas vil jeg prøve at teste dem op mod hinanden. Ikke så meget en kamp mellem det ene og det andet, for fremtiden (tror jeg) tilhører dem begge, men mere et forsøg på at finde ud af, hvor dårlig Flash præsterer og om tilhængere af canvas, som “Flash Killer” har noget at have det i. Jeg vil opdatere efterhånden som jeg rammer flere forskellige telefoner på min vej:
Dersire HD (2.2): Canvas ~ 16.5 FPS og Flash 10.1 ~ 24.2 FPS
HTC Desire (2.2): Canvas ~ 14.5 FPS og Flash 10.1 21.7 to 23.5 FPS
I er velkommen til at indsende oprigtige målinger
Konklusion
Jeg ser en relativ højere frame rate når jeg afvikler i Flash Player på Android, end hvis jeg udfører tilsvarende med canvas elementet. Det er ikke lykkedes mig at vende forholdet mellem tallene på min telefon, end ikke få dem til at nærme sig hinanden, mærkbart. Jeg vil derfor mene at brugeren vil have en bedre oplevelse af dette eksperiment i en Flash Player, end ved en canvas-løsning. Det er vigtigt at huske på, at canvas elementets evne til at præstere, ikke behøver at gå ud over den generelle opfattelse af HTML5 og CSS3. Min fornemmelse er, at CSS3 har en ok afvikling på de mobile enheder, måske på grund af deres forudsigelige natur, men det har jeg stadig tilbage at undersøge.
Endelig har jeg ikke forholdt mig til, hvad der er installeret på enhederne. Det kan være relevant i en fintælling at se på parametre som:
Hvor lang tid telefonen har været tændt.
Er den tilsluttet oplader.
Kører der programmer i baggrunden.
Videodokumentation af test
Mit ønske her er at få nogle tal i luften, og et forhold til den relativt ringe afvikling af materiale på mobile enheder.
Meld gerne tilbage med resultater af jeres egne målinger på computer, tablet og mobil.
Hvis din udgave af Photoshop begynder at opføre sig underligt på Mac, kan det være fordi systemet er blevet opdateret til Mac OS 10.6.5 eller Mac OS 10.6.6.
I følge Adobes egen Knowledge base (http://kb2.adobe.com/cps/881/cpsid_88159.html) kan de kun opfordre til at systemet bliver på version 10.6.4, indtil en løsning er fundet, men i praksis er det jo nok ikke muligt.
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.
Så kom listen med de udvalgte Community Champions for 2011, og jeg er glad for at se at jeg har fået lov til at bestride jobbet (igen) i år. Det bliver et rigtigt spændende år for internetteknologier og software til design og udvikling på diverse platforme, og jeg glæder mig til at sprede information om Flash, HTML5, Adobe, Photoshop, mobile, interaktivitet, Illustrator osv. osv. til alle der gider at høre nyt fra den verden.
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
Der er mange diskussioner om hvordan der skal kommunikeres på Internettet i fremtiden, og mange klumper af mudder flyver fra henholdsvis Flash og HTML lejren, med forsøg på at berettige deres egen eksistens. Når designere og udviklere er så passioneret, som de heldigvis ofte er, kommer klapperne desværre op og de glemmer at zoome lidt ud og se det hele i et større perspektiv. Jeg selv, er jo en Adobe mand af guds nåde og elsker alt, hvad der har med design af interaktive løsninger at gøre, så jeg bliver rendt meget på dørene med spørgsmål som “Er Flash en død sild?”, “Kan man overhovedet noget med HTML?”, “Hvordan er performance?”, “Kan man lave Flash sites uden flash?” osv.
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
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:
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
Efter at have haft et par fantstisk hyggelige dage, med gamle og nye ansigter på New Media Days 2010, raser debatten altid bagefter på et mere eller mindre sagligt plan. Hvor jeg selv kan være ret god til det usaglige, kan jeg heller ikke undslå mig fra at være nødt til at tage ting alvorligt – engang imellem. Det første jeg vil kommentere er at der blev gjort et stort arbejde i at få tingene til at glide, og jeg følte mig godt tilpads på alle leder og kanter (sted, forplejning, agenda osv.)
Vi er New Media
Det der slog mig denne gang, var noget som jeg selv brokkede mig over sidste år. Christiane Vejlø (@christianevejlo) bekræftede mig, med hendes research i to ting. For det første at hun er en brandgod moderator og en gevinst ved denne her slags panel-debatter, men lige så vigtigt at “new media is now.” Hende vox-pop forklarede med al tydelighed, at vi er nød til at have denne her slags konferencer der ogaå arbejder med aktuelle emner og vender dem. Til jer der ikke var der, kan den ses her:
Det er næsten lige så sikkert som krummer i forhold til konceptet “mad på sengen”, at folk brokker sig over at der ikke var nok nyt, og det var “gamle” nyheder der blev introduceret og perspektivering var sparsom. På nogle punkter kan jeg da også være enig, men det er vigtigt for mig at fastslå (også overfor mig selv) hvorfor jeg beskæftiger mig i dette felt.
Nogle ville kalde det “Media Days” og udelade “new”, som jeg selv fejlagtigt foreslog sidste år, og andre er utilfredse med form og indhold.
Problemet med kritikken er at den kommer fra etablerede aktører, der mange gange er så kloge selv, at de ligeså godt kunne stå på scenen (sagt positivt) og det måske er et udslag af tilfældigheder at de ikke er blevet spurgt. Vi er en kreds af mennesker der er så heldige at vi kan mødes og diskutere konceptet bag “new media” – hvor det er nu og hvor det bevæger sig hen.
Ikke future media days
I en verden hvor det gælder om at differenciere sig og vise man kan noget, leder vi altid efter den guldklump som ligger et sted ude i fremtiden. Vi fiser rundt som Harry Potter på en Quidditch bane for at finde den lille klump først, så vi kan hæve trofæet og modtage folkets (og hinandens) hyldest. Men kuglen er så lille at ingen af vores tilskuer kan se den, med mindre at den tilfældigvis farer lige forbi deres snude. Så mens alle andre på holdet prøver at få gang i et reelt spil, hvor styrkeforholdet gælder om at hæve sig ét point (eller et par) ad gangen, håber vi (måske gennem en konference) at få 250 point og vinde i en håndevending.
Det er selvfølgelig sat groft op, og jeg vil også allerede undskylde overfor HP-fans, hvis jeg ikke kan huske detaljer om point og regler. Min pointe er at “vi” er new media days, og Christiane naglede vigtige pointer i en vox-pop som ramte mig med en hammer. Ting som uvidenhed, misforståelse, geografi, frygt, dobbelttydning og indforståethed.
Hvad er new media?
det er et gennemtærsket udtryk som i mange henseender bliver misbrugt. Hvis du synes du har en klar opfattelse, så bare springe dette over … og måske skulle du alligevel ikke Jeg definerer selv new media således:
“New Media er et fællesudtryk for medieteknologier og -platforme, hvis funktionalitet ikke helt, eller næsten helt, er er overtaget af en anden enheds virkemåde.”
Det var det der gjorde at mobilen overtog telefonen, at WAP kom ind over for en kort bemærkning. Den linje blev til sidst opslugt af smartphones, som nu i lang tid fremover vil konkurrere om, hvem der er smartest, indtil noget helt andet kommer og tager over.
Computeren, som begreb er stadig new media, men på grund af dens rivende udvikling har den udviklet sig til at blive et meta-begreb for hvad der kan være i den. Computeren i sin fysiske manifestation betragtes ikke som ny, men indholdet af den, dens hardware eller software er med til at definere new media. De softwareplatforme som vi kommunikerer gennem på computeren, bliver i denne tid delt med andre hardware-platforme (smartphones, tablets oa.) og fjerner nu fokus over på teknologier, der kan forbinde os med hinanden igennem denne lille plade vi har opfundet. Vi prøver at finde meningen bag koncepterne og famler eksperimenterende rundt (som vi bør gøre) for at finde de umiddelbare grænser.
Du kan selvfølgelig finde gråzoner, hvor begrebet bliver sværere at forholde sig til, men som grundholdning kan du sætte meget på plads via den tankegang.
Hvor er brugerne
Mens vi sidder på konferencer og snakker om hvor meget vi har tænkt os at droppe facebook og twitter om at der er så få der kan høre os, når vi er trendy, så ser vi en video med omverden. Lad mig lige tage de par ord jeg så i deres ansigter, en af gangen:
uvidenhed: lyser ud af øjnene for manges vedkommende. En del målgrupper kan ikke forholde sig til modeord som app, gps, buzz, lol og øøøh … Gin Fizz. De tror de er dømt til at fejle, hvis de prøver at snakke med på det område og er tit bange for at udstille sig selv. Det er en slags “Jeg kigger bare” mennesker, der ikke vil have en indsigt eller en holdning. De vil mere have at vide, hvad de skal gøre for at være på rette spor.
misforståelse: “det er jo det der, hvor man sætter ind med billeder på, eller hvad?!” Overbærende fnisen fra de fleste deltagere på konferencen (inklusiv mig selv). Man får næsten lyst til at trøste hende, men hun kan være din kunde. De hører i øst og vest, og får næsten altid modificerede svar der tjener afsenderen. Mit skræmme eksempel er Danske Banks mobil app, der kun kan finde deres egne hæveautomater – den slags firmaer skulle ha’ en røvfuld.
geografi: “Jeg er lige kommet hertil fra færøerne!” Det er selvfølgelig sjovt at høre, men fortæller at evnen til at kommunikere mulighederne til modtagerne er en del af problematikken. Jeg skal på en eller anden måde få en person, hvis liv er fyldt op med alt andet end det jeg beskæftiger mig med, til at forstå essensen af det jeg beskæftiger mig med.
frygt: “Du skal lade være med at pille ved det, hvis du ikke ved hvad du gør.” Den rare ældre dame har helt sikkert fået lignende at vide, og hun har nok på egen krop mærket en computers modvilje mod at samarbejde. Hun kommer fra en verden, hvor man kunne leve med at “e” hoppede på skrivemaskinen, til at der ikke er forbindelse p. gr. af problemer med DNS-serveren.
dobbelttydning: “Applikation. Det er når man bliver … øh, ansøgt om noget – er det ik’?” Småfnisende, som et forsvar gemmer hun sig bag at hun rent faktisk ikke har ret i sammenhæng med spørgsmålet. Hun har en klar fornemmelse af at “Application” betyder ansøgning på engelsk, men kan mærke at eksisterende viden ikke slår til mere. Hun bliver usikker på, hvor meget af det hun ved, der kan trækkes over i denne nye verden.
indforståethed. Fona-fyren til sidst smider lige en arketype på bordet, der småsmilende snakker med og nævner en del af de rigtige ord, og samtidig smider et par ekstra i puljen, i sin behagelige jagt på at finde ud af, hvor meget journalisten rent faktisk ved om begreberne.
Husk at nyde turen
Jeg er begyndt at frygte at mange er så ivrige efter at skabe overskrifter, at de tramper alle afgrøder ned for den målgruppe, der prøver at forstå dem. I en verden hvor alt hvad vi finder på bliver skrevet med <h1>-tags, skal man være anderledes, have mange penge eller være markant bedre for at blive hørt. Man skal lave medie-stunts til alle større kampagner og må ikke gentage koncepter for mange gange.
Vi glemmer at stoppe op og vente. Kunderne har det som om vi bare stikker af fra dem på bjerget, eller i bedste fald cykler videre opad, ligeså snart, de stakåndet har trampet sig op så vi er i syne igen. Vi kaster milliarder af nåle i høstakken, så de ikke ved, hvad der er den “rigtige nål”, men hele tiden finder noget at stikke sig på. Konferencer som New Media Days, bør være hvor man diskuterer den samtid vi lever i, og mindre af den fremtid vi lever i.
Det, du laver nu, var svært engang
Der var rigtig mange gode ting på konferencen, og jeg kunne lide de fleste oplæg. Det eneste tidspunkt, hvor jeg måtte gå var da Scene 1 blev indtaget af et par amerikaner, der var mere interesseret i at de var der, end at vi var der. Konferencen har også en opgave i at bekræfte, opsummere og trække stregerne tydeligere op som vi selv har skitseret. Disse streger skal vi så sende videre til dem vi tjener penge på og farvelægge dem på alle mulige måder, så de stadig synes vi er kreative
Vi springer ligesom det der “konsensus-led” over og giver brugeren 3d-briller og 4 browsere, så de kan tilgå 5 sociale netværk, fra 6 slags telefoner. Vi fortæller dem hvad de skal downloade, sådan så vi selv kan teste om det fungerer. Vi laver offentlige beta’er så vi kan gemme os under at det ikke er så let at kommunikere i denne her rodekasse vi selv har skabt.
På et tidspunkt falder det vi kæmper med, til ro. De stærkeste har overlevet og andre slikker deres sår, mens de kigger efter et hul i hækken, så de måske kan smutte udenom og komme stærkt igen. Når Facebook er blevet standard, leder vi efter andre måder at nå brugerne på. Vi kan ikke li’ at blive annoncører i et firkantet hul på et website. Vi vil snakke med alle dem der er derude … i enerum, så de føler sig set. Vel at bemærke uden at de får den fornemmelse af, at vi har misbrugt deres data på at målrette kampagnen.
Stop så, Karsten!
Hvis du sidder med den fornemmelse af at jeg snakker for meget og kan tale en ko ud af en kløvermark, så har du ret. Her skriver jeg bare fra hoften og er nok nød til at rette til, som debatten går skrider frem. Min kæphest er nok at alt for mange sidder og kloger i hvad web 3.0 er for en størrelse. Vi tør knapt at sige web 2.0 mere af frygt for at alle de andre i sort tøj stiller sig og fniser af mig i et hjørne. Brugerne, tror jeg, vil gerne vide, hvad web 2.0 egentlig er inden vi hopper videre til 3.0. De vil også gerne vide, hvad en applikation og Android er (eller hvad det også kan være, rettere sagt) og hvilken telefon de skal vælge.
… min frygt er at vi rent faktisk ikke helt er klar over, hvad vi skal sige til dem, og vi har brugt to dage på ikke at tale om det. Vi talte om det de skal forholde sig til, når de er cyklet op til os.
Smid gerne en kommentar og ret mig ind, hvis du føler der er behov. Det er ikke sikkert jeg retter mig efter det, for jeg er smagsdommer
En kort opdatering – eller rettere en teaser for, hvad den næste version af Flash Player’en kommer til at indeholde. Hvis rygterne rundt omkring på nettet taler sandt, og det du kan søge dig frem til står for troende, så vil MAX 2010 give noget særligt, til dem der er interesseret i at udvikle spil eller andre applikationer, der udnytter alle tre dimensioner.
Det hele startede (tror jeg) med at Thibault Imbert, der er Product Manager på Flash Playeren skrev følgende tweet
Join Sebastian Marketsmueller, Adobe Flash Player engineer, for a deep dive into the next-generation 3D API coming in a future version of Flash Player. Marketsmueller will unveil exciting new APIs and demos never shown before, including some exclusive content you cannot miss as a Flash Platform developer.
Efterfølgende uddyber Thibault på sin side. Uddyber og uddyber – det er måske så meget sagt. Men han skærper helt sikkert interessen. Andre sites som http://templatereactor.com/blog/3d-api-for-the-flash-player.html fulgte kort efter. Rygterne strækker sig langt, og kommentarfeltet fanger mange af dem – helt til Unity og Flash integration af en slags.
Set i lyset af de nye muligheder for at udvikle applikationer til iPhone med Flash udviklingsværktøjer, bliver det helt sikkert interessant, hvad der diskes op med. En ting er sikkert – der skal også diskes op med nogle hastighedsforbedringer, hvis det rigtig skal rykke
Der er vel ikke andet at sige end: “Glæder mig til slutningen af oktober!”