Vi gör tvärt emot vad konferensen självt gjorde och placerar visionärerna sist i vår berättelse i stället för först.

Årets upplaga av mobilism.nl var i praktiken inte en utan två konferenser: den ena, som vi beskrev i det förra inlägget en ganska teknisk historia med en lite pessimistisk ton: den andra bestod av två mycket visionära framträdanden av två ganska världsberömda personer i sin i och för sig ganska snävt avgränsade värld.

Read the rest of this entry »

I del fyra så gjorde vi en djupdykning om varför en hybridmetod oftast är det bästa alternativet vid apputveckling. I denna femte och avslutande del av denna bloggserie så gör vi en sammanfattning av hybridmetoden och vad beslutsfattare bör tänka på när de väljer leverantör:

Fördelar med att välja hybridstrategi

Följande punkter belyser några av de viktigaste fördelarna med att välja hybridmetoden för apputveckling:

• Utveckling av prototyper är enkel och snabb
• Största delen av koden kan återanvändas och är plattformsoberoende
• Appar kan enkelt distribueras på flera AppStores
• Appar kan distribueras direkt i webbläsaren
• Budgeten räcker längre så att appar kan göras tillgängliga på fler enheter

Att tänka på när du väljer leverantör

Följande kunskaper är de viktigaste hos din nästa tjänsteleverantör. Några viktigare än andra, men alla bör vara närvarande:

• Expertis inom HTML5 och CSS3
• Expertis inom modern JavasScript (t.ex ramverk som Underscore.js & Backbone.js)
  Expertis kring s.k. “Restful APIs”
• Stor kunskap om den mobila infrastrukturen
• Kunskaper i Objective-C
• Kunskaper i Java
• Mobil serverutveckling (t.ex Node.js, MongoDB)

I del tre i denna bloggserie så diskuterade vi mer ingående de fyra val av mobila operativsystem som beslutsfattare har för sina app-projekt. Faktum är att det finns ett till, en hybridmetod som många gånger fungerar bättre.  I denna artikel tar vi en närmare titt på denna hybridmetod.

“Native” -utveckling är svårt

Det är lätt att förstå att även om företag kan utveckla “native” för flera mobila operativsystem blir kostnaden i både tid och budget snabbt ohållbar.

Därför är det inte oväntat att både företagsledare och utvecklare letar efter alternativ till en utvecklingsmetod som är renodlat “native”.

En hybridmetod

En strategi som kan råda bot på den fragmenterade verklighet som nativeutveckling utgör är hybridmetoden.

Denna metod används idag på stora företag som t.ex. Facebook, LinkedIn och Bank of America.

Hybridutveckling är en blandmetod som utnyttjar det faktum att moderna smartphones har tillgång till en mer avancerad webteknologi som t.ex. HTML5, CSS3, Backbone.js, Underscore.js och Node.js som är gemensam för alla relevanta mobila operativsystem. Webteknologin blandas med “native” -element för vissa delar av applikationen.

Vid utveckling med hybridmetod skapas en lättviktig “ram” för applikationen med hjälp “native”-utveckling vilket innebär att utvecklare kan förpacka för distribution via t.ex. Apples App- Store.

Hybridmetoden låter även organisationer publicera appar direkt i webbläsaren vilket är vettigt eftersom majoriteten av native appar för det mesta redan visar övervägande webbinnehåll.

Det bästa av två världar

På detta sätt kan en app utnyttja det bästa av båda teknologierna, den kan distribueras i en AppStore men även distribueras som en webbaserad app som körs direkt i webbläsaren.

Kanske ännu intressantare är att denna metod gör det möjligt att underhålla en app på ett modulärt, organiserat och utbyggbart sätt.

Till exempel kan organisationer utöka funktionaliteten i sina appar på ett iterativt och flexibelt sätt utan att behöva gå igenom olika AppStore -procedurer varje gång en uppdatering gjorts.

Genom att använda en hybridmetod kan en prototyp av appen skapas direkt i webbläsaren och dess huvudsakliga funktionalitet utvärderas och analyseras snabbt.

På så sätt kan man bespara sig “tunga lyft” programmeringmässigt i ett projekt som kanske ännu inte är fullständigt definierat.

I förra delen av denna bloggserie så pratade vi om hur komplicerade app-projekt snabbt kan bli. I del tre så går vi igenom de fyra val som beslutsfattare har vid beslut kring mobila operativsystem:

Att utveckla “native”

Det längre svaret kräver en lite djupare förståelse av de olika plattformarna och vad som kommit att kallas “native” – utveckling.
Begreppet refererar till utvecklingen av appar i det programspråk som är exklusivt för varje operativsystem.

