Realdania, In2media og Greener Pastures har stået for konceptet, In2media har designet, Oxygen Software har udviklet API’et og vi har lavet iOS og Android-koden og Realdania har projektledet og samlet trådene.

Målet med appen er at kommunikere hvilke projekter Realdania støtter, vise fremdriften på de aktive projekter og give et indblik i Realdanias virke og effekt.

Konceptet er bygget op omkring det meget visuelle univers, som Realdania befinder sig i kombineret med en geografisk repræsentation. Dette kommer f.eks. til udtryk i oversigten over projekter, der er lavet som en collage af billeder der hvert repræsenterer et projekt. Denne liste er sorteret geografisk ud fra brugerens aktuelle position.

App skal på samme tid være inspirerende og lokal relevant. Samtidigt har vi tilstræbt at lave en så enkel og ligetil app – og forsøgt at undgå for mange knapper og funktionalitet. Mantraet har været: Vis billeder og undgå knapper.

Målgruppen for appen er først og fremmest alle de interessenter Realdania har kontakt med – arkitekter, politikere, medlemmer, ingeniører, involverede i projekterne – og i anden række den arkitektur- og byudviklings-interesserede bruger.

Appens styrke ligger især i det utroligt stærke billedmateriale som Realdania har og især synes vi at iPad-versionen fungerer godt.

Vurder selv resultatet – vi er slemt stolte af den her. Tjek den på iPhone eller iPad eller på Android eller via Realdanias campaign site om appen.

Målgruppen for BiQ er professionelle brugere der har brug for præcise og opdaterede erhvervsdata i deres daglige virke.

Vil du prøve appen skal du have et abonnement BiQ. Dette kan heldigvis fåes gratis på prøve.

BiQ appen er et godt eksempel på at eksisterende data kan bruges i nye sammenhænge eller i nye situationer – og på den måde supplere eksisterende eller skabe nye services.

Bedøm selv: hent iPhone versionen eller Android versionen.

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.

Grunden til at Apple – og Google og Microsoft for den sags skyld – afviser apps er først og fremmest, at de ønsker, at apps ikke crasher eller kompromiterer brugernes data. Derudover ønsker de, at brugerne på netop deres platform får den bedste brugeroplevelse. Og så er der også en række hensyn til deres forretning, der også spiller ind.

Vi har fået afvist – men altid senere godkendt – en række apps. Så vi holder selvfølgelig øje med, hvad der kan være en årsag til at apps bliver afvist. I den danske debat er der mest fokuseret på, hvorfor Ekstrabladets og Peter Øvigs Hippie får afvist apps og e-bøger pga. amerikansk moral i forhold til nøgenbilleder. I praksis er det typisk helt andre grunde, der gør ,at Apple afviser apps.

Her er en liste over de mere typiske grunde til afvisninger:

Crashes
Hvis der opstår fejl, som får appen til at gå ned, vil den blive afvist. For eksempel blev der i iOS 6 ændret en hel del. Og hvis man så laver en lille rettelse i en app, der allerede er frigivet til iOS 5, men ikke tjekker den helt igennem på iOS 6, kan den gå ned, og så bliver den afvist.

Brug af andres logoer og trademarked materiale
Hvis en app bruger andre virksomheders logoer eller andet varemærkebeskyttet materiale uden, at ejerne af disse varemærker har givet lov til dette, så vil appen blive afvist.

Manglende kreditering af data
En af de første afvisninger vi oplevede, var en kort-app, der brugte Google Maps. Her havde vi lavet et fint halvgennemsigtigt panel der i visse situationer kom op og delvist dækkede bunden af kortet. Men det dækkede også delvist Googles logo. Afvist.

Forkert brug af ikoner
Hvis man bruger visse standardkomponenter – fx deling – så skal man bruge de ikoner, der findes i standardkomponenten. Hvis man fx ændrer udseendet af Facebook-knappen, så vil appen blive afvist.

Ugyldig brug af lagring
Med iOS 5.1 kunne apps bruge iCloud til backup. Ideen er, at brugeren kan bruge en iPad eller en iPhone uden en computer og stadig have en fornuftig backup-løsning. Derfor har Apple sat nogle begrænsninger op i forhold til, hvor store mængder data en app må opbevare i de dele af apps, der automatisk bliver backup’et.

