Bryngfors.com

Intervju om Facebook, spel och Flash

Nisse Bryngfors — Wed, 02 Mar 2011 09:29:50 GMT

(missa inte tidigare intervjuer om hur kampanjen Tackfilm producerades och iPhoneutveckling ur en flashutvecklares perspektiv)

Kan du berätta lite kort om dig själv och din bakgrund när det gäller både flashplattformen i stort, och kanske lite mer hur du kombinerar det med spelutveckling?

Jag heter Christoffer Enedahl och jobbar som spelprogrammerare på Muskedunder Interactive. Jag har varit intresserad av att utveckla spel sen skoltiden och har nu privilegiet att kunna göra det på arbetstid. När jag vill göra ett nytt spel väljer jag först och främst Flash som utvecklingsmiljö. Det går snabbt att få resultat, utvecklingsspråket är moget, prestandan är tillräcklig och du kan köra spelet i många miljöer.

Vad använder du för verktyg och kodbibliotek när du utvecklar spel?

Program:

Jag använder FlashDevelop för att skriva kod. Den har en aggressiv auto-complete funktion som är beroendeframkallande.
Flash, för layout, animering och vectorgrafik.
PhotoShop för bitmapgrafik. Paint.Net fungerar skapligt som substitut.
Sfxr: Ett program för att skapa chipliknande ljudeffekter. När jag gör egna spel hemma använder jag ofta detta suveräna program.

Nödvändiga bibliotek:

As3-Signals. Robert Penners tolkning av C# events och Qt signals. Jag bara älskar signals. Istället för att skriva en egen eventklass skapar man bara en instans av en Signal klass. Man ser direkt på en klass vilka events den sänder ut. När man städar upp i sin klass behöver man inte avregistrera alla lyssnare manuellt, man kör bara signal.removeAll(). Snyggare, mer översiktligt och färre rader kod.
Tweener för interpolering och animering.
Box2D när det behövs avancerad fysik. Det finns även en Alchemy-variant som jag inte hunnit titta på. Men det kommer jag göra i nästa fysikbaserade spel jag ska göra.
PixelBender använder jag för att göra egna filter när de inbyggda inte fyller mina behov. Jag kommer nog göra ett GlowFilter som ignorerar pixlar med alpha härnäst.

Det finns ju en uppsjö av spelmotorer att använda. Vad är din syn på det? Är det en bra väg att gå när man vill göra spel i flash?

Det första man skall fråga sig är vill man göra spel eller programmera spel? Ganska stor skillnad. Har du en spelidé och vill få den realiserad fort rekommenderar något du redan kan. Vill du lära dig något nytt, plocka upp Flixel eller PushButtonEngine och kolla in ett gäng tutorials om dem. Nu säger jag inte att det är enkelt att göra spel med en spelmotor. Men 9 fall av 10 tror jag det är rätt val. Är du mer som jag, dvs om du vill programmera spel, är valet lätt: gör det själv. Det kommer gå långsammare, du kommer göra fel, men det är dina fel och du lär dig massor på vägen. http://www.flashrealtime.com/flash-game-library-engine-list/

Just Facebook har ju visat sig vara en utmärkt plattform för sociala ”casual games”. Hur ser du på framtiden för den kombinationen?

Om man nu skall spekulera så tror jag att det kommer utvecklas mer på det sociala planet. Multiplayer och mer direkt kommunikation / interaktion mellan spelare. Det är i alla fall det jag vill se.

Kan man tjäna pengar på Facebookspel? Hur?

Här har vi tre olika sätt att tjäna pengar på Facebookspel:

Reklam: Man har helt enkelt banners bredvid sitt spel. Ifall användaren inte gillar ditt spel kanske du kan få ett klick på din banner iallafall.
Innehåll: Du säljer innehåll, tex banor eller själva spelet i sig. Detta verkar inte vara så vanligt som man kan tro.
Mikrotransaktioner: Du säljer virtuella ting i spelet, det kan vara bonusar, kläder, tid, saker som du kan uttrycka dig själv med. Detta alternativet är det som jag tror är det man tjänar mest på.

Har du några tips att ge till flashutvecklare som vill göra spel. Då tänker jag dels rent allmänt, men även specifikt på spel förl Facebook?

Gör en snabb prototyp på kanske 2-3 dagar. Se ifall din idé fungerar. Blir spelet inte kul efter en eller två dagars justerande är det antagligen spelidén det är fel på. Verkar spelet fungera och du vill köra vidare på det bör du nu skapa ett nytt projekt och lyfta in de delar som du är nöjd med och skriva om de delarna som ser ut som spaghetti.

Försök få ut en spelbar version på Facebook så snabbt som möjligt. Tänk XP (eXtreme Programming), dvs utveckla endast det som behövs för att klara av din uppgift för tillfället. Var inte för rädd att stuva om i koden när det behövs. Är man rädd för att ändra strukturer har man antagligen tappat kontrollen, dags att ta tillbaka kommandot (I alla fall när det gäller typade språk).

Hur vet jag nu att spelet är skoj? Jo man behöver feedback från de som spelar spelet. Ett enkelt formulär som sparar spelarnas åsikter räcker.
Lite senare kanske det blir dags att mäta vad spelarna gör. Hur långt de kommer, hur länge de spelar olika banor etc...

Använd det som underlag för hur du skall gå vidare med spelet. Räkna med att spelet inte kommer bli som du tänkt från början.

Spel handlar mycket om att ge belöningar. Tex poäng, pickups och XP är en form av belöning. En annan typ av belöning är audiovisuell feedback. Ljudeffekter och tex partiklar när man utför saker i spelet. Jag kan nästan påstå att audiovisuell feedback är viktigare.

Vilka är de största svårigheterna när det kommer till att utveckla spel som använder Facebooks plattform?

Att komma igång, ta reda på hur man skall göra är nog det svåraste. Vi valde att använda Adobes Facebook-bibliotek till att börja med. Det blev ganska snabbt utdaterat så vi har bytt till att kommunicera med Facebook via JavaScript, om de ändrar något i framtiden behöver vi troligtvis inte ändra i spelen utan bara i vårt JavaScript-lager. Detta underlättar även till att sprida spelen på andra sociala nätverk.

Har ni någon gång råkat ut för att Facebook ändrat något som påverkat spel som ligger live?

Javisst ett flertal gånger. De ändrar i api:n och i regler titt som tätt. Senast ändrade Facebook hur iframes kan ändras i storlek och tusentals sidor fick fula skrollar eller blev kapade på fel ställe.

Just spel är ett område som de flesta är tycker det är vettigt att använda Flash till. När man ser på utvecklingen av HTML5 så känns det som det bara är en tidsfråga innan det är tillräckligt moget även för spelutveckling. Ser du något annat problem med att använda HTML5/JS än att det är svårt att stödja olika webbläsarversioner?

Utvecklingstiden kommer bli längre. Mest med tanke på att as3 är typat och kompilerat medan JS inte är det så blir det svårare att hitta buggar i JS.

Facebook har nyligen uttalat sig om att de kommer fokusera på HTML5. Det finns även indikationer att detta även gäller spel på Facebook. Vad är dina tankar om det?

Tja, jag har inget emot det, men jag föredrar att utveckla i Flash framför HTML5 beroende på utvecklingstiden och att det enkelt går att se källkoden för HTML5-spel. Obfuskering bör kanske undersökas. Som spelare är jag bara intresserad av att spelet fungerar bra, inte vilken teknik som används.

Har du hunnit läsa något om Molehill, flashspelarens kommande stöd för hårdvaruaccellererad grafik på lågnivå? Kommer det att förändra hur flash används, både rent generellt och mer specifikt för spel?

Givetvis kommer cross-platform, hårdvaruaccelererat, 3d-stöd förändra användningen av Flash. Jag tror att även rena 2d applikationer kommer utnyttja denna nya processorkraft. Nya UI-bibliotek med hårdvarustöd blir lika självklara som Tweener-biblioteket är idag. Fler Flash-spel kommer göras i 3d, på gott och ont. Mest ont antagligen. Kanske kommer stora spelhus göra 3d-online-spel i Flash med mikrotransaktioner som inkomstkälla.

Förutom hårdvaruaccelerering, är det något annat du saknar i flashspelaren som skulle förbättra eller förenkla spelutveckling?

Gamepad-stöd, vilket kommer med Molehill enligt Adobe. Att kunna sätta muspekarens position på skärmen kommer bli mycket önskat när 3d stödet finns på plats, då det är en nyckelfunktion för att kunna göra första persons-spel.

I as3 vill jag gärna få in templates så som Vector är implementerat.

När man embeddar symboler från swfer följer inte framescripts med. Detta är ganska irriterande. Jag undviker gärna skript i grafik men det är väldigt smidigt att slänga in en stop() eller gotoAndPlay() i animationerna.

Det är ju ingen tvekan om att vi ser en boom, sedan några år tillbaka, för avancerade mobiltelefoner och andra mobila enheter. Speciellt iPhone har ju skapat en helt ny marknad för applikationer och då inte minst spel. Hur ser du på framtiden för mobila spel?

Ja, det är på mobilen det händer just nu. App Store och Android Market är nyckeln till boomen på mobilmarknaden. De gör det möjligt att leverera och ta betalt på ett smidigt sätt. Folk som aldrig spelat datorspel eller köpt program till sin dator förut sitter nu och köper och laddar hem appar till sin telefon pga detta. För spelutvecklare betyder det nya konsumenter men också nya krav på användarvänlighet och anpassning till olika telefoner, inte en trivial problematik.

Vilken strategi ska man ha när det kommer till mobila plattformar? Finnas på så många som möjligt, bara de största, eller till och med enbart koncentrera sig på en specifik plattform?

Jag läste en bra artikel om just detta från en flashutvecklares perspektiv. http://www.doomsday.no/esn/2011/02/my-2-on-android-dev-vs-iphone-dev/
Vad som är rent affärsmässigt bäst kan man ju argumentera för och emot alla möjliga alternativ. Vilken marknad är störst? Var finns min målgrupp? Vilken marknad ger mitt spel minst konkurrens? Jag skulle välja att börja på en plattform som passar mig själv bäst, göra klart mitt spel, lansera och sen se responsen på den plattformen. Går spelet så pass bra att det är värt att jobba vidare på det så skulle jag helt klart porta det till andra plattformar. Vill man att ens suveräna spel skall bli riktigt stort behövs nog tyvärr en massa publicitet och reklam.

Har du själv börjat med spelutveckling för mobiltelefoner?

Jag har precis startat ett enkelt litet spelprojekt för att lära mig Java och Android. Jag tycker att det är effektivast att lära sig nya saker genom att göra ett projekt.

Till sist, tusen tack för att du tog dig tid för den här intervjun! Är det några spel som du varit med att utveckla som du vill tipsa om?

Kul att få vara med! Jag hoppas att jag haft något vettigt att säga. Jodå jag har en massa halvklara spel-projekt där hemma och hittills tre släppta Facebook-spel sen jag blev anställd på Muskedunder. Här är två länkar för den intresserade:

