All posts in Gode apps

Ta Cyklen Danmark - Greener Pastures

Tak for 1.208.221 cykelture

Nu afrundes den landsdækkende kampagne ‘Ta’ Cyklen Danmark’. Det betyder, at vi lukker Ta’ Cyklen-appen (en del af kampagnen) – og samtidig sender en stor tak til alle de seje cyklister, der har taget imod udfordringen.

Ta’ Cyklen appen – din personlige cykelcoach – blev til i samarbejde mellem Kræftens Bekæmpelse og Greener Pastures. Appen skulle få os til at vælge cyklen oftere på de korte strækninger. Målet var 10.000 downloads.
Læs videre…

coop medlem app shortlist dda 2017

Coop Medlem shortlistet til Danish Digital Award 2017

Greener Pastures har – i fællesskab med et engageret og kompetent team hos Coop og Hello Group – gentænkt og relanceret appen Coop Medlem. Coop Medlem er shortlistet til den digitale pris, DDA 2017.

Den nye medlems-app sætter fokus på de økonomiske medlemsfordele og gør det nemmere for Coops 1,6 millioner medlemmer at shoppe og forberede gode og sunde måltider.

Vi ser selv appen som en lille revolution for dagligvarehandelen.

Læs videre…

Sådan taler du om teknisk gæld med ikke-tekniske kolleger

Teknisk gæld er når man i forbindelse med udviklingen af et IT-system har valgt kortsigtede løsninger eller ikke har taget sig tid til at skabe en konsistent og sammenhængende løsning. Teknisk gæld kan også dække over at man ikke har fået opdateret eller udskiftet ældre IT-systemer og på den måde står med noget ubetalt gæld, når disse IT-systemer skal bruges i nye sammenhænge.

Udover at gæld altid er irriterende at have, så er det største problem ved teknisk gæld, at det er svært at få talt om uden for den tekniske organisation. Det kan ganske enkelt være svært for kolleger uden en teknisk baggrund at forstå, hvorfor et modul, der blev indkøbt for 5 år siden, nu pludselig gør alle nye indkøb tre gange så dyre, fordi man skal arbejde uden om den tekniske gæld. Eller hvorfor den kortsigtede hurtige løsning meget hurtigt kan blive et dyrt bekendtskab, når løsningen giver problemer på grund af manglende fleksibilitet eller dyrt vedligehold.

Læs videre…

UI lost in translation

Nogle designere er på udebane, når de arbejder med apps. De kommer især til kort, når de skal overlevere deres arbejde og beskrive alle for app-udviklingen relevante dele. Andre designere har helt styr på apps, men budgetter og deadlines afholder dem fra at komme i mål med specifikation og overlevering. Desværre er designspecifikationen noget af det første, der bliver droppet, når projektet er under pres. Sikkert fordi det ikke er noget kunden umiddelbart kan se værdien i.
Læs videre…

Soft launch – betyder det, at produktet ikke virker?

En soft launch er, når vi lægger en ny app live uden at der tændes for markedsføringen samtidig. Vi anbefaler stort set altid vores kunder at starte med en soft launch, fordi det er en mulighed for at sikre at alle integrationer fungerer live, og for at give mulighed for at lave de små justeringer der altid kommer, når appen møder de rigtige brugere.

En soft launch betyder ikke, at appen ikke er klar – det er den. Men det betyder at vi er realister. Vi ved, at med så komplekse og forretningskritiske produkter, som apps efterhånden er blevet, så er der altid noget der kan og skal justeres. Det kan være data, der skal hentes fra et andet system, der ikke er så rent som det datasæt vi brugte i udviklingsmiljøet, det kan være at hjælpeteksterne skal have en tur mere, eller noget helt tredje. Og det kan være, at det data vi får på rigtige brugeres brug af appen gør, at vi gerne vil lave ændringer. Læs videre…

Mine apps forstår mig ikke…

Vil du også gerne undgå at din app forsvinder i ligegyldighed – eller ligefrem bliver slettet? Andreas Klinke Johannsen har hjulpet flere af vores kunder med at sikre, at deres apps’ indhold, og især notifikationer, er relevante og rettidige for brugerne.