Forkert brug af keyboards
I iOS kan der bruges forskellige keyboards i inputfelter (numerisk, URL-tastatur eller almindeligt tastatur). Hvis man bruger et almindeligt tastatur i et felt, hvor man kan kan indtaste tal, kan appen blive afvist.

App-ikoner der lægger sig meget tæt op ad andre (kendte) ikoner
En sikker måde at få afvist en app på er at snuppe app-ikonet fra Safari eller Mail, ændre et par pixels og så sende appen til godkendelse. Ligesom logoer så værner Apple om de enkelte apps identitet. Det gælder for andre store virksomheder som Facebook og Twitter – men det gælder bestemt også for Apples egne apps.

Overdreven brug af vibrator eller GPS
Både vibratoren og GPS’en kan bruge en del batteri. Hvis man fx laver et spil, hvor vibratoren konstant er aktiveret, så kan det blive afvist.

Beta, version 0.9 eller næsten færdig
Apple – i modsætning til Google – bryder sig ikke om beta-versioner eller software-produkter, der fremstilles som tests eller halvfærdige. Kalder man sin app for “Min Beta app v.0.9″, så er man helt sikker på, at den bliver afvist hos Apple.

Langsom starttid
iOS tillader ikke, at apps er over 15 sekunder om at starte. Så hvis man fx designer sin app sådan, at den viser et logo i 30 sekunder, eller henter en masse data, før den startes, så kan appen blive afvist.

Manglende håndtering af dårlige netværksforbindelse
Mange apps fungerer kun, hvis der er en netværksforbindelse til at hente data eller billeder eller andet. Hvis appen ikke på en pæn måde håndterer, at der ikke er nogen netværksforbindelse (eller en meget langsom én), vil appen blive afvist.

Rascistisk, pornografisk, nedsættende eller injurierende indhold
En af vores kollegaer i branchen fik afvist et spil, de havde arbejdet på længe, fordi der i beskrivelsen af spillet var begreber som i en dansk sammenhæng virkede helt uskyldige, men i en amerikansk kontekst var nedsættende. Apple vil afvise alle apps, der ikke lever op til hvad nogle betragter som politisk korrekt amerikanske standarder.

Kald til “private API’er”
Der er en masse funktioner, man som udvikler kan bruge, men som kun er til brug for Apples egen kode. Og selvom man godt kan bruge den slags “private API-kald”, så er det en sikker måde at få en app afvist på.
Som en kommentar til denne liste vil jeg nævne, at vi aldrig har måttet opgive at få en app godkendt. Alle apps vi har sendt til godkendelse er blevet godkendt. Apple er hurtig til at svare hvorfor de afviser og anviser altid en løsning. Som softwareudvikler kan vi godt savne “gamle dage”, hvor man smed et website på en server, og så var det publiceret. Men denne godkendelse er vilkårerne for at kunne komme ud på brugernes telefoner via de store App Stores. Og langt de fleste afvisninger er faktisk fornuftige og giver i sidste ende bedre apps til brugerne og en mere konsistent brugsoplevelse.

Ofte bliver vi spurgt, om Apple vil godkende en bestemt app eller en bestemt funktion i en app. Eller om vi kan garantere, at Apple vil godkende appen. Og svaret er, at det ikke er til at sige på forhånd. Og det hjælper heller ikke at spørge Apple, for svaret er altid “hvis appen overholder retningslinjerne for apps, så vil den blive godkendt”.
Så normalt er vores svar, “vi er ret sikre på, at den vil blive godkendt, men vi kan aldrig være 100% sikre”.

Hent den i App Store her.

Noget af det vigtigste for FDB er, at nå deres medlemmer der hvor medlemmerne er. Derfor har FDB udvidet deres madunivers, Vi skal spise!, med en iPad-version der passer perfekt til både køkkenet og sofaen.

Appen har alle de 5.000 opskrifter med billeder som findes på Vi skal spise! og den skulle gerne være superlet at gå til. I forhold til websitet har udfordringen være at lave en enklere og mere magasin-agtig version af universet. Overskriften for projektet har været “Inspiration” – og de to situationer appen skal understøtte er madlavning i køkkenet og planlægning i sofaen.