FloodDiggR (http://blog.enedahl.com/?p=81)

Ett experiment med vatten, kaniner och fiskar.

Hello Adventure (http://apps.facebook.com/helloadventure/?src=bryngfors)

Ett Dungeon-crawl-spel på Facebook som vi på Muskedunder utvecklat. Vi använder mät-data som guide till vidareutvecklingen.

Vad får vi se på Adobe MAX?

Nisse Bryngfors — Sat, 23 Oct 2010 15:23:55 GMT

Vi kan med all säkerhet räkna med att Adobe kommer fukusera på mobiltelefoner, tablets och TV-apparater. De pratar ofta om "multi screen" och hur Flash och Adobe AIR är lösningen om man vill nå så många olika enheter som möjligt. Det är troligt att vi kommer få se många intressanta samarbeten mellan Adobe och andra hård-och mjukvarutillverkare.

Nedan har jag listat lite av vad vi vet att det kommer pratas om, vad jag tror och vad jag hoppas på.

Det givna

BlackBerry Playbook - Både RIM och Adobe har postat information om att Flash och Adobe AIR är en viktig del i RIMs kommande tablet Playbook.
Samsung TV - Med Adobe AIR kommer man kunna bygga applikationer för Samsung TV-apparater och Blu-ray spelare .
3D i Flash - Riktig stöd för 3D i Flash är på gång, och på MAX får vi veta mer om detaljerna.

Det troliga

JSON - Både anställda hos Adobe och övriga i communityt har uttryckt behovet av stöd för JSON direkt i flashspelaren (finns idag via diverse bibliotek). Kanske kommer det i nästa version.
Nook - Ted Patrick slutar på Adobe för att jobba med Nook hos Barnes & Nobles. Kommer vi få mer information om Adobe AIR och Flash på nästa Nook?
Modulär Flashspelare - Det har pratats lite kring hur utvecklare ska kunna slå på och av funktionalitet i Flashspelaren för att öka prestandan. Ett intressant koncept.
WebOS - HP har redan utannonserat att WebOS 2.0 kommer ha stöd för Flash. Kanske kommer de även ha stöd för Adobe AIR.

Förhoppningsvis

Adobe AIR bundlat i nästa Andriod - AIR finns redan tillgängligt för Android och installeras vi market. Förhoppningsvis fördjupar Google integrationen och bundlar AIR runtime i nästa version av Android. Det skulle göra AIR till ett fullgott alternativ istället för Java för vissa typer av Androidapplikationer.
Microsoft Phone 7 - Flash och Adobe AIR på Windows Phone 7 är viktigt för att kunna hävda fördelarna med en cross OS/devices plattform.
Optimerad kompilator - Joa Ebert har under lång tid visat att det finns gott om utrymme att optimera bytekod för Actionscript på kompilatornivå. Det är dags att Adobe gör samma sak med sin kompilator.
Packager for iPhone - Apple tog nyligen bort restriktionerna för tredjepartsutveckladeappar. Det innebär att Packager for iPhone är tillåtet igen. Adobe tappade 6 månaders utvecklingstid men ska nu ha tagit upp arbetet igen. Tyvärr tror jag inte de hunnit speciellt mycket längre i arbetet ännu.

Mobila appar, inte längre lika enkelt

Nisse Bryngfors — Mon, 18 Oct 2010 18:19:10 GMT

Med iPhone revolutionerade Apple marknaden för smartphones. Orsaken var inte bara bättre hårdvara, utan den största förklaringen låg snarare i dess mjukvara. Apple döpte om applikationer till appar och skapade en stabil grund för utvecklare att bygga vidare på. Med iPhones intåg blev det helt plötsligt enkelt att skapa, distribuera, sälja, köpa och använda mobila applikationer.

En stor del av orsaken till att appar fungerade så bra var att Apple under lång tid var ensamma på marknaden. Utvecklare behövde till en början bara bry sig om EN plattform, EN skärmupplösning och i stort sett bara EN processor. Med tiden lanserade Apple naturligtvis fler produkter som utvecklarna behövde ta hänsyn till, men det var ändå hanterbart.

Idag är en app inte längre synonymt med en mobilapplikation för iPhone. Apple har fått konkurrens och det finns fler plattformar, telefoner och utvecklingsalternativ. Och det är inte bara Googles Android som tävlar om uppmärksamheten utan vi har även RIM, Windows Phone 7, HP (Palm) och Nokia (nåja). Lägg därtill olika språk och plattformsoberoende tekniker, utöver nativespråk för varje plattform, så inser man snabbt komplexitetsgraden i mobila applikationer.

På Sticky Beat jobbar vi med att utveckla digitala produktioner. Vi realiserar våra kunders kreativa idéer och en stor roll i det är att vara rådgivande när det gäller val av teknik. Ibland är Flash rätt verktyg, ibland HTML/JS/CSS. Ibland används WordPress, ibland något annat bloggverktyg eller CMS. På samma sätt tror jag att produktionsbolag som Sticky Beat behöver ha kunskap om och hjälpa till med val av teknik när det kommer till mobila applikationer.

Apple TV, inte riktigt den revolution jag hoppats på

Nisse Bryngfors — Wed, 01 Sep 2010 18:33:06 GMT

Uppdatering: Apple TV har en A4 processor, så det är inte omöjligt att det är iOS som körs i bakgrunden, med ett anpassat gränsnitt ovanpå. Det skulle innebära att det fortfarande finns möjlighet att Apple öppnar upp för tredjeparts-apps så småningom.

I en tidigare bloggpost skrev jag om varför jag trodde att Apple TV skulle kunna förändra hur vi konsumerar innehåll för tv . Nu när Apple nyss har presenterat nästa generation av Apple TV känner jag mig en aning besviken.

Orsaken är främst avsaknaden av iOS och därmed en obefintlig appstore riktad mot användning på en TV. Applikationer skräddarsydda för att användas på en TV i vardagsrummet hade kunnat bli hur intressant som helst. Det skulle kunna revolutionerat app-marknaden än en gång, på samma sätt som iPhone gjorde när den introducerade tredjepartsappar.

Apple verkar ha bestämt sig för att Apple TV ska göra ett fåtal saker bra, istället för att öppna upp för innovation från tredjepartsutvecklare. Antagligen kommer konceptet fungera väl, speciellt med tanke på priset. Och att Apple förfinar möjligheterna att få tag på kvalitetsinnehåll enkelt, och för ett vettigt pris, är bara bra för film och TV-branschen. Men jag kan ändå inte släppa tanken på hur bra det kunde blivit.

Däremot, något som är extremt intressant är möjligheten att streama innehåll från en iOS enhet till AppleTV. Att kunna visa bilder eller video tagna med en iPhone direkt på en stor tv-skärm är väldigt elegant. Och om tredjepartsprogram som SVT-play eller liknande också får tillgång till dessa API öppnas möjligheterna upp ytterliggare.

Apple TV har alla chanser att bli en succé, men har inte Apple missat en stor chans att bredda marknaden för iOS appar?

Vad "the wilderness downtown" visar

Nisse Bryngfors — Tue, 31 Aug 2010 14:15:00 GMT

Sajten The Wilderness Downtown har fått mycket uppmärksamhet senaste tiden. Det är ett HTML5 experiment utvecklat specifikt för Googles webbläsare Chrome. Sajten är riktigt bra gjord och är väldigt fängslande. Den är väl värd all uppmärksamhet.

Samtidigt är jag tveksam till att en liknande sajt gjord i Flash hade fått samma uppmärksamhet. Dels för att HTML5 är hetare än Flash, dels för att för att förväntningarna på vad en kampanjsajt i Flash teknisk kan klara är mycket högre än för en kampanjsajt gjord i HTML5.

Med tanke på den ständigt pågående diskussionen om Flash och HTML5, som jag egentligen är ganska trött på, så vill jag bara dra några snabba slutsatser:

Upplevelser är fortfarande viktiga - Att så många har länkat till och diskuterat "The Wilderness Downtown" visar att den här typen av kampanjsajter kan engagera och skapa ett värde.
Laddningstid och prestanda - "The Wilderness Downtown" kräver en hel del både i prestanda och bandbredd. Flash brukar få kritik för detta, men "The Wilderness Downtown" visar att det handlar om innehåll och utförande snarare än teknik.
Mobilt - Flash beskylls för att inte fungera på mobiltelefoner, men "The Wilderness Downtown" visar att det inte fungerar per automatik på mobiltelefoner bara för att något använder HTML5.
HTML5 utvecklas - Vi kommer få se mer och mer kampanjsajter gjorda i HTML5 och gränserna för vad som är möjligt kommer hela tiden flyttas fram.
HTML5 är inte moget än - "The Wilderness Downtown" fungerar endast i Google Chrome. Det är möjligt att man skulle kunnat stödja fler läsare, men frågan är hur mycket jobb det hade inneburit.

För mig har det alltid varit viktigt att nätet inte bara består av text, bild och kortare videofilmer. Jag vill även bli berörd och att det ska finnas plats för mer konstnärliga interaktiva experiment och kampanjsajter. Därför blev jag väldigt glad när The Wilderness Downtown fick så mycket uppmärksamhet.

För mig handlar det i slutändan om bra upplevelser, inte teknik.

Aggressiv minneoptimering i Flash Player 10.1

Nisse Bryngfors — Fri, 27 Aug 2010 12:44:53 GMT

Adobe har gjort ett utmärkt jobb när det kommer till prestanda och minneshantering i flashspelare 10.1, vilket var nödvändigt för att Flash skulle fungera bra på mobila enheter med sämre hårdvara. Det gör också att innehåll som skapats i första hand för kraftfulla skrivbordsdatorer har en chans att fungera okej på mobila enheter.

Men det finns också lägen då de nya optimeringarna i flashspelare 10.1 kan försämra prestanda. I ett projekt upptäckte vi att den aggressiva minnesoptimeringen i flashspelare 10.1 påverkade prestandan, speciellt animationer, i vissa situationer.

Det här exemplet visar hur flashspelare 10.1 släpper minnet för inlästa bilder efter en kort tid av inaktivitet.

Vad exemplet visar är hur flashspelaren allokerar minne för bitmapbilder. I flashspelare 10.0 ligger minnet hela tiden kvar på samma nivå. Det intressanta är hur flashspelare 10.1 hanterar inladdade bilder. När bilder inte animeras tas de bort från minnet och kvar finns endast skärmbufferten. När bilderna ska animeras igen återskapas de, gissningsvis från komprimerade versioner som redan finns i minnet, så att de kan användas när grafiken ska renderas om. Det resulterar i en extrem minnesoptimering där minnet rasar ned till en tiondel av dess ursprungliga storlek. Imponerande.

Tyvärr har den här typen av optimering en negativ sidoeffekt. När skärmen ska uppdateras, vid animationer t.ex., måste de först gå från komprimerad till okomprimerad form. Detta går relativt snabbt, men eftersom det oftast sker precis innan en animation så blir det väldigt märkbart. Vi upptäckte det här beteendet i en stor 360 snurra som användaren själv kunde navigare inom. Prestandaförlusten gjorde applikationen i stort sett oanvändbar.

Det finns inget dokumenterat sätt att slå av minnesoptimeringen för inlästa bilder, men man kan gå runt problemet genom att "smutsa" ner den inlästa bilden genom att sätta om ett pixelvärde på en pixel i bilden.

Apple iTV kommer förändra hur vi konsumerar innehåll för TV

Nisse Bryngfors — Sun, 22 Aug 2010 06:24:51 GMT

Kevin Rose, grundaren av Digg, beskriver i en bloggpost varför han tror att Apples (troliga, fortfarande bara rykten) iTV kommer förändra allt:

iOS TV Applications: Expect to see an iPhone/Pad like marketplace for television applications. Video sharing/streaming/recording apps, interactive news apps, and of course games.
a la carte (app) stations: With Apple's iAds, content producers (eg. ABC/NBC/etc.) can directly monetize and distribute their content. This will eventually destroy the television side of the cable and satellite industry, as your only requirement to access these on-demand stations will be an internet connection. Say goodbye to your monthly cable bill.
.Me Picture/Video sharing: At $99 your parents, grandparents, and friends will have an iTV. Sharing pictures/videos from your iPhone will happen with the push of a button. Imagine getting a notification of new family videos the next time you turn on your TV. My mom will love this feature.
The iPad will turn into one big badass remote control: The iPad will be the preferred input device for the iTV. You'll be able to editing videos, control games, and extend the interactive television experience. Imagine watching monday night football on the TV while viewing/exploring other camera angles on the iPad.

Om Apple iTV blir verklighet tror jag Kevin är väldigt rätt ute i sina påståenden.

Jag har alltid ansett att Apple sjabblat bort chansen till något riktigt stort när de inte gjort det möjligt att köra tredjepartsapplikationer på deras, som den heter nu, Apple TV. Är det något Apple har bevisat de senaste åren är att användare är beredda att installera, och framförallt betala för, applikationer till sina telefoner. Att kunna köra applikationer på en stor skärm i vardagsrummet framför soffan öppnar upp helt nya möjligheter.

En annan viktig sak med iTV är att den breddar marknaden för iOS applikationer. Med tanke på Androids framfart på mobilsidan, och troligtvis så småningom även när det kommer till tablet-datorer, så är det här nödvändigt för att iOS även i fortsättningen ska vara ledande. Utvecklare är i första hand intresserade av hur många användare en plattform når, och på mobilsidan är det bara en tidsfråga innan Android blir den första plattformen att utveckla sina applikationer för.

Förutom möjligheten att installera applikationer tillkommer ju dessutom möjligheten att visa foto, video och varför inte FaceTime samtal. Allt sammankopplat med din iPhone och iPad naturligtvis.

Vi har sett en explosionsartad utveckling när det gäller smarta mobiltelefoner och vi är alldeles i starten av en ny typ av datorer i form av små och smidiga tablet-datorer. Nästa område ser ut att bli TV-apparater.

Google har visat upp sina planer på hur de vill forma morgondagens TV-upplevelse, men om Apple sköter sina kort rätt tror jag de har en klar fördel. Det finns nämligen inget annat ställe där användarupplevelsen är så kritisk som när vi ska konsumera innehåll tillbakalutade i våra soffor.

Flash på mobiltelefoner är inte det intressanta

Nisse Bryngfors — Tue, 10 Aug 2010 20:47:55 GMT

Senaste tiden har det varit ganska mycket fokus på Flash för mobiltelefoner. Dels har det handlat om att Apple vägrar Flash för sina enheter, dels har det handlat om att Flash nu finns tillgängligt för Android 2.2.

Men med allt fokus på Flash i mobila webbläsare så känns det som att den verkliga nyheten, där det finns mest potential, helt har missats av den stora massan. Det jag refererar till är naturligtvis Adobe AIR.

Android kommer få stöd för Adobe AIR. Det innebär att flashutvecklare kommer kunna skapa applikationer som enkelt kan installeras på enheter som kör Android genom att paketera dem som AIR applikationer.

Det intressanta med Adobe AIR är att samma kod sedan kan användas till fristående applikationer för Windows, Mac och Linux, eller till och med via flashspelaren i en webbläsare. Med tanke på Adobes breda samarbete med branschen i övrigt är det heller inte otänkbart att Adobe AIR hittar in hos HP's WebOS eller RIM's BlackBerry OS. Kanske till och med Microsofts Windows Phone 7. Om man sedan tänker på den outforskade marknaden för tablet-datorer så inser man snabbt att det finns ett värde att nå så många plattformar som möjligt med sin applikation eller spel.

Vänder man på resonemanget så ser man att de språk och ramverk som varje plattform idag använder blir begränsade när det kommer till spridning. Utvecklar du en applikation i Objective-C/Cocoa Touch når du iDevices. Utvecklar du i Java för Android når du enheter som kör Android. Det blir dock väldigt svårt att använda samma kod till en ny typ av plattform.

Adobe AIR, om det får tillräckligt brett stöd, kan bli en vettig lösning för ett stort antal typer av applikationer. Helt klart kommer vissa typer av applikationer alltid behöva utvecklas specifikt för en viss plattform. Men för lika många applikationer är det viktiga att de når så många användare som möjligt utan för stor kostnad.

Det största hindret för att Adobe AIR verkligen ska lyckas är naturligtvis Apple. Adobe löste de tekniska bitarna för att skapa iPhone applikationer via AIR, men Apple såg till att förhindra det via utvecklaravtal.

Det är inte säkert att det blir just Adobe AIR som blir lösningen på att skapa applikationer för alla typer av plattformar, men jag är övertygad om att vi förr eller senare kommer få se ett vettigt alternativ. I längden är det ändå ohållbart, för majoriteten av alla applikationer, att skriva om dem för varje ny plattform.

Förhindrar Apple innovationen inom digitala magasin?

Nisse Bryngfors — Tue, 01 Jun 2010 21:31:53 GMT

Ända sedan jag först hörde talas om iPad har jag sett fram emot att kunna använda den till att läsa digitala magasin. Just magasin är något som, enligt mig, är en utmärkt typ av innehåll att konsumera på en tablet-dator. Jag vill ha slipad och genomtänkt formgivning, men också interaktiva element som drar nytta av de unika egenskaper som en tablet-dator ger.

Därför blev jag glad när jag hörde om Adobes samarbete med Conde Nast om att göra en digital version av magasinet Wired. Filmerna som visades upp verkade mycket lovande och just interaktiva magasin var ett område där Flash och Adobe AIR faktiskt skulle kunna göra nytta och vara ett vettigt val jämfört med andra tekniker.

När Apple ändrade sin Terms Of Service så att de inte längre tillät krosskompilerade applikationer såg det ut som att Wired appen aldrig skulle bli verklighet. Åtminstone inte på Apples enheter. Men Adobe gjorde om sina utvecklingsverktyg och visade att de är inriktade på att göra en lösning för magasin som fungerar oavsett plattform, även om det innebär att Flash inte alltid kan användas.

Det intressanta med Adobes lösning är egentligen inte själva appen i sig, utan snarare arbetsgången för hur den skapas. Adobe har utgått från InDesign och sedan skapat verktyg kring programmet för att skapa digitala versioner av ett magasin. Det gör det möjligt att använda stora delar av arbetsflödet för den tryckta tidningen, men med möjligheten att berika den digitala versionen med olika interaktiva element. Med tanke på mängden magasin som skapas, samt hur ofta de kommer ut, inser man snabbt att just arbetsflödet samt verktygen för att skapa innehåll är en otroligt viktig och central del.

Wired appen känns fräsch och formgivningen är extremt krisp och genomtänkt. Bara en sån sak som att varje sida har olika layout för landskapsläge och porträttläge gör att den känns proffsig och genomarbetad. Navigeringsmetaforen är nyskapande utan att vara överarbetad och den fungerar väldigt väl. Att appen har interaktiva inslag gör att den uppmanar till utforskning vilket leder till att man gärna sitter och använder den under lång tid.

När det kommer till den tekniska lösningen av själva appen så är den dock inte speciellt imponerande. Varje sida består av två bilder, en för landskapsläge och en för porträttläge. Dessa navigerar man sedan mellan genom att dra åt höger eller vänster för att komma framåt i magasinet, samt uppåt och nedåt för att läsa artiklar. Att sidorna utgörs av bilder gör att det varken går att zooma eller söka i text. Interaktionerna är relativt enkla och består av filmer, som då öppnas i en "extern" spelare, ljudklipp eller olika varianter av bildspel. Det finns också 360 graders visualiseringar, men de är helt enkelt bildsekvenser som man styr genom att dra med fingret över dem.

Det är någonstans här som jag inte kan låta bli att fundera på hur resultatet skulle kunna bli om Apple hade tillåtit Flash som interaktiva element i appar. Oavsett vad man tycker om Flash så måste man ändå medge att det finns ett ekosystem av välbeprövade verktyg och utvecklingsprogram för att skapa innehåll. De har funnits länge och det finns en stor skara av kreativa producenter som behärskar dem. Notera att jag inte enbart talar om Flash IDE utan alla tänkbara verktyg runtomkring som Illustrator, Catalyst, After Effects, Photoshop samt diverse tredjepartsverktyg. Alla kan användas för att skapa grafiskt tilltalande och högst interaktivt innehåll.

Hade det funnits möjlighet att använda Flash till interaktiva element i digitala magasin så är jag övertygad om att vi snabbare skulle kunna få den pånyttfödelse som tidningsbranschen så desperat behöver. Den interaktivitet Wired på iPad i dagsläget visar upp är skrattretande jämfört med vad Flash levererat de senaste fem, tio åren.

Förhoppningsvis kommer vi kunna se en viss del av den här potentialen när Adobes nya verktyg används för att publicera till Android och Windowsbaserade tabletdatorer. Tyvärr finns det en risk att iPad, med den enorma försäljningssuccén som den blivit, kommer blockera utvecklingen för digitala magasin närmaste tiden eftersom det blir svårare att skapa interaktiva element för magasin på Apples plattform.

Så kan Google skaka om Apple

Nisse Bryngfors — Fri, 07 May 2010 14:52:36 GMT

På utvecklarkonferensen Google IO förväntas Google utannonsera att videocodecen VP8, som de numera äger efter att de köpt upp On2, släpps som öppen källkod. Syftet enligt de flesta är att skapa det bästa alternativet för video i HTML5 när det gäller prestanda, kvalité och patent.

En stor del av diskussionen kring HTML5 har handlat om hur specifikationen en gång för alla ska lösa problemet med video på nätet. Tyvärr har de inblandade inte kunnat enas om en gemensam codec och därför tvingar inte specifikationen vilken codec webbläsarna ska implementera. Detta har lett till att det skapats två läger, de som satsar på H.264 och de som satsar på Ogg Theora.

H.264 har fördelar när det gäller kvalité och bandbredd, samt att den har brett stöd i olika hårdvara. Tyvärr dras den med en minst sagt oklar bild kring licensiering och patent. Ogg Theora är helt open source och ska inte dras med patentproblem (även om Steve Jobs nyligen antydde att det finns potentiella patentproblem med alla codecs).

Med VP8 har Google ett unikt tillfälle att skaka upp marknaden, och då främst Apple som de konkurrerar med på mobilmarknaden, tabletmarknaden och nu även inom annonsering efter att Apple utannonserat iAds.

Säg att Google först gör VP8 till öppen källkod. Sedan implementerar de den i webbläsaren Chrome. Efter det ser de till att det finns hårdvarustöd och att enheter som kör Android använder det. Som en sista tvist ser de till att gradvis koda om videos på Youtube till att använda VP8 istället för H.264.

Allt detta skulle ställa till stora problem för Apple eftersom de så hårt har satsat på H.264. Att H.264 fungerar bra på iDevices beror främst på hårdvarustöd. Att avkoda video enbart med mjukvara kostar CPU-tid och minskar därmed batteritiden.

För att snabbt ställa om så att video på nätet börjar använda VP8 som codec utan att gamla webbläsare, och nya som Safari och Internet Explorer, har stöd, behöver de hjälp av Adobe. Om Adobe skulle implementera VP8 i den kommande flashspelaren skulle en stor del av världens internetuppkopplade datorer kunna ha stöd för VP8 inom ett år. Speciellt om Google ställer sig bakom det och hjälper till genom att sprida flashspelaren via Youtube och liknande.

De som skulle drabbas hårdast av detta är Apple. De skulle ha valet att börja stöda Flash och därmed VP8 eller att helt enkelt implementera codecen själva. Oavsett vad de väljer missar de hårdvarustödet i befintliga enheter, och det är något som tar lång tid att förändra.

På det här sättet skulle Google snabbt kunna ge sig själv fördelar både på mobilmarknaden och tabletmarknaden.

Att Google gör VP8 till öppen källkod är högst troligt. Att de kommer använda den i Chrome är mer eller mindre givet. Likaså att Opera och Mozilla följer efter. Microsoft har nyligen sagt att de kommer köra på H.264, men de har alltid avvaktat för att se vad andra gör. Börjar marknaden tippa över till VP8 tror kommer Microsoft förr eller senare följer efter. Adobe har senaste tiden allt mer samarbetat med Google och att flashspelaren skulle få stöd för VP8 är inte helt osannolikt. Däremot tror jag inte att Google vågar riskera YouTube genom att koda om material till att enbart köra VP8.

Oavsett vad kommer det bli intressant att följa vad som händer med VP8. Jag tror verkligen Google har stora planer för codecen och att det kommer påverka Apple på ett eller annat sätt. Frågan är hur Apple väljer att reagera.

Tankar om Apple

Nisse Bryngfors — Mon, 03 May 2010 14:35:08 GMT

För att inte bli beskylld för att vara en Apple-hatare och Adobe-fanboy vill jag först inleda med att jag äger en iPhone, har en iPad via jobbet samt att min sekundära utvecklingsdator är en Mac Book Pro. Jag älskar verkligen min iPhone och tror på iPad-konceptet. När det kommer till användargränssnitt och användbarhet så är det inget som kommer i närheten av det Apple gör.

Men jag är heller ingen Apple-fanboy. Jag litar inte blint på vad Steve Jobs och Apple säger utan att se på det med kritiska ögon. Det finns alltid en tanke och strategi som påverkar vad de väljer för väg och vilka beslut de tar.

På samma sätt ser jag kritiskt på vad Adobe gör. De har alldeles för sent insett att det är smartphones som revolutionerar den mobila marknaden. Istället har de tjurigt försökt att återupprepa den succé de hade i Asien där Flash Lite blev mycket framgångsrikt. Efter Adobes köp av Macromedia har det varit mer fokus på befästa flashspelarens position än att satsa på nyskapande funktioner. Om Adobe inte utökar flashspelaren med nya intressanta saker tappar den sin relevans. Man kan redan se exempel på att detta håller på att hända. Adobe har många saker de måste göra bättre.

Orsaken till det här, ganska långa, blogginlägget är naturligtvis Steve Jobs post "Thoughts on Flash" som publicerades förra veckan. Jag tänkte först låta bli att kommentera det eftersom många andra redan skrivit väldigt bra inlägg (länkar finns i slutet av den här posten), men samtidigt vill jag försöka ge en lite mer nyanserad bild än vad som kommer fram i sensationsjournalistiken (som tyvärr gäller även tekniknyheter).

Om du inte orkar läsa hela bloggposten kan jag sammanfatta det såhär: Apple gör väldigt bra produkter. De har all rätt att bestämma över sin plattform. Ja, jag tycker det är synd att det inte finns plats för Flash i deras strategi, men jag förstår varför. HTML5 kan göra mycket av det Flash gör, men det behöver också anpassas för mobila enheter för att fungera bra. Mycket av det Steve Jobs säger om Flash, det säger han för egen vinning.

Innan jag går in på mitt resonemang varför Apple fortsätter vägra Flash, så vill jag bara kommentera några av de påståenden Steve Jobs gör. Detta är några punkter där han tänjer på sanningen, undviker att ta upp relaterade saker eller helt enkelt gör felaktiga påstående.

Säger att Adobe var det sista stora företaget att gå över till Cocoa, men säger inte att iTunes och Final Cut Pro fortfarande är Carbon-applikationer. Adobe kunde ha varit mycket snabbare, helt klart, men antagligen handlar det både i Apples och Adobes fall om att det är stora och väldigt komplicerade program som tar tid att porta (i kombination med prioritering naturligtvis).
Apple tror på en öppen webb, inget fel i det, men undviker att lyfta fram att de använder den proprietära codecen H.264 för video.
Säger att Flash är en helt stängd plattform när det i själva verket finns många delar som är öppna specifikationer samt vissa delar som är öppen källkod. Dessutom erkänner han också att Apple har stängda produkter, men då är det någonting bra.
Multitouch gör att Flashsajter inte fungerar eftersom de förlitar sig på mouseover. De fungerar utmärkt, och vore det ett problem skulle det även gälla HTML-sajter.
Lägger fram prestanda som ett problem, vilket det potentiellt är, men Flash ska jämföras med HTML5 och inte appar kodade i Objective-C. Prestanda för Flash på iPhone kan bli minst lika bra som för HTML5. Man måste också inse att applikationer utvecklade för mobila enheter måste anpassas och optimeras. Oavsett om det gäller Flash eller HTML5.

När Microsoft gör liknande uttalanden blir de snabbt beskyllda för att ägna sig åt FUD, Fear Uncertainty and Doubt. Steves uttalande syftar alltså till stor del att skapa osäkerhet kring flashplattformen.

Varför vill Apple då skapa osäkerhet kring flashplattformen? Förutom att det handlar om att ha total kontroll över sin plattform, och på så sätt kunna garantera hög kvalitet, tror jag det finns två viktiga saker att lyfta fram, nämligen DRM-skyddad video och tillgång till interaktivt innehåll.

Med sjunkande priser på hårdvara i kombination med ökad konkurrens blir det allt viktigare att kontrollera innehållet. Apple gör det för film, tv-serier och musik via iTunes Media Store samt för spel och applikationer via Appstore. Men hur skulle Flash potentiellt kunna rubba detta?

Vi tar video först. Steve Jobs påstår att iPod/iPhone/iPad-användare inte missar något videoinnehåll på webben eftersom sajter ändå erbjuder anpassade versioner som kan köras på Apples enheter. Egentligen har han fel, det är mycket som ännu inte är anpassat, men jag tror ändå att han i längden får rätt. Apples enheter är allt för viktiga att bortse från för innehållsskapare och när det gäller video är det relativt lätt att anpassa så det fungerar utan Flash. Men det är inte gratis video på diverse sajter som hotar Apples affärsmodell utan det är video som kräver DRM-skydd. HTML5 video har inget stöd för DRM och det tvingar de som har rättigheter till materialet att antingen sälja det via iTunes, med Apples egna proprietära DRM format som skydd, eller skapa en app som säljs via Appstore. Även om appen skulle vara gratis sker det genom en kanal som Apple har kontroll på och som adderar till värdet för Apples enheter.

Flash har DRM-skydd och om iPod/iPhone/iPad hade stöd för flashspelaren, eller för den delen Silverlight som är större när det kommer till DRM, skulle det finnas ett alternativt sätt att leverera DRM-skyddat material. Jag tror personligen att många ändå skulle välja att göra egna native appar, men det viktiga att inse är att förhandlingsläget mot rättighetsinnehavare skulle bli sämre för Apple. De skulle helt enkelt inte få lika lätt att diktera villkoren när det kommer till DRM-skyddat innehåll.

När det gäller interaktivt innehåll finns det även här ett intresse att förhindra Flash. Apple vill att applikationer och spel bara ska finnas till deras plattform eftersom det ökar värdet på de enheter de säljer. Flash är i grund och botten en cross platform lösning, och det är inget som är positivt sett ur Apples synvinkel. Jag säger inte att Flash skulle klara av ens i närheten av det som många native appar idag gör, men det finns många enklare spel och liknande appar som fungerar alldeles utmärkt att utveckla i Flash. Det skulle inte påverka ens mätbart negativt på Apples försäljning i Appstore, men att vissa appar enkelt skulle kunna portas mellan olika plattformar är inget som gynnar Apple.

Om Apple skulle släppa in flashspelaren på sina enheter skulle de också öppna upp för eventuella framtida innovationer som Adobe kan tänkas göra. Den kontrollen tänker de inte släppa ifrån sig. Har de väl släppt in flash kan de inte enkelt slänga ut det i ett senare skede.

Vad innebär då allt detta för dig som flashutvecklare? Först och främst, sluta se dig som flashutvecklare och börja istället se dig som en webbutvecklare. Låt Flash bli din spets och HTML din bas. Krydda sedan gärna med andra tekniker. Kom också ihåg att Apple inte är ensamma på mobilmarknaden. De var först med en telefon som verkligen fungerade bra och var kul att använda, men konkurrensen börjar hårdna. Android ser allt bättre ut, HP har nyligen köpt Palm, Microsofts nya mobilplattform verkar extremt intressant. Alla dessa har gemensamt att de har en mycket öppnare filosofi än Apple vilket naturligtvis är till fördel för Adobe och Flash.

Man kan också se den otroliga uppmärksamhet Apple vs Flash har gett som ett kvitto på att det finns ett värde i Flash. I hela den här cirkusen som varit senaste tiden har jag läst väldigt lite om Silverlight eller Java t.ex.

Vad som är tydligt är att vi är inne i ett skifte där vi blir allt mer mobila. Våra mobila enheter blir allt mer kraftfulla och bandbredden ökar. Det för med sig att användarnas krav på innehåll ökar. Både när det gäller kvalitet och kvantitet. En lösning som gör det tidseffektivt att skapa rikt innehåll som enkelt kan nå flera kanaler har en naturlig plats. Det är inom detta området Flash hittills har verkat och det är här det även i fortsättningen har sin plats. Under förutsättning att Adobe tar sig i kragen och verkligen ser till att ge Flash tillräckligt med nya funktioner för att hålla det relevant.

Länkar:

Flex och Flashutvecklaren går igenom Steve Jobs "lögner"
http://jessewarden.com/2010/04/steve-jobs-on-flash-correcting-the-lies.html

Video som visar att HTML5 inte "magiskt" fungerar klockrent på en iPad (finns naturligtvis potential om det anpassas och optimeras).
http://www.youtube.com/watch?v=rfmbZkqORX4

Flash och multi-touch
http://theflashblog.com/?p=1975

Flashapplikationer och spel för Android
http://theflashblog.com/?p=1926

Apple är inte mer öppna än Adobe
http://arstechnica.com/apple/news/2010/04/pot-meet-kettle-a-response-to-steve-jobs-letter-on-flash.ars

Fakta om H.264 och Flash
http://www.flashstreamworks.com/archive.php?post_id=1272747220

Hur stor skada H.264 potentiellt kan ställa till med
http://www.osnews.com/story/23236/Why_Our_Civilization_s_Video_Art_and_Culture_is_Threatened_by_the_MPEG-LA

Packager for iPhone, ett första steg mot öppen källkod?

Nisse Bryngfors — Wed, 14 Apr 2010 15:20:14 GMT

Ingen kan ha undgått kampen mellan Apple och Adobe som började med att Apple vägrar flashspelaren på iPhone/iPad och fortsatt med att de via utvecklaravtal förhindrar Adobes Packager for iPhone.

Med utvecklaravtalet verkar det som att Apple har riktat in sig speciellt på Adobes lösning, men samtidigt har de "råkat" ta med andra liknande lösningar som Unity3D och Appcelerator Titanium.

Det finns skillnader i de tekniska detaljerna hur dessa lösningar fungerar. Därför är det fortfarande oklart om utvecklaravtalet kommer slå mot alla lösningar eller bara mot ett fåtal. Eftersom man kan utgå från att orsaken till utvecklaravtalet är att hindra Adobe så kan man tänka sig att andra lösningar kan klara sig.

Vad Adobe därför bör göra, om möjligt, är att avvakta och se vilka andra lösningar som Apple anser vara okej för att sedan efterlikna hur de fungerar. En gissning är att om Packager for iPhone genererar ett Objective-C projekt istället för en färdigpaketerad och signerad applikation så finns chansen att Apple inte kan stoppa det. Speciellt om de tidigare sagt okej till andra lösningar som fungerar likadant.

Förutom att en sådan lösning skulle ta bort mycket av enkelheten (paketering och signering) så skulle det också innebära att Adobe skulle exponera myckat av funktionalitet som finns parallellt i flashspelaren idag. För att Packager for iPhone ska fungera antar jag att det finns mycket kod som är direkt hämtad från flashspelren och som fungerar som wrapperkod i den kod som genereras i Packager for iPhone.

Det största hindret för att göra flashspelaren open source idag är att det finns kod som Adobe inte har rättigheter till att öppna upp. Det gäller främst deras implementering av codecs för video. iPhone appar som skapas med Packager for iPhone har inte stöd för video, annat än via Apples API, och därför elimineras problemet med kod för videocodecs.

Så om Adobe rent tekniskt kan generera ut ett Objective-C projekt, och den här biten är jag högst tveksam till eftersom de använder LLVM, så har de en utmärkt chans att göra all källkod open source. Det skulle driva på utvecklingen av Packager for iPhone, ge Adobe credd samt ta bort en del av diskussionen kring att flashspelaren inte är open source idag.

Om det här är möjligt rent tekniskt skulle det enligt mig vara ett smart drag av Adobe rent strategiskt, men även tekniskt. Packager for iPhone är i ett tidigt stadie och det finns mycket utrymme för optimering, något de i så fall skulle kunna få hjälp med av utomstående utvecklare.

En första titt på Flash CS5

Nisse Bryngfors — Sun, 11 Apr 2010 15:05:15 GMT

Idag utannonserar Adobe Creative Suite 5, en stor uppgradering av hela produktportföljen. Jag har haft möjlighet att prova Flash CS5 under några dagar och den här bloggposten summerar min första uppfattning om den nya versionen. Det är viktigt att poängtera att jag testat programmet under en begränsad tid. Vissa funktioner är det svårt att ge en rättvis bedömning av innan man använt dem under en lång tid och det är också möjligt att jag missat vissa saker. Jag gissar att jag får anledning att göra en uppföljning i en senare bloggpost.

Sammanfattningsvis

För att undvika att tråka ut mina läsare sammanfattar jag mina intryck innan jag går in på detaljerna.

Problemet med Flash Professional CS5 är att ingen ny flashspelare släppts sedan Flash Professional CS4. Visst, flashspelare 10.1 är i Release Candidate läge och kommer antagligen släppas samtidigt som CS5, men det är främst en version där Adobe jobbat hårt med att optimera och utveckla funktioner för mobila enheter. Det är en otroligt viktig release, men det är inga nya funktioner som kräver en ny version av Flash för att kunna användas.

Det som ändå gör Flash Professional CS5 relevant är funktionen för att paketera flashapplikationer så de kan köras på iPhone. När nu Apple ser ut att täppa till även den möjligheten, tidigare har de ju vägrat implementera flashspelaren, så faller Flash Professional CS5 ganska platt.

Är du utvecklare och enbart använder Flash för att skapa assets till dina applikationer bjuder Flash Professional CS5 inte på mycket nytt. Antagligen är du då mer intresserad av nyheterna i Flash Builder 4 som släpptes tidigare, och Flash catayst som också är en del av CS5. Använder du Flash till bannerproduktioner och liknande samt använder det tillsammans med andra produkter i CS familjen finns det en hel del förbättringar att dra nytta av.

Eftersom Flash Professional CS5 inte släpps parallellt med en ny version av flashspelaren har inte mina förväntningar varit speciellt höga. Jag använder Flash IDE allt mindre, oftast bara för att sätta ihop assets och exportera dem som SWC-filer, så det är inte en produkt som är riktad till mig. Jag kan dock inte låta bli att känna att den här versionen känns lite trött och visionslös (frånsett Packager for iPhone som rent tekniskt är inget annat än ren magi). Jag skulle vilja se Flash bryta ny mark och gå mot att kännas mer som ett After Effects för interaktiva lösningar. Det skulle behöva kännas mer riktat mot proffsen och inte den vanliga användaren. Jag skulle också gärna sett att Adobe experimenterade med HTML5 export från Flash. Varför inte kunna exportera bannerproduktioner och liknande projekt till HTML5 Javascript/Canvas t.ex?

Det var mina spontana tankar om Flash Professional CS5. Här kommer de viktigaste nya funktionerna i detalj.

Packager for iPhone

Packager for iPhone är Adobes lösning på problemet med att Apple varken varit intresserade eller tillmötesgående när det kommer till flashspelaren på iPhone/iPad. Packager for iPhone gör det möjligt att kompilera ut, paketera samt signera Flash AS3 projekt direkt från Flash Professional CS5. Det intressanta är att man inte ens behöver en Mac, hela kedjan kan göras på en PC också.

En iPhone applikation utvecklad i Flash Professional CS5 kross-kompileras över till ett format som kan köras på en ARM processorarkitektur. Det är viktigt att poängtera att det inte finns någon flashspelare med i slutresultatet och ingen kod som interpreteras vid körning.

Hela lösningen är väldigt imponerande och som utvecklare programmerar du som vanligt mot Flashspelarens API:er vilket sedan översätts till motsvarande iPhone API:er. Det gör att inlärningströskeln i stort sett är obefintlig, även om man sedan behöver lära sig mer för att optimera sina applikationer på ett effektivt sätt.

Naturligtvis finns det nackdelar med sådana här lösningar. Man kommer inte åt alla API:er, det kan vara svårare med optimeringar osv. Men Adobes tanke är inte att konkurrera med Objective-C utveckling utan att istället göra det möjligt att på ett enkelt sätt kunna utveckla för flera mobila plattformar, varav iPhone är en. Eftersom inga Cocoa Touch komponenter används i slutresultatet lämpar sig Packager for iPhone bäst för 2D-spel och experimentella applikationer.

Tyvärr gillar inte Apple att utvecklare ska kunna använda verktyg som kan generera kod för olika plattformar och har därför alldeles nyligen gjort ett tillägg i sin utvecklarlicens där de effektivt sätter stopp för Packager for iPhone (och många andra liknande och populära lösningar). Det innebär att funktionen i dagsläget är oanvändbar om man vill utveckla applikationer för att publicera dem i appstore. Det är möjligt att Apple ändrar villkoren, eller att Adobe kan gå runt dem på något sätt, men just nu ser det mörkt ut.

Device Central

Med Device Central kan man testa och emulera sina applikationer på olika enheter. Device Central är egentligen inte specifikt för Flash utan kan även användas via After Effects, Photoshop, Captivate, Fireworks och Illustrator. Jag har inte hunnit testa igenom det speciellt mycket men det verkar väldigt lovande. Man kan simulera multi touch, geo location, bandbredd osv. Det finns mängder av profiler för enheter och vem som helst kan skapa egna. För att testa mobilt innehåll, och då tänker jag inte enbart på applikationerutan även bakgrundsbilder, filmer och liknande, så tror jag att Device Central kan bli väldigt användbart.

Ny textmotor

Från och med flashspelare 10 finns det stöd för en ny avancerad textmotor. Den är ett direkt resultat av att Adobe köpte upp Macromedia och lånar mycket av den teknologi som idag finns i produkter som InDesign med flera. För Flash är det här ett stort steg framåt, men också något som hittills hamnat i skymundan. Orsaken till det är främst att det varit ganska svårtillgängligt eftersom det inte funnits något grafiskt gränssnitt för att dra nytta av det. Text Layout Framework, ett actionscriptbibliotek för att använda den nya motorn, har funnits tillgängligt ett tag men även det kan vara ganska avancerat att sätta sig in i.

Flash Professional CS5 erbjuder total kontroll över textmassor. Jag gillar speciellt hur enkelt det är att flöda text mellan flera textfält, något som man alltid tagit för givet i sidbrytningsprogram men som aldrig varit möjligt i Flash tidigare (man kan göra lösningar med hjälp av actionscript, men de dras alltid med en rad nackdelar). Text som flödar mellan flera textfält kan markeras som vanligt, vilket är det förväntade beteendet.

En annan användbar funktion är möjligheten att dela upp ett textfält i flera kolumner där texten automatiskt flödar melln dem. Jag kan se framför mig att detta kan komma till stor användning i applikationslayouter där man vill förändra hur texten presenteras beroende på bredd och liknande. Framförallt i en applikation som ska fungera lika bra på stora skärmar som TV-apparater likasåväl som små mobilskärmar.

För alla typografifascister så finns det oändligt med inställningsmöjligheter för att få texter att se ut som man vill.

XML-baserade källkodsfiler

Nackdelen med FLA-formatet, som Flash använder till sina arbetsfiler, är att det är ett binärt format. Orsaken till det är naturligtvis att det är effektivare men nackdelen är att det är svårt för flera utvecklare att arbeta i samma fil samt att det förhindrar tredjepartsutvecklare att skapa verktyg som använder formatet. Därför har Adobe skapat ett nytt format som heter XFL.

Det är ett bra drag av Adobe att öppna upp fler delar av komponeterna i sina utvecklingsverktyg. Föhoppningsvis leder det till att nya verktyg skapas vilket ger mer möjligheter för utvecklare.

Förbättrad kodeditor

Jag har länge känt att det största problemet med Flash IDE genom åren är att det har varit riktat mot så många olika typer av utvecklare och så många olika typer av kreatörer. Adobe vill tilltala såväl nybörjaren som den seniora utvecklaren och såväl animatörer och programmerare. Kodeditorn är ett bra exempel på den problematiken. Vid varje ny version har de haft kravet på sig att lägga till mer avancerade funktioner som t.ex. ordentlig code completion/intellisense. Samtidigt har man lagt till saker som en skriptgenerator som hjälper icke-kodaren att generera enklare skript.

I vilket fall har Flash CS5 fått en bättre kodeditor med saker som code completion/intellisense som fungerar inte bara på Flash egna API:er utan även på egenutvecklad kod. Det är bra att kodeditorn äntligen har blivit användbar, men de som gör mer avancerad utcekling har sedan länge flyttat över till verktyg som Flashdevelop, Flash Builder, FDT med flera. Jag kan se ett litet behov av förbättrad kodeditor även för avancerade utvecklare som snabbt vill testa olika idéer utan att sätta upp ett nytt projekt.Det kan också vara en stor hjälp för nybörjare när de ska böra programmera i Flash, så egentligen är det här ett bra tillskott även om större projekt alltid ska göras i mer kompetenta verktyg för utveckling.

Integration med övrig CS program, inklusive Flash Builder

Att Adobes uppköp av Macromedia skulle resultera i bättre integration med övriga program i Creative Suite var inte en direkt stor överraskning. Det har redan gjorts i tidigare versioner och Flash CS5 har möjligheterna utökats ytterligare.

Man kan redigera bitmap grafik i Photoshop via "Edit with Photoshop", exportera grafik (inklusive vektorgrafik) till formatet FXG som sedan kan öppnas i Illustrator. Exportera grafik till Flash Catalyst och jobba vidare med den där samt använda Flash Builder som kodeditor för Flash projekt. Förbättringar på att öppna format från t.ex. After Effects, InDesign och Fireworks har också gjorts.

När man använder Flash Builder som kodeditor till Flash har man också möjlighet att

Spring for Bones och Deco Tool

Bones och Deco Tool var funktioner som kom redan i Flash CS4 och i CS5 har det nu gjorts förbättringar i dessa. Bones och Deco Tool är ytterligare exempel på att Adobe försöker tilltala nybörjare. Jag tycker det är synd, speciellt när det görs på det här sättet. Verktygen är knappast användbara i skarpa projekt och varför lägga energi på det när det finns många andra områden att förbättra. De är dessutom programmerade i Actionscript 3 och det hade varit bättre att låta tredjepartsutvecklare utveckla dem och erbjuda dem som utökningar till Flash.

Videoförbättringar

Den största förbättringen när det kommer till video är att man nu kan spela den direkt på scenen, utan att kompilera och testa sin applikation. I alla fall om man använder de inbyggda komponenterna. Detta kan helt klart vara användbart, men ändå inte någon större revolution.

Förutom möjlighet att spela video direkt på scenen har Adobe förbättrat stegen att importera och bädda in video.

Apple förhindrar Adobes "Packager for iPhone"

Nisse Bryngfors — Fri, 09 Apr 2010 14:10:14 GMT

Det har länge varit tydligt att Apple aldrig kommer släppa in Flash på iPhone OS. Adobe har varit väl medvetna om detta och har därför under lång tid arbetat på en lösning som gör att utvecklare kan använda sina befintliga kunskaper de har i flashplattformen för att skapa iPhone appar. Man behöver inte ens lära sig ett nytt API, utan flashspelarens API'er mappas så långt det är möjligt mot iPhone OS API'er.

Verktyget som gör detta möjligt heter "Packager for iPhone " och kommer släppas som en del av nästa version av Flash, nämligen Flash CS5.

I samband med utannonseringen av iPhone OS 4.0 uppdaterade Apple även sin Terms Of Service, d.v.s den text som säger vad en utvecklare får och inte får göra när det kommer till iPhone-appar. Den del som påverkar "Packager for iPhone" lyder så här:

3.3.1 — Applications may only use Documented APIs in the manner prescribed by Apple and must not use or call any private APIs. Applications must be originally written in Objective-C, C, C++, or JavaScript as executed by the iPhone OS WebKit engine, and only code written in C, C++, and Objective-C may compile and directly link against the Documented APIs (e.g., Applications that link to Documented APIs through an intermediary translation or compatibility layer or tool are prohibited).

Vad betyder det här för Adobe?

Kort sagt är detta inget mindre än en katastrof. Det kommer extremt olägligt för Adobe. Lanseringen av CS5 paketet ligger endast fyra dagar bort, och "Packager For iPhone" är den enskilt viktigaste nyheten i Flash som förväntas vara det som till stor del ska driva försäljningen av Flash CS5.

Eftersom iPhone OS fortfarande är i betastadie är det fullt möjligt att texten i Terms Of Service kommer ändras. Även om den skulle göra det, och "Packager for iPhone" återigen blir tillåtet, så har det skadat Adobe eftersom det skapat en stor osäkerhet kring sådana här lösningar. Ändrar Apple texten är det bara ett tecken på att de ägnar sig åt samma FUD taktik som Microsoft ofta gjort genom åren.

Vad vinner Apple på det?

Apple ser till att knyta utvecklare närmare till sig och eftersom man måste använda Apple's verktyg kommer det även driva på försäljningen av Apples hårdvara. Apple har råd att göra så här eftersom de redan lockat till sig en stor skara utvecklare det är tillräckligt intressant att utveckla för iPhone/iPad för att man ska kunna stå ut med få val när det kommer till utvecklingsmiljöer.

Möjligheter för Google/Android

Google har en stor möjlighet här. Om Apple börjar begränsa utvecklarnas val av utvecklingsmiljöer bör Google istället jobba ännu hårdare på att ge utvecklare alternativ. Javautvecklare har redan en given plats. Google samarbetar redan nu med Adobe för att ge plattformen stöd för både Flash och AIR. De bör även se till att Silverlight fungerar bra för att bjuda in Microsoftutvecklarna.

Vad Google dessutom bör göra är att antingen ge Android stöd för C/C++ eller erbjuda en lösning liknande "Packager For iPhone" med skillnaden att man enkelt kan konvertera sina iPhone appar skrivna i Objective-C till Javaapplikationer. Båda dessa lösningar skulle underlätta att porta iPhone appar till Androidplattformen och på så sätt minska Apples monopolställning när det kommer till appar.

Vad betyder det för Flashplattformen?

Man måste komma ihåg att det finns många fler plattformar än iPhone/iPad. Flashplattformen har många ben att stå på och kommer dessutom utvecklas och ge oss fler unika möjligheter framöver. Man kan inte undkomma att iPhone/iPad är viktiga enheter att kunna utveckla för och därför är det synd att nu när Adobe har hittat en bra lösning, som dessutom bara är några dagar bort, så kommer den inte kunna användas.

Samarbetet med övriga mobiltillverkare blir allt viktigare och Adobe får helt enkelt hoppas på att Android kan bli en så stor plattform som den faktiskt har potential till.

Som utvecklare tycker jag Apples val av väg är oerhört skrämmande. Jag har full förståelse för att de vill garantera användarupplevelsen och därför vägrar att ge iPhone och iPad stöd för Flash. Men att de ger sig på utvecklarna och begränsar deras val av utvecklingsmiljö är en helt annan sak. Och om du tror att detta bara påverkar Adobe så ska du tänka om. Det finns många andra verktyg som fungerar på samma sätt och som också ligger i farozonen, t.ex. Unity som används till många av de populära 3D-spelen i Appstore.

Det står helt klart att iPhone och iPad har blivit mindre intressant för utvecklare som vill använda andra verktyg än Apples egna. Tyvärr är detta inget användarna kommer bry sig om och därför kommer iPhone och iPad fortsätta sin succé. Oavsett att villkoren för de vanliga arbetarna, d.v.s. utvecklarna, har blivit mycket sämre.

Fler som skriver om Apples nya licensavtal:

http://www.idg.se/2.1085/1.309118/apple-stoppar-adobes-flash-konverterare

http://www.teknikveckan.se/2010/04/apple-blockerar-flash-packager-for-iphone-i-sdk-4-agreement/

Jobbletande Flashutvecklare sökes

Nisse Bryngfors — Thu, 25 Mar 2010 15:17:31 GMT

Eftersom jag trivs bra på Sticky Beat, där jag jobbar, så är jag själv inte intresserad av att hoppa på sådana här erbjudanden om de inte går att göra som projekt via Sticky Beat. Däremot tipsar jag mer än gärna andra flashutvecklare om jobben.

Om du är intresserad av att bli tipsad när, och om, det dyker upp något så skicka gärna dina kontaktuppgifter till mig. Skriv också några rader om vad du kan, vad du vill, var i landet du kan tänka dig att jobba och liknande. Jag kan naturligtvis inte lova att det leder till något, men man vet aldrig.

Skicka dina uppgifter till nisse@bryngfors.com. Tack!

Från Flash till iPhoneutveckling - intervju med Anders Färdigh

Nisse Bryngfors — Sat, 13 Feb 2010 15:48:46 GMT

Många flashutvecklare har blandade känslor när det kommer till Apples iPhone. Det är en telefon som imponerar när det kommer till användargränssnitt och funktion, men samtidigt är det en stängd plattform där Apple skriver reglerna. Som alla vet har Apple beslutat sig för att inte ge iPhone stöd för Flash vilket gör det svårt för flashutvecklare att kunna utveckla program för plattformen.

Valet är att antingen gå vägen via HTML5, som i sig inte skiljer sig speciellt mycket från Flash, eller att ta steget fullt ut och lära sig Objective-C och Cocoa. Vill man distribuera sina applikationer via App Store har man inget val, då är det Objective-C som gäller. Det finns, och det kommer fler, lösningar som gör att man kan utveckla i andra språk, men att använda Apples verktyg är det säkraste kortet.

Jag fick chansen att ställa några frågor till iPhone-utvecklaren Anders Färdigh. Han utvecklade tidigare främst för flashplattformen men har nu tagit steget till att mestadels utveckla för iPhone.

Kan du berätta lite kort om dig själv och din bakgrund när det gäller både flashplattformen och iPhone utveckling?

Efter att ha frilansat inom webbutveckling och mobil grafik började jag på Illianced med flashutveckling som enda fokus. Därefter började jag frilansa igen, till en början enbart med Flash. Sedan ett år tillbaka har jag använt iPhone SDK:t och senaste halvåret har jag mer eller mindre uteslutande arbetat med iPhone-projekt. Nu senast har jag varit med och startat upp mobilbyrån Appsters.

När du började att utveckla för iPhone, hade du någon nytta av dina tidigare erfarenheter från flashplattformen?

Absolut. Framförallt som en grund för att gå över till ett annat objektorienterat språk.

Hur var inlärningströskeln? Något speciellt som du upplevde som extra svårt?

Det svåraste för min del var att hitta rutiner för minneshantering som fungerar lite annorlunda. Sen är syntaxen till en början rätt främmande. Numera ser jag dock Objective-C som mitt huvudspråk och ser mer fördelar än nackdelar med det.

Vad gäller grafik och animering tycker jag fortfarande att Flash kan vara mer lättöverskådligt och snabbjobbat så fort man lämnar standardkomponenterna i iPhone SDK:t.

Vad har du för tips att ge till flashutvecklare som vill börja utveckla iPhoneapplikationer?

Alla är väl olika, men jag tror att man tjänar på att verkligen lära sig Objective-C och Cocoa-ramverket relativt grundligt. När man väl har koll på det kommer det gå i hög takt framåt.

De som redan utvecklar AS3 tror jag generellt har en ganska hög programmeringsmässig grundförsåelse och många klarar sig nog på material som finns på internet. Apple’s dokumentation i samband med iphoneutvecklingsbloggar kommer man långt på.

Jag skulle rekommendera att börja kolla på sajter som icodeblog.com , cocoadevcentral.com och cocoawithlove.com. Stanfords iPhonekurser (iTunesU) verkar också bra. Såg ett avsnitt men hade kommit lite för långt kunskapsmässigt för att uppskatta det. Tror dock att de är perfekta som introduktion.

Sen kan man hålla lite koll Sweden iPhone Development (iphonedev.se) och CocoaHeads Stockholm om ni söker den lokala iPhone-communityn för att träffa andra utvecklare: http://groups.google.com/group/iphonedev-swe ,
http://groups.google.com/group/cocoaheads-stockholm

Vad gäller det kodmässiga har jag verkligen lärt mig uppskatta Apples standardkomponenter/-lösningar. Läste nyligt en bloggare som skrev “If you can’t do it better than Apple – don’t do it”, vilket jag tycker är något man bör ta till sig. Program som Tweetie, DN På Stan, Flickr m fl tycker jag ändå ger en mycket bra användarupplevelse.

En stor orsak till Apples succé med iPhone är ju naturligtvis App Store och möjligheten för utvecklare att ta betalt för sina applikationer. Dock känns det lite som att guldruschen är över nu. Kan man fortfarande tjäna pengar på att sälja appar eller är konkurrensen för hård?

Det är nog få som tjänar stora pengar på att sälja appar. Om man släpper en app för svenska marknaden kan man ganska snabbt räkna ut att det är svårt att bli rik. Det går inte heller att bara släppa en app och tro att den automatiskt når topplistorna även om den är bra. Marknadsföring av app känns som en minst lika viktig del för att lyckas nu när du ska synas bland 140 000 appar. Det finns ju dock andra sätt att tjäna pengar förutom på just försäljningen via AppStore.

Adobe visade i slutet av förra året upp ”Packager for iPhone”, en lösning som tillåter utvecklare att skapa applikationer för iPhone direkt från Flash med Actionscript 3.0 som programmeringsspråk. Det finns också andra liknande utvecklingsverktyg. Ser du någon framtid för den här typen av lösning?

Jag har inte använt “Packager for iphone” och har inte tillräckligt stor insikt för att bedöma ur stort Flash kan bli som utvecklingsmiljö för iPhone-appar. Jag har dock inte blivit imponerad av något som släppts via Packagern hittills. Då jag provade spel på en iPhone 3G var prestandan dessutom rätt dålig, men det har jag förstått ska vara bättre när lösningen släpps för allmänheten.

Jag är inte heller direkt imponerad av det jag testat hittills. Är det möjligt att lösa
prestandaproblemen? Finns det inte en risk att man ändå måste optimera sin kod för iPhone och att fördelarna då till stor del försvinner?

Prestandan känns som en superviktig del för att Adobe ska lyckas med iPhone-satsningen. Måste dock erkänna att jag hoppas att AppStore inte väller över av "Flash-iPhone-appar" och spel. Dels för att det blir svårare att synas men även för att Apples granskningsprocess kan bli längre.

Skulle du kunna tänka dig att använda sådana här utvecklingsverktyg, eller är nackdelarna för stora?

Jag har börjat gilla objective-c till den grad att jag helst inte lämnar språket förutom för korta utsvävningar. Men ett utvecklingsverktyg som skulle skapa bra och prestandaoptimerade program för flera plattformar skulle absolut kunna vara intressant. Där exempelvis Flex inte bara kompilerar en flex-app utan även en native Android- och iPhone-app. Jag skulle gärna höra om någon läsare vet mer.

Hur ser du på framtiden för iPhone och dess applikationer? Är det verkligen hållbart att fortsätta utveckla för en specifik plattform med tanke på nya enheter och plattformar som börjar dyka upp?

Det känns som att det är svårt att få de stora mobiljättarna att närma sig varandra så i stora drag lär mycket vara likt hur det ser ut nu även om det inte är tidseffektivt för utvecklare. Jag antar att man kommer välja plattformar efter budget och målgrupp. Sen kommer nog Apple, Google, Samsung, Microsoft och Intel/Nokia göra sitt bästa för att locka till sig utvecklare av sina respektive plattformar. Appar känns centralt för att lyckas just nu och de vill självklart åstadkomma samma succé som Apple fått med AppStore, vilket genererar både användare och pengar.

När man pratar om Flash och iPhone är det ofrånkomligt att inte diskutera avsaknaden av Flashspelare. Vad är dina tankar kring att iPhone ännu inte har stöd för Flash?

För iPhone bryr jag mig inte så mycket. Det är ingenting jag saknar. Däremot är det något jag defintivt skulle uppskatta i en iPad.

Precis. Vad tror du är orsaken till att Apple vägrar Flash? Prestanda, strategi?

Strategi. Vet inte hur stor vikt man ska lägga vid Steve Jobs uttalanden om att det är för buggigt.

Apple har ju tydligt visat att det är HTML5 som gäller för webbapplikationer och Objective-C för applikationer till App-store. Har Flash någon framtid? Då tänker jag främst på iPhone, men också i ett större perspektiv.

Flash på iPhone verkar ju vara rätt dött och HTML5 verkar kunna ta stora delar av det som tidigare per automatik kopplats till flash. Jag tror dock att Flash kommer ha en stark roll inom kombinerade webb/desktop-lösningar samt spel.

Tusen tack för att du ställde upp på den här intervjun. Har du några egna appar du vill tipsa om, eller kanske några andra appar du själv tycker är bra?

Tack själv! Det var bara roligt. Jag jobbar fortfarande en del incognito som underleverantör, men under våren kommer Appsters slutföra några intressanta egna kundprojekt. På startskärmen: Tweetie2, Dropbox, Analytics App, Wordpress2, Orbital, DN På Stan, SVT Play.

Apple iPad, den verkliga flashdödaren

Nisse Bryngfors — Sat, 30 Jan 2010 02:25:38 GMT

Efter en rejäl rykteskarusell släppte då Apple sin tablet dator iPad. Personligen gillar jag konceptet. Jag kan se ett behov av en dator som alltid är på, har ett enkelt och intuitivt gränssnitt och som kan användas till att konsumera allt från böcker till film. Dessutom är priset överkomligt. Däremot är jag tveksam till avsaknaden av t.ex. multi tasking och HDMI-port.

Naturligtvis kan jag inte undvika att beröra det som antagligen påverkar mig mest, nämligen att iPad inte har stöd för Flash. Jag vet att det finns minst sagt delade åsikter om Flash. Oavsett vad man tycker måste man ändå medge att det finns oändliga mängder befintligt innehåll på nätet som använder flashplattformen. Det är inte heller bara video utan också spel, applikationer, experimentella sajter, kampanjsajter och så vidare. Att iPads webbläsare Safari inte har stöd för Flash innebär att man som användare missar mycket av det som nätet erbjuder idag.

Jag tror att det främst finns två orsaker till varför Apple vägrar Flash. Den ena är att de vill ha kontroll över sin plattform. En enhet som iPad lever mycket på att den är enkel och fungerar utan att krascha. Instick ger Apple mindre kontroll och heller ingen möjlighet för dem själva att åtgärda problemen när de dyker upp. Den andra orsaken är att en stängd plattform är lättare att tjäna pengar på. Flash skulle kunna vara ett alternativ till många av applikationerna på app store. Inte minst när det kommer till spel.

Så vad spelar det här för roll för flashplattformen? Det beror först och främst på om iPad blir en succé eller inte. Apples iPad har en smalare och mer outforskad nisch än vad iPhone hade när den introducerades. Å andra sidan är konkurrensen desto mindre. Den har alla möjligheter att lyckas, speciellt eftersom den riktar in sig på en bred publik till ett överkomligt pris.

Om vi utgår från att iPad blir en succé så är det på kort sikt onlinevideo som kommer påverkas. Eftersom video via Flash inte fungerar på iPad så måste sajterna skapa alternativa videospelare. Närmst till hands blir då en spelare som utnyttjar videotaggen i HTML5 och som faller tillbaka på flashvideo för de som inte har moderna webbläsare. På lång sikt blir iPad alltför viktig att bortse från och då kommer det helt enkelt skapas mindre med flashinnehåll.

Ytterligare en sak att ta i beaktning är att reklambyråer, digitala byråer och
produktionsbyråer i ganska stor utsträckning använder produkter från Apple. Det finns en möjlighet att iPad blir deras nya leksak. Den kommer sätta nivån för hur digitala kampanjer ska se ut och finns det inte flashstöd kommer HTML5 eller iPad appar att användas istället.

Jag tror iPad kommer lyckas. Jag tror inte Apple har något större intresse av Flash. Naturligtvis är detta ett riktigt bakslag för både Adobe och flashplattformen. Det kan till och med vara det som ger skjutsen framåt som HTML5 för tillfället behöver. Vi får se.

Oavsett vad, är du flashutvecklare har du inget att vara orolig för. Apple har med iPad, och tidigare iPhone, visat att användarvänlighet och användarupplevelse är viktigt och efterfrågat. Det är precis det du jobbat med i alla år. Det är bara att ta den erfarenheten till en ny teknik. Jag har tidigare berört detta i posten "Därför ska flashutvecklare inte frukta HTML5".

Till sist, kommer jag själv att köpa en iPad? Ja, troligen.

Så gjordes Tackfilm - intervju med flashutvecklaren Johan Åhman

Nisse Bryngfors — Tue, 05 Jan 2010 18:14:40 GMT

Kampanjen Tackfilm från Radiotjänst får kanske ses som en av 2009 års mest lyckade nätkampanjer. Den lyckas kombinera en stark idé med en mycket välgjord och dramaturgisk genomarbetad film, allt förpackat på ett mycket snyggt och tekniskt bra sätt.

Det är i sådana här produktioner Flash verkligen skiner och man omöjligt kan ifrågasätta valet av teknik. Jag blev lite nyfiken på hur tackfilm gjordes och vilka problem och lösningar som avverkats längs vägen. Jag lyckades få kontakt med flashutvecklaren Johan Åhman på produktionsbolaget Moment77 som var ansvarig för de tekniska delarna i projektet. Johan var tacksamt nog villig att göra en kort intervju om projektet.

Ska vi börja med att du berättar lite om din bakgrund, om hur du började med Flash och hur länge du har jobbat som flashutvecklare.

Egentligen har jag nog aldrig börjat eller slutat. Jag kommer ihåg att jag gjorde en beatbox app runt -98/-99 någon gång, så det måste ha varit kring den tiden. Men efter det så har jag hoppat ganska mycket fram och tillbaka mellan olika miljöer i såväl kod som arbete, och det har ibland gått flera år mellan gångerna jag öppnat Flash. Men nu är det slut på det. Jag har bestämt mig för att exkludera annat och koncentrera mig på Flash. Det är helt klart det roligaste jag vet att jobba med. I alla fall just nu.

Tackfilm blev på kort tid väldigt populär och har fått en enorm viral spridning. Hur känns det när något man varit med och skapat blir en sådan succé?

Jo, den tog fart ganska omedelbart. Jag kommer inte ihåg exakt hur många unika besök det var under första dagarna men det var astronomiska siffror för att vara en viral kampanj vid det stadiet. Själv sitter jag ganska långt nere i näringskedjan och har väl inte vältrat mig i några hyllningar direkt. Jag märkte först vilken enorm genomslagskraft kampanjen haft när en släkting långt utanför det normala spridningsområdet kommenterade den nu under jul. Häftigt.

Som du själv nämner så uppmärksammas sällan de som sitter längre ned i näringskedjan när sådana här produktioner blir en succé. Är det något du saknar?

Näe, egentligen inte. Förut kändes det viktigare att vinna awards och stå på scenen för projekt jag varit delaktig i, att vara inne i svängen så att säga. Jag har flyttat från Stockholm till Umeå för att komma ifrån den delen av mitt arbete och jag trivs enormt bra av att jobba som jag gör nu. Det känns inte så viktigt för mig att vara en del av den kreativa processen längre, att slåss för "nya galna idéer" i konceptmöten. Jag gillar upplägget av att kunden har en idé på vad de vill göra, och jag löser deras problem. Självklart kommer jag med förslag och lösningar, utvecklingar på deras grundidéer. Production is the new black.

Varför tror du just Tackfilm lyckades nå ut så bra?

Delvis på grund av tekniken såklart. Har fått väldigt många kommentarer om just "plånboksscenen" som många upplever som ett tekniskt genidrag. Men även på grund av enkelheten, dels att sprida filmen men även att skapa en egen film är ju extremt enkelt och intuitivt. Sen handlar det såklart om timing också. Tekniken har ju funnits för att göra detta, men ingen har så vitt jag vet vågat löpa linan fullt ut och implementera det i den här skalan. Ny teknik ger ju automatiskt en knuff i ryggen. Sen får ju vilken människa som helst en ego-boost när hon drar fram kortet ur kuväret. ;)

Det är alltid många inblandade i en produktion av sådana här mått. Vilka andra har varit delaktiga, och vilken var din roll i projektet?

Reklambyrån var Draft FCB, och produktionsbyrå var Stopp , som i sin tur kontaktade mig för att lösa det tekniska, långt nere i de trånga korridorerna så att säga. Jag trivdes som fisken i vattnet från projektets start med den roll jag hade. Även om jag ägnat ofantliga timmar åt buggtestning och vilken teknik vi i slutändan skulle använda. Jag har även gjort ett GUI för filmen, så att videoredigerarna på Stopp kunde färgsätta fotot som laddas upp/tas med webbkamera, så att det i största mån smälter in i filmen. Detta GUI går att testa på vår hemsida, www.moment77.se.

Var du från början säker på att det skulle gå att lösa i Flash, eller fanns det en risk att begränsningar i tekniken skulle sätta stopp på ett tidigt stadie?

Jadå. Stopps egna flashutvecklare hade gjort ett statiskt proof of concept, så vi visste att det gick att lösa på ett sätt eller ett annat. Sen var det upp till mig att forska vidare och hitta nya lösningar och att producera slutprodukten. Men visst, det fanns tillfällen då jag tvivlade på att jag inte kunde nå hela vägen fram. Men så länge man är ihärdig och uppfinningsrik så löser sig det allra mesta, vilket det gjorde även denna gång. Nu har vi flera nya projekt där vi står på samma linje och sliter vårat hår. Det är en nervpirrande känsla som är oslagbar när man kompilerar och inser att det fungerar som det är tänkt!

Kampanjsajten går ut på att användaren spelar hjälten i filmen genom att ladda upp ett kort på sig själv. Kortet passas sedan in helt naturligt i olika sammanhang i filmen. Hur är den här effekten gjord?

Jag fick en filmsnutt och 4 ascii-filer med trackingpunkter, x & y koordinater och vilken frame i filmen varje punkt hörde till. Ett av kraven från start var att vi skulle nå samma kvalitet som SVT Play och då i streamat format. Den mesta delen av buggtestning gick åt i denna fas, då många nya gråa hår växte ut och ändlösa kvällar med att leta mig fram mellan hinder och problem. I slutändan visade det sig att det inte går att göra ännu, på grund av vad jag ser som en bugg, som gör att flash spelar upp samma frame vid två olika tidskoder lite då och då. Det blir ungefär så här: 1 2 3 4 5 6 7 7 8 9 10 11 11 12 13 14 14 15. Så i slutändan blev vi tvungna att embedda filmen och köra den som swf för att kunna matcha trackingpunkterna till 100%. Jag nådde en träffsäkerhet på 98-99% med streamad film, men den minsta misspassningen är så extremt tydlig att det tyvärr inte höll hela vägen.

Hoppas att någon kan motbevisa mig!

Det känns som att det just nu är mycket diskussioner dels kring nackdelarna med Flash samt att HTML 5 är på framfart och börjar ta över mycket av det som tidigare endast varit möjligt att åstadkomma med Flash. Men trots problemen du stött på, hade det verkligen varit möjligt att göra det här projektet på något annat sätt?

Jag tror inte riktigt att det finns något bättre sätt att göra det på. Jag kan så lite om Silverlight, men antagligen borde det väl ha gått att göra där också. Och HTML 5 ser jag så avlägset ännu att jag själv tror att det dröjer länge innan större kunder väljer att satsa på det själva. Tyvärr. Det är ju oftast de som har möjlighet att påverka utvecklingen snabbast och driva nya tekniker framåt, med den stora massan.

Det som imponerade mest på mig var hur väl kortet smälter in i filmen. Man ser reflektioner i kortet och färger stämmer väl överrens med resten av filmen. Det känns väldigt genomarbetat. Vad har gjorts för att resultatet ska bli så bra?

Dels så handlar det såklart om postproduktionen som Stopp har gjort, men även att färgmatcha fotot med rätt nyanser och färgtoner hade en väldigt stor inverkan. Detta kan alla såklart få testa själva via GUI på moment77.se .

Men i övrigt, t.ex. plånboksscenen är en alphakanal som ligger i filmen som jag fick levererad. Så väldigt mycket av det visuella mästerverket står Stopp för!

Har du några råd till de som vill skapa en liknande effekt? Kanske saker du önskar att du visste innan du började utvecklingen.

Har blivit ombedd att hålla inne de smaskigaste detaljerna tillsvidare, eftersom det verkar ha skapat ett ha-begär hos flera kunder till byråerna, så jag antar att de vill behålla försprånget så att säga. Men som alltid är det ju bra att få så mycket information som möjligt innan man sätter igång. Hade kunnat spara rätt mycket huvudvärk om materialet jag fick levererat stämde från början, så det är ett hett tips! Säkerhetsställ att trackingkoderna matchar den film du testar mot.

Används några speciella ramverk eller kodbibliotek i applikationen?

Jag skrev det mesta från grunden, har enbart använt mig av Grant Skinners ColorMatrix class för att färgsätta fotot på ett smidigt sätt.

I andra projekt, har du några favoritramverk eller kodbibliotek du brukar använda dig av?

CASA lib är nog det enda återkommande som jag använder mig av. Full med godsaker. Sen är det ju väldigt specifikt beroende på de projekt jag jobbar med. Jag är ytterst tacksam och faller på knä för alla de som producerar och släpper sina libs opensource. Det bidrar så otroligt mycket till utvecklingen och man har en chans att lära sig av hur andra tänker. Tusen tack till alla er som gör sådant. Vi (på moment77) håller själva på för tillfället med ganska kraftfulla optimeringar av FLARToolkit och FaceTracking lib, och möjligheten att spela in video från flash med dynamiska objekt. Förhoppningsvis kommer vi att få ge tillbaka lite till communityt, och hjälpa till att knuffa fram gränserna ännu ett steg. Självklart blir dessa tillgängliga för alla så småningom!

Kan du berätta lite om din utvecklingsmiljö när du gör flashprojekt?

Jag kodar just nu i Flash Builder 4, tycker att de har lyckats väldigt bra med denna version, speciellt med tanke på Eclipse och hanteringen av live-debugging. Känslan av att kunna koda i 30 minuter och sedan kompilera utan att ha missat ett kommatecken eller deklaration av en variabel är jäkligt skön. Sen ser jag fram emot integrationen med Flash CS5 och Flash Builder vilket verkar bli otroligt smidigt.

Till sist vill jag passa på att gratulera till en mycket lyckad kampanj, även om du ”bara” stod för den tekniska lösningen. Kommer vi få se mer intressanta produktioner från dig under 2010?

Tusen tack! Jadå det hoppas jag, även om ribban ligger ganska högt nu så håller vi på med flera intressanta projekt just nu. Håll utkik på twitter eller på hemsidan under våren!

Så gör du en mosaikbild som kan zoomas i Flash

Nisse Bryngfors — Tue, 29 Dec 2009 21:25:32 GMT

Varje år, eller åtminstone de tre senaste åren, gör jag egna julkort som jag skickar till familj och vänner. Jag försöker vara lite kreativ och göra så personliga julkort som möjligt. De tre senaste årens julkort är upplagda på Flickr.

När man har barn är det mer eller mindre givet att de ska finnas med på julkortet. Som en liten ironisk passning tänkte jag det kunde vara kul att spinna vidare på det temat, men överdriva det en aning. Resultatet blev en mosaikbild på barnen beståenda av alla kort tagna under året. Mosaikbilden är uppbyggd av mer än 800 enskilda bilder.

Det är naturligtvis omöjligt att sätta ihop en sådan här mosaik utan hjälp av något program. Programmet jag använde mig av heter AndreaMosaik och är väldigt kompetent. Man kan göra många och detaljerade inställningar, men framförallt kan den generera ut mosaikbilder i väldigt höga upplösningar.

En mosaikbild består av flera andra bilder vilket gör det väldigt lätt att skapa högupplösta bilder med hög kvalité och detaljrikedom. Sådana här bilder är väldigt intressanta att zooma in i. Nackdelen är att de blir väldigt stora i filstorlek.

En lösning på det problemet är att stycka upp bilden i flera mindre bilder och i flera zoomsteg. På det viset kan man låta användaren zooma i delar av bilden utan att ladda ned hela bildfilen på en gång.

Med Silverlight 2 slog Microsoft på stora trumman när de visade upp funktionen Deepzoom. Med Deepzoom är det möjligt att enkelt skapa zoombara bilder utifrån en högupplöst bild. Men faktum är att det varit möjligt sedan länge i Flash. Det finns flera tredjepartsverktyg som löser uppgiften, men vad många inte vet är att man kan göra det direkt via Photoshop.

Om man öppnar en bild i Photoshop och sen väljer "File" och "Export..." så finns det ett val som heter "Zoomify". Vad som händer är att bilden styckas upp och exporteras i ett antal mindre bilder i olika zoomnivåer. Dessa laddas sedan in i en liten bildvisare byggd i Flash beroende på hur användaren panorerar och zoomar.

Jag har gjort en Zoomifybild av mitt julkort och har laddat upp den så att du själv kan se hur det fungerar här.

Svårare än så är det inte att skapa zoombara bilder i Flash.

5 möjligheter för Flash att integrera bättre med webbläsare

Nisse Bryngfors — Sat, 12 Dec 2009 17:16:32 GMT

I en tidigare bloggpost skrev jag om 10 anledningar varför sajter byggda i Flash inte alltid suger. Min poäng var att de saker flashspelaren vanligtvis får kritik för oftast är ganska enkla att lösa, bara man vet hur.

Men det finns naturligtvis saker som kan fungera mycket bättre. En av dessa är hur flashspelaren interagerar med webbläsaren den körs i. Det skulle öka användbarhet avsevärt samtidigt som Flash i större grad skulle likna hur HTML beter sig och därmed även hur användare förväntar att det ska bete sig.

Antagligen finns det orsaker till varför inga av dessa punkter är fixade i flashspelaren. Troligaste orsaken till det är att det inte finns något API för webbläsarfunktioner, eller åtminstone inga standardiserade API:n. Oavsett, följande fem punkter skulle förbättra Flash avsevärt.

1. Utskrift

Flash har bra möjligheter för utvecklaren att bestämma hur utskrifter ska se ut. Ofta vill man inte skriva ut exakt det som användaren ser på skärmen utan istället anpassad information som gör sig bättre på papper. Problemet är att gör man det så har användaren två sätt att skriva ut på. Antingen via ett val i flashapplikationen eller genom att använda webbläsarens val för utskrift. Sannolikt väljer användaren det senare och då har utvecklaren ingen möjlighet att styra utseendet på utskriften. Det blir istället upp till webbläsaren.

Om man i Flash fick reda på när användaren väljer utskriftsvalet i webbläsaren skulle man enkelt kunna göra snygga utskrifter. Inget nytt att lära för användaren utan allt fungerar "precis som vanligt".

2. Sök

Att söka efter text via webbläsarens inbyggda sökfunktion fungerar utmärkt i HTML. Tyvärr fungerar det inte alls i Flash. Det går naturligtvis att implementera en egen sökfunktion men den kommer inte fungera när användaren använder webbläsarens inbyggda.

Hade det funnits ett sätt i Flash att få reda på när en sökning via webbläsaren görs så hade det öppnat upp många möjligheter. Man skulle då kunna använda sin egna sökfunktion i Flash för att hitta texten som eftersöks. Man skulle inte heller vara begränsad till att bara visa upp text utan även kunna markera bilder och liknande som passar in på sökfrasen.

3. Kortkommandon

När en flashapplikation väl fått fokus så släpper den inte igenom några kortkommandon till webbläsaren. Ett tydligt exempel är att försöka skapa en ny tom tabb i webbläsaren via kortkommando när man är på en flashsajt. Det fungerar helt enkelt inte.

Ett sätt att lösa detta på hade varit att kunna definiera en lista av kortkommandon som flashapplikationen inte är intresserad av och därför släpper vidare till webbläsaren. På så sätt blir det upp till utvecklaren att bestämma vilka kortkommandon man vill ta hand om själv och vilka man överlåter till webbläsaren.

4. Statusfältet

Den största nyttan av statusfältet i webbläsaren är att kunna se vart länkar går innan man klickar på dem genom att föra muspekaren över dem. Gör du samma sak i Flash händer ingenting.

Det går visserligen att uppdatera statusraden i webbläsaren via javascript men om detta åtminstone skedde per automatik för länkar skulle det vara en klar förbättring för besökarna.

5. Zooma in/Zooma ut

Man kan zooma innehållet på en webbsida genom kortkommando, scrollhjul eller i webbläsarens menyer. Kortkommando och scrollhjul kan man lösa i Flash men inte om det görs via menyerna.

Återigen, hade man kunnat få reda på när användaren gör ett val via menyn hade man enkelt kunnat förändra applikationen. Användaren hade heller inte behövt att lära om.