Andreas har skrevet et blogindlæg om sit forhold til sine apps. Enjoy.


App – vi er nødt til at tale sammen

Flere og flere af jer apps vil kommunikere med mig. Eller rettere: Flere og flere af jeres udgivere vil sende mig information, som de selv synes er interessant. Og det er ikke ligefrem fordi, jeg sidder og venter på den information. Læs videre…

Sådan designer man apps til store organisationer

At designe apps til store organisationer, handler grundlæggende om to ting: de svære fravalg, og hvordan man arbejder som et lille team i en stor organisation.

At lave tekniske udviklingsprojekter i store organisationer er svært
De fleste, der selv er en del af en stor organisation, kender udfordringerne, da de er de samme i alle prestigeprojekter. Og apps er fortsat et prestigeprojekt i langt de fleste organisationer.

Problemerne drejer sig ofte om tre temaer:

  1. App-projekterne har mange stakeholdere og ofte flere ejere, hvilket gør projektledelsen til noget, der skal køres af en erfaren person, og ønskelisten til funktionalitet lidt for lang
  2. Appen skal ofte løse adskillige forretningsmæssige problemer samtidig med, at man ønsker at det hele skal samles i en app og kan har svært ved at skære noget fra
  3. Der er lange beslutnings- og godkendelsesprocesser, hvilket ofte kombineres med konsensuskultur. Det betyder, at de svære beslutninger, der skal tages, ofte bliver taget for sent

Læs videre…

Det gode API

Vi har igennem de seneste 5 år udviklet 100+ apps til forskellige kunder. 90% af disse apps henter og gemmer data via et API. API’et er på den måde en hel central komponent for både appens udviklingsforløb, kvalitet og afgørende for appens performance.

API’et er bindeled mellem to organisationer og mellem to forskellige IT-systemer og måske også mellem to forskellige IT-teknologier. Derfor er udfordringer relateret til API’et det mest typiske problem i app-projekter.

Der er god økonomi i at lave et godt API fordi det sparer udviklingstid i app-udviklingen, det giver bedre apps og det giver færre fejl.

Vi har samlet 7 tips til hvordan skaber et godt API: Læs videre…

Typiske fejl virksomheder begår, når de skal lave apps

Det er nemt at kritisere, det ved vi godt. Men punkterne nedenfor kan undgås hvis man er opmærksom, så her er de alligevel: 8 fejl og faldgruber vi ser i projekter med forretningskritiske apps:

  1. Overvurderer datakvalitet
    Alt handler om data i disse dage, og langt de fleste virksomheder har adgang til data, der med fordel kan bruges i en app. Men kvaliteten af data, adgangen til den, og sikkerheden omkring data, overvurderes i rigtig mange tilfælde. Problemerne er både tekniske, at data enten ikke findes, ikke er tilgængelige eller ikke kan bindes sammen på den rigtige måde. Og problemerne er også datakvaliteten, hvor vi f.eks. ofte møder virksomheder der har data, som de efter en grundigere undersøgelse ikke kan udstille dataene offentligt før dataene er “vasket”.
  2. Afsenderorienteret app-koncept
    Vi ser stadig apps, hvis rationale er “hvad kan vi spare” eller “vi har noget information som vi gerne vil vise vores kunder”, i stedet for at finde ud af, hvilke brugssituationer brugerne har behov for.
  3. Overholder ikke interface-konventioner
    Naturligvis kan man blive forelsket i et kantet og anderledes design, men en brugeroplevelse i en app er meget afhængig af, at brugeren kan finde ud af at anvende appen. Og hvis man revolutionerer navigationen, så skal man vide, at man laver en enorm barriere for ens brugere og at det kan fordyre projektet.
  4. Kender ikke kundernes behov
    I mange organisationer har man oparbejdet en stor viden om ens kunder. Desværre er den ofte anekdotisk. Det er vigtigt at få talt med brugerne, så det behov man dækker med appen ikke er et stykke skrivebordsarbejde.
  5. IOS og Android skal være ens
    Konventionerne i interfacet i de to styresystemer er faktisk forskelligt. Og tit er argumentet for at lave de to apps ens, at man helst ikke vil supportere to forskellige oplevelser – hvilket igen er afsenderorienteret i forhold til at lave noget, der møder brugernes behov.
  6. Der er langt ind til hovedfunktionen i appen
    “Når nu vi har fat i kunden, så skal vi have en masse info fra dem” – sådan lyder det af og til. Men hvis der går for langt tid fra man åbner appen, til man får lov at gøre noget, få værdi, så forsvinder brugeren hurtigt igen.
  7. Samle-apps
    Det er fristende at samle alting i én app. Og i nogen tilfælde kan det godt give mening. Men de fleste brugere foretrækker en enkel brugeroplevelse, og har ikke det samme behov som virksomheden for at have alting samlet. Det er et lidt kontroversielt punkt, for i mange brugerundersøgelser hører man netop brugere sige, at de gerne vil have én app, der kan det hele. Men det matcher ikke det reelle brug og det er langt sværere at designe og udvikle store apps der løser en række problemer frem for apps der løser præcist et problem.