Vi har bistået med koncept, design og kode – og FDB har været med hele vejen.

Appen er gratis og der skulle være masser af inspiration at hente til alle. Appen kan hentes på Apple App Store.

I fredags holdt den danske App-branche fest – og fejrede sig selv og branchens kunder ved at uddele priser til kunder og hinanden.

Vi er slemt glade over at to af vores kunder kunne tage en pris med hjem den aften. De to apps var:

• GoCook for FDB – der vandt kategorien “Best app – Science and Education”.
• Radio24syv – der vandt kategorien “Best app – Reading and News”.

Vi er selvfølgelig glade og stolte for denne lille anerkendelse. Begge projekter har været gode projekter med gode samarbejdspartnere og forhåbentlig også en masse glade brugere.

Vi er selvfølgelig glade for at fem apps vi har været med til at udvikle er nomineret til en pris. Det er bl.a.:

• GoCook for FDB
• mitNykredit (endnu ikke releaset)
• Radio24syv
• Børn i byen
• 

Holdbarhed trækker på data fra viskalspise.dk. Vi har stået for koncept, design og kode sammen med FDB og Thorbjørn König.

Holdbarhed er i den grad et eksempel på en KISS-app – der gør een ting og gør den godt. Holdbarhed indeholder informationer om hvordan man opbevarer madvarer så de holder sig længst og bedst muligt. Databasen i app’en har informationer om ca. 600 madvarer og bliver løbende opdateret og udvidet. Det unikke og gode ved Holdbarhed er selvfølgelig det indhold som FDBs ernæringseksperter har lagt i systemet og kvaliteten af dette. App’en er designet så teknikken er så diskret som muligt og ikke står i vejen for indholdet.

DR, Elektronista, Samvirke og mange flere har også opdaget Holdbarhed - og det er selvfølgelig derfor app’en har fået sådan en god start i App Store.

FDB har valgt at kickstarte kampagnen ved at smide en reklame for Android og iPhone app’en bag på alle mælkekartoner i denne uge. Vi elsker når vores kunder markedsfører deres apps – så vi er selvfølgelig pænt glade for FDBs lille tiltag her.

Hent selv app’en til dig eller din teenager til iPhone eller Android - udover opskrifter med indbyggede timere, er der en fin kokkeskole med gode videoer hvor vi sikkert alle kan lære et trick eller to.

Vi har udviklet apps og Reload har stået for website og API.

I dag lancerer Robocat og BLIND spillet 101 Airborne. Vi har fulgt processen tæt – hørt om problemerne med spil-frameworks og amerikanske standarder for godkendelse og hvad der nu ellers er af små udfordringer i sådant et projekt.

Men nu er det her – og hvor er det dog fedt.

Så vi vil da lige sende lidt god karma i Robocats retning og håber at spillet bliver en succes.

Men for Android-klienten valgte TimeLog at lægge designet op ad de anbefalinger og best practices, som er for Android apps. Resultatet skiller sig en del ud fra TimeLogs andre produkter. Til gengæld er der en række fordele ved at “arbejde med” og ikke “mod” platformen.

De fordele jeg ser, er:

• Resulatet fremstår som mere “naturligt” på Android-platformen
• Brugerne har nemmere ved at afkode og anvende app’en
• App’en er mere fremtidssikret i forhold til opdateringer af Android OS’et
• Fordi designet stort set udelukkende benytter standardkomponenter har app’en fået en del features “forærende” – og det har været nemmere at indbygge f.eks. swipe og long-press – som gør app’en mere brugervenlig
• Samtidigt fremstår TimeLogs designlinje alligevel stærkt ved at logo mv. er blevet indarbejdet i app’en på

Pointen er simpel: Man får mere app for pengene, hvis man designer med – og ikke mod – en platforms logik og best practice. For at kunne gøre dette er det en forudsætning at især den grafiske designer investerer noget tid i at læse om og forstå hvordan platformen fungerer. Vi møder mange grafikere der har masser af erfaringer og holdninger til iOS-platformen – den samme viden og engagement er desværre ikke altid til stede i forhold til Android-platformen.

