CMBO Special Café bij Adobe gaf duidelijkheid over verscheidenheid ‘content-apps’ markt

Niemand weet precies hoe het maken van ‘content-apps’ er in de toekomst precies uit zal gaan zien. Afhankelijk van de wensen van ‘uitgevers’ kan op dit moment gekozen worden voor ‘in-app-content-apps’, een ‘web-app’ of een ‘serverbased-native-app’. De verschillen en overeenkomsten.

Drie soorten app ontwikkeltrajecten als voorlopig model voor uitgevers

Klik op de afbeelding voor vergrote weergave…..

De ‘in-app-content-apps’ worden gevoed vanuit een van oorsprong print gabaseerde workflow. Adobe heeft op dit gebied een aantal tools ontwikkeld, die aan InDesign vergaande mogelijkheden heeft toegevoegd om interactieve content toe te voegen aan de basis die aanvankelijk voor print was gemaakt. Klaasjan Tukker gaf daarbij duidelijk aan, dat de workflow niet inhoudt dat met één druk op de knop vanuit print een app wordt gemaakt: ‘De één op één conversie van print naar een iPad is zinloos en biedt geen enkele toegevoegde waarde’.
De ‘in-app-content-app’ is een volledige off-line werkende app, immers alle content wordt tijdens de download in de desbetreffende tablet geplaatst. Voordeel is dat de consument de inhoud zonder netwerkverbinding kan consumeren, er hoeft immers geen contact gemaakt te worden met een content management systeem. Nadeel kan een nogal lange download tijd zijn. Magazines met alle inhoud ‘aan boort’ worden al gauw tientallen MB’s groot.
De ‘in-app-content=apps’ zijn vooral bedoeld voor niet al te frequente uitgaven, waarbij de uitgever bepaalt wat de consument gaat consumeren, zowel redactioneel als commercieel.
De gehanteerde businessmodellen zijn doorgaans conventioneel, waarbij sommige uitgevers voor losse nummers vaak fors hoge prijzen vragen in vergelijking tot printedities daar zij de meerkosten van de interactiviteit doorberekenen aan de consument.
Adobe wil dit type apps zoveel mogelijk crossplatform aanbieden, dus met een eenmalige native reader en daarbinnen de content op basis van het door hun ontwikkelde .issue format.

Ten tweede bestaat de ‘web-app’, bij veel ontwikkelaars een onderwerp van discussie. Vooral de mogelijkheden van HTML5(*) staan daarbij centraal. Web-apps zijn websites die geschikt gemaakt worden voor consumptie op tablets. Ze draaien op basis van de standaard browser, die de bouwer in sommige gevallen onzichtbaar kan maken, zodat het erop lijkt alsof een native app draait. Een web-app vraagt een WIFI of 3G verbinding, daar de content gewoon vanaf een webserver wordt gedownload. Daarmee is de snelheid van de web-app dus afhankelijk van de kwaliteit van de data verbinding.
Web-apps hebben als voordeel dat ze niet, net zoals de ‘in-app-content-apps’ en de ‘serverbased-native-apps’ alleen via een ‘app-store’ kunnen worden gekocht of gedownload. Daar tegenover staat het nadeel dat ze niet op één centrale plek voor elk platform kunnen worden gezien. Het is immers een ‘gewone’ website, waarvan je zelf eerst het adres in de browser moet invoeren en daarna – afhankelijk van de mogelijkheiden – als web-app op je tablet kunt plaatsen.

(*) HTML5 apps kunnen ook als native apps worden gemaakt via PhoneGap

De derde mogelijkheid is de ‘serverbased-native-app’, zoals deze werd verduidelijkt door Jelle Prins van Moop.me. Met native wordt bedoeld dat de app is gemaakt met een voor het besturingssysteem bedoelde software ontwikkel omgeving (SDK – Sofware Development Kit). De ‘serverbased-native-app’ is in omvang doorgaans redelijk klein, omdat de – actuele! – content via een netwerk verbinding steeds van de server wordt gehaald. De ‘serverbased-native-app’ vraag net zoals bij web-apps, meestal om een werkende netwerk verbinding.
De ‘serverbased-native-app’ maakt het mogelijk om content aan te bieden op maat en dus op wens van de consument. Verschillende apps bieden de mogelijkheid een XML feed op te nemen of berichten met bijvoorbeeld koppeling naar twitter account met achterliggende artikelen. Dit vergt een nieuwe manier van denken van de uitgever. Immers titel , identiteit en journalistiek kunnen door de gebruiker volledig door elkaar worden gebruikt – al dan niet in combinatie met andere aanbieders.
Nadeel van de ‘serverbased-native-app’ is dat ze voor vrijwel elk besturingssysteem apart moeten worden ontwikkeld.

De eerste twee mogelijkheden zijn redelijkerwijs vanuit bestaande workflows (print en web) te maken en bieden snel de mogelijkheid content op tablets aan te bieden. De derde vergt meer inspanningen, maar biedt de voordelen van beide en geeft de consument meer controle over de eigen media consumptie. Uitgevers die thans keuzes maken, zullen wellicht de neiging hebben dat te doen op basis van hun huidige signatuur en identiteit. Maar inmiddels zijn er voldoende nieuwe initiatieven die apps ontwikkelen voor verschillende tablets, die nieuwe doelgroepen aanspreken die meer controle over hun eigen media consumptie willen hebben. Het is aan de uitgever om hier al dan niet vanuit diverse advertentie-, business-, communicatie- en distributiemodellen op te reageren.

Model gemaakt door nieuwsmarkt.nl

Apple is binnen iOS redelijk streng met het toelaten van apps. Zowel inhoudelijk als qua manier van programmeren. Anderzijds verandert Apple regelmatig de voorwaarden en versoepelt dan soms ook weer regels, die voorheen (extreem) streng waren. Bij de andere besturings systemen worden soepeler voorwaarden gehanteerd.