En god app er designet til brugeren, ikke til virksomheden

Et af de vigtigste spørgsmål i vores arbejde er, hvad en god app er. Det korte svar er, at en god app er designet til den bruger, der skal have den i hånden, ikke til den virksomhed der har sendt den på markedet.

Et godt app-projekt starter derfor ikke overraskende med, at man har gjort sit forarbejde grundigt. Hvilken målgruppe henvender man sig til, og hvilke mål har man med appen? Hvem skal bruge appen, i hvilken situation og præcis hvad skal den bruges til?

Mange virksomheder i Danmark er skarpe på, hvilke forretningsmæssige mål en app kan bidrage til at opnå, men er slet ikke skarpe nok på, i hvilken brugssituation de mål skal nås.

Læs videre…

Sådan briefer du dit app-bureau (i én sætning)

Tilblivelsen af en app starter for os på mange forskellige måder. Nogen af vores kunder og partnere har en grundig beskrivelse, en mockup og måske ligefrem et design klart allerede når de ringer til os. Andre har en skarp idé, som vi hjælper med at få gjort konkret.

Vi har lavet en formel for et rigtigt godt udgangspunkt for et brief:

Appen gør det muligt for Y at X, i situation Z

Et eksempel på et brief kunne være: “Netbank-appen gør det muligt for de unge kunder at tjekke deres saldo i bussen”.

Læs videre…

Thermo til Android – the simpler approach to weather

De sidste par måneder har vi arbejdet sammen med firmaet Robocat på at lave en Android-version af deres app, Thermo. Robocat står for design, koncept og markedsføring. Vi står for koden.

Under sloganet “Simpler approach to weather” lavede Robocat for nogle år siden iOS-versionen af Thermo. Thermo er et termometer der helt simpelt viser temperaturen udenfor, temperaturen igår og hvor koldt eller varmt det føles.

Thermos design er i den grad Skeuomorphism og bruger bl.a. elementer som glas, læder, træ og metal.

iOS-versionen af Thermo er blevet massivt downloadet og Thermo er gået fra at være en app til et lille univers med specielle delingsmuligheder, add-ons etc. Og der er nogle vilde udvidelser på vej.

Udfordringen i forhold til Android-versionen har været at konvertere iOS-designet, og især Skeumorphism-stilen, til Android. Derudover er iOS-designet meget baseret på “pixels” – og det passer rigtigt dårligt til Android-verdenens mange modeller og skærmstørrelser og standard GUI-elementer.

Resultatet er ude nu og vi er pænt stolte af denne app. Der er en del hjerteblod i det her projekt. Vi har ingen forventninger om at få dækket udviklingsomkostningerne, men det har været en fornøjelse at lave appen. Økonomien bag Thermo er en kombination af in-app purchase, add-ons og annoncer.

Men bedøm selv ved at hente Thermo fra Google Play. Og, vi vil som altid meget gerne have feedback hvis du har problemer med eller ønsker til appen.