Det er TimeLogs grafiker, Anders Brandstrup, der har stået for designet – og Anders og Greener Pastures har lavet IA og wireframes sammen.

Nedenfor er vist et par skærmbilleder fra Android app’en – så kan du selv vurdere resultatet – eller hente app’en fra Google Play:

MetroXpress har også opdaget app’en og har lavet en lille anmeldelse af den.  Hvis du selv har børn så kan app’en varmt anbefales – jeg har allerede brugt den en del denne sommer.

App’en kan hentes fra App Store - og hvis du kan lide den er jeg sikker på, at Børn i byen vil blive glade for et par gode reviews.

For Dansk Sprognævn udviklede vi i foråret en lille app, Sproghælp. Sproghjælp er en samling huskesedler, der giver et overblik over de typiske problemer danskerne har med grammatik og retskrivning.

Den primære målgruppe er skoleelever – men app’en er vist også relevant for de fleste af os der forlod skolen for mange år siden.

Dansk Sproghjælp releasede Sproghjælp lidt over en uge siden – og app’en lå fra første dag på App Store’s top-10 og nåede i dag førstepladsen. App’en får tillige fine brugeranmeldelser på både Google Play og App Store. Det betyder selvfølgelig, at der er rigtig mange der henter app’en og rigtig mange der er glade for den.

Det er vi selvfølgelig glade for – og det er Sprognævnet garanteret også.

Jeg tror at en af grundene til at app’en er vellykket er, at den rammer en “situation” helt rigtigt: når man er i gang med at skrive en tekst og er i tvivl om, om det hedder “hans” eller “sin” eller hvordan er det nu lige med sammensatte engelske ord i en dansk tekst – så giver Sproghælp svaret. Den er hurtig at bruge, overskuelig og der er ingen ekstra features eller støj af nogen art.

Samtidig er Dansk Sprognævns timing god i forhold til at release app’en. Delvist er releasen koordineret med skolestart. Det skaber selvfølgelig øget fokus på området – både fra brugere og medier. Derudover er august en rolig måned på App-markedet (intet OL, ingen jule-spil, udviklerne er ikke rigtigt kommet i gang efter sommerferien). Derfor er det lettere for en ny app at komme op på Top-10 og derved lettere at få ekstra opmærksomhed om app’en.

Vurder selv – hent Sproghælp via Apple AppStore eller Google Play.

Vi er på udkig efter en ny udvikler, der:
- Allerede har sendt et par apps på Google Play
- Kender Android-platformen
- Kan køre selv
- Er dus med teknologier som Android Support Library, Google GSON, Google Guava, Google Maps API
- Har erfaring med SCRUM

Du vil skulle indgå i et team af seniorudviklere, som stort set kun udvikler apps til iOS og Android.

Send en email til info@greenerpastures.dk med dit CV og links til dine apps, hvis du er interesseret.

• En eksisterende server-komponent har værdifulde data
• For at kunne eksponere data fra server-komponenten, udvikles der et API
• App’en henter data via API’et og viser disse på mobiltelefonen – gerne på en ny og frisk måde
• Ofte kombineres data fra server-komponenten med andre data eller andre services, så der skabes en helt ny service tilpasset en mobil kontekst

I mange af disse projekter skal API’et udvikles eller der eksisterer allerede et halvfærdigt API, som skal justeres og gøres klart.

Udviklingen eller opdateringen af API’et gøres alt for ofte til et rent teknisk spørgsmål – skal API’et laves som REST eller SOAP? Skal det anvende JSON eller XML? Disse spørgsmål er bestemt relevante og vigtige.

Men, de vigtige spørgsmål om hvilke forretningsmuligheder API’et kan åbne op for, hvordan laves API’et på en måde så det reelt kan genbruges stilles ofte ikke.

Min erfaring er, at der spildes mange penge og mange muligheder, fordi der laves dårlige, ikke-gennemtænkte og ikke-dokumenterede API’er. Fordi det er svært for ikke-teknikere at tjekke et API og svært at forstå det, så overlades API’et fuldstændigt til teknikere. Og fordi det mærkeligt nok tit er lav-status at udvikle API’er, så er det ofte ”den nye mand” eller junior-udviklere der laver API-opgaverne. Resultatet er dårlig kvalitet, manglende forretningsforståelse og spild af forretningsmuligheder.

