Hvis du vil høre lidt mere om den tekniske side af iPhone app-udvikling, så holder vi et seminar for SoftWorld d. 9. juni i København.
“The App Moment”
Når vi snakker med kunder, så bruger vi tit lang tid på at snakke om hvornår deres kunder anvender apps, i hvilke situationer apps er computeren overlegen, hvilken “mental tilstand” man skal forvente brugeren er i, når hun bruger apps på telefonen.
I fredags var jeg til en lille konference om App-markedet, hvor Jes Brinch fra e-conomic brugte termen “The App Moment” til netop at beskrive denne situation. (Jeg tror at Jes havde udtrykket fra en anden taler – men jeg fangede ikke lige hvem.)
Ikke alle apps rammer “The App Moment”, men jeg synes alligevel udtrykket er meget rammende.
“The app moment” er:
- Når man lige har ti minutter hvor man ikke skal noget
- I toget, i bussen, i venteværelset, når man venter på børnehavebussen
- Når man godt vil lege med sin telefon, men ikke gider åbne sin computer
- Når man godt vil underholdes
- Når man keder sig
Dette sætter nogle klare rammer for hvad der karakteriserer en god app:
- Den gør een ting, som den gør godt
- Den åbner hurtigt og leverer værdi med det samme
- App’en åbner den mest brugte funktion eller side med det samme – menuen gemmes som en valgmulighed
- Den har et enkelt og overskueligt brugerinterface, fordi man skal kunne bruge app’en i bussen, stående, med handsker på etc.
- Den følger standard GUI guidelines – fordi brugeren har ikke tid til at lære nye måder at gøre ting på
Der er en række apps, der ikke rammer “The App Moment” – f.eks Utilities, kort-baserede apps, transaktions-orienterede apps m.fl. Men, de samme designregler gælder typisk også for disse.
iPhone design – tips til webdesigneren
Noget der gælder for de fleste iPhone-projekter vi er involveret i er, at vi har en grafiker med, som ikke tidligere har lavet design til iPhone – men derimod har lavet masser af design til webløsninger.
Jeg er ikke grafiker – og bliver det heller aldrig – men der er en del spilleregler, formater og best-practices, som er anderledes ved iPhone-design end ved web-design. Her kommer en lille liste:
Sådan får du en app i AppStore
Et spørgsmål vi tit får via mail er: hvad skal man gøre for at få en app i AppStore. Derfor kommer der her en mini-guide til dette.
1. Apple-konto
Det første man skal gøre er, at tilmelde sig Apples iOS Developer Program. Ved at tilmelde sig dette program, bliver en virksomhed eller en person i stand til at udvikle, teste og distribuere apps til iPhone og iPad. Formentligt skal I kun distribuere apps, men det kan alligevel anbefales at gøre dette i eget navn. Delvist vil al omsætning gå direkte til virksomhedens bankkonto. Delvist vil virksomhedens navn og brand blive promoveret mere. Og hvis I har jeres egen konto, kan I selv trække data om antal downloads, ændre markedsføringstekster mv. Det koster $99 om året at være en del af Apples Developer Program.
Ny app: Ledernes lønstatistik
I slutningen af sidste år udviklede vi en app for Lederne – og denne blev frigivet for et par uger siden.
Læs hvad Lederne siger om app’en her eller se vores side om app’en her.
Greener Pastures skifter selskabsform
Per d. 1/1/2011 er firmaet Greener Pastures blevet omdannet til et Aps. For vores kunder og samarbejdspartnere har skiftet ingen betydning – ud over at vi også skifter bank og derved kontonummer. Vi har bare fået et par spørgsmål i denne sammenhæng – derfor denne blogpost.
Grunden til at vi vælger at skifte selskabsform er, at et anpartsselskab giver os forskellige nye muligheder for at vokse. Vi har også benyttet lejligheden til at få tilført en smule kapital til virksomheden. Vi er stadig den samme lille forretning og vores fokus er stadig 100% på app-udvikling. Vi er i gang med at brede vores fokus ud på app-udvikling på flere platforme – men bortset fra det kører vi videre præcist som hidtil.
Hvor mange har opgraderet til iOS 4?
Når man udvikler en applikation (uanset om det er til en mobiltelefon eller web eller noget helt andet), skal man fra starten have besluttet hvilke versioner af den pågældende platform, løsningen skal fungere på. Ideelt set skal løsningen naturligvis fungere på alle versioner af platformen, men jo flere versioner der skal understøttes, des længere tager det at udvikle.
Især kan der være features, som er meget simple at lave i nye versioner, men som er et sted mellem vanskelige og umulige at implementere i ændre versioner. Der er helt sikkert en del webudviklere, der har brugt massevis af timer og frustration på at få en enkelt lille ting til at fungere ordentligt i en gammel, obskur version af Internet Explorer…
Så det er altid en afvejning af udviklingstid versus antal brugere, der udelukkes. Når vi udvikler apps til iOS for tiden er spørgsmålet reelt “Version 4 og opefter eller version 3 og opefter?”. Og for at kunne besvare det, skal vi vide, hvor mange der har opgraderet til iOS 4. Denne artikel fra appadvice.com giver nogle tal:
| iOS version | % brugere |
|---|---|
| 4.x | 89,73% |
| 3.x | 10,25% |
| 2.x | 0,02% |
Som altid med den slags statistikker kan man ikke være sikker på, at det er repræsentativt for hele iOS-verdenen eller for Danmark eller for en bestemt type brugere. Men det er en udmærket indikation af, at langt de fleste har opgraderet til iOS 4 efterhånden.
App-udvikling – fra ide til færdig app
Med lidt over 20 app-projekter i bagagen begynder vi nu at have et klart billede af processen og best-practice for app-udvikling.
Vi har delt processen op i 11 faser. Størstelen af de apps vi har udviklet har fulgt nedenstående forløb.
Sådan bliver din app en succes
Vi har fornøjelsen af at tale med en del virksomheder og iværksættere om app-projekter. Det er blevet til en del gode projekter – men også en del projekter, der ikke er kommet ud over rampen.
Det mønster vi indtil nu kan se er, at at følgende fire forhold skal være på plads for at en app bliver en succes. Nogle af disse kan måske synes indlysende – f.eks. at der skal være en plan for markedsføringen af app’en – men alligevel er en sådan ofte helt fraværende.
Endelig: Dansk keyboard, ny mailklient og multitasking til iPad
Apple har her til aften releaset iOS version 4.2 til iPhone og iPad. Dette er en lille release for Apple, men alligevel en stor nyhed for udviklere til iOS-platforme – ikke mindst her i Danmark.
For det første følges OS-versionerne på iPhone, iPod Touch og iPad nu ad. Dette er en klar fordel, når man udvikler apps til disse. Især har det været et problem, at iPad har haltet bagefter.
For det andet får især iPad’en en række nye features – de vigtigste er formentligt multitasking, bedre mailklient og dansk tastatur.
Derudover indeholder iOS 4.2 nye features til både iPhone og iPad – print, nemmere medieafspiling, leje af film over nettet mm. Men – de store forbedringer ligger i at iPad endelig er oppe på 4.x.
Læs mere om iOS 4.2 her.
Gå-hjem-møde om mobile applikationer
Torsdag d. 11/11 holder Netmester et Gå-hjem-møde om mobile applikationer. Vi holder et oplæg om vores erfaringer fra de første 20 iPhone-projekter.
Se mere om mødet eller tilmeld dig her.
Stregkoder
I forbindelse med et oplæg til en lille app, hvor man skulle kunne få uddybende information om en virksomheds produkter, fik vi den idé at bruge produkternes stregkode til at identificere produktet.
Efter lidt research fandt vi to komponenter, man kan benytte i sine egne projekter:
- RedLaser – (download demo-app)
Er imponerende god til at genkende stregkoder, men også imponerende dyr (10% af prisen pr. app for betalte apps og minimum et par tusinde dollars for gratis apps.) - ZBar – (download demo-app)
Er næsten lige så god og hurtig (men ikke helt) som RedLaser. Og gratis.
Både RedLaser og ZBar understøtter både de almindelige “vare-stregkoder” (EAN-13 og EAN-8) og specialstregkoder (Code 128 og Code 39, som man typisk finder på print-selv-billetter og lignende) samt 2D-stregkoder (QR Codes, som typisk bruges til URL’er til mobile enheder) – og et par andre formater.
Bemærk, at ZBar kun fungerer med iPhone 4 eller iPhone 3Gs, mens RedLaser også fungerer på den ældre iPhone 3. RedLaser kræver iOS 4, men ZBar kan også køre på iPhone OS 3.1 (men iOS 4 anbefales).
Hvad kan man?
Man kan scanne en stregkode med iPhonens indbyggede kamera og få returneret “værdien”. Det vil sige de data, som stregkoden indeholder. For de almindelige stregkoder er det det tal, som står nedenunder stregkoden; for Code 128, Code 39 og QR Codes kan det være et tal eller en kort tekst.
Det nummer (eller tekst eller URL) kan man så bruge som en nøgle til at slå mere information op (produktnavn eller priser, hvis det er en vare eller hvilken som helst anden information, billeder eller film/lyd). Enten i en lokal database i app’en eller ved at spørge en server på nettet.
Hvordan gør man?
Man trykker på en knap, og så ser man billedet fra kameraet. Når man holder telefonen hen foran en stregkode og holder den stille et øjeblik, genkender app’en stregkoden og aflæser den og lukker kamera-vinduet. Det er ligegyldigt, om stregkoden vender på højkant eller på hovedet, men den skal selvfølgelig være nogenlunde tydelig.
Hvad kan man bruge det til?
Alt muligt!
Man kan for eksempel:
- scanne varer og sammenligne priser
- tjekke, om en vare indeholder noget, man er allergisk overfor
- finde opskrifter, den indeholder den pågældende vare
- scanne billetter med en stregkode og registrere dem som anvendt
- få mere information om et sted ud fra et skilt med en stregkode
- hente yderligere information om en vare
Hvor dyrt er det?
Ikke særlig dyrt. Hvis man bruger ZBar koster softwaren ikke noget, og det tager mindre end én dag at implementere en funktion til at scanne en stregkode og slå noget tilhørende information op i en database.
Slides fra morgenmøde om iPhone-udvikling
I dag holdt vi et indlæg på et morgenmøde hos DIS/PLAY om iPhoneudvikling og det danske app-marked.
Agendaen var:
- Smartphone-markedet i Danmark – 2010/2011
- Den gode app
- App-projekt vs. web-projekt
- Case
- Markedsføring af Apps
Se slides her:
API i “skyen” – Windows Azure i praksis
Til app’en Find Smiley bruger vi Microsofts cloud-løsning, Windows Azure, til at hente, behandle og tilgængeliggøre data. Selvom Windows Azure ikke direkte har noget med iPhone-udvikling at gøre – så er det alligevel relevant i denne blog, fordi stort set alle iPhone-projekter involverer et API.
(Et API er en adgang til data, som er målrettet udveksling af data mellem forskellige IT-systemer. F.eks. henter de fleste geo apps deres data over Internet via et API. Et API stiller på den måde data “til rådighed” for andre IT-systemer. Ved mange iPhone-projekter er det API’et der er den største tekniske udfordring. Læs mere API’er her.)
Udfordringen i forhold til Smiley app’en og dataene fra Fødevarestyrelsen var, at dataene ligger i en 32 MB stor fil, der ikke lige kunne sendes ud til en mobiltelefon og at adresserne ikke havde længdegrad/breddegrad.
Ideer og data efterlyses
Her hos Greener Pastures har vi kørende en løbende brainstorm om hvilke apps der kunne være interessant at udvikle til det danske eller det globale marked. Mange app-ideer ender ved at de kræver nogle specielle data – som ikke lige er offentligt tilgængelige.
Så – hvis du ligger inde med adgang til data der kunne være interessant for en iPhone app, hvis du har en god ide til en app eller måske dyb viden om et specielt domæne – så send en mail til info@greenerpastures.dk eller skriv en kommentar nedenfor. Hvem ved, det kunne være starten på et hyggeligt og givende samarbejde :-)
Det gode App-design
En af fornøjelserne ved at udvikle iPhone og iPad Apps er, at projekterne oftest er kortvarige og overskuelige. Oftest når vi gennem hele udviklingsforløbet på en måned eller to – fra ide til brugerfeedback. Hvis man som mig tidligere mest har arbejdet med Web Apps eller Windows Applikationer, så kommer man langt hurtigere ud over rampen med mobile Apps – og det er sundt i forhold til at blive klogere på App-design og på produktdesign generelt.
Vi har nu programmert ni iPhone Apps og her er et par løse betragtninger om hvad der er god og dårlig stil for godt App design.
Feel free to disagree. Læs videre…
Huskeliste til upload til App Store
Vi har efterhånden lavet en del iPhone-projekter, og udover selve applikationen er der en del følgeleveringer med til en release – også kaldet “Collateral”. Nogle gange står vi for disse leveringer – nogle gange står kunden for en del af disse.
Vi har lavet en lille huskeliste til disse colllaterals. Alle nedenstående delleveringer skal være på plads før en app kan uploades til Apples App Store.