Det finns många mobila operativsystem, men de viktigaste är naturligtvis iOS och Android med Windows Phone och WebOS på tredje respektive fjärde plats.
Alla dessa operativsystem använder programmeringsspråk som är exklusiva för sig själva och det finns mycket få utvecklare som behärskar samtliga.

Låt oss gå igenom fyra av dem:

iOS (och Objective-C)

iOS har utan tvekan varit ledande inom det som kallats “Post-PC” -revolutionen och är det operativsystem som körs på Apples iPhone och iPads. Däremot är systemet i rena installationssiffror på väg att börja passeras av Android (mer om det längre ner).

iOS -appar programmeras i ett språk som kallas Objective-C.

Det största problemet med Objective-C är att det inte finns så många Objective-C programmerare att anlita och de som är bra är antingen väldigt dyra eller mycket upptagna.

En stor anledning till bristen på Objective-C programmerare är att de ofta startar egna företag baserat på egna appar som de distribuerar via Apples AppStore.

En annan anledning till svårigheten att genomföra ett iOS projekt är den mödosamma processen att få appar lanserade och distribuerade via AppStore.

Android (och Java)

En fördel med iOS är att Apple lyckats få de flesta användarna att uppdatera till senaste versionen, vilket är avgörande när appar behöver avancerade funktioner.

Android är en plattform med s.k. öppen källkod som Google lanserade 2008 som konkurrent till iOS. Detta operativsystem distribueras gratis.

Det faktum att det är gratis är anledningen till att installationbasen ökade dramatiskt under 2010. Globalt har Android har passerat iOS som det mest installerade mobila operativsystemet. Enheter baserade på Android produceras av många tillverkare t.ex. HTC, Samsung, Sony eller Amazons Kindle Fire.

Appar för Android programmeras i ett språk som heter Java. I motsats till Objective-C är Java-utvecklare lättare att hitta, problemet här är snarare att identifiera vilka som är bra.

Huvudorsaken till att det är lättare att hitta utvecklare för An- droid är att Java länge varit det kanske vanligaste programmeringsspråket i världen. Eftersom Android Market inte blivit lika populärt bland konsumenter som Apples App Store har inte utvecklarna haft samma tendens att starta egna företag.