Det lyder måske banalt – men min erfaring er, at API’et både nedprioriteres og at dets reelle værdi ikke forståes. Der er selvfølgelig undtagelser – men vi ser fere dårlige API’er end gode.

Var jeg projektleder eller forretningsudvikler i en større organisation ville jeg sikre mig, at følgende spørgsmål blev stillet inden man satte en udvikler i gang med at kode og dokumentere:

1. Skal der udvikles et API der senere kan genbruges?
2. Hvordan skal API’et dokumenteres, så det reelt kan anvendes af 3. part?
3. Vil det være en fordel at gøre API’et åbent eller lukket?
4. Hvilke services eller data er relevante? Kan vi forudsige kommende services?
5. Et API er en ”kontrakt” mellem forskellige IT-systemer – hvordan sikrer vi at vi overholder denne ”kontrakt”?
6. Hvordan tjekker man som ikke-tekniker et API?

Lad os tage spørgsmålene et ad gangen:

1. Skal der udvikles et API der kan genbruges senere?

Et APIs funktion er at eksponere data eller services, så andre IT-systemer kan anvende disse data eller services på en enkel og sikker måde uden at skulle kende til de bagvedliggende systemer.

Lad os sige vi har en virksomhed der driver togdrift og vi er ved at lave et API, der kan eksponere data om køreplaner og forsinkelser. Vil det senere være relevant at eksponere disse data i andre IT-systemer? Vil vi måske skulle lave notifikations-services, vise køreplaner på elektroniske tavler eller på anden vis offentliggøre disse? Svaret på disse spørgsmål er uomtvisteligt ja. Derfor skal der selvfølgelig udvikles et API der kan genbruges senere.

Skal API’et kunne genbruges til andre projekter, skal det selvfølgelig dokumenteres og det skal kodes på en måde, så det kan anvendes uden at man har viden om interne systemer og terminologier etc.

Det er klart at det øger udviklingsomkostninger en smule at lave et generelt API. Men, det er minimalt i forhold til hvad der alligevel skulle investeres.

2. Hvordan dokumenterer vi et API, så det reelt kan anvendes af 3. part?

I 4 ud af 5 API’er vi har arbejdet med det sidste år, har den eneste dokumentation været en url og måske et kodeeksempel. Så, en god start er lave noget dokumentation. Næste udfordring er, at dokumentationen skal være skrevet til eksterne programmører. Ofte er navngivning og forklaringer indadvendt – forstået på den måde at API’et fortsætter med at bruge serversystemet termininologi og kontekst. Dette giver bare sjældent mening set udefra.

Et andet problem vi nogle gange møder er, at dokumentationen er et 400 siders langt dokument. Hvis man siddder med et lille 80 timers projekt – så kan det virke en smule overvældende.

Den dokumentation vi foretrækker er når dokumentationen er lavet som et lille website med små kodeeksempler og forklaringer. Vi har lavet en lille opave baseret på data fra Google Analytics Reporting Engine – og deres dokumentation er forbilledlig: https://developers.google.com/analytics/devguides/reporting/core/v3/

De typiske problemer ved implementeringen og dokumentationen af API’er er:

• Der er ingen dokumentation eller forældet dokumentation
• Navngivningen er dårlig
• Navngivningen er baseret på det interne systems (legacy)-terminologi
• Forskellige services og feeds i det samme API bruger forskellige navne for de samme data
• Der anvendes dansk navngivning

3. Vil det være en fordel at gøre API’et åbent eller lukket for vores virksomhed?

Tager vi igen eksemplet med jernbaneselskabet – så er det oplagte svar ”ja”. Det er i selskabets interesse, at der er så mange services som muligt der integrere data om togafgange – så disse f.eks. vises sammen med tidsplaner for andre trafikformer, så de advarer kunderne om forsinkelser etc.

I nogle tilfælde er svaret selvfølgelig ”Nej”, hvis virksomheden igen lever af at sælge disse data. Men, igen kan det være en fordel at indbygge en generisk sikkerheds-model, så virksomheden kan begynde at sælge data via API’et til partnere.