Ett problem med Android är den stora fragmenteringen av operativsystemsversioner (http://goo.gl/y8vwe). Effekten blir att det är svårt att vara säker på vilken funktionalitet som kommer att finnas på målenheterna.

Andra relevanta mobila operativsystem

Även om det är tydligt att dagens smartphonelandskap domineras av iOS och Android och att det kommer bli ytterst svårt att ta marknadsandelar från dem finns det ytterligare två mobila operativsystem som företagsledare bör känna till.

Windows Phone (och Silverlight)

Windows Phone är Microsofts mobila OS lanserat 2010. Windows Phone använder en blandning av Silverlight, XNA, Visual Basic och C# som programmeringsspråk. Det är något som gör det svårt för utvecklare att börja med Windows Phone (delvis på grund av att framstående programmerare på senare tiden haft en tendens att undvika dessa programmeringsspråk)

Utveckling för Windows Phone är potentiellt stort men dess marknadsandel gör det idag svårt för företagsledare att rättfärdiga utveckling för den.

HP (och WebOS)

HPs mobila operativsystem heter WebOS, det köptes från Palm under 2010. HP WebOS är en “underdog” och ett mycket bra operativssystem men deras marknadsandel är nästan obefintlig. Sommaren 2011 lyckades HP lansera en läsplatta baserad på WebOS men den drogs bort från marknaden två månader senare.

I del 1 av denna bloggserie så pratade vi om att i takt med att mobilenheter ökar i popularitet pressas också organisationer att leverera bra mobila upplevelser i form av “appar” för smartphones och läsplattor, beslutsfattare ställs inför olika utmaningar:

Beslutsfattarens utmaning

För vilka mobila operativsystem bör vi utveckla vår app? iOS, Android, Windows Phone, WebOS? Hur många mobila operativsystem tillåter budgeten oss att utveckla för? Vad händer om min tjänsteleverantör bara utvecklar för en plattform?

Dessa frågor ställs i många svenska företag idag. Företagsledare vet att de borde “ha en app” (eller en programsvit) till sina kunder men det är väldigt lätt att sådana projekt får problem vid utförandet.

Problemet är att det finns många mobila operativsystem och majoriteten av tjänsteleverantörerna utvecklar bara för en plattform.

Detta har många företagsledare redan upplevt när de har startat ett app projekt utan att ha genomfört en ordentlig analys:

• Man upptäcker att ens tjänsteleverantör bara utvecklar för ett mobilt operativsystem.
• Kod utvecklad för iOS kommer inte att fungera på Android och vice versa.
• Man tvingas hantera flera tjänsteleverantörer vilket gör hanteringen av uppdateringar allt svårare

Varje punkt på denna lista kostar utvecklingstid och budgetpengar.

För att komplicera saken kommer organisationer som inte lyckas utöka sina apptjänster till flera mobila operativsystem med största sannolikhet få problem på marknaden.

Utvecklingsprocessen ur olika tidsperspektiv

Varför är det så komplicerat att framgångsrikt hantera och lansera ett apputvecklingsprojekt samt hitta en bra leverantör?

Det kortare svaret är att apputveckling är en komplicerad uppgift eftersom varje mobilt operativsystem kommer med sin egen uppsättning regler, programmeringsspråk, distributionskanal och typ av utvecklare.

Det finns stora skillnader mellan de olika plattformarna och deras utvecklare.

Denna klyfta är ingen tillfällighet, en utvecklare kan helt enkelt inte specialisera sig på alla plattformar.

I denna bloggserie kommer vi ta upp frågan om vilka mobila operativsystem en affärschef bör utveckla sitt appprojekt för och vilken typ av tjänsteleverantör som behövs för detta.

I takt med att mobilenheter ökar i popularitet pressas också organisationer att leverera bra mobila upplevelser i form av “appar” för smartphones och läsplattor. Mängden mobila operativsystem gör det svårt att välja rätt metod för applikation- sutveckling samt balansera en bra användarupplevelse för att nå maximalt antal enheter.

Med en mängd apparater på marknaden t.ex. iPhones, iPads, Androidtelefoner och läsplattor, Blackberry-telefoner och läsplattor, Windows-telefoner, HPs läsplattor, HTC och ZTE telefoner är det ingen överraskning att företagsledare känner sig osäkra vilka mobila operativsystem de borde fokusera på och vilken typ av utvecklare de behöver anlita.

Denna bloggserie vill förse beslutsfattare med baskunskaper inför beslutet av mobila operativsystem inför framtida app- projekt. Den går till slut in på varför en hybridstrategi i de flesta situationer är det bästa tillvägagångssättet.

Plats

Den gängse uppfattningen om vilka “vanliga” situationer mobila tjänster borde designas för brukar vara att tänka sig en jäktad individ som på gator och torg korsar folkmassor och trafik.

Det är i och för sig ett helt rimligt scenario, men faktum är att de ställen smartphones används är betydligt fler än så. 84% använder sin smartphone i hemmet. Att snabbt kolla mailen eller posta en bild på den senaste hemgjorda cupcaken på Instagram är ett betydligt vanligare scenario än “mobilen på stan”.

De flesta “mobila kontexter” har dock en sak gemensamt; det är inte så troligt att mobila digitala tjänster kan räkna med 100% av användarens uppmärksamhet.

Ett typiskt användningsmönster på mobilen är nämligen den att interaktionen sker med hjälp av “en hand och ett öga”. Man interagerar oftast med mobilen med enbart en hand och folks uppmärksamhet är oftast “partiell”, alltså fokuserad på flera saker samtidigt (i bankomatkön, under matlagning, tevetittande i soffan).

Mobila tjänster har därför mycket att vinna på om de designas i åtanke på det här, anpassade för att de så smidigt som möjligt kan användas i sådana situationer.

Tid

Olika enheter används under olika tider. Valet handlar ibland om ren närhet, den enhet som är närmast och som kan utföra jobbet används helt enkelt. Men det finns fall där olika typer av enheter är bättre lämpade att utföra specifika ärenden.

Följande graf visar hur folk använder sina iPhones för att läsa artiklar som de sparat för att läsa senare (Med hjälp av appen Read It Later). Man ser ganska snabbt att telefonen tas upp ur fickan för att användas i små och korta “bursts” (de höga topparna):

Appar och webappar som lyckas anpassa sig väl till detta typ av beteendemönster via ett gränssnitt som uppmuntrar snabba, aktuella och relevanta uppdateringar under dagen är väl positionerade för att utnyttja den mobila explosionen (tänk Instagram, Twitter et c.).

Tittar vi på samma graf fast för en iPad ser vi att den används intensivt på morgonen för att sedan användas relativt stabilt under dagen med merparten av användandet på kvällen i sängen:

Den logiska konklusionen är att appar som används på en iPad kan vara något mer komplexa i sin funktionalitet då den används under andra former än tex en iPhone.

Vänd begränsningarna till en fördel

Dessa begränsningar bör inte ses som något hämmande på designprocessen, snarare tvärtom. De ger oss klara fingervisningar på hur bättre mobila designlösningar kan skapas. Dessa begränsningar tvingar designers och utvecklare att börja tänka annorlunda på hur digitala tjänster egentligen används under dagens lopp. Dessa naturliga begränsningar är snarare möjligheter som hjälper oss att komma fram med innovativa lösningar.

Hur kan man på bästa sätt rivstarta processen att organisera och strukturera mobilappar?

Att bara föra över det som fungerade med din lösning för den stationära datorn till mobilen är oftast inte att rekommendera. Det är bättre att istället tänka på mobilens unika egenskaper, vad den är bra på och utefter det anpassa din lösning efter dina kunders behov.

Skillnaderna mellan PC’n och mobilen blir enklare att studera ur ett fågelperspektiv gemom att fokusera på hur och varför människor idag använder sina mobila enheter.

En bra utgångspunkt för starten av en analys för ditt nästa mobila projekt är Googles uppdelning av mobila användare i tre beteendemässiga grupper: “det omedelbara nuet”, “det upprepande nuet” samt “det uttråkade nuet”.

Dessa grupper kan även delas in i “Utförande av mikrouppgifter”, “Jag är lokal” och “Jag är uttråkad”. (Som Josh Clarke uttrycker det i Tapworthy).

Oavsett vilka namn du ger dessa beteenden består mobilanvändning oftast av ett par typer av interaktioner:

1. Slå upp/söka (omedelbar info/lokal info)
   Jag behöver få något besvarat genast, ofta i samband med min nuvarande geografiska position.
2. Utforska-spela (uttråkad/lokal info)
   Jag har lite död tid och behöver något som distraherar mig under en stund.
3. Incheckning-status (repetition/mikrouppgifter)
   Något som är viktigt för mig ändras eller uppdateras ständigt och det är nödvändigt för mig att hålla mig ajour om dess status.
4. Redigera-skapa (omedelbar förändring/mikrouppgifter)
   Jag måste få någonting gjort nu som inte kan vänta.

Som du säkert redan uppmärksammat så finns en direkt relation mellan dessa beteenden och varför en person väljer att ta upp sin smartphone från fickan.

Dessa beteenden är såpass inarbetade att de med fördel bör utnyttjas vid struktureringen och organisationen av mobilappar. På så sätt tillgodoser du de flesta människors behov.

—
Sliter du med definitionen av ett app-projekt? Kontakta oss på erik(at)plexical.com idag för att boka en timmes gratis konsulting.

I kölvattnet av mobilmässan i Barcelona där den “mobila webben” snabbt blev huvudtemat så vill vi ge några råd angående s.k HTML5 appar och hur företag och startups kan sätta dem i användning i sin mobila strategi.

För att klargöra (eftersom finns frågetecken på vad HTML5 appar verkligen är), med HTML5 appar så syftar man på appar som fungerar direkt i mobilens webbläsare utan att användaren behöver ladda ner appen på AppStore eller Android Market. En s.k “native” app är en applikation som laddas ner på en AppStore.

Är din tjänst/produkt beroende av en stark social komponent?

Ett problem för digitala tjänster och produkter som har en ansenlig mängd “viral” trafik är att de inte alltid fungerar så bra för iTunes eller Android app stores då dessa butiker saknar sociala kanaler för att dela och upptäcka innehåll och appar.

För appar som till sin natur är sociala – såsom musik, foto-delning eller nyhetsmedia och som ännu inte kommit till den punkt där de skapar ett betydande kassaflöde, är sålunda en HTML5-strategi, baserad på iOS inbyggda Twitter integration samt Facebooks mobila virala kanaler ett utmärkt första steg och vi vågar nog påstå även nödvändig.

De viktigaste överväganden ditt företag och dina utvecklare behöver ta hänsyn till när de fattar beslut om att utveckla HTML5, “native” eller båda, är alltså att förstå om din trafik är starkt beroende av e-post eller sociala nätverk.

Är så fallet är en HTML5 app ett bra utgångsläge.

Om din digitala produkt eller tjänst å andra sidan förlitar sig på direkt trafik eller om ditt företag har råd att satsa på att betala för användaranskaffning, kan det vara vettigt att som utgångsläge satsa på “native” utveckling för iOS eller Android.

Att ditt företag startar med HTML5 appar behöver nödvändigtvis inte betyda att du lämnar “native” utveckling helt åt sidan. Många appar med en stark “social” komponent använder sig av en kombinerad strategi där man lanserar HTML5 appar för helt nya kunder och “native” apps för de mest lojala användarna.

Det finns givetvis en mängd andra aspekter för ditt företag att ta hänsyn till oavsett om det gäller utveckling av HTML5 appar, “native” appar eller hybridappar.