Vores erfaring er, at langt de fleste virksomheder og organisationer har en interesse i at deres data bliver brugt og integreret i andre systemer. Derfor skal API’et være åbent.en det reelle værdi ikke forståes.’ styr på. Men, nu har jeg bare set fejlen en hel har finansieret. et godt API, så se lige DS

4. Hvilke services eller data er relevante? Kan vi realistisk forudsige kommende services?

Den er faktisk sværere. I eksemplet med togdriften er det ret oplagt – men det er ofte svært at forudsige hvilke data der er relevante i kommende projekter eller IT-systemer. Hvis det er svært vil det ofte være klogt at lade være med at forsøge, og kun eksponere præcist de data der skal bruges her og nu.

Men, det er helt sikkert, at det kræver reel domæneviden og forretningsforståelse for at kunne afgøre hvilke data og services der skal gøres tilgængelige. Så, hvis man sætter den senest ansatte programmør til at udvikle API’et – så kan vedkommende helt sikkert ikke afgøre hvad der formentligt bliver relevant.

5. Et API er en ”kontrakt” mellem forskellige IT-systemer – hvordan sikrer vi at vi overholder denne ”kontrakt”?

En anden typisk problemstilling er, at der er udviklet en app som trækker på data fra et API som en intern IT-afdeling har bygget. Et år senere holder app’en eller servicen op med at virke – fordi API’et er slukket, blevet ændret eller er flyttet til et nyt domæne. Med andre ord blev den ”kontrakt” som API’et er, ikke overholdt.

Det vigtigste er, at sikre sig hvem der har ansvaret for API’et. Hvem ved hvilke systemer der trækker på data fra API’et og hvem er ansvarlig for at API’et kører? På den måde er et API fuldstændigt ligesom et website eller en ydelse – der er nogen der skal ”eje” det”. Har virksomheden et overvågningssystem til sine websites er det oplagt at koble API’et på dette system, så det overvåges.

Dernæst skal der laves en plan for hvordan API’et opdateres og udvides. Den typiske løsning er, at man versionerer API’et, så man ved at f.eks. version 1.0 fortsætter med at fungere efter at version 1.1 er releaset.

6. Hvordan tjekker man som ikke-tekniker et API?

Som ikke-tekniker kan et API godt være svært at gennemskue. Men, i praksis er det faktisk ofte ret simpelt hvad det er der foregår. De fleste API’er vi arbejder med er åbne – og følger en helt simpel struktur:

1. App’en kalder API’et og efterspørger data
2. API’et sender data tilbage på struktureret form – typisk som XML eller JSON

Nogle gange laves der først et login, hvor API’et sender en ”Nøgle” tilbage. Og denne ”nøgle” bruges så ved alle kald.

I et enkelt REST API kan man kalde API’et direkt via et link. Prøv f.eks. at åbne følgende link i en browser: https://raw.github.com/currencybot/open-exchange-rates/master/latest.json.

Dette API returnerer en liste over valutakurser i forhold til US$ i JSON-formatet og kunne f.eks. bruges til at lave en simpel valutaomregner.

Prøv så at åbn websiden http://jsonformatter.curiousconcept.com/ og læg https://raw.github.com/currencybot/open-exchange-rates/master/latest.json ind i feltet “JSON data url” og klik på “Proces”. Nu formatteres JSON’en pænt – og det er tydeligt hvad der foregår.

Hvis det var din IT-afdeling der havde eksponerer centrale data for jeres virksomhed, vil du kunne tilgå data sådan.

Andre typer af API’er er “pakket ind”, så det er nemmere at arbejde med disse i udviklingsprocessen. Men, der er altid værktøjer, som kan åbne API’er – tjek med udviklingsafdelingen hvordan man kan gøre dette.

Morale – DSB har fattet det

Og for lige at komme med et eksempel på en organisation der virkelig har fået fuld valuta for at lave et godt API, så se lige DSBs fine DSB Labs: http://dsblabs.dk/webservices – og nyd hvor mange apps og services der trækker på API’et – http://dsblabs.dk/category/show/1281442209 – vel at mærke både apps og services som DSB har finansieret og apps og services som andre har finansieret.